This patch series contain the below updates,
- Fixes on the Microchip LAN8670/1/2 10BASE-T1S PHYs support in the
net/phy/microchip_t1s.c driver.
- Adds support for the Microchip LAN8650/1 Rev.B0 10BASE-T1S Internal
PHYs in the net/phy/microchip_t1s.c driver.
Changes:
v2:
- Updated cover letter contents.
- Modified driver description is more generic as it is common for all the
Microchip 10BASE-T1S PHYs.
- Replaced read-modify-write code with phy_modify_mmd function.
- Moved */ to the same line for the single line comments.
- Changed the type int to u16 for LAN865X Rev.B0 fixup registers
declaration.
- Changed all the comments starting letter to upper case for the
consistency.
- Removed return value check of phy_read_mmd and returned directly in the
last line of the function lan865x_revb0_indirect_read.
- Used reverse christmas notation wherever is possible.
- Used FIELD_PREP instead of << in all the places.
- Used 4 byte representation for all the register addresses and values
for consistency.
- Comment for indirect read is modified.
- Implemented "Reset Complete" status polling in config_init.
- Function lan865x_setup_cfgparam is split into multiple functions for
readability.
- Reference to AN1760 document is added in the comment.
- Removed interrupt disabling code as it is not needed.
- Provided meaningful macros for the LAN865X Rev.B0 indirect read
registers and control.
- Replaced 0x10 with BIT(4).
- Removed collision detection disable/enable code as it can be done with
a separate patch later.
v3:
- Comment for phy_modify_mmd() is extended to indicate that the write is
not required if the register already has the required value.
- Commit message is updated for the not supported hardware revisions
0x0007C160 (Rev.A0) and 0x0007C161 (Rev.B0) since they are never
released to production.
- Commit message is updated to indicate that the Reset Complete interrupt
will be cleared when the STS2 register read is done.
- Corrected the typo in the offset calculation comment.
- Used reverse christmas notation for the local variable declarations.
Parthiban Veerasooran (6):
net: phy: microchip_t1s: modify driver description to be more generic
net: phy: microchip_t1s: replace read-modify-write code with
phy_modify_mmd
net: phy: microchip_t1s: update LAN867x PHY supported revision number
net: phy: microchip_t1s: fix reset complete status handling
net: phy: microchip_t1s: remove unnecessary interrupts disabling code
net: phy: microchip_t1s: add support for Microchip LAN865x Rev.B0 PHYs
drivers/net/phy/microchip_t1s.c | 269 +++++++++++++++++++++++++++-----
1 file changed, 229 insertions(+), 40 deletions(-)
--
2.34.1
Remove LAN867X from the driver description as this driver is common for
all the Microchip 10BASE-T1S PHYs.
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Parthiban Veerasooran <[email protected]>
---
drivers/net/phy/microchip_t1s.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
index 094967b3c111..a42a6bb6e3bd 100644
--- a/drivers/net/phy/microchip_t1s.c
+++ b/drivers/net/phy/microchip_t1s.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Driver for Microchip 10BASE-T1S LAN867X PHY
+ * Driver for Microchip 10BASE-T1S PHYs
*
* Support: Microchip Phys:
* lan8670, lan8671, lan8672
@@ -111,7 +111,7 @@ static int lan867x_read_status(struct phy_device *phydev)
return 0;
}
-static struct phy_driver lan867x_driver[] = {
+static struct phy_driver microchip_t1s_driver[] = {
{
PHY_ID_MATCH_MODEL(PHY_ID_LAN867X),
.name = "LAN867X",
@@ -124,7 +124,7 @@ static struct phy_driver lan867x_driver[] = {
}
};
-module_phy_driver(lan867x_driver);
+module_phy_driver(microchip_t1s_driver);
static struct mdio_device_id __maybe_unused tbl[] = {
{ PHY_ID_MATCH_MODEL(PHY_ID_LAN867X) },
@@ -133,6 +133,6 @@ static struct mdio_device_id __maybe_unused tbl[] = {
MODULE_DEVICE_TABLE(mdio, tbl);
-MODULE_DESCRIPTION("Microchip 10BASE-T1S lan867x Phy driver");
+MODULE_DESCRIPTION("Microchip 10BASE-T1S PHYs driver");
MODULE_AUTHOR("Ramón Nordin Rodriguez");
MODULE_LICENSE("GPL");
--
2.34.1
By default, except Reset Complete interrupt in the Interrupt Mask 2
Register all other interrupts are disabled/masked. As Reset Complete
status is already handled, it doesn't make sense to disable it.
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: Parthiban Veerasooran <[email protected]>
---
drivers/net/phy/microchip_t1s.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
index 05a88b561993..6f9e197d8623 100644
--- a/drivers/net/phy/microchip_t1s.c
+++ b/drivers/net/phy/microchip_t1s.c
@@ -12,8 +12,6 @@
#define PHY_ID_LAN867X_REVB1 0x0007C162
-#define LAN867X_REG_IRQ_1_CTL 0x001C
-#define LAN867X_REG_IRQ_2_CTL 0x001D
#define LAN867X_REG_STS2 0x0019
#define LAN867x_RESET_COMPLETE_STS BIT(11)
@@ -106,17 +104,7 @@ static int lan867x_revb1_config_init(struct phy_device *phydev)
return err;
}
- /* None of the interrupts in the lan867x phy seem relevant.
- * Other phys inspect the link status and call phy_trigger_machine
- * in the interrupt handler.
- * This phy does not support link status, and thus has no interrupt
- * for it either.
- * So we'll just disable all interrupts on the chip.
- */
- err = phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_IRQ_1_CTL, 0xFFFF);
- if (err != 0)
- return err;
- return phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_IRQ_2_CTL, 0xFFFF);
+ return 0;
}
static int lan867x_read_status(struct phy_device *phydev)
--
2.34.1
As per the datasheet DS-LAN8670-1-2-60001573C.pdf, the Reset Complete
status bit in the STS2 register has to be checked before proceeding to
the initial configuration. Reading STS2 register will also clear the
Reset Complete interrupt which is non-maskable.
Signed-off-by: Parthiban Veerasooran <[email protected]>
---
drivers/net/phy/microchip_t1s.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
index 8f29d9802131..05a88b561993 100644
--- a/drivers/net/phy/microchip_t1s.c
+++ b/drivers/net/phy/microchip_t1s.c
@@ -14,6 +14,9 @@
#define LAN867X_REG_IRQ_1_CTL 0x001C
#define LAN867X_REG_IRQ_2_CTL 0x001D
+#define LAN867X_REG_STS2 0x0019
+
+#define LAN867x_RESET_COMPLETE_STS BIT(11)
/* The arrays below are pulled from the following table from AN1699
* Access MMD Address Value Mask
@@ -65,6 +68,27 @@ static int lan867x_revb1_config_init(struct phy_device *phydev)
int err;
+ /* Read STS2 register and check for the Reset Complete status to do the
+ * init configuration. If the Reset Complete is not set, wait for 5us
+ * and then read STS2 register again and check for Reset Complete status.
+ * Still if it is failed then declare PHY reset error or else proceed
+ * for the PHY initial register configuration.
+ */
+ err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
+ if (err < 0)
+ return err;
+
+ if (!(err & LAN867x_RESET_COMPLETE_STS)) {
+ udelay(5);
+ err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
+ if (err < 0)
+ return err;
+ if (!(err & LAN867x_RESET_COMPLETE_STS)) {
+ phydev_err(phydev, "PHY reset failed\n");
+ return -ENODEV;
+ }
+ }
+
/* Read-Modified Write Pseudocode (from AN1699)
* current_val = read_register(mmd, addr) // Read current register value
* new_val = current_val AND (NOT mask) // Clear bit fields to be written
--
2.34.1
Replace read-modify-write code in the lan867x_config_init function to
avoid handling data type mismatch and to simplify the code.
Signed-off-by: Parthiban Veerasooran <[email protected]>
---
drivers/net/phy/microchip_t1s.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
index a42a6bb6e3bd..b5b5a95fa6e7 100644
--- a/drivers/net/phy/microchip_t1s.c
+++ b/drivers/net/phy/microchip_t1s.c
@@ -31,19 +31,19 @@
* W 0x1F 0x0099 0x7F80 ------
*/
-static const int lan867x_fixup_registers[12] = {
+static const u32 lan867x_fixup_registers[12] = {
0x00D0, 0x00D1, 0x0084, 0x0085,
0x008A, 0x0087, 0x0088, 0x008B,
0x0080, 0x00F1, 0x0096, 0x0099,
};
-static const int lan867x_fixup_values[12] = {
+static const u16 lan867x_fixup_values[12] = {
0x0002, 0x0000, 0x3380, 0x0006,
0xC000, 0x801C, 0x033F, 0x0404,
0x0600, 0x2400, 0x2000, 0x7F80,
};
-static const int lan867x_fixup_masks[12] = {
+static const u16 lan867x_fixup_masks[12] = {
0x0E03, 0x0300, 0xFFC0, 0x000F,
0xF800, 0x801C, 0x1FFF, 0xFFFF,
0x0600, 0x7F00, 0x2000, 0xFFFF,
@@ -63,23 +63,22 @@ static int lan867x_config_init(struct phy_device *phydev)
* used, which might then write the same value back as read + modified.
*/
- int reg_value;
int err;
- int reg;
/* Read-Modified Write Pseudocode (from AN1699)
* current_val = read_register(mmd, addr) // Read current register value
* new_val = current_val AND (NOT mask) // Clear bit fields to be written
* new_val = new_val OR value // Set bits
- * write_register(mmd, addr, new_val) // Write back updated register value
+ * write_register(mmd, addr, new_val) // Write back updated register value.
+ * Although AN1699 says Read, Modify, Write, the write is not required if
+ * the register already has the required value.
*/
for (int i = 0; i < ARRAY_SIZE(lan867x_fixup_registers); i++) {
- reg = lan867x_fixup_registers[i];
- reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
- reg_value &= ~lan867x_fixup_masks[i];
- reg_value |= lan867x_fixup_values[i];
- err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
- if (err != 0)
+ err = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
+ lan867x_fixup_registers[i],
+ lan867x_fixup_masks[i],
+ lan867x_fixup_values[i]);
+ if (err)
return err;
}
--
2.34.1
On Wed, May 24, 2023 at 08:15:35PM +0530, Parthiban Veerasooran wrote:
> Replace read-modify-write code in the lan867x_config_init function to
> avoid handling data type mismatch and to simplify the code.
>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
On Wed, May 24, 2023 at 08:15:37PM +0530, Parthiban Veerasooran wrote:
> As per the datasheet DS-LAN8670-1-2-60001573C.pdf, the Reset Complete
> status bit in the STS2 register has to be checked before proceeding to
> the initial configuration. Reading STS2 register will also clear the
> Reset Complete interrupt which is non-maskable.
>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
On Wed, May 24, 2023 at 08:15:35PM +0530, Parthiban Veerasooran wrote:
> Replace read-modify-write code in the lan867x_config_init function to
> avoid handling data type mismatch and to simplify the code.
>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
> ---
> drivers/net/phy/microchip_t1s.c | 23 +++++++++++------------
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
> index a42a6bb6e3bd..b5b5a95fa6e7 100644
> --- a/drivers/net/phy/microchip_t1s.c
> +++ b/drivers/net/phy/microchip_t1s.c
> @@ -31,19 +31,19 @@
> * W 0x1F 0x0099 0x7F80 ------
> */
>
> -static const int lan867x_fixup_registers[12] = {
> +static const u32 lan867x_fixup_registers[12] = {
> 0x00D0, 0x00D1, 0x0084, 0x0085,
> 0x008A, 0x0087, 0x0088, 0x008B,
> 0x0080, 0x00F1, 0x0096, 0x0099,
> };
>
> -static const int lan867x_fixup_values[12] = {
> +static const u16 lan867x_fixup_values[12] = {
> 0x0002, 0x0000, 0x3380, 0x0006,
> 0xC000, 0x801C, 0x033F, 0x0404,
> 0x0600, 0x2400, 0x2000, 0x7F80,
> };
>
> -static const int lan867x_fixup_masks[12] = {
> +static const u16 lan867x_fixup_masks[12] = {
> 0x0E03, 0x0300, 0xFFC0, 0x000F,
> 0xF800, 0x801C, 0x1FFF, 0xFFFF,
> 0x0600, 0x7F00, 0x2000, 0xFFFF,
> @@ -63,23 +63,22 @@ static int lan867x_config_init(struct phy_device *phydev)
> * used, which might then write the same value back as read + modified.
> */
>
> - int reg_value;
> int err;
> - int reg;
>
> /* Read-Modified Write Pseudocode (from AN1699)
> * current_val = read_register(mmd, addr) // Read current register value
> * new_val = current_val AND (NOT mask) // Clear bit fields to be written
> * new_val = new_val OR value // Set bits
> - * write_register(mmd, addr, new_val) // Write back updated register value
> + * write_register(mmd, addr, new_val) // Write back updated register value.
> + * Although AN1699 says Read, Modify, Write, the write is not required if
> + * the register already has the required value.
> */
Nitpick, I think this block comment can be reduced to:
/* The following block deviates from AN1699 which states that a values
* should be written back, even if unmodified.
* Which is not necessary, so it's safe to use phy_modify_mmd here.*/
The comment I added was intended to describe why I was doing weird
things, but now I think it's more interesting to describe why we're
deviating from the AN.
Or the block comment could be dropped all togheter, I'm guessing no one
is going to consult the AN if things 'just work'
> for (int i = 0; i < ARRAY_SIZE(lan867x_fixup_registers); i++) {
> - reg = lan867x_fixup_registers[i];
> - reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
> - reg_value &= ~lan867x_fixup_masks[i];
> - reg_value |= lan867x_fixup_values[i];
> - err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
> - if (err != 0)
> + err = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
> + lan867x_fixup_registers[i],
> + lan867x_fixup_masks[i],
> + lan867x_fixup_values[i]);
> + if (err)
> return err;
> }
>
> --
> 2.34.1
>
On Wed, May 24, 2023 at 08:15:35PM +0530, Parthiban Veerasooran wrote:
> Replace read-modify-write code in the lan867x_config_init function to
> avoid handling data type mismatch and to simplify the code.
>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
> ---
> drivers/net/phy/microchip_t1s.c | 23 +++++++++++------------
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
> index a42a6bb6e3bd..b5b5a95fa6e7 100644
> --- a/drivers/net/phy/microchip_t1s.c
> +++ b/drivers/net/phy/microchip_t1s.c
> @@ -31,19 +31,19 @@
> * W 0x1F 0x0099 0x7F80 ------
> */
>
> -static const int lan867x_fixup_registers[12] = {
> +static const u32 lan867x_fixup_registers[12] = {
> 0x00D0, 0x00D1, 0x0084, 0x0085,
> 0x008A, 0x0087, 0x0088, 0x008B,
> 0x0080, 0x00F1, 0x0096, 0x0099,
> };
>
> -static const int lan867x_fixup_values[12] = {
> +static const u16 lan867x_fixup_values[12] = {
> 0x0002, 0x0000, 0x3380, 0x0006,
> 0xC000, 0x801C, 0x033F, 0x0404,
> 0x0600, 0x2400, 0x2000, 0x7F80,
> };
>
> -static const int lan867x_fixup_masks[12] = {
> +static const u16 lan867x_fixup_masks[12] = {
> 0x0E03, 0x0300, 0xFFC0, 0x000F,
> 0xF800, 0x801C, 0x1FFF, 0xFFFF,
> 0x0600, 0x7F00, 0x2000, 0xFFFF,
> @@ -63,23 +63,22 @@ static int lan867x_config_init(struct phy_device *phydev)
> * used, which might then write the same value back as read + modified.
> */
>
> - int reg_value;
> int err;
> - int reg;
>
> /* Read-Modified Write Pseudocode (from AN1699)
> * current_val = read_register(mmd, addr) // Read current register value
> * new_val = current_val AND (NOT mask) // Clear bit fields to be written
> * new_val = new_val OR value // Set bits
> - * write_register(mmd, addr, new_val) // Write back updated register value
> + * write_register(mmd, addr, new_val) // Write back updated register value.
> + * Although AN1699 says Read, Modify, Write, the write is not required if
> + * the register already has the required value.
> */
> for (int i = 0; i < ARRAY_SIZE(lan867x_fixup_registers); i++) {
> - reg = lan867x_fixup_registers[i];
> - reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
> - reg_value &= ~lan867x_fixup_masks[i];
> - reg_value |= lan867x_fixup_values[i];
> - err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
> - if (err != 0)
> + err = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
> + lan867x_fixup_registers[i],
> + lan867x_fixup_masks[i],
> + lan867x_fixup_values[i]);
This change answers an uncertainty in the block comment in the top of
this func, pasted here for your convenience
/* HW quirk: Microchip states in the application note (AN1699) for the phy
* that a set of read-modify-write (rmw) operations has to be performed
* on a set of seemingly magic registers.
* The result of these operations is just described as 'optimal performance'
* Microchip gives no explanation as to what these mmd regs do,
* in fact they are marked as reserved in the datasheet.
* It is unclear if phy_modify_mmd would be safe to use or if a write
* really has to happen to each register.
* In order to exactly conform to what is stated in the AN phy_write_mmd is
* used, which might then write the same value back as read + modified.
*/
This change also invalidates most of the comment. I think this should be
reduced to something along the lines of:
/* HW quirk: Microchip states in the application note (AN1699) for the phy
* that a set of read-modify-write (rmw) operations has to be performed
* on a set of seemingly magic registers.
* The result of these operations is just described as 'optimal performance'
* Microchip gives no explanation as to what these mmd regs do,
* in fact they are marked as reserved in the datasheet.*/
Additionally I don't mind it if you change the tone of the comment. This was brought
up in the sitdown we had, where it was explained from Microchip that
documenting what the reg operations actually does would expose to much
of the internal workings of the chip.
Possibly this comment should move down to where the fixup reg operations
are performed, and replace the comment about the 'read write modify'
stuff all togheter.
In my opinion I kind of loose context about what the func does when it
first explains the fixup stuff, then actually does something with the
STS2 regs, and finally actually does the fixup.
> + if (err)
> return err;
> }
>
> --
> 2.34.1
>
> This change also invalidates most of the comment. I think this should be
> reduced to something along the lines of:
> /* HW quirk: Microchip states in the application note (AN1699) for the phy
> * that a set of read-modify-write (rmw) operations has to be performed
> * on a set of seemingly magic registers.
> * The result of these operations is just described as 'optimal performance'
> * Microchip gives no explanation as to what these mmd regs do,
> * in fact they are marked as reserved in the datasheet.*/
I agree the comments should be reviewed in light of these changes.
>
> Additionally I don't mind it if you change the tone of the comment. This was brought
> up in the sitdown we had, where it was explained from Microchip that
> documenting what the reg operations actually does would expose to much
> of the internal workings of the chip.
They cannot care too much, or the firmware in the PHY would do this
where it is all hidden away.
Andrew
On Wed, May 24, 2023 at 08:15:34PM +0530, Parthiban Veerasooran wrote:
> Remove LAN867X from the driver description as this driver is common for
> all the Microchip 10BASE-T1S PHYs.
>
> Reviewed-by: Andrew Lunn <[email protected]>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
> ---
Reviewed-by: Ram?n Nordin Rodriguez <[email protected]>
> + /* Read STS2 register and check for the Reset Complete status to do the
> + * init configuration. If the Reset Complete is not set, wait for 5us
> + * and then read STS2 register again and check for Reset Complete status.
> + * Still if it is failed then declare PHY reset error or else proceed
> + * for the PHY initial register configuration.
> + */
> + err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
> + if (err < 0)
> + return err;
> +
> + if (!(err & LAN867x_RESET_COMPLETE_STS)) {
> + udelay(5);
> + err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
> + if (err < 0)
> + return err;
> + if (!(err & LAN867x_RESET_COMPLETE_STS)) {
> + phydev_err(phydev, "PHY reset failed\n");
> + return -ENODEV;
> + }
> + }
This comment explains exactly what the code does, which is also obvious
from reading the code. A meaningful comment would be explaining why the
state can change 5us later.
On Wed, May 24, 2023 at 08:15:38PM +0530, Parthiban Veerasooran wrote:
> By default, except Reset Complete interrupt in the Interrupt Mask 2
> Register all other interrupts are disabled/masked. As Reset Complete
> status is already handled, it doesn't make sense to disable it.
>
> Reviewed-by: Andrew Lunn <[email protected]>
> Signed-off-by: Parthiban Veerasooran <[email protected]>
> ---
Reviewed-by: Ram?n Nordin Rodriguez <[email protected]>
Tested-by: Ram?n Nordin Rodriguez <[email protected]>
Testing has been pretty rudamentary, but the procedure has been as
follows:
* Hotplug 2 devices
* Unload and reload the lkm
* Ping 2 devices over ipv6 link local addresses
All testing has been performed with the EVB-LAN8670-USB
Hi Ramon,
On 25/05/23 8:38 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Wed, May 24, 2023 at 08:15:35PM +0530, Parthiban Veerasooran wrote:
>> Replace read-modify-write code in the lan867x_config_init function to
>> avoid handling data type mismatch and to simplify the code.
>>
>> Signed-off-by: Parthiban Veerasooran <[email protected]>
>> ---
>> drivers/net/phy/microchip_t1s.c | 23 +++++++++++------------
>> 1 file changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
>> index a42a6bb6e3bd..b5b5a95fa6e7 100644
>> --- a/drivers/net/phy/microchip_t1s.c
>> +++ b/drivers/net/phy/microchip_t1s.c
>> @@ -31,19 +31,19 @@
>> * W 0x1F 0x0099 0x7F80 ------
>> */
>>
>> -static const int lan867x_fixup_registers[12] = {
>> +static const u32 lan867x_fixup_registers[12] = {
>> 0x00D0, 0x00D1, 0x0084, 0x0085,
>> 0x008A, 0x0087, 0x0088, 0x008B,
>> 0x0080, 0x00F1, 0x0096, 0x0099,
>> };
>>
>> -static const int lan867x_fixup_values[12] = {
>> +static const u16 lan867x_fixup_values[12] = {
>> 0x0002, 0x0000, 0x3380, 0x0006,
>> 0xC000, 0x801C, 0x033F, 0x0404,
>> 0x0600, 0x2400, 0x2000, 0x7F80,
>> };
>>
>> -static const int lan867x_fixup_masks[12] = {
>> +static const u16 lan867x_fixup_masks[12] = {
>> 0x0E03, 0x0300, 0xFFC0, 0x000F,
>> 0xF800, 0x801C, 0x1FFF, 0xFFFF,
>> 0x0600, 0x7F00, 0x2000, 0xFFFF,
>> @@ -63,23 +63,22 @@ static int lan867x_config_init(struct phy_device *phydev)
>> * used, which might then write the same value back as read + modified.
>> */
>>
>> - int reg_value;
>> int err;
>> - int reg;
>>
>> /* Read-Modified Write Pseudocode (from AN1699)
>> * current_val = read_register(mmd, addr) // Read current register value
>> * new_val = current_val AND (NOT mask) // Clear bit fields to be written
>> * new_val = new_val OR value // Set bits
>> - * write_register(mmd, addr, new_val) // Write back updated register value
>> + * write_register(mmd, addr, new_val) // Write back updated register value.
>> + * Although AN1699 says Read, Modify, Write, the write is not required if
>> + * the register already has the required value.
>> */
>
> Nitpick, I think this block comment can be reduced to:
> /* The following block deviates from AN1699 which states that a values
> * should be written back, even if unmodified.
> * Which is not necessary, so it's safe to use phy_modify_mmd here.*/
>
> The comment I added was intended to describe why I was doing weird
> things, but now I think it's more interesting to describe why we're
> deviating from the AN.
>
> Or the block comment could be dropped all togheter, I'm guessing no one
> is going to consult the AN if things 'just work'
>
By consolidating all your comments in the other emails as well on this
2nd patch, do you agree for my below proposal?
We will remove all block comments and simply put AN1699 reference as we
did for lan865x_revb0_config_init with a small addition on top of
phy_modify_mmd for loop? so the comment will look like below,
/* Reference to AN1699
*
https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
* AN1699 says Read, Modify, Write, but the Write is not required if
the register already has the required value. So it is safe to use
phy_modify_mmd here.
*/
So in future, if someone wants to know about this configuration they can
simply refer the AN1699.
What do you think?
Best Regards,
Parthiban V
>> for (int i = 0; i < ARRAY_SIZE(lan867x_fixup_registers); i++) {
>> - reg = lan867x_fixup_registers[i];
>> - reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
>> - reg_value &= ~lan867x_fixup_masks[i];
>> - reg_value |= lan867x_fixup_values[i];
>> - err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
>> - if (err != 0)
>> + err = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
>> + lan867x_fixup_registers[i],
>> + lan867x_fixup_masks[i],
>> + lan867x_fixup_values[i]);
>> + if (err)
>> return err;
>> }
>>
>> --
>> 2.34.1
>>
Hi Ramon,
On 25/05/23 11:56 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> + /* Read STS2 register and check for the Reset Complete status to do the
>> + * init configuration. If the Reset Complete is not set, wait for 5us
>> + * and then read STS2 register again and check for Reset Complete status.
>> + * Still if it is failed then declare PHY reset error or else proceed
>> + * for the PHY initial register configuration.
>> + */
>> + err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
>> + if (err < 0)
>> + return err;
>> +
>> + if (!(err & LAN867x_RESET_COMPLETE_STS)) {
>> + udelay(5);
>> + err = phy_read_mmd(phydev, MDIO_MMD_VEND2, LAN867X_REG_STS2);
>> + if (err < 0)
>> + return err;
>> + if (!(err & LAN867x_RESET_COMPLETE_STS)) {
>> + phydev_err(phydev, "PHY reset failed\n");
>> + return -ENODEV;
>> + }
>> + }
>
> This comment explains exactly what the code does, which is also obvious
> from reading the code. A meaningful comment would be explaining why the
> state can change 5us later.
>
As per design, LAN867x reset to be completed by 3us. Just for a safer
side it is recommended to use 5us. With the assumption of more than 3us
completion, the first read checks for the Reset Complete. If the
config_init is more faster, then once again checks for it after 5us.
As you mentioned, can we remove the existing block comment as it
explains the code and add the above comment to explain 5us delay.
What is your opinion on this proposal?
Best Regards,
Parthiban V
On Fri, May 26, 2023 at 05:48:25AM +0000, [email protected] wrote:
> Hi Ramon,
> > Nitpick, I think this block comment can be reduced to:
> > /* The following block deviates from AN1699 which states that a values
> > * should be written back, even if unmodified.
> > * Which is not necessary, so it's safe to use phy_modify_mmd here.*/
> >
> > The comment I added was intended to describe why I was doing weird
> > things, but now I think it's more interesting to describe why we're
> > deviating from the AN.
> >
> > Or the block comment could be dropped all togheter, I'm guessing no one
> > is going to consult the AN if things 'just work'
> >
> By consolidating all your comments in the other emails as well on this
> 2nd patch, do you agree for my below proposal?
>
> We will remove all block comments and simply put AN1699 reference as we
> did for lan865x_revb0_config_init with a small addition on top of
> phy_modify_mmd for loop? so the comment will look like below,
>
> /* Reference to AN1699
> *
> https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
> * AN1699 says Read, Modify, Write, but the Write is not required if
> the register already has the required value. So it is safe to use
> phy_modify_mmd here.
> */
>
> So in future, if someone wants to know about this configuration they can
> simply refer the AN1699.
>
> What do you think?
>
I'm not sure about the link, resources have a tendency to move.
Otherwise LGTM
> Best Regards,
> Parthiban V
On Fri, May 26, 2023 at 06:00:08AM +0000, [email protected] wrote:
> Hi Ramon,
> >> + /* Read STS2 register and check for the Reset Complete status to do the
> >> + * init configuration. If the Reset Complete is not set, wait for 5us
> >> + * and then read STS2 register again and check for Reset Complete status.
> >> + * Still if it is failed then declare PHY reset error or else proceed
> >> + * for the PHY initial register configuration.
> >> + */
> >
> > This comment explains exactly what the code does, which is also obvious
> > from reading the code. A meaningful comment would be explaining why the
> > state can change 5us later.
> >
> As per design, LAN867x reset to be completed by 3us. Just for a safer
> side it is recommended to use 5us. With the assumption of more than 3us
> completion, the first read checks for the Reset Complete. If the
> config_init is more faster, then once again checks for it after 5us.
>
> As you mentioned, can we remove the existing block comment as it
> explains the code and add the above comment to explain 5us delay.
> What is your opinion on this proposal?
>
> Best Regards,
> Parthiban V
>
I'd suggest the following
/*The chip completes a reset in 3us, we might get here earlier than that,
as an added margin we'll conditionally sleep 5us*/
Hi Ramon,
On 26/05/23 12:44 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, May 26, 2023 at 06:00:08AM +0000, [email protected] wrote:
>> Hi Ramon,
>>>> + /* Read STS2 register and check for the Reset Complete status to do the
>>>> + * init configuration. If the Reset Complete is not set, wait for 5us
>>>> + * and then read STS2 register again and check for Reset Complete status.
>>>> + * Still if it is failed then declare PHY reset error or else proceed
>>>> + * for the PHY initial register configuration.
>>>> + */
>>>
>>> This comment explains exactly what the code does, which is also obvious
>>> from reading the code. A meaningful comment would be explaining why the
>>> state can change 5us later.
>>>
>> As per design, LAN867x reset to be completed by 3us. Just for a safer
>> side it is recommended to use 5us. With the assumption of more than 3us
>> completion, the first read checks for the Reset Complete. If the
>> config_init is more faster, then once again checks for it after 5us.
>>
>> As you mentioned, can we remove the existing block comment as it
>> explains the code and add the above comment to explain 5us delay.
>> What is your opinion on this proposal?
>>
>> Best Regards,
>> Parthiban V
>>
>
> I'd suggest the following
> /*The chip completes a reset in 3us, we might get here earlier than that,
> as an added margin we'll conditionally sleep 5us*/
Ok I will use this proposal in the next version.
Best Regards,
Parthiban V
On 26/05/23 12:40 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Fri, May 26, 2023 at 05:48:25AM +0000, [email protected] wrote:
>> Hi Ramon,
>>> Nitpick, I think this block comment can be reduced to:
>>> /* The following block deviates from AN1699 which states that a values
>>> * should be written back, even if unmodified.
>>> * Which is not necessary, so it's safe to use phy_modify_mmd here.*/
>>>
>>> The comment I added was intended to describe why I was doing weird
>>> things, but now I think it's more interesting to describe why we're
>>> deviating from the AN.
>>>
>>> Or the block comment could be dropped all togheter, I'm guessing no one
>>> is going to consult the AN if things 'just work'
>>>
>> By consolidating all your comments in the other emails as well on this
>> 2nd patch, do you agree for my below proposal?
>>
>> We will remove all block comments and simply put AN1699 reference as we
>> did for lan865x_revb0_config_init with a small addition on top of
>> phy_modify_mmd for loop? so the comment will look like below,
>>
>> /* Reference to AN1699
>> *
>> https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
>> * AN1699 says Read, Modify, Write, but the Write is not required if
>> the register already has the required value. So it is safe to use
>> phy_modify_mmd here.
>> */
>>
>> So in future, if someone wants to know about this configuration they can
>> simply refer the AN1699.
>>
>> What do you think?
>>
>
> I'm not sure about the link, resources have a tendency to move.
Yes, I agree with you but somehow there is no way for giving the
reference to this document. May be we will keep this link for the
reference, later if someone is not able to access the link then they can
request Microchip to get the document.
What do you think about this proposal? If you agree then I will proceed
for preparing the next version with your comments.
> Otherwise LGTM
>
>> Best Regards,
>> Parthiban V
> >> /* Reference to AN1699
> >> *
> >> https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
> >> * AN1699 says Read, Modify, Write, but the Write is not required if
> >> the register already has the required value. So it is safe to use
> >> phy_modify_mmd here.
> >> */
> >>
> >> So in future, if someone wants to know about this configuration they can
> >> simply refer the AN1699.
> >>
> >> What do you think?
> >>
> >
> > I'm not sure about the link, resources have a tendency to move.
> Yes, I agree with you but somehow there is no way for giving the
> reference to this document. May be we will keep this link for the
> reference, later if someone is not able to access the link then they can
> request Microchip to get the document.
>
> What do you think about this proposal? If you agree then I will proceed
> for preparing the next version with your comments.
Thumbs up from me
R
> > Otherwise LGTM
> >
> >> Best Regards,
> >> Parthiban V
>
Hi Ramon,
On 26/05/23 7:32 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>>>> /* Reference to AN1699
>>>> *
>>>> https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
>>>> * AN1699 says Read, Modify, Write, but the Write is not required if
>>>> the register already has the required value. So it is safe to use
>>>> phy_modify_mmd here.
>>>> */
>>>>
>>>> So in future, if someone wants to know about this configuration they can
>>>> simply refer the AN1699.
>>>>
>>>> What do you think?
>>>>
>>>
>>> I'm not sure about the link, resources have a tendency to move.
>> Yes, I agree with you but somehow there is no way for giving the
>> reference to this document. May be we will keep this link for the
>> reference, later if someone is not able to access the link then they can
>> request Microchip to get the document.
>>
>> What do you think about this proposal? If you agree then I will proceed
>> for preparing the next version with your comments.
>
> Thumbs up from me
Thanks.
Best Regards,
Parthiban V
> R
>
>>> Otherwise LGTM
>>>
>>>> Best Regards,
>>>> Parthiban V
>>