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(-)

-- 
2.33.0

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?

thanks,

greg k-h

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@huawei.com/

/Huisong

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@huawei.com/

So those patches must be applied in order?  That was not obvious and I
would have gotten them wrong :(

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.

thanks,

greg k-h

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@huawei.com/
> 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.