Felipe Balbi <balbi@xxxxxx> writes: > Hi, > > On Wed, Mar 20, 2013 at 03:37:01PM +0200, Alexander Shishkin wrote: >> >> dr_cap is what the device can actually do (host, peripheral, etc). Tells >> >> us which roles to initialize and wether we can access OTGSC on this >> >> device. >> >> dr_mode is what function of the device we'll be using on this particular >> >> board. >> > >> > Sorry, I don't get why the driver needs to know what the chipidea can do >> > in theory (dr_cap). IMHO it should be sufficient to tell the driver what >> > that exact hardware it runs on can do (dr_mode). What the hardware can >> > do depends on the actual chipidea implementation used in that SoC and >> > the board the SoC is soldered on. >> >> Again, see the discussion above. >> >> In real world products (that is, phones and tablets as opposed to jolly >> fun development boards), vendors will want to limit the usb >> functionality to peripheral only or host only or whatever, because the >> middleware stack can only do one thing or because they don't want to go >> through with otg certification or you name it. Meanwhile, the controller > > that's not entirely true. A manufacturer can decide to skip OTG > certification but still support Dual Role. Look at the whole Android > Accessory Kit, for example. Sure, I was just making an example of how device capabilities can differ from device's intended function. >> and the whole device can still support otg. And we need to know that if >> we're to try to detect vbus session, because that is done via OTGSC >> which is only available in otg configurations. > > well, if it's only available in OTG configurations, then you make the > same assumption in driver. If driver was compiled with OTG, you check > OTGSC; otherwise don't. I'd kind of like to support different configurations in runtime and have as few compilation options as possible. Of course, if it means extra spaghetti, there's a trade off right there. Regards, -- Alex -- 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
