From: <Parthiban.Veerasooran@microchip.com>
To: <Horatiu.Vultur@microchip.com>
Cc: <netdev@vger.kernel.org>, <andrew@lunn.ch>, <davem@davemloft.net>,
<Jan.Huber@microchip.com>, <Thorsten.Kummermehr@microchip.com>,
<ramon.nordin.rodriguez@ferroamp.se>
Subject: Re: [PATCH net-next 2/2] net: phy: microchip_t1s: add support for Microchip LAN865x Rev.B0 PHYs
Date: Thu, 27 Apr 2023 11:28:25 +0000 [thread overview]
Message-ID: <b12e2702-68b5-e7ed-99dd-9da4b3333fc7@microchip.com> (raw)
In-Reply-To: <20230426212144.xze2t4vfggziuhk6@soft-dev3-1>
Hi Horatiu,
Thanks for reviewing my patches. Please see my comments below.
Best Regards,
Parthiban V
On 27/04/23 2:51 am, Horatiu Vultur wrote:
> The 04/26/2023 17:16, Parthiban Veerasooran wrote:
>
> Hi Parthiban,
>
>>
>> This patch adds support for the Microchip LAN865x Rev.B0 10BASE-T1S
>> Internal PHYs (LAN8650/1). The LAN865x combines a Media Access Controller
>> (MAC) and an internal 10BASE-T1S Ethernet PHY to access 10BASE‑T1S
>> networks.
>
> I really thought that first we will have an internal review as we
> discussed before sending this out!
As the initial version of the microchip 10BASE-T1S PHY driver is already
in the mainline with lan867x support, I sent these patches directly to
apply on top of that.
Definitely for the upcoming new drivers in the pipeline, I will approach
for the internal review with you first before going to the mainline.
Sorry if I had a miscommunication here.
Also please let me know if you have other proposal?
>
>>
>> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com>
>> ---
>> drivers/net/phy/microchip_t1s.c | 200 ++++++++++++++++++++++++++++++--
>> 1 file changed, 191 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
>> index 793fb0210605..3d8d285b3c34 100644
>> --- a/drivers/net/phy/microchip_t1s.c
>> +++ b/drivers/net/phy/microchip_t1s.c
>> @@ -4,6 +4,7 @@
>> *
>> * Support: Microchip Phys:
>> * lan8670/1/2 Rev.B1
>> + * lan8650/1 Rev.B0 Internal PHYs
>> */
>>
>> #include <linux/kernel.h>
>> @@ -11,9 +12,10 @@
>> #include <linux/phy.h>
>>
>> #define PHY_ID_LAN867X_REVB1 0x0007C162
>> +#define PHY_ID_LAN865X_REVB0 0x0007C1B3
>>
>> -#define LAN867X_REG_IRQ_1_CTL 0x001C
>> -#define LAN867X_REG_IRQ_2_CTL 0x001D
>> +#define LAN86XX_REG_IRQ_1_CTL 0x001C
>> +#define LAN86XX_REG_IRQ_2_CTL 0x001D
>>
>> /* The arrays below are pulled from the following table from AN1699
>> * Access MMD Address Value Mask
>> @@ -49,6 +51,174 @@ static const int lan867x_revb1_fixup_masks[12] = {
>> 0x0600, 0x7F00, 0x2000, 0xFFFF,
>> };
>>
>> +/* LAN865x Rev.B0 configuration parameters from AN1760
>> + */
>
> You can put */ on previous line.
Sure, will do.
>
>> +static const int lan865x_revb0_fixup_registers[28] = {
>> + 0x0091, 0x0081, 0x0043, 0x0044,
>> + 0x0045, 0x0053, 0x0054, 0x0055,
>> + 0x0040, 0x0050, 0x00D0, 0x00E9,
>> + 0x00F5, 0x00F4, 0x00F8, 0x00F9,
>> + 0x00B0, 0x00B1, 0x00B2, 0x00B3,
>> + 0x00B4, 0x00B5, 0x00B6, 0x00B7,
>> + 0x00B8, 0x00B9, 0x00BA, 0x00BB,
>> +};
>> +
>> +static const int lan865x_revb0_fixup_values[28] = {
>
> Can't this be u16? As this is used only by phy_write_mmd which gets an
> u16.
yes, will do it.
>
>> + 0x9660, 0x00C0, 0x00FF, 0xFFFF,
>> + 0x0000, 0x00FF, 0xFFFF, 0x0000,
>> + 0x0002, 0x0002, 0x5F21, 0x9E50,
>> + 0x1CF8, 0xC020, 0x9B00, 0x4E53,
>> + 0x0103, 0x0910, 0x1D26, 0x002A,
>> + 0x0103, 0x070D, 0x1720, 0x0027,
>> + 0x0509, 0x0E13, 0x1C25, 0x002B,
>> +};
>> +
>> +/* indirect read pseudocode from AN1760
>
> In the entire file, sometimes when you write the comment you start with
> a lower case, sometimes with an upper case, please be consistent.
Sure, I will.
>
>> + * write_register(0x4, 0x00D8, addr)
>> + * write_register(0x4, 0x00DA, 0x2)
>> + * return (int8)(read_register(0x4, 0x00D9))
>> + */
>> +static int lan865x_revb0_indirect_read(struct phy_device *phydev, u16 addr)
>> +{
>> + int ret;
>> +
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0xD8, addr);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0xDA, 0x0002);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0xD9);
>
> You can return phy_read_mmd, there is no point to check the ret here.
Ah good idea.
>
>> + if (ret < 0)
>> + return ret;
>> +
>> + return ret;
>> +}
>> +
>> +static int lan865x_setup_cfgparam(struct phy_device *phydev)
>> +{
>> + s8 offset1;
>> + s8 offset2;
>> + s8 value;
>> + u16 cfgparam;
>> + int ret;
>
> Please use reverse christmas notation
Sure, I will.
>
>> +
>> + ret = lan865x_revb0_indirect_read(phydev, 0x0004);
>> + if (ret < 0)
>> + return ret;
>> + value = (s8)ret;
>> + /* Calculation of configuration offset 1 from AN1760
>> + */
>
> Again, you can put */ on the previous line. There other places in the
> file, I will not mention all of them.
Sure, I will.
>
>> + if ((value & 0x10) != 0)
>> + offset1 = value | 0xE0;
>> + else
>> + offset1 = value;
>> +
>> + ret = lan865x_revb0_indirect_read(phydev, 0x0008);
>> + if (ret < 0)
>> + return ret;
>> + value = (s8)ret;
>> + /* Calculation of configuration offset 2 from AN1760
>> + */
>> + if ((value & 0x10) != 0)
>> + offset2 = value | 0xE0;
>> + else
>> + offset2 = value;
>> +
>> + /* calculate and write the configuration parameters in the
>> + * 0x0084, 0x008A, 0x00AD, 0x00AE and 0x00AF registers (from AN1760)
>> + */
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0x0084);
>> + if (ret < 0)
>> + return ret;
>> + cfgparam = (ret & 0xF) | (((9 + offset1) << 10) |
>> + ((14 + offset1) << 4));
>
> What about using FIELD_PREP to skip all <<?
Ok noted.
>
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0x84, cfgparam);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0x008A);
>
> Small thing, here you use 0x008A, and few lines bellow only 0X8A, please
> be consistent
Sure, I will.
>
>> + if (ret < 0)
>> + return ret;
>> + cfgparam = (ret & 0x3FF) | ((40 + offset2) << 10);
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0x8A, cfgparam);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0x00AD);
>> + if (ret < 0)
>> + return ret;
>> + cfgparam = (ret & 0xC0C0) | (((5 + offset1) << 8) | (9 + offset1));
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0xAD, cfgparam);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0x00AE);
>> + if (ret < 0)
>> + return ret;
>> + cfgparam = (ret & 0xC0C0) | (((9 + offset1) << 8) | (14 + offset1));
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, 0xAE, cfgparam);
>> + if (ret)
>> + return ret;
>> +
>> + ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, 0x00AF);
>> + if (ret < 0)
>> + return ret;
>> + cfgparam = (ret & 0xC0C0) | (((17 + offset1) << 8) | (22 + offset1));
>> + return phy_write_mmd(phydev, MDIO_MMD_VEND2, 0xAF, cfgparam);
>
> There are quite a lot of hardcoded values in the previous code, can you add
> some comments what they mean, or add defines for them.
Sure, I will check this.
>
>> +}
>> +
>> +static int lan865x_revb0_config_init(struct phy_device *phydev)
>> +{
>> + int addr;
>> + int value;
>> + int ret;
>
> Please use reverse x-mas
Ok noted.
>
>> +
>> + /* As per AN1760, the below configuration applies only to the LAN8650/1
>> + * hardware revision Rev.B0.
>> + */
>> + for (int i = 0; i < ARRAY_SIZE(lan865x_revb0_fixup_registers); i++) {
>> + addr = lan865x_revb0_fixup_registers[i];
>> + value = lan865x_revb0_fixup_values[i];
>
> Doesn't seem that you need the variable value here.
Ok noted.
>
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, addr, value);
>> + if (ret)
>> + return ret;
>> + }
>> + /* function to calculate and write the configuration parameters in the
>> + * 0x0084, 0x008A, 0x00AD, 0x00AE and 0x00AF registers (from AN1760)
>> + */
>> + ret = lan865x_setup_cfgparam(phydev);
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* disable all the interrupts
>> + */
>> + ret = phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN86XX_REG_IRQ_1_CTL, 0xFFFF);
>> + if (ret)
>> + return ret;
>> + return phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN86XX_REG_IRQ_2_CTL, 0xFFFF);
>
> You can use GENMASK instead of 0xFFFF
Ok noted.
>
>> +}
>> +
>> +static int lan865x_revb0_plca_set_cfg(struct phy_device *phydev,
>> + const struct phy_plca_cfg *plca_cfg)
>> +{
>> + int ret;
>> +
>> + ret = genphy_c45_plca_set_cfg(phydev, plca_cfg);
>> + if (ret)
>> + return ret;
>> +
>> + /* Disable the collision detection when PLCA is enabled and enable
>> + * collision detection when CSMA/CD mode is enabled.
>> + */
>> + if (plca_cfg->enabled)
>> + return phy_write_mmd(phydev, MDIO_MMD_VEND2, 0x0087, 0x0000);
>> + else
>> + return phy_write_mmd(phydev, MDIO_MMD_VEND2, 0x0087, 0x0083);
>> +}
>> +
>> static int lan867x_revb1_config_init(struct phy_device *phydev)
>> {
>> /* HW quirk: Microchip states in the application note (AN1699) for the phy
>> @@ -90,13 +260,13 @@ static int lan867x_revb1_config_init(struct phy_device *phydev)
>> * 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);
>> + err = phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN86XX_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 phy_write_mmd(phydev, MDIO_MMD_VEND2, LAN86XX_REG_IRQ_2_CTL, 0xFFFF);
>> }
>>
>> -static int lan867x_read_status(struct phy_device *phydev)
>> +static int lan86xx_read_status(struct phy_device *phydev)
>> {
>> /* The phy has some limitations, namely:
>> * - always reports link up
>> @@ -111,23 +281,34 @@ static int lan867x_read_status(struct phy_device *phydev)
>> return 0;
>> }
>>
>> -static struct phy_driver lan867x_revb1_driver[] = {
>> +static struct phy_driver lan86xx_driver[] = {
>> {
>> PHY_ID_MATCH_EXACT(PHY_ID_LAN867X_REVB1),
>> .name = "LAN867X Rev.B1",
>> .features = PHY_BASIC_T1S_P2MP_FEATURES,
>> .config_init = lan867x_revb1_config_init,
>> - .read_status = lan867x_read_status,
>> + .read_status = lan86xx_read_status,
>> .get_plca_cfg = genphy_c45_plca_get_cfg,
>> .set_plca_cfg = genphy_c45_plca_set_cfg,
>> .get_plca_status = genphy_c45_plca_get_status,
>> - }
>> + },
>> + {
>> + PHY_ID_MATCH_EXACT(PHY_ID_LAN865X_REVB0),
>> + .name = "LAN865X Rev.B0 Internal Phy",
>> + .features = PHY_BASIC_T1S_P2MP_FEATURES,
>> + .config_init = lan865x_revb0_config_init,
>> + .read_status = lan86xx_read_status,
>> + .get_plca_cfg = genphy_c45_plca_get_cfg,
>> + .set_plca_cfg = lan865x_revb0_plca_set_cfg,
>> + .get_plca_status = genphy_c45_plca_get_status,
>> + },
>> };
>>
>> -module_phy_driver(lan867x_revb1_driver);
>> +module_phy_driver(lan86xx_driver);
>>
>> static struct mdio_device_id __maybe_unused tbl[] = {
>> { PHY_ID_MATCH_EXACT(PHY_ID_LAN867X_REVB1) },
>> + { PHY_ID_MATCH_EXACT(PHY_ID_LAN865X_REVB0) },
>> { }
>> };
>>
>> @@ -135,4 +316,5 @@ MODULE_DEVICE_TABLE(mdio, tbl);
>>
>> MODULE_DESCRIPTION("Microchip 10BASE-T1S Phy driver");
>> MODULE_AUTHOR("Ramón Nordin Rodriguez");
>> +MODULE_AUTHOR("Parthiban Veerasooran <parthiban.veerasooran@microchip.com>");
>> MODULE_LICENSE("GPL");
>> --
>> 2.34.1
>>
>
next prev parent reply other threads:[~2023-04-27 11:28 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 11:46 [PATCH net-next 0/2] add driver support for Microchip LAN865X Rev.B0 Internal PHYs Parthiban Veerasooran
2023-04-26 11:46 ` [PATCH net-next 1/2] net: phy: microchip_t1s: update LAN867x PHY supported revision number Parthiban Veerasooran
2023-04-26 20:56 ` Horatiu Vultur
2023-04-26 11:46 ` [PATCH net-next 2/2] net: phy: microchip_t1s: add support for Microchip LAN865x Rev.B0 PHYs Parthiban Veerasooran
2023-04-26 20:53 ` Ramón Nordin Rodriguez
2023-04-26 21:43 ` Andrew Lunn
2023-04-27 12:28 ` Parthiban.Veerasooran
2023-04-27 14:17 ` Parthiban.Veerasooran
2023-04-26 21:21 ` Horatiu Vultur
2023-04-27 11:28 ` Parthiban.Veerasooran [this message]
2023-04-26 21:52 ` Andrew Lunn
2023-04-27 14:19 ` Parthiban.Veerasooran
2023-04-26 22:02 ` Andrew Lunn
2023-04-27 14:23 ` Parthiban.Veerasooran
2023-04-26 20:50 ` [PATCH net-next 0/2] add driver support for Microchip LAN865X Rev.B0 Internal PHYs Horatiu Vultur
2023-04-27 7:07 ` Parthiban.Veerasooran
2023-04-27 11:24 ` Horatiu Vultur - M31836
2023-04-27 14:26 ` Parthiban.Veerasooran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b12e2702-68b5-e7ed-99dd-9da4b3333fc7@microchip.com \
--to=parthiban.veerasooran@microchip.com \
--cc=Horatiu.Vultur@microchip.com \
--cc=Jan.Huber@microchip.com \
--cc=Thorsten.Kummermehr@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ramon.nordin.rodriguez@ferroamp.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.