[PATCH v3] USB: gadget: Add ID numbers to configfs-gadget driver names

[Andrzej Pietrasiewicz]

Hi,

W dniu 12.01.2023 o 09:33, Chanh Nguyen pisze:
> 
> 
> On 11/01/2023 16:46, Andrzej Pietrasiewicz wrote:
>> Hello,
>>
>> W dniu 11.01.2023 o 07:51, Chanh Nguyen pisze:
>>> It is unable to use configfs to attach more than one gadget. When
>>> attaching the second gadget, it always fails and the kernel message
>>> prints out:
>>>
>>> Error: Driver 'configfs-gadget' is already registered, aborting...
>>> UDC core: g1: driver registration failed: -16
>>>
>>> This commit fixes the problem by using the gadget name as a suffix
>>> to each configfs_gadget's driver name, thus making the names
>>> distinct.
>>>
>>> Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets")
>>> Signed-off-by: Chanh Nguyen <chanh at os.amperecomputing.com>
>>>
>>> ---
>>> Changes in v3:
>>>    - Use the gadget name as a unique suffix instead     [Andrzej]
>>>    - Remove the driver.name allocation by template        [Chanh]
>>>    - Update commit message                                [Chanh]
>>>
>>> Changes in v2:
>>>    - Replace scnprintf() by kasprintf() to simplify the code [CJ]
>>>    - Move the clean up code from gadgets_drop() to
>>>      gadget_info_attr_release()                        [Frank Li]
>>>    - Correct the resource free up in gadges_make()   [Alan Stern]
>>>    - Remove the unnecessary variable in gadgets_make()    [Chanh]
>>>    - Fixes minor grammar issue in commit message          [Chanh]
>>> ---
>>>   drivers/usb/gadget/configfs.c | 12 ++++++++++--
>>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>>> index 96121d1c8df4..0853536cbf2e 100644
>>> --- a/drivers/usb/gadget/configfs.c
>>> +++ b/drivers/usb/gadget/configfs.c
>>> @@ -393,6 +393,7 @@ static void gadget_info_attr_release(struct config_item 
>>> *item)
>>>       WARN_ON(!list_empty(&gi->string_list));
>>>       WARN_ON(!list_empty(&gi->available_func));
>>>       kfree(gi->composite.gadget_driver.function);
>>> +    kfree(gi->composite.gadget_driver.driver.name);
>>>       kfree(gi);
>>>   }
>>> @@ -1572,7 +1573,6 @@ static const struct usb_gadget_driver 
>>> configfs_driver_template = {
>>>       .max_speed    = USB_SPEED_SUPER_PLUS,
>>>       .driver = {
>>>           .owner          = THIS_MODULE,
>>> -        .name        = "configfs-gadget",
>>>       },
>>>       .match_existing_only = 1,
>>>   };
>>> @@ -1623,13 +1623,21 @@ static struct config_group *gadgets_make(
>>>       gi->composite.gadget_driver = configfs_driver_template;
>>> +    gi->composite.gadget_driver.driver.name = kasprintf(GFP_KERNEL,
>>> +                                "configfs-gadget.%s", name);
>>
>> This line is 88 chars long, which means you're taking advantage of checkpatch
>> allowing 100 columns nowadays. That's absolutely fine. If you collapse the above
>> two lines into one, the combined length is exactly 100 chars, so you might
>> just as well use a single line. In any case (collapsed or not) you can add my
>>
>> Reviewed-by: Andrzej Pietrasiewicz <andrzej.p at collabora.com>
>>
> 
> Thanks Andrzej for the review.
> 
> Just found out the commit title is not totally correct.
> It should be "usb: gadget: Append name as suffix to configfs-gadget driver names".
> 

Heh, good catch :D

"Append gadget name to configfs-gadget driver names?"

I'm not a native speaker, but to me "to append" is the opposite of "to prepend",
isn't it? So IMO "to append" already contains the notion of "adding at the end",
which is the same thing as a suffix. I also suggest it is better to qualify the
"name", it is not just any name, it is specifically a gadget name. If you only
insert the word "gadget" and don't remove "as suffix" then the title becomes
lengthy, hence my suggestion as above.

> I wonder if these issues could be fixed when get merged or should I resend a v4 
> with that two lines collapsed and with the title adjust?

If it is only about making the title better reflect patch contents and
whitespace changes I'd say it is ok to send a v4 with Reviewed-by and Tested-by
already added. Not making the maintainer think why there's no ID numbers is
a good thing. But then Greg's automaton might get confused if it sees a v4
without v1, 2 and 3 preceding it. I'm not sure how it reacts if you reply-to v3
with corrected title, either. On the flip side, if you send a new patch (without
any v number) in a new thread, you also make the maintainer think why the patch
already contains R-b and T-b, so...

Regards,

Andrzej

> 
> Thanks a lot,
> - Chanh
> 
>>> +    if (!gi->composite.gadget_driver.driver.name)
>>> +        goto err;
>>> +
>>>       gi->composite.gadget_driver.function = kstrdup(name, GFP_KERNEL);
>>>       gi->composite.name = gi->composite.gadget_driver.function;
>>>       if (!gi->composite.gadget_driver.function)
>>> -        goto err;
>>> +        goto out_free_driver_name;
>>>       return &gi->group;
>>> +
>>> +out_free_driver_name:
>>> +    kfree(gi->composite.gadget_driver.driver.name);
>>>   err:
>>>       kfree(gi);
>>>       return ERR_PTR(-ENOMEM);
>>