Re: [PATCH v4] usb: gadget: storage_common: make FSG_NUM_BUFFERSvariable size

From: Per Forlin
Date: Fri Aug 19 2011 - 07:42:16 EST


2011/8/19 Michal Nazarewicz <mina86@xxxxxxxxxx>:
> On Fri, 19 Aug 2011 10:39:24 +0200, Per Forlin <per.forlin@xxxxxxxxxx>
> wrote:
>
>> 2011/8/18 Michal Nazarewicz <mina86@xxxxxxxxxx>:
>>>
>>> On Thu, 18 Aug 2011 11:28:46 +0200, Per Forlin wrote:
>>>>
>>>> diff --git a/drivers/usb/gadget/f_mass_storage.c
>>>> b/drivers/usb/gadget/f_mass_storage.c
>>>> index 5b93395..3e546d9 100644
>>>> --- a/drivers/usb/gadget/f_mass_storage.c
>>>> +++ b/drivers/usb/gadget/f_mass_storage.c
>>>> @@ -363,7 +363,6 @@ struct fsg_common {
>>>>       struct fsg_buffhd       *next_buffhd_to_fill;
>>>>       struct fsg_buffhd       *next_buffhd_to_drain;
>>>> -       struct fsg_buffhd       buffhds[FSG_NUM_BUFFERS];
>>>>       int                     cmnd_size;
>>>>       u8                      cmnd[MAX_COMMAND_SIZE];
>>>> @@ -407,6 +406,8 @@ struct fsg_common {
>>>>       char inquiry_string[8 + 16 + 4 + 1];
>>>>       struct kref             ref;
>>>> +       /* Must be the last entry */
>>>> +       struct fsg_buffhd       buffhds[0];
>>>
>>> I would rather see it as “struct fsg_buffhd *buffhds;” since this change
>>> requires both mass_storage.c and multi.c to be changed.
>>>
>> If the allocation of buffhds is done separately in fsg_common_init().
>> mass_storage.c and multi.c doesn't need to be changed. But it's little
>> tricky to know whether buffhds should be allocated or not.
>
> They should be always allocated.  If the code allocate fsg_common itself,
> the
> case is obvious.  If caller passes a pointer to fsg_common structure, it is
> assumed that the structure is not initialised, thus the function need to
> allocate buffers.
>
Is it true that fsg_common_init() will never be called twice to
initialise the same fsg_common structure. It is always called once
followed by release.
If this is the case it is safe to only:
if (common->buffhds)
common->buffhds = kzalloc()

Thanks,
Per
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/