Messages in this thread Patch in this message | | | Subject | Re: [PATCH v4] usb: gadget: storage_common: make FSG_NUM_BUFFERS variable size | Date | Fri, 19 Aug 2011 12:45:04 +0200 | From | "Michal Nazarewicz" <> |
| |
On Fri, 19 Aug 2011 10:39:24 +0200, Per Forlin <per.forlin@linaro.org> wrote:
> 2011/8/18 Michal Nazarewicz <mina86@mina86.com>: >> 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.
-- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz (o o) ooo +-----<email/xmpp: mnazarewicz@google.com>-----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |