[PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Andy Shevchenko]

The driver does two things that need to be addressed:
- includes subject to remove gpio.h
- checks for error code from device property APIs when it can be done in
  a robust way

This series addresses the above and adds a couple of additional refactoring.

Changelog v2:
- rebased on top of the latest changes in the driver
- Cc'ed to Ulf and Josua due to above
- elaborated dropping of_node parameter (Vladimir)

v1: 20260219202910.2304440-1-andriy.shevchenko@linux.intel.com

Andy Shevchenko (4):
  phy: phy-can-transceiver: Convert to use device property API
  phy: phy-can-transceiver: Move OF ID table closer to their user
  phy: phy-can-transceiver: Don't check for specific errors when parsing
    properties
  phy: phy-can-transceiver: Drop unused include

 drivers/phy/phy-can-transceiver.c | 84 ++++++++++++++++---------------
 1 file changed, 44 insertions(+), 40 deletions(-)

-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v2 1/4] phy: phy-can-transceiver: Convert to use device property API

[Andy Shevchenko]

It seems the driver is half-moved to use device property APIs.
Finish that by converting everything to use that.

While at it, drop unneeded argument to devm_phy_create() which
extracts device node from the given device by default.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/phy/phy-can-transceiver.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 2b52e47f247a..80eece74f77d 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>
@@ -152,7 +152,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;
@@ -161,8 +160,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;
 
@@ -187,7 +185,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.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v2 2/4] phy: phy-can-transceiver: Move OF ID table closer to their user

[Andy Shevchenko]

There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/phy/phy-can-transceiver.c | 59 +++++++++++++++----------------
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 80eece74f77d..aaed8d08fcf0 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -97,35 +97,6 @@ static const struct can_transceiver_data tja1057_drvdata = {
 	.flags = CAN_TRANSCEIVER_SILENT_PRESENT,
 };
 
-static const struct of_device_id can_transceiver_phy_ids[] = {
-	{
-		.compatible = "ti,tcan1042",
-		.data = &tcan1042_drvdata
-	},
-	{
-		.compatible = "ti,tcan1043",
-		.data = &tcan1043_drvdata
-	},
-	{
-		.compatible = "nxp,tja1048",
-		.data = &tja1048_drvdata
-	},
-	{
-		.compatible = "nxp,tja1051",
-		.data = &tja1051_drvdata
-	},
-	{
-		.compatible = "nxp,tja1057",
-		.data = &tja1057_drvdata
-	},
-	{
-		.compatible = "nxp,tjr1443",
-		.data = &tcan1043_drvdata
-	},
-	{ }
-};
-MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
-
 static struct phy *can_transceiver_phy_xlate(struct device *dev,
 					     const struct of_phandle_args *args)
 {
@@ -229,6 +200,35 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 	return PTR_ERR_OR_ZERO(phy_provider);
 }
 
+static const struct of_device_id can_transceiver_phy_ids[] = {
+	{
+		.compatible = "ti,tcan1042",
+		.data = &tcan1042_drvdata
+	},
+	{
+		.compatible = "ti,tcan1043",
+		.data = &tcan1043_drvdata
+	},
+	{
+		.compatible = "nxp,tja1048",
+		.data = &tja1048_drvdata
+	},
+	{
+		.compatible = "nxp,tja1051",
+		.data = &tja1051_drvdata
+	},
+	{
+		.compatible = "nxp,tja1057",
+		.data = &tja1057_drvdata
+	},
+	{
+		.compatible = "nxp,tjr1443",
+		.data = &tcan1043_drvdata
+	},
+	{ }
+};
+MODULE_DEVICE_TABLE(of, can_transceiver_phy_ids);
+
 static struct platform_driver can_transceiver_phy_driver = {
 	.probe = can_transceiver_phy_probe,
 	.driver = {
@@ -236,7 +236,6 @@ static struct platform_driver can_transceiver_phy_driver = {
 		.of_match_table = can_transceiver_phy_ids,
 	},
 };
-
 module_platform_driver(can_transceiver_phy_driver);
 
 MODULE_AUTHOR("Faiz Abbas <faiz_abbas@ti.com>");
-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v2 3/4] phy: phy-can-transceiver: Don't check for specific errors when parsing properties

[Andy Shevchenko]

Instead of checking for the specific error codes (that can be considered
a layering violation to some extent) check for the property existence first
and then either parse it, or apply a default value.

With that, return an error when parsing of the existing property fails.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/phy/phy-can-transceiver.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index aaed8d08fcf0..21b0406d1a09 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -128,8 +128,9 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 	struct gpio_desc *standby_gpio;
 	struct gpio_desc *enable_gpio;
 	struct mux_state *mux_state;
-	u32 max_bitrate = 0;
 	int err, i, num_ch = 1;
+	const char *propname;
+	u32 max_bitrate;
 
 	drvdata = device_get_match_data(dev);
 	if (drvdata->flags & CAN_TRANSCEIVER_DUAL_CH)
@@ -148,8 +149,15 @@ static int can_transceiver_phy_probe(struct platform_device *pdev)
 
 	priv->mux_state = mux_state;
 
-	err = device_property_read_u32(dev, "max-bitrate", &max_bitrate);
-	if ((err != -EINVAL) && !max_bitrate)
+	propname = "max-bitrate";
+	if (device_property_present(dev, propname)) {
+		err = device_property_read_u32(dev, propname, &max_bitrate);
+		if (err)
+			return dev_err_probe(dev, err, "failed to parse %s\n", propname);
+	} else {
+		max_bitrate = 0;
+	}
+	if (max_bitrate == 0)
 		dev_warn(dev, "Invalid value for transceiver max bitrate. Ignoring bitrate limit\n");
 
 	for (i = 0; i < num_ch; i++) {
-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

[PATCH v2 4/4] phy: phy-can-transceiver: Drop unused include

[Andy Shevchenko]

This file does not use the symbols from the legacy
<linux/gpio.h> header, so let's drop it.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/phy/phy-can-transceiver.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
index 21b0406d1a09..8e250039c183 100644
--- a/drivers/phy/phy-can-transceiver.c
+++ b/drivers/phy/phy-can-transceiver.c
@@ -5,12 +5,11 @@
  * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
  *
  */
+#include <linux/gpio/consumer.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>
 #include <linux/mux/consumer.h>
 
 struct can_transceiver_data {
-- 
2.50.1


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Andy Shevchenko]

On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:
> The driver does two things that need to be addressed:
> - includes subject to remove gpio.h
> - checks for error code from device property APIs when it can be done in
>   a robust way
> 
> This series addresses the above and adds a couple of additional refactoring.

Any comments on this? Doesn't look like it being applied so far...

-- 
With Best Regards,
Andy Shevchenko



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 4/4] phy: phy-can-transceiver: Drop unused include

[Josua Mayer]

Am 17.03.26 um 21:27 schrieb Andy Shevchenko:
> This file does not use the symbols from the legacy
> <linux/gpio.h> header, so let's drop it.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/phy/phy-can-transceiver.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 21b0406d1a09..8e250039c183 100644
> --- a/drivers/phy/phy-can-transceiver.c
> +++ b/drivers/phy/phy-can-transceiver.c
> @@ -5,12 +5,11 @@
>   * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com
>   *
>   */
> +#include <linux/gpio/consumer.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>
>  #include <linux/mux/consumer.h>
>  
>  struct can_transceiver_data {
Reviewed-by: Josua Mayer <josua@solid-run.com>
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Josua Mayer]

Hi Andy,

Am 14.04.26 um 20:43 schrieb Andy Shevchenko:
> On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:
>> The driver does two things that need to be addressed:
>> - includes subject to remove gpio.h
>> - checks for error code from device property APIs when it can be done in
>>   a robust way
>>
>> This series addresses the above and adds a couple of additional refactoring.
> Any comments on this? Doesn't look like it being applied so far...
For unknown reason your patch-set did not arrive in my inbox.
Perhaps it went missing for others, too?

sincerely
Josua Mayer
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 1/4] phy: phy-can-transceiver: Convert to use device property API

[Josua Mayer]

Hi Andy,

Am 17.03.26 um 21:27 schrieb Andy Shevchenko:
> It seems the driver is half-moved to use device property APIs.
> Finish that by converting everything to use that.
As per v7.1-rc1 it seems you really just drop the last of_* function call,
while you're no adding any new device property call.
>
> While at it, drop unneeded argument to devm_phy_create() which
> extracts device node from the given device by default.
This was counter-intuitive to me at first,
but I confirmed it by reading in phy-core.c.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  drivers/phy/phy-can-transceiver.c | 8 +++-----
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/phy/phy-can-transceiver.c b/drivers/phy/phy-can-transceiver.c
> index 2b52e47f247a..80eece74f77d 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>
> @@ -152,7 +152,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;
> @@ -161,8 +160,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;
>  
> @@ -187,7 +185,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);

Commit message seems sub-optimal, but code change looks good.

Reviewed-by: Josua Mayer <josua@solid-run.com>
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Andy Shevchenko]

On Mon, Apr 27, 2026 at 11:09:48AM +0000, Josua Mayer wrote:
> Am 14.04.26 um 20:43 schrieb Andy Shevchenko:
> > On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:
> >> The driver does two things that need to be addressed:
> >> - includes subject to remove gpio.h
> >> - checks for error code from device property APIs when it can be done in
> >>   a robust way
> >>
> >> This series addresses the above and adds a couple of additional refactoring.
> > Any comments on this? Doesn't look like it being applied so far...
> For unknown reason your patch-set did not arrive in my inbox.
> Perhaps it went missing for others, too?

Are you in the MAINTAINERS for this part of the kernel?
The CAN NETWORK DRIVERS and GENERIC PHY FRAMEWORK do not list your name.

If you think of mail delivery in general, it's delivered at least to the ML
https://lore.kernel.org/all/20260317203001.2108568-1-andriy.shevchenko@linux.intel.com/

TBH I don't know what to answer to your question as I don't know your expectations and
how it should be fulfilled taking into account my above question...

But thanks for the reviewing! I will address the commit message in v3.

-- 
With Best Regards,
Andy Shevchenko



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Josua Mayer]

Am 27.04.26 um 15:34 schrieb Andy Shevchenko:
> On Mon, Apr 27, 2026 at 11:09:48AM +0000, Josua Mayer wrote:
>> Am 14.04.26 um 20:43 schrieb Andy Shevchenko:
>>> On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:
>>>> The driver does two things that need to be addressed:
>>>> - includes subject to remove gpio.h
>>>> - checks for error code from device property APIs when it can be done in
>>>>   a robust way
>>>>
>>>> This series addresses the above and adds a couple of additional refactoring.
>>> Any comments on this? Doesn't look like it being applied so far...
>> For unknown reason your patch-set did not arrive in my inbox.
>> Perhaps it went missing for others, too?
> Are you in the MAINTAINERS for this part of the kernel?
> The CAN NETWORK DRIVERS and GENERIC PHY FRAMEWORK do not list your name.
Correct. I touched can phy once related to mux only.
> If you think of mail delivery in general, it's delivered at least to the ML
> https://lore.kernel.org/all/20260317203001.2108568-1-andriy.shevchenko@linux.intel.com/
>
> TBH I don't know what to answer to your question as I don't know your expectations and
> how it should be fulfilled taking into account my above question...

Changelog v2:
- Cc'ed to Ulf and Josua due to above

This is why I expected it in my inbox.
Usually in this situation I blame my provider.

>
> But thanks for the reviewing! I will address the commit message in v3.
Great!
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

Re: [PATCH v2 0/4] phy: phy-can-transceiver: Ad-hoc cleanups and refactoring

[Andy Shevchenko]

On Mon, Apr 27, 2026 at 01:41:43PM +0000, Josua Mayer wrote:
> Am 27.04.26 um 15:34 schrieb Andy Shevchenko:
> > On Mon, Apr 27, 2026 at 11:09:48AM +0000, Josua Mayer wrote:
> >> Am 14.04.26 um 20:43 schrieb Andy Shevchenko:
> >>> On Tue, Mar 17, 2026 at 09:27:26PM +0100, Andy Shevchenko wrote:

...

> >> For unknown reason your patch-set did not arrive in my inbox.
> >> Perhaps it went missing for others, too?
> > Are you in the MAINTAINERS for this part of the kernel?
> > The CAN NETWORK DRIVERS and GENERIC PHY FRAMEWORK do not list your name.
> Correct. I touched can phy once related to mux only.
> > If you think of mail delivery in general, it's delivered at least to the ML
> > https://lore.kernel.org/all/20260317203001.2108568-1-andriy.shevchenko@linux.intel.com/
> >
> > TBH I don't know what to answer to your question as I don't know your expectations and
> > how it should be fulfilled taking into account my above question...
> 
> Changelog v2:
> - Cc'ed to Ulf and Josua due to above
> 
> This is why I expected it in my inbox.
> Usually in this situation I blame my provider.

Ah, blame me then. I most likely missed to add your name to the Cc list.

> > But thanks for the reviewing! I will address the commit message in v3.
> Great!

And will try hard to make sure your address will be in the Cc list.

-- 
With Best Regards,
Andy Shevchenko



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy