On Thu, Sep 19, 2024 at 08:03:37PM GMT, Łukasz Bartosik wrote: > On Thu, Sep 19, 2024 at 11:38 AM Heikki Krogerus > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > > > On Sun, Sep 15, 2024 at 12:08:45AM +0200, Łukasz Bartosik wrote: > > > On Wed, Sep 11, 2024 at 4:09 PM Heikki Krogerus > > > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > > > > > > > Hi, > > > > > > > > On Tue, Sep 10, 2024 at 10:15:25AM +0000, Łukasz Bartosik wrote: > > > > > Add netlink to ChromeOS UCSI driver to allow forwarding > > > > > of UCSI messages to userspace for debugging and testing > > > > > purposes. > > > > > > > > Why does this need to be cros_ec specific? > > > > > > > > > > You're right. Netlink does not have to be cros_ec_ucsi specific. > > > Would you like to have netlink in typec_ucsi ? > > > > Does it need to be netlink? We would then have tracepoints, the > > custom debugfs interface, and this netlink interface. > > > > I think this information could be exposed via trancepoints (unless I'm > > missing something). > > > > Hi Heikki, > > I agree that there is a common area which is covered by both trace > events and netlink. > However netlink also has advantages which IMHO trace events lack. One > of our cases is that > from userspace it is easy to forward the UCSI messages to a Wireshark > with a plugin > which can decode it. Another case is to use UCSI forwarded messages > through netlink > for testing and validation of chromebooks. > > How about leaving netlink specific to cros_ec_ucsi driver ? Would you > consent to that ? I think having it specific to cros_ec_ucsi is the worst option out of three. It should either be generified to work with all UCSI drivers or go away and be replaced by tracepoints (against, generic to all UCSI drivers) or some other mechanism (e.g. TCPM has rolling log of messages). -- With best wishes Dmitry
