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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 18 Apr 2023 20:56:47 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Ramón Nordin Rodriguez 
        <ramon.nordin.rodriguez@...roamp.se>
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

> +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"

> 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.

>  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...

> +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.

> +	/* 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.

> +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.

> +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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ