netdev - Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus

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]

Date:   Mon, 16 Oct 2017 07:16:14 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Martin Hundebøll <mnhu@...vas.dk>
CC:     "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Subject: Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus

On October 16, 2017 6:39:43 AM PDT, Andrew Lunn <andrew@...n.ch> wrote:
>On Mon, Oct 16, 2017 at 03:16:51PM +0200, Martin Hundebøll wrote:
>> On 2017-10-16 14:32, Andrew Lunn wrote:
>> >So this used to work. I have a 10G phy connected to the external MII
>> >bus on a 6390. I wonder when this got broken? Supporting phy-handle
>is
>> >old code, so when i added the external MII i don't think i needed to
>> >change any generic code.
>> 
>> It could look like commit cd28a1a9baee7 ('net: dsa: fully divert PHY
>> reads/writes if requested') changed the of-case to use the mdio bus
>> associated with struct dsa_switch unconditionally.
>
>Hi Martin
>
>I think ds->phys_mii_mask is playing a role here. I need to add some
>debug prints to my setup and see what is happening with my external
>10G PHY.

FWIW, bcm_sf2 uses a mixture of PHYs referenced by phandle and fixed PHY so if this did not work, I would have noticed.

The logic goes like this:

- try to connect to the PHY via phy-handle
- if we have a PHY we are connecting via phy-handle but we need to divert MDIO reads/writes connect using its address on the diverted bus
- connect using a fixed PHY
- finally try using the DSA slave MII bus which would connect to the switch internal PHYs

If 1) fails then that needs investigating as it really should not. Is it somehow possible that your PHY is powered down or something at that time and there is a timing/dependency not well handled?

-- 
Florian