From: "Ramón Nordin Rodriguez" <ramon.nordin.rodriguez@ferroamp.se>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org
Subject: Re: [PATCH] drivers/net/phy: add driver for Microchip LAN867x 10BASE-T1S PHY
Date: Wed, 19 Apr 2023 10:51:21 +0200 [thread overview]
Message-ID: <ZD+riUQkTIY2Ep30@debian> (raw)
In-Reply-To: <2806b25b-1914-4525-a085-b0867711bce9@lunn.ch>
On Tue, Apr 18, 2023 at 08:56:47PM +0200, Andrew Lunn wrote:
> > +config LAN867X_PHY
> > + tristate "Microchip 10BASE-T1S Ethernet PHY"
> > + help
> > + Currently supports the LAN8670, LAN8671, LAN8672
> > +
>
> This file is sorted by tristate string, so it should come before
> tristate "Microchip PHYs"
>
Ah, I missed that, fixing it in the next patch version.
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> > index b5138066ba04..a12c2f296297 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -78,6 +78,7 @@ obj-$(CONFIG_MICROSEMI_PHY) += mscc/
> > obj-$(CONFIG_MOTORCOMM_PHY) += motorcomm.o
> > obj-$(CONFIG_NATIONAL_PHY) += national.o
> > obj-$(CONFIG_NCN26000_PHY) += ncn26000.o
> > +obj-$(CONFIG_LAN867X_PHY) += lan867x.o
>
> And this is sorted by CONFIG_ so should appear after
> CONFIG_INTEL_XWAY_PHY.
>
Same thing here, will fix it.
> > obj-$(CONFIG_NXP_C45_TJA11XX_PHY) += nxp-c45-tja11xx.o
> > obj-$(CONFIG_NXP_TJA11XX_PHY) += nxp-tja11xx.o
> > obj-$(CONFIG_QSEMI_PHY) += qsemi.o
> > diff --git a/drivers/net/phy/lan867x.c b/drivers/net/phy/lan867x.c
>
> Maybe call it microchip_t1s.c ? That sort of fits with the pattern of
> the current files:
>
> microchip.c
> microchip_t1.c
>
> Microchip drivers don't really have a consistent naming, because they
> keep buying other vendors, like vitesse, Microsemi, Micrel/Kendin...
>
Totally agree with the name suggestion.
> > +static int lan867x_config_init(struct phy_device *phydev)
> > +{
> > + /* 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.
> > + */
> > +
> > + /* The arrays below are pulled from the following table from AN1699
> > + * Access MMD Address Value Mask
> > + * RMW 0x1F 0x00D0 0x0002 0x0E03
> > + * RMW 0x1F 0x00D1 0x0000 0x0300
> > + * RMW 0x1F 0x0084 0x3380 0xFFC0
> > + * RMW 0x1F 0x0085 0x0006 0x000F
> > + * RMW 0x1F 0x008A 0xC000 0xF800
> > + * RMW 0x1F 0x0087 0x801C 0x801C
> > + * RMW 0x1F 0x0088 0x033F 0x1FFF
> > + * W 0x1F 0x008B 0x0404 ------
> > + * RMW 0x1F 0x0080 0x0600 0x0600
> > + * RMW 0x1F 0x00F1 0x2400 0x7F00
> > + * RMW 0x1F 0x0096 0x2000 0x2000
> > + * W 0x1F 0x0099 0x7F80 ------
> > + */
> > +
> > + const int registers[12] = {
> > + 0x00D0, 0x00D1, 0x0084, 0x0085,
> > + 0x008A, 0x0087, 0x0088, 0x008B,
> > + 0x0080, 0x00F1, 0x0096, 0x0099,
> > + };
> > +
> > + const int masks[12] = {
> > + 0x0E03, 0x0300, 0xFFC0, 0x000F,
> > + 0xF800, 0x801C, 0x1FFF, 0xFFFF,
> > + 0x0600, 0x7F00, 0x2000, 0xFFFF,
> > + };
> > +
> > + const int values[12] = {
> > + 0x0002, 0x0000, 0x3380, 0x0006,
> > + 0xC000, 0x801C, 0x033F, 0x0404,
> > + 0x0600, 0x2400, 0x2000, 0x7F80,
> > + };
> > +
> > + int err;
> > + int reg;
> > + int reg_value;
>
> netdev uses reverse christmas tree. That is, variables should be
> sorted with the longest lines first, shorted last.
>
Missed that in the style guide, will fix it.
> > + /* 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
> > + */
> > + for (int i = 0; i < ARRAY_SIZE(registers); i++) {
> > + reg = registers[i];
> > + reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
> > + reg_value &= ~masks[i];
> > + reg_value |= values[i];
> > + err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
> > + if (err != 0)
> > + return err;
> > + }
>
> Maybe phy_modify_mmd(). However, that skips the write if the value is
> not changed by the mask and set value.
>
I've reached out to Microchip regarding this and asked them if a write
is required even if the resulting value is not modified.
I suggest we leave this as is, and if they respond that it's not
required to write on unmodified I will submit a patch that removes this
block and uses phy_modify_mmd instead.
In breif I don't feel confident that I can verify that I've achieved
'optimal perfomance' as they refer to it as and would like to get
feedback from the manufacturer.
> > +static int lan867x_config_interrupt(struct phy_device *phydev)
> > +{
> > + /* None of the interrupts in the lan867x phy seem relevant.
> > + * Other phys inspect the link status and call phy_trigger_machine
> > + * on change.
> > + * This phy does not support link status, and thus has no interrupt
> > + * for it either.
> > + * So we'll just disable all interrupts instead.
> > + */
>
> It interrupts are pointless, just don't provide the functions. phylib
> will then poll.
>
Gotcha, I'll remove the func.
> > +static int lan867x_read_status(struct phy_device *phydev)
> > +{
> > + /* The phy has some limitations, namely:
> > + * - always reports link up
> > + * - only supports 10MBit half duplex
> > + * - does not support auto negotiate
> > + */
> > + phydev->link = 1;
> > + phydev->duplex = DUPLEX_HALF;
> > + phydev->speed = SPEED_10;
> > + phydev->autoneg = AUTONEG_DISABLE;
> > +
> > + return 0;
>
> Not that polling gives anything useful!
>
> Andrew
:) Great feedback! Trying to get a new patch out today
next prev parent reply other threads:[~2023-04-19 8:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 17:52 [PATCH] drivers/net/phy: add driver for Microchip LAN867x 10BASE-T1S PHY Ramón Nordin Rodriguez
2023-04-18 18:56 ` Andrew Lunn
2023-04-19 8:51 ` Ramón Nordin Rodriguez [this message]
2023-04-19 14:40 ` Parthiban.Veerasooran
2023-04-19 15:10 ` Andrew Lunn
2023-04-20 5:32 ` Parthiban.Veerasooran
2023-04-20 6:39 ` 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=ZD+riUQkTIY2Ep30@debian \
--to=ramon.nordin.rodriguez@ferroamp.se \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.