On Tue, May 15, 2012 at 08:42:14AM +0200, Andrzej Pietrasiewicz wrote: > Hello Greg, > > On Monday, May 14, 2012 6:29 PM Greg Kroah-Hartman wrote: > > <snip> > > > diff --git a/drivers/staging/ccg/Kconfig b/drivers/staging/ccg/Kconfig > > > new file mode 100644 > > > index 0000000..8015c74 > > > --- /dev/null > > > +++ b/drivers/staging/ccg/Kconfig > > > @@ -0,0 +1,8 @@ > > > +config USB_G_CCG > > > + tristate "Configurable Composite Gadget (EXPERIMENTAL)" > > > + depends on EXPERIMENTAL > > > > This needs to depend on STAGING, right? > > Right, thanks for pointing that out. > > > > > > --- a/drivers/usb/gadget/Kconfig > > > +++ b/drivers/usb/gadget/Kconfig > > > @@ -842,6 +842,8 @@ config USB_G_PRINTER > > > For more information, see Documentation/usb/gadget_printer.txt > > > which includes sample code for accessing the device file. > > > > > > +source "drivers/staging/ccg/Kconfig" > > > + > > > > Why are you including this here and not in drivers/staging/Kconfig? > > That is where it should be to show that this really is a staging driver. > > > > Ok, I know it is a hack. I should have said something about > it when I posted it. The hack is applied because of the way the usb gadget > driver is built, specially for the compiled-in case: during the kernel > configuration only one variant of the gadget (e.g. Gadget Zero, Mass > Storage, > Printer, Ethernet and so on), can be exclusively selected. > So I wanted the ccg (Configurable Composite Gadget) to be one of these > mutually-exclusive options while at the same place it in staging. > What do you think? this is only true for built-in linking, and that's because we miss the configfs-based binding. After that's done, we will allow everything to be built into the kernel and Gadget driver will be "generated" through configfs. -- balbi
Attachment:
signature.asc
Description: Digital signature
