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. > 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. > > > > > > > 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
Attachment:
signature.asc
Description: Digital signature
