phy: core: Make 'phy_optional_get' return NULL when not implemented

Make 'phy_optional_get' return NULL instead of ERR_PTR(-ENOSYS) when the CONFIG_GENERIC_PHY is not enabled. It makes more sense to return NULL instead of straight up throwing a error since the function has 'optional' in its name. This also fixes dwc2 usb driver which would previously fail inside its probe function despite being able to function without a phy just fine.

Quoted 5 lines · Daniel Brát

Make 'phy_optional_get' return NULL instead of ERR_PTR(-ENOSYS) when the CONFIG_GENERIC_PHY is not enabled. It makes more sense to return NULL instead of straight up throwing a error since the function has 'optional' in its name. This also fixes dwc2 usb driver which would previously fail inside its probe function despite being able to function without a phy just fine.

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

Quoted 2 lines · Sascha Hauer

Quoted 1 line · Daniel Brát

Make 'phy_optional_get' return NULL instead of ERR_PTR(-ENOSYS) when

the

Quoted 1 line

Quoted 1 line

CONFIG_GENERIC_PHY is not enabled. It makes more sense to return NULL

instead

Quoted 1 line

Quoted 1 line

of straight up throwing a error since the function has 'optional' in

its name.

Quoted 1 line

Quoted 1 line

This also fixes dwc2 usb driver which would previously fail inside its

probe

Quoted 6 lines

Quoted 1 line

function despite being able to function without a phy just fine.

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

But this force enables GENERIC_PHY when it's not needed.

There are commonly many device nodes in Linux dts files that are not used by an enabled Barebox driver.  It's normal to turn off a driver that might be or could be used.  Is it necessarily an error if a phy is present in the dts but we don't wish to include support for it?

   struct phy *phy_optional_get(struct device_d *dev, const char *string)
   {
           if (dev->device_node &&
               !of_parse_phandle_with_args(dev->device_node, "phys",
   "#phy-cells", of_property_match_string(dev->device_node, "phy-names",
   string), NULL))
                   dev_warn(dev, "%s phy specified in device tree but
   CONFIG_GENERIC_PHY support is not enabled", string);
           return NULL;
   }

Quoted 7 lines · Trent Piepho

Quoted 4 lines · Sascha Hauer

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

Quoted 6 lines

But this force enables GENERIC_PHY when it's not needed.

There are commonly many device nodes in Linux dts files that are not used by an enabled Barebox driver. It's normal to turn off a driver that might be or could be used. Is it necessarily an error if a phy is present in the dts but we don't wish to include support for it?

We need to distinguish the cases "There is a phy specified, but the reset defaults are good enough to go without a driver" and "There is a phy specified and we need driver support for it". barebox can't know this.

Returning NULL from the phy_optional_get() stub has another problem:
Some devices might work with CONFIG_GENERIC_PHY disabled, but stop to work when CONFIG_GENERIC_PHY gets enabled, because we might have no driver for the phy. Having boards that only work with CONFIG_GENERIC_PHY disabled is rather unexpected as well.

Quoted 10 lines

   struct phy *phy_optional_get(struct device_d *dev, const char *string)
   {
           if (dev->device_node &&
               !of_parse_phandle_with_args(dev->device_node, "phys",
   "#phy-cells", of_property_match_string(dev->device_node, "phy-names",
   string), NULL))
                   dev_warn(dev, "%s phy specified in device tree but
   CONFIG_GENERIC_PHY support is not enabled", string);
           return NULL;
   }

I am fine with this approach. We could add a check if the phy node has a status = "disabled" property. That would allow a board to explicitly state that we do not need to support a phy. We could then do the right thing no matter if CONFIG_GENERIC_PHY is enabled or not.

Thinking about it I would prefer something like barebox,status = "disabled" to prevent the property from leaking into Linux.

Quoted 16 lines · Sascha Hauer

Quoted 13 lines · Trent Piepho

Quoted 4 lines · Sascha Hauer

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

But this force enables GENERIC_PHY when it's not needed.

There are commonly many device nodes in Linux dts files that are not used by an enabled Barebox driver. It's normal to turn off a driver that might be or could be used. Is it necessarily an error if a phy is present in the dts but we don't wish to include support for it?

Quoted 4 lines

We need to distinguish the cases "There is a phy specified, but the reset defaults are good enough to go without a driver" and "There is a phy specified and we need driver support for it". barebox can't know this.

Could we say that compiling barebox without CONFIG_GENERIC_PHY means the driver is not needed and compiling it with the driver means that is it?

One can have the defconfig include drivers that might be needed, but at some point an engineer ought to be able to

Quoted 5 lines

Returning NULL from the phy_optional_get() stub has another problem:
Some devices might work with CONFIG_GENERIC_PHY disabled, but stop to work when CONFIG_GENERIC_PHY gets enabled, because we might have no driver for the phy. Having boards that only work with CONFIG_GENERIC_PHY disabled is rather unexpected as well.

Return NULL if there is no driver.

Quoted 16 lines

Quoted 10 lines

   struct phy *phy_optional_get(struct device_d *dev, const char *string)
   {
           if (dev->device_node &&
               !of_parse_phandle_with_args(dev->device_node, "phys",
   "#phy-cells", of_property_match_string(dev->device_node, "phy-names",
   string), NULL))
                   dev_warn(dev, "%s phy specified in device tree but
   CONFIG_GENERIC_PHY support is not enabled", string);
           return NULL;
   }

I am fine with this approach. We could add a check if the phy node has a status = "disabled" property. That would allow a board to explicitly state that we do not need to support a phy. We could then do the right thing no matter if CONFIG_GENERIC_PHY is enabled or not.

Quoted 2 lines

Thinking about it I would prefer something like barebox,status = "disabled" to prevent the property from leaking into Linux.

Wouldn't it be easier to just delete the phy-names property to disable the phy?

Quoted 17 lines · Trent Piepho

Quoted 16 lines · Sascha Hauer

Quoted 13 lines · Trent Piepho

Quoted 4 lines · Sascha Hauer

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

But this force enables GENERIC_PHY when it's not needed.

There are commonly many device nodes in Linux dts files that are not used by an enabled Barebox driver. It's normal to turn off a driver that might be or could be used. Is it necessarily an error if a phy is present in the dts but we don't wish to include support for it?

Quoted 8 lines

Quoted 4 lines

We need to distinguish the cases "There is a phy specified, but the reset defaults are good enough to go without a driver" and "There is a phy specified and we need driver support for it". barebox can't know this.

Could we say that compiling barebox without CONFIG_GENERIC_PHY means the driver is not needed and compiling it with the driver means that is it?

Please no. Enabling Kconfig options ideally gives you additional features, but it should not break anything. Consider the case when you need to enable CONFIG_GENERIC_PHY for something else like an LVDS phy or whatever, you don't want to end up with broken USB support then and have to choose whether USB or LVDS is working.

Quoted 1 line

Wouldn't it be easier to just delete the phy-names property to disable the phy?

My point is that you sometimes start Linux with the barebox internal device tree. We should then pass a device tree Linux can handle properly. A barebox,status would just be ignored by Linux whereas a status = "disabled" property or deleted phy-names property would disable the phy for Linux as well.

Quoted 27 lines · Sascha Hauer

Quoted 17 lines · Trent Piepho

Quoted 16 lines · Sascha Hauer

Quoted 13 lines · Trent Piepho

Quoted 4 lines · Sascha Hauer

The phy is only optional as long as none is specified in the device tree. When there is one specified then it's no longer optional. We can't do the right thing here without checking the device tree. Given that it's simple to enable CONFIG_GENERIC_PHY I think this is the way to go.

But this force enables GENERIC_PHY when it's not needed.

There are commonly many device nodes in Linux dts files that are not used by an enabled Barebox driver. It's normal to turn off a driver that might be or could be used. Is it necessarily an error if a phy is present in the dts but we don't wish to include support for it?

Quoted 8 lines

Quoted 4 lines

We need to distinguish the cases "There is a phy specified, but the reset defaults are good enough to go without a driver" and "There is a phy specified and we need driver support for it". barebox can't know this.

Could we say that compiling barebox without CONFIG_GENERIC_PHY means the driver is not needed and compiling it with the driver means that is it?

Quoted 5 lines

Please no. Enabling Kconfig options ideally gives you additional features, but it should not break anything. Consider the case when you need to enable CONFIG_GENERIC_PHY for something else like an LVDS phy or whatever, you don't want to end up with broken USB support then and have to choose whether USB or LVDS is working.

I thought your goal was to prevent less experienced users from building a non-functional Barebox and then not understanding what they had done. Turning off a necessary driver and breaking USB while producing no warnings nor errors. But I now gather I was mistaken and this isn't really the problem.

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.

Quoted 11 lines · Trent Piepho

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.

Quoted 3 lines

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

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

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;

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.

Quoted 12 lines · Sascha Hauer

Quoted 11 lines · Trent Piepho

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 3 lines

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?

Quoted 7 lines

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.

Quoted 8 lines

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.

Make 'phy_optional_get' return NULL instead of ERR_PTR(-ENOSYS) when the CONFIG_GENERIC_PHY is not enabled. It makes more sense to return NULL instead of straight up throwing a error since the function has 'optional' in its name. This also fixes dwc2 usb driver which would previously fail inside its probe function despite being able to function without a phy just fine.

Signed-off-by Daniel Brát <[email protected]>

---
 include/linux/phy/phy.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

include/linux/phy/phy.h +1 -1

index 679ce6e42..321e546f9 100644
@@ -195,7 +195,7 @@ static inline struct phy *phy_get(struct device_d *dev, const char *string)
 static inline struct phy *phy_optional_get(struct device_d *dev,
 					   const char *string)
 {
-	return ERR_PTR(-ENOSYS);
+	return NULL;
 }
 
 static inline struct phy *of_phy_get_by_phandle(struct device_d *dev,

Signature · 7 lines

2.17.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox