On Wednesday 11 December 2013 02:23 PM, Heikki Krogerus wrote: > Hi, > > On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote: >>>>>> 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 >>> >>> right. but that doesn't consider broken dt data. With quirks we'll >>> able to tell if a controller in a particular platform has PHY or not >>> without depending on the dt data. >> >> Broken dt data? What kind of scenario are you thinking here? Do you >> mean case where the dt does not describe the phy on a platform that >> depends on it? Shouldn't that problem be fixed in the dt and not >> hacked in the drivers? Or are you thinking about something else? >> >> Is there a case where something like that is actually happening? > > I'm guessing I'm not getting an answer to this one. > > Look, this patch will not work with ACPI enumerated devices. We will > have a platform providing a single ACPI id, but there is a whole bunch > of boards based on it and we have no way of telling which of them > need/have phys to deal with and which ones don't. Alright.. I'll drop this patch then. Thanks Kishon -- 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
