It seems the driver is half-moved to use device property APIs.
Finish that by converting everything to use that.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/phy/phy-can-transceiver.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 330356706ad7..f2259af4af8a 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,9 +5,9 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
*
*/
-#include <linux/of.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/module.h>
#include <linux/gpio.h>
#include <linux/gpio/consumer.h>
@@ -130,7 +130,7 @@ MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
static inline struct mux_state *
devm_mux_state_get_optional(struct device *dev, const char *mux_name)
{
- if (!of_property_present(dev->of_node, "mux-states"))
+ if (!device_property_present(dev, "mux-states"))
return NULL;
return devm_mux_state_get(dev, mux_name);
@@ -162,7 +162,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
struct can_transceiver_phy *can_transceiver_phy;
struct can_transceiver_priv *priv;
const struct can_transceiver_data *drvdata;
- const struct of_device_id *match;
struct phy *phy;
struct gpio_desc *silent_gpio;
struct gpio_desc *standby_gpio;
@@ -171,8 +170,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
u32 max_bitrate = 0;
int err, i, num_ch = 1;
- match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
- drvdata = match->data;
+ drvdata = device_get_match_data(dev);
if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
num_ch = 2;
@@ -197,7 +195,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
can_transceiver_phy = &priv->can_transceiver_phy[i];
can_transceiver_phy->priv = priv;
- phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
+ phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
if (IS_ERR(phy)) {
dev_err(dev, "failed to create can transceiver phy\n");
return PTR_ERR(phy);
--
2.50.1Hi Andy,
On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote:
> It seems the driver is half-moved to use device property APIs.
> Finish that by converting everything to use that.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/phy/phy-can-transceiver.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 330356706ad7..f2259af4af8a 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -5,9 +5,9 @@
> * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
> *
> */
> -#include <linux/of.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/property.h>
> #include <linux/module.h>
> #include <linux/gpio.h>
> #include <linux/gpio/consumer.h>
> @@ -130,7 +130,7 @@ MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
> static inline struct mux_state *
> devm_mux_state_get_optional(struct device *dev, const char *mux_name)
> {
> - if (!of_property_present(dev->of_node, "mux-states"))
> + if (!device_property_present(dev, "mux-states"))
There's an entire saga with this function - devm_mux_state_get_optional().
Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series.
Would you mind not touching this, to avoid complicating what is already
a complicated operation? It is going away anyway, and from what I can
see in Josua's last series, its implementation from drivers/mux/core.c
is already using device property APIs:
https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/
> return NULL;
>
> return devm_mux_state_get(dev, mux_name);
> @@ -162,7 +162,6 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> struct can_transceiver_phy *can_transceiver_phy;
> struct can_transceiver_priv *priv;
> const struct can_transceiver_data *drvdata;
> - const struct of_device_id *match;
> struct phy *phy;
> struct gpio_desc *silent_gpio;
> struct gpio_desc *standby_gpio;
> @@ -171,8 +170,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> u32 max_bitrate = 0;
> int err, i, num_ch = 1;
>
> - match = of_match_node(can_transceiver_phy_ids, pdev->dev.of_node);
> - drvdata = match->data;
> + drvdata = device_get_match_data(dev);
> if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
> num_ch = 2;
>
> @@ -197,7 +195,7 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
> can_transceiver_phy = &priv->can_transceiver_phy[i];
> can_transceiver_phy->priv = priv;
>
> - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops);
> + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops);
It is not obvious why you replaced dev->of_node with NULL here.
It doesn't appear correct. You seem to be breaking OF-based PHY lookups.
> if (IS_ERR(phy)) {
> dev_err(dev, "failed to create can transceiver phy\n");
> return PTR_ERR(phy);
> --
> 2.50.1
>
>
On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote: > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote: ... > > - if (!of_property_present(dev->of_node, "mux-states")) > > + if (!device_property_present(dev, "mux-states")) > > There's an entire saga with this function - devm_mux_state_get_optional(). > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series. > Would you mind not touching this, to avoid complicating what is already > a complicated operation? It is going away anyway, and from what I can > see in Josua's last series, its implementation from drivers/mux/core.c > is already using device property APIs: > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/ Basically you ask me to postpone the series until that will be in. Since this file is a mess in terms of OF/fwnode API use in exchange I would like whoever is doing the other part to speed up a bit if possible. I prefer to see cleaner solution to be applied sooner and last in a long distance, that's why I see either mine first but soon, or that first but also soon should be in. Can we try to achieve that? ... > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops); > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops); > > It is not obvious why you replaced dev->of_node with NULL here. > It doesn't appear correct. You seem to be breaking OF-based PHY lookups. It's the default. Yeah, I probably have to explain this in the commit message. Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be converted to that approach. Or even better, a new (agnostic) API should take default fwnode from the same device. phy = devm_phy_create_simple(dev, &..._phy_ops); // name was quickly chosen and may be not the best we can come up with ... Thanks for the review! -- With Best Regards, Andy Shevchenko
On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote: > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote: > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote: > > ... > > > > - if (!of_property_present(dev->of_node, "mux-states")) > > > + if (!device_property_present(dev, "mux-states")) > > > > There's an entire saga with this function - devm_mux_state_get_optional(). > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series. > > Would you mind not touching this, to avoid complicating what is already > > a complicated operation? It is going away anyway, and from what I can > > see in Josua's last series, its implementation from drivers/mux/core.c > > is already using device property APIs: > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/ > > Basically you ask me to postpone the series until that will be in. Since this > file is a mess in terms of OF/fwnode API use in exchange I would like whoever > is doing the other part to speed up a bit if possible. > > I prefer to see cleaner solution to be applied sooner and last in a long distance, > that's why I see either mine first but soon, or that first but also soon should > be in. Can we try to achieve that? The idea is that Ulf already expressed the availability to take the phy-can-transceiver patch through the mmc tree and provide back a tag to be pulled into linux-phy: https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/ If linux-phy takes your patch first, there will be a conflict when pulling the stable branch, and it won't be so fun, plus we can't even build-test Josua's submission on linux-phy, so that's obviously not great. So yeah, I'm not requesting you to postpone the entire series, just not touch devm_mux_state_get_optional() and don't let it appear in your patch context. Somebody will have to remove "#include <linux/of.h>" at the end of the whole process, but that's minor. > ... > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops); > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops); > > > > It is not obvious why you replaced dev->of_node with NULL here. > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups. > > It's the default. Yeah, I probably have to explain this in the commit message. Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment. Sorry and noted, but please add it to the commit message too. > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be > converted to that approach. Or even better, a new (agnostic) API should take > default fwnode from the same device. > > phy = devm_phy_create_simple(dev, &..._phy_ops); > > // name was quickly chosen and may be not the best we can come up with I agree in principle. PHY drivers shouldn't be given a function where they routinely have to set one of the arguments to NULL, but a simpler function without that argument. But the phy-core.c doesn't support fwnode at all yet, it uses OF throughout. I think it would be preferable to leave this change to somebody who has business in that area. (are you interested in PHYs with a fwnode for any particular reason, or just because the API is more "generic" just in case?)
On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote: > On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote: > > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote: > > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote: ... > > > > - if (!of_property_present(dev->of_node, "mux-states")) > > > > + if (!device_property_present(dev, "mux-states")) > > > > > > There's an entire saga with this function - devm_mux_state_get_optional(). > > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series. > > > Would you mind not touching this, to avoid complicating what is already > > > a complicated operation? It is going away anyway, and from what I can > > > see in Josua's last series, its implementation from drivers/mux/core.c > > > is already using device property APIs: > > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/ > > > > Basically you ask me to postpone the series until that will be in. Since this > > file is a mess in terms of OF/fwnode API use in exchange I would like whoever > > is doing the other part to speed up a bit if possible. > > > > I prefer to see cleaner solution to be applied sooner and last in a long distance, > > that's why I see either mine first but soon, or that first but also soon should > > be in. Can we try to achieve that? > > The idea is that Ulf already expressed the availability to take the phy-can-transceiver > patch through the mmc tree and provide back a tag to be pulled into linux-phy: > https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/ > > If linux-phy takes your patch first, there will be a conflict when pulling the > stable branch, and it won't be so fun, plus we can't even build-test Josua's > submission on linux-phy, so that's obviously not great. > > So yeah, I'm not requesting you to postpone the entire series, just not > touch devm_mux_state_get_optional() and don't let it appear in your > patch context. Thanks for explanation. I prefer that Ulf's staff settles down first as it seems more important. > Somebody will have to remove "#include <linux/of.h>" at the end of the > whole process, but that's minor. > > ... > > > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops); > > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops); > > > > > > It is not obvious why you replaced dev->of_node with NULL here. > > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups. > > > > It's the default. Yeah, I probably have to explain this in the commit message. > > Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment. > Sorry and noted, but please add it to the commit message too. Sure. > > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be > > converted to that approach. Or even better, a new (agnostic) API should take > > default fwnode from the same device. > > > > phy = devm_phy_create_simple(dev, &..._phy_ops); > > > > // name was quickly chosen and may be not the best we can come up with > > I agree in principle. PHY drivers shouldn't be given a function where > they routinely have to set one of the arguments to NULL, but a simpler > function without that argument. > > But the phy-core.c doesn't support fwnode at all yet, it uses OF > throughout. I think it would be preferable to leave this change to > somebody who has business in that area. > > (are you interested in PHYs with a fwnode for any particular reason, or > just because the API is more "generic" just in case?) Because of inconsistency. This makes my mind blown and the code is not good for others to read and understand when it's inconsistent like this. That's it. -- With Best Regards, Andy Shevchenko
On Sat, Feb 28, 2026 at 01:10:02PM +0200, Andy Shevchenko wrote: > On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote: > > On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote: > > > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote: > > > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote: ... > > > > > - if (!of_property_present(dev->of_node, "mux-states")) > > > > > + if (!device_property_present(dev, "mux-states")) > > > > > > > > There's an entire saga with this function - devm_mux_state_get_optional(). > > > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series. > > > > Would you mind not touching this, to avoid complicating what is already > > > > a complicated operation? It is going away anyway, and from what I can > > > > see in Josua's last series, its implementation from drivers/mux/core.c > > > > is already using device property APIs: > > > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/ > > > > > > Basically you ask me to postpone the series until that will be in. Since this > > > file is a mess in terms of OF/fwnode API use in exchange I would like whoever > > > is doing the other part to speed up a bit if possible. > > > > > > I prefer to see cleaner solution to be applied sooner and last in a long distance, > > > that's why I see either mine first but soon, or that first but also soon should > > > be in. Can we try to achieve that? > > > > The idea is that Ulf already expressed the availability to take the phy-can-transceiver > > patch through the mmc tree and provide back a tag to be pulled into linux-phy: > > https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/ > > > > If linux-phy takes your patch first, there will be a conflict when pulling the > > stable branch, and it won't be so fun, plus we can't even build-test Josua's > > submission on linux-phy, so that's obviously not great. > > > > So yeah, I'm not requesting you to postpone the entire series, just not > > touch devm_mux_state_get_optional() and don't let it appear in your > > patch context. > > Thanks for explanation. I prefer that Ulf's staff settles down first as it seems > more important. Any news on that front? > > Somebody will have to remove "#include <linux/of.h>" at the end of the > > whole process, but that's minor. > > > > ... > > > > > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops); > > > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops); > > > > > > > > It is not obvious why you replaced dev->of_node with NULL here. > > > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups. > > > > > > It's the default. Yeah, I probably have to explain this in the commit message. > > > > Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment. > > Sorry and noted, but please add it to the commit message too. > > Sure. > > > > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be > > > converted to that approach. Or even better, a new (agnostic) API should take > > > default fwnode from the same device. > > > > > > phy = devm_phy_create_simple(dev, &..._phy_ops); > > > > > > // name was quickly chosen and may be not the best we can come up with > > > > I agree in principle. PHY drivers shouldn't be given a function where > > they routinely have to set one of the arguments to NULL, but a simpler > > function without that argument. > > > > But the phy-core.c doesn't support fwnode at all yet, it uses OF > > throughout. I think it would be preferable to leave this change to > > somebody who has business in that area. > > > > (are you interested in PHYs with a fwnode for any particular reason, or > > just because the API is more "generic" just in case?) > > Because of inconsistency. This makes my mind blown and the code is not good > for others to read and understand when it's inconsistent like this. That's it. -- With Best Regards, Andy Shevchenko
On Tue, Mar 17, 2026 at 12:41:19PM +0200, Andy Shevchenko wrote: > On Sat, Feb 28, 2026 at 01:10:02PM +0200, Andy Shevchenko wrote: > > On Tue, Feb 24, 2026 at 08:30:00PM +0200, Vladimir Oltean wrote: > > > On Tue, Feb 24, 2026 at 06:54:48PM +0200, Andy Shevchenko wrote: > > > > On Tue, Feb 24, 2026 at 06:26:06PM +0200, Vladimir Oltean wrote: > > > > > On Thu, Feb 19, 2026 at 09:26:19PM +0100, Andy Shevchenko wrote: ... > > > > > > - if (!of_property_present(dev->of_node, "mux-states")) > > > > > > + if (!device_property_present(dev, "mux-states")) > > > > > > > > > > There's an entire saga with this function - devm_mux_state_get_optional(). > > > > > Josua Mayer is preparing to move it to the MUX core, which will be a cross-tree series. > > > > > Would you mind not touching this, to avoid complicating what is already > > > > > a complicated operation? It is going away anyway, and from what I can > > > > > see in Josua's last series, its implementation from drivers/mux/core.c > > > > > is already using device property APIs: > > > > > https://lore.kernel.org/linux-phy/20260208-rz-sdio-mux-v9-2-9a3be13c1280@solid-run.com/ > > > > > > > > Basically you ask me to postpone the series until that will be in. Since this > > > > file is a mess in terms of OF/fwnode API use in exchange I would like whoever > > > > is doing the other part to speed up a bit if possible. > > > > > > > > I prefer to see cleaner solution to be applied sooner and last in a long distance, > > > > that's why I see either mine first but soon, or that first but also soon should > > > > be in. Can we try to achieve that? > > > > > > The idea is that Ulf already expressed the availability to take the phy-can-transceiver > > > patch through the mmc tree and provide back a tag to be pulled into linux-phy: > > > https://lore.kernel.org/linux-phy/CAPDyKFrtTaJ5fqqbGrE_K6SAdTZYUfp-BycGjtWs4SabwBysKA@mail.gmail.com/ > > > > > > If linux-phy takes your patch first, there will be a conflict when pulling the > > > stable branch, and it won't be so fun, plus we can't even build-test Josua's > > > submission on linux-phy, so that's obviously not great. > > > > > > So yeah, I'm not requesting you to postpone the entire series, just not > > > touch devm_mux_state_get_optional() and don't let it appear in your > > > patch context. > > > > Thanks for explanation. I prefer that Ulf's staff settles down first as it seems > > more important. > > Any news on that front? Okay, I found the new patches in Linux Next. I will respin my set based on that. > > > Somebody will have to remove "#include <linux/of.h>" at the end of the > > > whole process, but that's minor. ... > > > > > > - phy = devm_phy_create(dev, dev->of_node, &can_transceiver_phy_ops); > > > > > > + phy = devm_phy_create(dev, NULL, &can_transceiver_phy_ops); > > > > > > > > > > It is not obvious why you replaced dev->of_node with NULL here. > > > > > It doesn't appear correct. You seem to be breaking OF-based PHY lookups. > > > > > > > > It's the default. Yeah, I probably have to explain this in the commit message. > > > > > > Ah, ok. Found the "phy->dev.of_node = node ?: dev->of_node;" assignment. > > > Sorry and noted, but please add it to the commit message too. > > > > Sure. > > > > > > Basically all devm_phy_create(dev, dev->of_node, ...) for clarity should be > > > > converted to that approach. Or even better, a new (agnostic) API should take > > > > default fwnode from the same device. > > > > > > > > phy = devm_phy_create_simple(dev, &..._phy_ops); > > > > > > > > // name was quickly chosen and may be not the best we can come up with > > > > > > I agree in principle. PHY drivers shouldn't be given a function where > > > they routinely have to set one of the arguments to NULL, but a simpler > > > function without that argument. > > > > > > But the phy-core.c doesn't support fwnode at all yet, it uses OF > > > throughout. I think it would be preferable to leave this change to > > > somebody who has business in that area. > > > > > > (are you interested in PHYs with a fwnode for any particular reason, or > > > just because the API is more "generic" just in case?) > > > > Because of inconsistency. This makes my mind blown and the code is not good > > for others to read and understand when it's inconsistent like this. That's it. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.