Hi, > On Wed, Oct 19, 2011 at 05:46:32PM +0530, Gupta, Ajay Kumar wrote: > > > > > > > which means that for a port which is host-only, it won't > > > > > > > require a gadget driver and for a port which is gadget-only, > > > > > > > it won't start host stack. > > > > > > > > > > > > If so then how about the menuconfig option for gadget driver > > > > > > for such host only port? Shouldn't the gadget driver option be > > > > > > unavailable for > > > > > such ports? > > > > > > > > > > how we can we change menuconfig for something which isn't > > > > > compile-time constant ? > > > > > > > > Yes, correct. So there will be option for selecting gadget module > > > > even when The port is host only and that would confuse the users. > > > > We would need to find a solution for this also. > > > > > > of course not mate. It's like saying we can't compile an i2c client > > > driver just because we didn't enable i2c-omap. It doesn't work that > way. > > > > Let me explain: > > I compile for omap3evm for a board which has a host only port. I use > > Omap3evm only defconfig and then go to drivers->USB support->Inventra. > > > > It would show OTG mode and go further below and you would see Gadget > > driver support which you *cannot* disable as the moment you Disable it > > Inventra option for host also will disappear. This will confuse Users > > and looks unnecessary for a board with HOST only ports. > > The controller is OTG-capable. Even if you say "on my board I only > support Host" that's just a lack of ID pin handling anyway. The > controller has been placed on Silicon with full support for Host and > Device modes. > > The choice I made few merge-windows ago was to drop all of that stupid > ifdeffery we had around host/gadget/otg support because the HW is > *always* OTG. This is fine. I don't see any issue in this but bringing in the confusing config options. > > > You point holds good for a multiconfig compile and if people are OK > > with this then no issue. > > why wouldn't they be ok ? It's not like there will be a gigantic amount > of extra code in the kernel. You also have to remember that building > always DRD support, allows for hacks like the Android Accessory > Framework even on an uncertified OTG device. Things are fine from driver wise but the concern in the way mecuconfig Would comeup in a single board config for boards with a host only musb port. Ajay > > > > > > > > > 3) Change musb driver so that there is no need for gadget > > > > > > > > driver for host only ports. (may be based on > > > > > > > > musb->board_mode > > > > > > > > ?) > > > > > > > > > > > > > > yes. > > > > > > > > > > > > Doesn't seem to be a cleaner way as explained above the issue > > > > > > of gadget Driver coming in menuconfig for such ports. > > > > > > > > > > you don't assign a port for a gadget driver. Ever. > > > > Yes, agree. But wouldn't it be confusing for a host only musb port > > > > showing gadget driver in menuconfig? > > > > > > why ? musb isn't the only gadget controller in the world. > > I meant in a single board config environment. > > there's no point in doing compile-time choices like that when we can > easily ask from the HW how it was configured and the HW will always say > it's OTG. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
