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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 01, 2021 at 11:33:07AM -0700, Trent Piepho wrote:
>    On Mon, Nov 1, 2021 at 2:01 AM Sascha Hauer <[1]sha@xxxxxxxxxxxxxx> wrote:
>    > On Wed, Oct 20, 2021 at 10:39:54AM +0200, Daniel Brát wrote:
>    > > 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.
> 
>    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.

>    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.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox




[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux