[PATCH] phy: core: Make 'phy_optional_get' return NULL when not implemented

[Trent Piepho]

On Mon, Nov 8, 2021 at 1:10 AM Sascha Hauer <sha at pengutronix.de> wrote:
> On Thu, Nov 04, 2021 at 02:40:08PM -0700, Trent Piepho wrote:
> >
> > I think the specific situation you are concerned about is where:
> > A) the dts does define a phy for usb
> > B) This phy does not work in Barebox, e.g. no driver
> > C) Despite B, USB will still operate with the desired level
> > functionality without a working phy driver.
> >
> > With the patch and CONFIG_GENERIC_PHY disabled, we get a non-fatal
> > return at step A and everything is good.  But once enabled, we now get
> > a fatal error at step B and this is not good.
> >
> > Could this be fixed by making the error at B non-fatal?  This is more
> > how Linux works here: errors that are non-fatal in Linux's
> > phy_optional_get() path are fatal for Barebox.
>
> In Linux phy_optional_get() returns NULL (which is a valid phy) when
> a) there is no "phys" property
> b) The phy os compatible to "usb-nop-xceiv"
> c) The phy has a status = "disabled" property

Add to this:
d) Missing phy-names property.
e) Named phy is not in phy-names.
f) Malformed phys property.
g) PHY's index from phy-names does not exist in phys property.
h) PHY exists in phys property, but has empty phandle
i) No '#phy-cells' property for phy.
j) No of_node for device and phy is not in the global phy list. No
driver, not defined, error adding, anything could cause this to
happen.

And then we go to device specific cases:
An Allwinner sun4i usb phy provider is given a phy index that is
greater than the number of defined phys.
A phy from a sun4i phy provider is marked as missing in the device
configuration data, i.e. phy 1 or 2 on an Allwinner H6.
A Broadcom stingray phy can not ioremap its registers with ENODEV.
And the list goes on, but I think my point is made.

> When there is a phy specified in the device tree then it's mandatory
> and failures in getting it must lead to an error. the "optional" in

"Must lead to an error"  Can this be said with certainty?  I can find
no real case where a warning results in a different end than an error.
Put another way, suppose it does not lead to an error?  What specific
bad thing happens?

> phy_optional_get() is only meant for the "there is no phy specified in
> the device tree" case, it's only a shortcut for
>
>         if (is_there_a_phy_in_device_tree())
>                 phy = phy_get();
>         else
>                 phy = NULL;

Perhaps that is what it was supposed to mean, I agree these seem like
sensible semantics, but see the various errors I tracked down above,
it's far far more complex than that.  IMHO, this complexity is
evidence of a bad design.  No one can keep straight what errors are
fatal and which are not.  It is better to just make all errors
non-fatal and be done with it.  Then at least one knows what to
expect.

> Once you interpret "optional" as something different you end up
> returning NULL for cases where you really need a phy. Only you as a
> human know that, in your special case, on your special board, there is a
> phy specified, but it can do without initialisation. That's why I
> suggested you should add a status = "disabled" property to the phy to
> explicitly state that it can work without the phy. By making it explicit
> you also document that you thought about the case and not just exploited
> a heuristic in barebox.

I think returning NULL on every error, with a warning message, will
allow this.  The warning lets the user know there may be an issue with
the usb phy.  If it works, they can decide the warning is spurious and
silence it, via existing dts editing methods (/delete-property/,
status = disabled, etc.).  If it doesn't work, they know they need to
enable a driver, write a driver, or perhaps disable USB entirely as
unsupported.