[EXT] Re: [PATCH] USB: gadget: Add ID numbers to configfs-gadget driver names
Chanh Nguyen
chanh at amperemail.onmicrosoft.com
Thu Dec 15 20:08:06 AEDT 2022
On 14/12/2022 11:20, Frank Li wrote:
>>
>> Caution: EXT Email
>>
>> On 13/12/2022 14:22, Christophe JAILLET wrote:
>>> Le 13/12/2022 à 05:12, Chanh Nguyen a écrit :
>>>> 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 a ".N" suffix added to each
>>>> configfs_gadget's driver name (where N is a unique ID number),
>>>> thus making the names distinct.
>>>>
>>>> Fixes: fc274c1e9973 ("USB: gadget: Add a new bus for gadgets")
>>>> Signed-off-by: Chanh Nguyen
>>>> <chanh-shex6MNQR2J/SfDzf78azzKzEDxYleXD at public.gmane.org>
>>>> ---
>>>> drivers/usb/gadget/configfs.c | 42
>> +++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 42 insertions(+)
>>>>
>>>> diff --git a/drivers/usb/gadget/configfs.c
>>>> b/drivers/usb/gadget/configfs.c
>>>> index 96121d1c8df4..d8c5156ad777 100644
>>>> --- a/drivers/usb/gadget/configfs.c
>>>> +++ b/drivers/usb/gadget/configfs.c
>>>> @@ -3,6 +3,7 @@
>>>> #include <linux/module.h>
>>>> #include <linux/slab.h>
>>>> #include <linux/device.h>
>>>> +#include <linux/idr.h>
>>>> #include <linux/kstrtox.h>
>>>> #include <linux/nls.h>
>>>> #include <linux/usb/composite.h>
>>>> @@ -11,6 +12,16 @@
>>>> #include "u_f.h"
>>>> #include "u_os_desc.h"
>>>> +static DEFINE_IDA(driver_id_numbers);
>>>> +
>>>> +/*
>>>> + * Driver name has the form of "configfs-gadget.%d", where %d
>>>> + * is id allocated by ida_alloc(). The max value returns by
>>>> + * ida_alloc() is INT_MAX, in 64-bit system, it is about nine
>>>> + * quintillion: 19 digits in decimal. Set the max length to 35.
>>>> + */
>>>> +#define DRIVER_NAME_LENGTH_MAX 35
>>>
>>> Hi,
>>>
>>> if paranoiac, the final \0 seems to be missing in the max length
>>> computation, but see below.
>>
>> Thanks CJ! Indeed, I have missed that.
>>
>>>
>>>> +
>>>> int check_user_usb_string(const char *name,
>>>> struct usb_gadget_strings *stringtab_dev)
>>>> {
>>>> @@ -52,6 +63,9 @@ struct gadget_info {
>>>> char qw_sign[OS_STRING_QW_SIGN_LEN];
>>>> spinlock_t spinlock;
>>>> bool unbind;
>>>> +
>>>> + /* Make driver names unique */
>>>> + int driver_id_number;
>>>> };
>>>> static inline struct gadget_info *to_gadget_info(struct config_item
>>>> *item)
>>>> @@ -1582,6 +1596,8 @@ static struct config_group *gadgets_make(
>>>> const char *name)
>>>> {
>>>> struct gadget_info *gi;
>>>> + char *driver_name;
>>>> + int ret;
>>>> gi = kzalloc(sizeof(*gi), GFP_KERNEL);
>>>> if (!gi)
>>>> @@ -1623,6 +1639,21 @@ static struct config_group *gadgets_make(
>>>> gi->composite.gadget_driver = configfs_driver_template;
>>>> + ret = ida_alloc(&driver_id_numbers, GFP_KERNEL);
>>>> + if (ret < 0)
>>>> + goto err;
>>>> + gi->driver_id_number = ret;
>>>> +
>>>> + driver_name = kmalloc(DRIVER_NAME_LENGTH_MAX, GFP_KERNEL);
>>>> + if (!driver_name)
>>>> + goto out_free_driver_id_number;
>>>> +
>>>> + ret = scnprintf(driver_name, DRIVER_NAME_LENGTH_MAX,
>>>> + "configfs-gadget.%d", gi->driver_id_number);
>>>
>>>
>>> using kasprintf() looks simpler here.
>>> No need to kmalloc()+scnprintf(), and no need for
>> DRIVER_NAME_LENGTH_MAX.
>>>
>>> Just my 2c,
>>>
>>> CJ
>>
>> Thanks CJ for the review!
>>
>> I've made some changes as below (in gadgets_make() to remove
>> unnecessary
>> variables) and now trying to test it as much as possible. Will re-post
>> it as v2 if looks good soon.
>>
>> static inline struct gadget_info *to_gadget_info(struct config_item *item)
>> @@ -1623,13 +1629,25 @@ static struct config_group *gadgets_make(
>>
>> gi->composite.gadget_driver = configfs_driver_template;
>>
>> + gi->driver_id_number = ida_alloc(&driver_id_numbers, GFP_KERNEL);
>> + if (gi->driver_id_number < 0)
>> + goto err;
>> +
>> + gi->composite.gadget_driver.driver.name =
>> + kasprintf(GFP_KERNEL, "configfs-gadget.%d",
>> + gi->driver_id_number);
>> + if (!gi->composite.gadget_driver.driver.name)
>> + goto out_free_driver_id_number;
>> +
>> 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_id_number;
>>
>> return &gi->group;
>> +
>> +out_free_driver_id_number:
>> + ida_free(&driver_id_numbers, gi->driver_id_number);
>> err:
>> kfree(gi);
>> return ERR_PTR(-ENOMEM);
>>
>>
>>>
>>>> + if (ret < 0)
>>>> + goto out_free_driver_name;
>>>> +
>>>> + gi->composite.gadget_driver.driver.name = driver_name;
>>>> gi->composite.gadget_driver.function = kstrdup(name, GFP_KERNEL);
>>>> gi->composite.name = gi->composite.gadget_driver.function;
>>>> @@ -1630,6 +1661,11 @@ static struct config_group *gadgets_make(
>>>> goto err;
>>>> return &gi->group;
>>>> +
>>>> +out_free_driver_name:
>>>> + kfree(driver_name);
>>>> +out_free_driver_id_number:
>>>> + ida_free(&driver_id_numbers, gi->driver_id_number);
>>>> err:
>>>> kfree(gi);
>>>> return ERR_PTR(-ENOMEM);
>>>> @@ -1637,6 +1673,12 @@ static struct config_group *gadgets_make(
>>>> static void gadgets_drop(struct config_group *group, struct
>>>> config_item *item)
>>>> {
>>>> + struct gadget_info *gi = to_gadget_info(item);
>>>> +
>>>> + mutex_lock(&gi->lock);
>>>> + kfree(gi->composite.gadget_driver.driver.name);
>>>> + ida_free(&driver_id_numbers, gi->driver_id_number);
>>>> + mutex_unlock(&gi->lock);
>
> Move all free into gadget_info_attr_release(), just before kfree(gi)
> Driver.name and gi create at the same place,
> Free should be the same place also.
>
Thanks a lot for the quick review comment.
As per my observation through the test, on the first mount, the
virtual-media the gadgets_make() is called, then later, when unmount,
the gadgets_drop() is called and followed by gadget_info_attr_release().
The gadget_info_attr_release() is registered as .release() of
gadget_root_type for the gi->group via the call
"config_group_init_type_name(&gi->group, name, &gadget_root_type);"
In general, the .release() will be called only for the group. There is
nothing to guarantee that the group will always be registered, ie:
incase without the call to "config_group_init_type_name(&gi->group,
name, &gadget_root_type);"
In this patch, what is added is an ida number to be used to make up the
composite driver name. This is done in gadgets_make() so we'd like to
add the cleanup code to gadgets_drop() as they are registered together
in the same place and would be a little easier to read than adding them
to _release() as the code below:
static struct configfs_group_operations gadgets_ops = {
.make_group = &gadgets_make,
.drop_item = &gadgets_drop,
};
Anyway, we still doubt that there might be something that we have missed
so please let me know the reason why putting cleanup codes to _release()
would be a better solution.
Thank you and best regards,
- Chanh
>
>>>> config_item_put(item);
>>>> }
>>>
More information about the openbmc
mailing list