netdev - Re: [PATCH net-next v2 1/2] ixgbe: register a 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8ff5f4f0-9a4a-d601-3add-fcfc91b6414d@silicom-usa.com>
Date:   Mon, 3 Dec 2018 18:38:40 +0000
From:   Steve Douthit <stephend@...icom-usa.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [PATCH net-next v2 1/2] ixgbe: register a mdiobus

On 12/3/18 1:18 PM, Andrew Lunn wrote:
>> Agreed, but I'd argue it's the same behavior we have today with the
>> existing MII ioctls in this driver.  That's not to say this is good,
>> it's just not any less broken than the current state of things.
> 
> Agreed.
> 
> I actually would be happy with a warning in the commit message that
> this code is not sufficient to make use of Linux PHY drivers, because
> of the hardware polling. You can then leave fixing that to whoever
> needs Linux PHY drivers.

OK, will update for v3.

>> AFAICT the polling hardware only pokes the device address that the
>> driver stores in 'hw->phy.mdio.prtad', so the PHY polling unit would
>> never see the switch, if it's even polling at all.  Some of the MAC
>> configurations will store MDIO_PRTAD_NONE, in which case I wouldn't
>> expect the polling unit to be active.  It's up to the board designer to
>> ensure there's no address conflicts on the bus.
> 
> Well, the 6390 does use address 0-10 for its port registers, and there
> is something which looks like a PHYID in register 3. So for your use
> case of DSA, it would be good to ensure it really is disabled.

You can actually strap the 6390 and friends for a multi-chip mode where
they claim only a single address, instead of one per port, plus a couple
more for global registers.  It vastly slows things down because of the
extra indirection, but it allows the switch to play nicely with other
MDIO devs.

>> Then in the ioctl code, in addition to checking the mii_bus is
>> available, also check that the requested address is one that phy_mask
>> says mii_bus owns, otherwise we fall through to the old code.
> 
> I'm not too bothered with the ioctl. It is there so you can shoot
> yourself in the foot. The hardware polling unit just adds more
> interesting weapons you can use to shoot yourself in the foot.

Hooray for enhanced anti-foot artillery :)