| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZD+riUQkTIY2Ep30@debian>
Date: Wed, 19 Apr 2023 10:51:21 +0200
From: Ramón Nordin Rodriguez
<ramon.nordin.rodriguez@...roamp.se>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] drivers/net/phy: add driver for Microchip LAN867x
10BASE-T1S PHY
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
Powered by blists - more mailing lists