[PATCH 1/2] net: dsa: LAN9303: Add basic support for LAN9354

[PATCH 1/2] net: dsa: LAN9303: Add basic support for LAN9354

[Jerry Ray]

Add initial BYTE_ORDER read to sync to improve driver robustness

The lan9303 expects two mdio read transactions back-to-back to read a 32-bit
register. The first read transaction causes the other half of the 32-bit
register to get latched.  The subsequent read returns the latched second half
of the 32-bit read. The BYTE_ORDER register is an exception to this rule. As
it is a constant value, there is no need to latch the second half. We read
this register first in case there were reads during the boot loader process
that might have occurred prior to this driver taking over ownership of
accessing this device.

This patch has been tested on the SAMA5D3-EDS with a LAN9303 RMII daughter
card.

Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
---
 drivers/net/dsa/lan9303-core.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index e03ff1f267bb..17ae02a56bfe 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -32,6 +32,7 @@
 #define LAN9303_INT_EN 0x17
 # define LAN9303_INT_EN_PHY_INT2_EN BIT(27)
 # define LAN9303_INT_EN_PHY_INT1_EN BIT(26)
+#define LAN9303_BYTE_ORDER 0x19
 #define LAN9303_HW_CFG 0x1D
 # define LAN9303_HW_CFG_READY BIT(27)
 # define LAN9303_HW_CFG_AMDX_EN_PORT2 BIT(26)
@@ -847,9 +848,10 @@ static int lan9303_check_device(struct lan9303 *chip)
 	int ret;
 	u32 reg;
 
-	ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
+	// Dummy read to ensure MDIO access is in 32-bit sync.
+	ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, &reg);
 	if (ret) {
-		dev_err(chip->dev, "failed to read chip revision register: %d\n",
+		dev_err(chip->dev, "failed to access the device: %d\n",
 			ret);
 		if (!chip->reset_gpio) {
 			dev_dbg(chip->dev,
@@ -858,6 +860,13 @@ static int lan9303_check_device(struct lan9303 *chip)
 		return ret;
 	}
 
+	ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
+	if (ret) {
+		dev_err(chip->dev, "failed to read chip revision register: %d\n",
+			ret);
+		return ret;
+	}
+
 	if ((reg >> 16) != LAN9303_CHIP_ID) {
 		dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
 			reg >> 16);
-- 
2.17.1

[PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Jerry Ray]

Adding support for the LAN9354 device by allowing it to use
the LAN9303 DSA driver.  These devices have the same underlying
access and control methods and from a feature set point of view
the LAN9354 is a superset of the LAN9303.

The MDIO access method has been tested on a SAMA5D3-EDS board
with a LAN9354 RMII daughter card.

While the SPI access method should also be the same, it has not
been tested and as such is not included at this time.

Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
---
 drivers/net/dsa/Kconfig        |  6 +++---
 drivers/net/dsa/lan9303-core.c | 11 ++++++++---
 drivers/net/dsa/lan9303_mdio.c |  1 +
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index d8ae0e8af2a0..07507b4820d7 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -76,7 +76,7 @@ config NET_DSA_SMSC_LAN9303
 	select NET_DSA_TAG_LAN9303
 	select REGMAP
 	help
-	  This enables support for the SMSC/Microchip LAN9303 3 port ethernet
+	  This enables support for the Microchip LAN9303/LAN9354 3 port ethernet
 	  switch chips.
 
 config NET_DSA_SMSC_LAN9303_I2C
@@ -90,11 +90,11 @@ config NET_DSA_SMSC_LAN9303_I2C
 	  for I2C managed mode.
 
 config NET_DSA_SMSC_LAN9303_MDIO
-	tristate "SMSC/Microchip LAN9303 3-ports 10/100 ethernet switch in MDIO managed mode"
+	tristate "Microchip LAN9303/LAN9354 3-ports 10/100 ethernet switch in MDIO managed mode"
 	select NET_DSA_SMSC_LAN9303
 	depends on VLAN_8021Q || VLAN_8021Q=n
 	help
-	  Enable access functions if the SMSC/Microchip LAN9303 is configured
+	  Enable access functions if the Microchip LAN9303/LAN9354 is configured
 	  for MDIO managed mode.
 
 config NET_DSA_VITESSE_VSC73XX
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index 17ae02a56bfe..4ea8c95cc23e 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -22,6 +22,10 @@
  */
 #define LAN9303_CHIP_REV 0x14
 # define LAN9303_CHIP_ID 0x9303
+# define LAN9352_CHIP_ID 0x9352
+# define LAN9353_CHIP_ID 0x9353
+# define LAN9354_CHIP_ID 0x9354
+# define LAN9355_CHIP_ID 0x9355
 #define LAN9303_IRQ_CFG 0x15
 # define LAN9303_IRQ_CFG_IRQ_ENABLE BIT(8)
 # define LAN9303_IRQ_CFG_IRQ_POL BIT(4)
@@ -867,8 +871,9 @@ static int lan9303_check_device(struct lan9303 *chip)
 		return ret;
 	}
 
-	if ((reg >> 16) != LAN9303_CHIP_ID) {
-		dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
+	if (((reg >> 16) != LAN9303_CHIP_ID) &&
+	    ((reg >> 16) != LAN9354_CHIP_ID)) {
+		dev_err(chip->dev, "unexpected device found: LAN%4.4X\n",
 			reg >> 16);
 		return -ENODEV;
 	}
@@ -884,7 +889,7 @@ static int lan9303_check_device(struct lan9303 *chip)
 	if (ret)
 		dev_warn(chip->dev, "failed to disable switching %d\n", ret);
 
-	dev_info(chip->dev, "Found LAN9303 rev. %u\n", reg & 0xffff);
+	dev_info(chip->dev, "Found LAN%4.4X rev. %u\n", (reg >> 16), reg & 0xffff);
 
 	ret = lan9303_detect_phy_setup(chip);
 	if (ret) {
diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
index bbb7032409ba..d12c55fdc811 100644
--- a/drivers/net/dsa/lan9303_mdio.c
+++ b/drivers/net/dsa/lan9303_mdio.c
@@ -158,6 +158,7 @@ static void lan9303_mdio_shutdown(struct mdio_device *mdiodev)
 
 static const struct of_device_id lan9303_mdio_of_match[] = {
 	{ .compatible = "smsc,lan9303-mdio" },
+	{ .compatible = "microchip,lan9354-mdio" },
 	{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, lan9303_mdio_of_match);
-- 
2.17.1

Re: [PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Andrew Lunn]

> -	if ((reg >> 16) != LAN9303_CHIP_ID) {
> -		dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
> +	if (((reg >> 16) != LAN9303_CHIP_ID) &&
> +	    ((reg >> 16) != LAN9354_CHIP_ID)) {
> +		dev_err(chip->dev, "unexpected device found: LAN%4.4X\n",
>  			reg >> 16);
>  		return -ENODEV;
>  	}
> @@ -884,7 +889,7 @@ static int lan9303_check_device(struct lan9303 *chip)
>  	if (ret)
>  		dev_warn(chip->dev, "failed to disable switching %d\n", ret);
>  
> -	dev_info(chip->dev, "Found LAN9303 rev. %u\n", reg & 0xffff);
> +	dev_info(chip->dev, "Found LAN%4.4X rev. %u\n", (reg >> 16), reg & 0xffff);
>  
>  	ret = lan9303_detect_phy_setup(chip);
>  	if (ret) {
> diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
> index bbb7032409ba..d12c55fdc811 100644
> --- a/drivers/net/dsa/lan9303_mdio.c
> +++ b/drivers/net/dsa/lan9303_mdio.c
> @@ -158,6 +158,7 @@ static void lan9303_mdio_shutdown(struct mdio_device *mdiodev)
>  
>  static const struct of_device_id lan9303_mdio_of_match[] = {
>  	{ .compatible = "smsc,lan9303-mdio" },
> +	{ .compatible = "microchip,lan9354-mdio" },

Please validate that what you find on the board actually is what the
compatible says it should be. If you don't validate it, there will be
some DT blobs that have the wrong value, but probe fine. But then you
cannot actually make use of the compatible string in the driver to do
something different between the 9303 and the 9354 because some boards
have the wrong compatible....

     Andrew

RE: [PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Jerry.Ray]

>> -     if ((reg >> 16) != LAN9303_CHIP_ID) {
>> -             dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
>> +     if (((reg >> 16) != LAN9303_CHIP_ID) &&
>> +         ((reg >> 16) != LAN9354_CHIP_ID)) {
>> +             dev_err(chip->dev, "unexpected device found: 
>> + LAN%4.4X\n",
>>                       reg >> 16);
>>               return -ENODEV;
>>       }
>> @@ -884,7 +889,7 @@ static int lan9303_check_device(struct lan9303 *chip)
>>       if (ret)
>>               dev_warn(chip->dev, "failed to disable switching %d\n", 
>> ret);
>>
>> -     dev_info(chip->dev, "Found LAN9303 rev. %u\n", reg & 0xffff);
>> +     dev_info(chip->dev, "Found LAN%4.4X rev. %u\n", (reg >> 16), reg 
>> + & 0xffff);
>>
>>       ret = lan9303_detect_phy_setup(chip);
>>       if (ret) {
>> diff --git a/drivers/net/dsa/lan9303_mdio.c 
>> b/drivers/net/dsa/lan9303_mdio.c index bbb7032409ba..d12c55fdc811 
>> 100644
>> --- a/drivers/net/dsa/lan9303_mdio.c
>> +++ b/drivers/net/dsa/lan9303_mdio.c
>> @@ -158,6 +158,7 @@ static void lan9303_mdio_shutdown(struct 
>> mdio_device *mdiodev)
>>
>>  static const struct of_device_id lan9303_mdio_of_match[] = {
>>       { .compatible = "smsc,lan9303-mdio" },
>> +     { .compatible = "microchip,lan9354-mdio" },
>
>Please validate that what you find on the board actually is what the compatible says it should be. If you don't validate it, there will be some DT blobs that have the wrong value, but probe fine. But then you cannot actually make use of the compatible string in the driver to do something different between the 9303 and the 9354 because some boards have the wrong compatible....
>
>     Andrew
>

At this time, the driver is meant to support both devices equally.  In the future, I will be adding content that only applies to the LAN9354.  That is when I'm planning to add .data to the .compatible entries.

Jerry.

Re: [PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Andrew Lunn]

> >Please validate that what you find on the board actually is what the compatible says it should be. If you don't validate it, there will be some DT blobs that have the wrong value, but probe fine. But then you cannot actually make use of the compatible string in the driver to do something different between the 9303 and the 9354 because some boards have the wrong compatible....

Please configure your mail client to stop corrupting emails. My reply
definitely did not have lines this long.

> >
> >     Andrew
> >
> 

> At this time, the driver is meant to support both devices equally.  In the future, I will be adding content that only applies to the LAN9354.  That is when I'm planning to add .data to the .compatible entries.

Which makes it even more important to validate the compatible against
what is actually on the board. As i said, in its current state, people
are going to get it wrong, and your .data won't work, since it will be
for a different chip to which is actually on the board.

    Andrew

Re: [PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Andrew Lunn]

>  static const struct of_device_id lan9303_mdio_of_match[] = {
>  	{ .compatible = "smsc,lan9303-mdio" },
> +	{ .compatible = "microchip,lan9354-mdio" },
>  	{ /* sentinel */ },

Please add this compatible to
Documentation/devicetree/bindings/net/dsa/lan9303.txt. Better still,
please convert it to YAML.

       Andrew

RE: [PATCH 2/2] net: dsa: LAN9303: Add basic support for LAN9354

[Jerry.Ray]

>>  static const struct of_device_id lan9303_mdio_of_match[] = {
>>       { .compatible = "smsc,lan9303-mdio" },
>> +     { .compatible = "microchip,lan9354-mdio" },
>>       { /* sentinel */ },
>
>Please add this compatible to
>Documentation/devicetree/bindings/net/dsa/lan9303.txt. Better still, please convert it to YAML.
>
>       Andrew
>

I was planning the conversion to YAML as a separate patch as I didn't want to delay this one.

Jerry.

Re: [PATCH 1/2] net: dsa: LAN9303: Add basic support for LAN9354

[Vladimir Oltean]

On Mon, Aug 29, 2022 at 01:00:36PM -0500, Jerry Ray wrote:
> Add initial BYTE_ORDER read to sync to improve driver robustness

Please don't post 2 different patches with the same commit message.
I think here, the first paragraph is what the commit message should
actually be.

> 
> The lan9303 expects two mdio read transactions back-to-back to read a 32-bit
> register. The first read transaction causes the other half of the 32-bit
> register to get latched.  The subsequent read returns the latched second half
> of the 32-bit read. The BYTE_ORDER register is an exception to this rule. As
> it is a constant value, there is no need to latch the second half. We read
> this register first in case there were reads during the boot loader process
> that might have occurred prior to this driver taking over ownership of
> accessing this device.
> 
> This patch has been tested on the SAMA5D3-EDS with a LAN9303 RMII daughter
> card.

Is this patch fixing a problem for any existing platforms supported by
this driver?

> 
> Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
> ---
>  drivers/net/dsa/lan9303-core.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
> index e03ff1f267bb..17ae02a56bfe 100644
> --- a/drivers/net/dsa/lan9303-core.c
> +++ b/drivers/net/dsa/lan9303-core.c
> @@ -32,6 +32,7 @@
>  #define LAN9303_INT_EN 0x17
>  # define LAN9303_INT_EN_PHY_INT2_EN BIT(27)
>  # define LAN9303_INT_EN_PHY_INT1_EN BIT(26)
> +#define LAN9303_BYTE_ORDER 0x19
>  #define LAN9303_HW_CFG 0x1D
>  # define LAN9303_HW_CFG_READY BIT(27)
>  # define LAN9303_HW_CFG_AMDX_EN_PORT2 BIT(26)
> @@ -847,9 +848,10 @@ static int lan9303_check_device(struct lan9303 *chip)
>  	int ret;
>  	u32 reg;
>  
> -	ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
> +	// Dummy read to ensure MDIO access is in 32-bit sync.

C-style comments /* */ are more typical in the Linux kernel coding style.

> +	ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, &reg);

Pretty strange to see the dummy read in lan9303_check_device().
Bootloader leaving things in a messy state is only a problem if we don't
have a reset GPIO, right?

How about introducing the logic here, right in lan9303_probe():

	lan9303_handle_reset(chip);

	if (!chip->reset_gpio) {
		/* Dummy read to ensure MDIO access is in 32-bit sync. */
		ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, &reg);
		if (ret) {
			dev_err(chip->dev, "failed to access the device: %pe\n",
				ERR_PTR(ret));
			return ret;
		}
	}

	ret = lan9303_check_device(chip);

>  	if (ret) {
> -		dev_err(chip->dev, "failed to read chip revision register: %d\n",
> +		dev_err(chip->dev, "failed to access the device: %d\n",
>  			ret);
>  		if (!chip->reset_gpio) {
>  			dev_dbg(chip->dev,

The context here reads:
		if (!chip->reset_gpio) {
			dev_dbg(chip->dev,
				"hint: maybe failed due to missing reset GPIO\n");
		}

Is the comment still accurate after the change, or do you feel that it
can be removed? Looks like you are fixing a known issue.

> @@ -858,6 +860,13 @@ static int lan9303_check_device(struct lan9303 *chip)
>  		return ret;
>  	}
>  
> +	ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
> +	if (ret) {
> +		dev_err(chip->dev, "failed to read chip revision register: %d\n",
> +			ret);
> +		return ret;
> +	}
> +
>  	if ((reg >> 16) != LAN9303_CHIP_ID) {
>  		dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
>  			reg >> 16);
> -- 
> 2.17.1
> 

RE: [PATCH 1/2] net: dsa: LAN9303: Add basic support for LAN9354

[Jerry.Ray]

>On Mon, Aug 29, 2022 at 01:00:36PM -0500, Jerry Ray wrote:
>> Add initial BYTE_ORDER read to sync to improve driver robustness
>
>Please don't post 2 different patches with the same commit message.
>I think here, the first paragraph is what the commit message should actually be.
>

Understood.

>>
>> The lan9303 expects two mdio read transactions back-to-back to read a 
>> 32-bit register. The first read transaction causes the other half of 
>> the 32-bit register to get latched.  The subsequent read returns the 
>> latched second half of the 32-bit read. The BYTE_ORDER register is an 
>> exception to this rule. As it is a constant value, there is no need to 
>> latch the second half. We read this register first in case there were 
>> reads during the boot loader process that might have occurred prior to 
>> this driver taking over ownership of accessing this device.
>>
>> This patch has been tested on the SAMA5D3-EDS with a LAN9303 RMII 
>> daughter card.
>
>Is this patch fixing a problem for any existing platforms supported by this driver?
>

This patch is fixing a problem I ran into that probably doesn't occur under
normal use case conditions.  I was probing around on the mdio bus within
u-boot, then booting linux.  This change makes the linux driver more robust
(tolerant) to this situation.

>>
>> Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
>> ---
>>  drivers/net/dsa/lan9303-core.c | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/dsa/lan9303-core.c 
>> b/drivers/net/dsa/lan9303-core.c index e03ff1f267bb..17ae02a56bfe 
>> 100644
>> --- a/drivers/net/dsa/lan9303-core.c
>> +++ b/drivers/net/dsa/lan9303-core.c
>> @@ -32,6 +32,7 @@
>>  #define LAN9303_INT_EN 0x17
>>  # define LAN9303_INT_EN_PHY_INT2_EN BIT(27)  # define 
>> LAN9303_INT_EN_PHY_INT1_EN BIT(26)
>> +#define LAN9303_BYTE_ORDER 0x19
>>  #define LAN9303_HW_CFG 0x1D
>>  # define LAN9303_HW_CFG_READY BIT(27)  # define 
>> LAN9303_HW_CFG_AMDX_EN_PORT2 BIT(26) @@ -847,9 +848,10 @@ static int 
>> lan9303_check_device(struct lan9303 *chip)
>>       int ret;
>>       u32 reg;
>>
>> -     ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
>> +     // Dummy read to ensure MDIO access is in 32-bit sync.
>
>C-style comments /* */ are more typical in the Linux kernel coding style.
>

Understood.

>> +     ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, &reg);
>
>Pretty strange to see the dummy read in lan9303_check_device().
>Bootloader leaving things in a messy state is only a problem if we don't have a reset GPIO, right?
>
>How about introducing the logic here, right in lan9303_probe():
>
>        lan9303_handle_reset(chip);
>
>        if (!chip->reset_gpio) {
>                /* Dummy read to ensure MDIO access is in 32-bit sync. */
>                ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, &reg);
>                if (ret) {
>                        dev_err(chip->dev, "failed to access the device: %pe\n",
>                                ERR_PTR(ret));
>                        return ret;
>                }
>        }
>
>        ret = lan9303_check_device(chip);
>

I'll look to move it.

>>       if (ret) {
>> -             dev_err(chip->dev, "failed to read chip revision register: %d\n",
>> +             dev_err(chip->dev, "failed to access the device: %d\n",
>>                       ret);
>>               if (!chip->reset_gpio) {
>>                       dev_dbg(chip->dev,
>
>The context here reads:
>                if (!chip->reset_gpio) {
>                        dev_dbg(chip->dev,
>                                "hint: maybe failed due to missing reset GPIO\n");
>                }
>
>Is the comment still accurate after the change, or do you feel that it can be removed? Looks like you are fixing a known issue.
>

The 'hint' message applies to the first chip access, which has now changed to the BYTE_ORDER read.

>> @@ -858,6 +860,13 @@ static int lan9303_check_device(struct lan9303 *chip)
>>               return ret;
>>       }
>>
>> +     ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, &reg);
>> +     if (ret) {
>> +             dev_err(chip->dev, "failed to read chip revision register: %d\n",
>> +                     ret);
>> +             return ret;
>> +     }
>> +
>>       if ((reg >> 16) != LAN9303_CHIP_ID) {
>>               dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n",
>>                       reg >> 16);
>> --
>> 2.17.1
>>

Thanks,
Jerry.