Hi, On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote: > On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote: > > On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: > >> There can be systems which does not have an external phy, so get > >> phy only if no quirks are added that indicates the PHY is not present. > >> Introduced two quirk flags to indicate the *absence* of usb2 phy and > >> usb3 phy. Also remove checking if return value is -ENXIO since it's now > >> changed to always enable usb_phy layer. > > > > Can you guys explain why is something like this needed? Like with > > clocks and gpios, the device drivers shouldn't need to care any more > > if the platform has the phys or not. -ENODEV tells you your platform > > Shouldn't we report if a particular platform needs a PHY and not able to get > it. How will a user know if a particular controller is not working because it's > not able to get and initialize the PHYs? Don't you think in such cases it's > better to fail (and return from probe) because the controller will not work > anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other error when getting the phy you can consider critical. They are the errors telling you that you do need a phy on this platform, but something actually went wrong when getting it. Those "quirks" should always be avoided, and I don't see any use for them here. > Thanks > Kishon Thanks, -- heikki -- 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
