Re: [PATCH v1 0/2] usb: gadget: udc: simplify lock holding using guards

[lihuisong (C)]

On 4/20/2026 2:30 PM, Greg KH wrote:
> On Mon, Apr 20, 2026 at 02:21:01PM +0800, lihuisong (C) wrote:
> > On 4/20/2026 1:40 PM, Greg KH wrote:
> > > On Mon, Apr 20, 2026 at 11:57:20AM +0800, Huisong Li wrote:
> > > > Simplify udc_lock and connect_lock holding using guards in
> > > > gadget_bind_driver() and gadget_unbind_driver().
> > > >
> > > > Huisong Li (2):
> > > >     usb: gadget: udc: simplify udc_lock holding using guards
> > > >     usb: gadget: udc: simplify connect_lock holding using guards
> > > >
> > > >    drivers/usb/gadget/udc/core.c | 77 ++++++++++++++++-------------------
> > > >    1 file changed, 35 insertions(+), 42 deletions(-)
> > > Only do this for new drivers, don't convert existing code that works
> > > just fine for no valid reason other than wanting to clean stuff up.
> > >
> > > Does this fix a bug?
> > Here not to fix a bug. But prepare for fixing a bug in link[1].
> > I found that there are many unlock of udc_lock in error path after that
> > patch.
> > So use the guard to simpliy them by the way.
> >
> > [1]https://patchwork.kernel.org/project/linux-usb/patch/20260420040223.1232745-1-lihuisong@xxxxxxxxxx/
> So those patches must be applied in order?  That was not obvious and I
> would have gotten them wrong :(
That patch in the link is not modified based on this series.
I originally thought that I would update that patch after this series is 
merged (because there are not functional changes).
I will drop this series if accept the unlock on multiple error path.
> The policy of these guard usages is not to add them just to "clean up"
> the code, only use them to actually fix real bugs today, or in new code.
> Otherwise the churn in the kernel tree would be huge for no valid
> reason, and cause even more bugs with backports than this pattern causes
> today.
got it.