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:   Mon, 13 Jan 2020 19:29:05 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, cphealy@...il.com,
        rmk+kernel@...linux.org.uk, kuba@...nel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: Maintain MDIO device and bus
 statistics

> For MDIO switches you would usually have the mdio_device claim the
> pseudo PHY address and all other MDIO addresses should correspond to
> built-in PHYs, for which we also have mdio_device instances, is there a
> case that I am missing?

Marvell switches don't work like this. It varies from family to
family. The 6390 family for example has address 0x0-0xa representing
registers for ports 0 to 10, 32 registers per port. address 0x1b and
0x1c contain registers for global configuration. 0x1e is used to
communication with the internal MCU, and 0x1f is the TCAM. The
internal PHYs are not in this MDIO address space at all, there is
another MDIO bus, implemented by a couple of the global registers.

The 6352 has a different layout. 0x0-0x4 represent the internal
PHYs. 0xf is the SERDES for SGMII, 0x10-x016 are the port registers,
0x1b 0x1c are global.

There is one family, i don't remember which, which uses 16
addresses. And you can put two of them on one MDIO bus.

In each of these cases, we have one mdiodev, per switch, claiming a
single address, generally 0.

Other vendors switches are similar, using multiple addresses on one
bus.

> If the answer to my question above is that we still have reads to
> addresses for which we do not have mdio_device (which we might very well
> have), then we could either:
> 
> - create <mdio_bus>:<address>/statistics/ folders even for non-existent
> devices, but just to track the per-address statistics
> - create <mdio_bus>/<address>/statistics and when a mdio_device instance
> exists we symbolic link <mdio_bus>:<address>/statistics ->
> ../<mdio_bus>/<addr>/statistics
> 
> Would that work?

Keeping the statistics for all 32 addresses in the struct mii_bus
would be good. Then directories 0-31. And symlinks. Yes, that is good.

      Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ