linux-kernel - Re: [PATCH v2 2/5] net: hpe: Add GXP UMAC MDIO

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]

Message-ID: <0b227994-2577-4a74-b604-79410f5607b8@lunn.ch>
Date:   Thu, 3 Aug 2023 00:39:55 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     nick.hawkins@....com
Cc:     christophe.jaillet@...adoo.fr, simon.horman@...igine.com,
        verdun@....com, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/5] net: hpe: Add GXP UMAC MDIO

> +config GXP_UMAC_MDIO
> +	tristate "GXP UMAC mdio support"
> +	depends on ARCH_HPE || COMPILE_TEST
> +	depends on OF_MDIO && HAS_IOMEM
> +	depends on MDIO_DEVRES
> +        help

nitpick: help should be indented same as depends.

> +	  Say y here to support the GXP UMAC MDIO bus. The
> +	  MDIO(mdio0) interface from the primary MAC (umac0)
> +	  is used for external PHY status and configuration.

Is it an external MDIO bus? So anything could be connected to it,
e.g. an Ethernet switch. 

> +	  The MDIO(mdio1) interface from the secondary MAC
> +	  (umac1) is routed to the SGMII/100Base-X IP blocks
> +	  on the two SERDES interface connections.

Is this one purely internal? If so, then the text is valid. If it also
goes external, there is no reason you could not put a PHY or an
Ethernet switch on it. You can then skip using the first MDIO bus all
together.

> +#define UMAC_MII                0x00  /* R/W MII Register */
> +#define UMAC_MII_PHY_ADDR_MASK  0x001F0000
> +#define UMAC_MII_PHY_ADDR_SHIFT 16
> +#define UMAC_MII_MOWNER         0x00000200
> +#define UMAC_MII_MRNW           0x00000100

Are these two bits? If so, please use BIT().

> +static int umac_mdio_read(struct mii_bus *bus, int phy_id, int reg)
> +{
> +	struct umac_mdio_priv *umac_mdio = bus->priv;
> +	unsigned int status;
> +	unsigned int value;
> +	int ret;
> +
> +	status = __raw_readl(umac_mdio->base + UMAC_MII);
> +
> +	status &= ~(UMAC_MII_PHY_ADDR_MASK | UMAC_MII_REG_ADDR_MASK);
> +	status |= ((phy_id << UMAC_MII_PHY_ADDR_SHIFT) &
> +			UMAC_MII_PHY_ADDR_MASK);
> +	status |= (reg & UMAC_MII_REG_ADDR_MASK);
> +	status |= UMAC_MII_MRNW; /* set bit for read mode */
> +	__raw_writel(status, umac_mdio->base + UMAC_MII);
> +
> +	status |= UMAC_MII_MOWNER; /* set bit to activate mii transfer */
> +	__raw_writel(status, umac_mdio->base + UMAC_MII);

I assume UMAC_MII_MOWNER must be set in a separate operation? But
using __raw_writel() i'm not sure there is any barrier between the two
writes.

	Andrew