On Thu, Apr 28, 2011 at 12:10:09PM -0400, Oleg Drokin wrote: > Hello! > > On Apr 28, 2011, at 2:14 AM, Mike Rapoport wrote: > >>>> +static struct omap_musb_board_data musb_board_data = { > >>>> + .interface_type = MUSB_INTERFACE_ULPI, > >>>> +#ifdef CONFIG_USB_MUSB_OTG > >>>> + .mode = MUSB_OTG, > >>>> +#elif defined(CONFIG_USB_MUSB_HDRC_HCD) > >>>> + .mode = MUSB_HOST, > >>>> +#elif defined(CONFIG_USB_GADGET_MUSB_HDRC) > >>>> + .mode = MUSB_PERIPHERAL, > >>>> +#endif > >>> This kind of ifdefery is handled inside the musb driver. I'd set the mode to > >>> MUSB_OTG unless you want to explicitly limit it to HOST or PERIPHERAL > >> Actually it's not. > >> If I set MUSB_OTG here and then I choose PERIPHERAL mode in the kernel config, > >> the musb transceiver code will complain about board file and kernel config mismatch. > >> The Nook Color is advertised as peripheral device, but OTG must be working too > >> (not totally working at this point) I think there is value to be able to configure it > >> in two different modes. > > Frankly, I haven't tried choosing different modes in the kernel config and in > > the board data. Still, I believe that board data should define desired operation > > mode and the driver should do the best effort to enable the controller in the > > desired mode. > > The desired operation mode is dependent on musb configuration. > E.g. see n8x0 board file for the example of the same thing. Only development platforms should have that ifdef trickery. The idea of that field is to tell the driver how the board is wired. Host/Peripheral/OTG support is hardwired by the circuitry around the USB receptacle you have on your board. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html