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: <94DA9CFF-71F3-4D89-A2F2-342A69AB434E@gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ