linux-kernel - Re: [PATCH] usb: udc: Add trace event for usb_gadget_set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKzKK0oyBomOOFGv4LHM18BgN8tS=Mcyok4gfq4q81vgk54iVA@mail.gmail.com>
Date: Thu, 11 Sep 2025 15:27:55 +0800
From: Kuen-Han Tsai <khtsai@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: royluo@...gle.com, jkeeping@...usicbrands.com, stern@...land.harvard.edu, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: udc: Add trace event for usb_gadget_set_state

Hi Greg,

On Sat, Sep 6, 2025 at 9:16 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Mon, Aug 18, 2025 at 04:27:19PM +0800, Kuen-Han Tsai wrote:
> > While the userspace program can be notified of gadget state changes,
> > timing issue can lead to missed transitions when reading the state
> > value.
> >
> > Introduce a trace event for usb_gadget_set_state to reliably track state
> > transitions.
> >
> > Signed-off-by: Kuen-Han Tsai <khtsai@...gle.com>
> > ---
> >  drivers/usb/gadget/udc/core.c  | 1 +
> >  drivers/usb/gadget/udc/trace.h | 5 +++++
> >  2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> > index d709e24c1fd4..e28fea614496 100644
> > --- a/drivers/usb/gadget/udc/core.c
> > +++ b/drivers/usb/gadget/udc/core.c
> > @@ -1125,6 +1125,7 @@ void usb_gadget_set_state(struct usb_gadget *gadget,
> >  {
> >       gadget->state = state;
> >       schedule_work(&gadget->work);
> > +     trace_usb_gadget_set_state(gadget, 0);
>
> Will this show the state the gadget has been set to?  And why not just
> do that in the work callback, as that is when it really happens.

Yes, it shows the new state by logging the state field from the gadget object.

The work callback is for handling asynchronous sysfs notifications
that occur later. Placing the tracepoint here accurately reflects when
the state change actually happens.

>
> What is the output of this trace line?
>

The output looks like

usb_gadget_set_state: speed 5/5 state 5 100mA
[sg:self-powered:activated:connected] --> 0
usb_gadget_set_state: speed 5/5 state 6 100mA
[sg:self-powered:activated:connected] --> 0
usb_gadget_set_state: speed 5/5 state 7 100mA
[sg:self-powered:activated:connected] --> 0
usb_gadget_set_state: speed 5/5 state 7 900mA
[sg:bus-powered:activated:connected] --> 0

Regards,
Kuen-Han