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. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
