netdev - Re: C45 support and mdiobus

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] [day] [month] [year] [list]

Message-ID: <20180810163449.GA11955@lunn.ch>
Date:   Fri, 10 Aug 2018 18:34:49 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Jose Abreu <Jose.Abreu@...opsys.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: C45 support and mdiobus_scan

On Fri, Aug 10, 2018 at 10:20:56AM -0500, Tom Lendacky wrote:
> On 8/9/2018 10:25 AM, Andrew Lunn wrote:
> >>> The PCIe core will look in the device tree and when it creates the
> >>> platform device for the i210 on the pcie bus, it points
> >>> pdev->dev.of_node at this node. So long as you are using a platform
> >>> with DT, you can do this. I hope you are not using x86..
> >>
> >> Yes I am :( Any possible solution for this?
> 
> I haven't looked too closely, but maybe you can add a new mdiobus_scan
> function for 10G that attempts get_phy_device() with is_c45 set to true
> and if nothing is found falls back to get_phy_device() with is_c45 set to
> false.

Hi Tom

I did consider at one point adding extra flags to the struct mii_bus
to indicate if the bus master supports C22 and or C45, and then scan
the bus as appropriate. We cannot unconditionally do a C45 scan on all
busses, because most bus drivers don't look for MII_ADDR_C45, and so
are wrongly going to do a C22 transaction. There is also one bus
driver i know of which can only do C45. But it at least returns
EOPNOTSUPP if you ask it to do a C22.

I think this needs addressing at some point. We are seeing more 2.5G,
5G and 10G MAC/PHY combinations, and they often need C45. So maybe
adding a flag saying C45 is supported, and then scanning is a good way
forward. Adding a flag saying C22 is supported might be too much work,
without enough return.

> I don't know what would happen if you have a non-c45 phy attached,
> but it's worth a shot to try it and see for each situation.

That should be fine. A C22 PHY should ignore a C45 transaction. At
least that was the design idea when C45 was introduced. But i would
not be too surprised if we find the odd C22 phy get confused, and we
need to add some sort of quirks.

     Andrew