Subject: Re: [PATCH] drivers/net/phy: add driver for Microchip LAN867x 10BASE-T1S PHY

From: Ramón Nordin Rodriguez <[email-masked]>
Date: Wed, 19 Apr 2023 10:51:21 +0200

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