Hi, On Tue, Jun 18, 2013 at 10:53:26AM -0400, Alan Stern wrote: > > > If the controllers don't want HCD core to manage the PHY they can just set it > > > to some error code. > > > > they shouldn't have the choice, otherwise it'll be a bit of a PITA to > > maintain the code. ehci core tries to grab the PHY, if it's not there, > > try to continue anyway. Assume it's not needed. > > Felipe, are all these issues straightened out to your satisfaction? I > can't tell from the email thread. > > Looking through the EHCI glue source files, there appears to be a > variety of different ways of getting the PHY. It's not at all clear > that they can be moved into the ehci-hcd core (or even better, the USB > core -- which is what Chao is trying to do). yeah, Roger brought up a big problem with OMAP's EHCI depending on the mode so, at least for now, we should keep phy_get and, in case of EHCI OMAP, phy_init in the glue :-( Roger has all the details, and they're also in the list archives, but basically, depending on the mode, PHY *must* be initialized at a particular point. > Given that the glue module has to be responsible for getting the PHY, > it should also be responsible for error checking. So the code added to > hcd.c doesn't need to apply an IS_ERR check; it can simply assume that > if hcd->phy is NULL then either there is no software-controllable PHY > or else the HCD doesn't want the core to manage it. makes sense to me, add the requirement to: if (IS_ERR(hcd->phy)) hcd->phy = NULL; -- balbi
Attachment:
signature.asc
Description: Digital signature