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. > 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. > The alternative is to have N more platform tweaks for > * dccparams_is_borked, > * otgsc_is_borked, > and a lot of luck trying to get that right in the probe(). This is, of > course a preferred approach for anyone who supports phandle creep in > DT. right, that'll look odd :-s -- balbi
Attachment:
signature.asc
Description: Digital signature
