On Fri, 9 Sep 2016, Alan Stern wrote: > On Fri, 9 Sep 2016, Tony Lindgren wrote: > > > * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [160909 13:41]: > > > On Fri, 9 Sep 2016, Tony Lindgren wrote: > > > > > > > * Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> [160909 12:47]: > > > > > You know, as far as I can tell the only thing that is OMAP-specific > > > > > about the ohci-omap3 driver is the initialization of OHCI_CTRL_RWC. > > > > > This could be added to the platform data or the DT bindings, after > > > > > which this driver wouldn't be needed at all -- the ohci_platform driver > > > > > would work. Does this seem reasonable? > > > > > > > > Sure makes sense to me. Do we have some standard binding for > > > > OCHI_CTRL_RWC? > > > > > > No, one would have to be created. > > > > OK I can do a patch for that, what should be binding be? > > > > ohci-ctrl-rwc-something? > > OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for > "Remote Wakeup Control". Sorry, careless mistake on my part. It actually stands for "Remote Wakeup Connected"; meaning that the remote-wakeup output signal from the controller is connected to something really can wake up the system. This is exactly the sort of hardware implementation detail that the firmware is supposed to know. Alan Stern > The flag indicates whether the controller > hardware is able to wake up the system, and it is supposed to be set > initially by the firmware during boot-up. Under DT, the driver will > have to set it manually. > > So you could call it ohci-ctrl-rwc-on, or ohci-ctrl-rwc-enable, or > anything similar. Use your own judgment. > > Alan Stern -- 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
