linux-kernel - Re: [PATCH net] net: mvpp2: Enable autoneg bypass for 1000BaseX/2500BaseX ports

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200529175225.a3be1b4faaa0408e165435ad@suse.de>
Date:   Fri, 29 May 2020 17:52:25 +0200
From:   Thomas Bogendoerfer <tbogendoerfer@...e.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: mvpp2: Enable autoneg bypass for
 1000BaseX/2500BaseX ports

On Fri, 29 May 2020 16:59:28 +0200
Andrew Lunn <andrew@...n.ch> wrote:

> On Fri, May 29, 2020 at 01:05:39PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 28 May 2020 23:04:20 +0100
> > Russell King - ARM Linux admin <linux@...linux.org.uk> wrote:
> > 
> > > Can you explain this please?  Just as we think we understand what's
> > > going on here, you throw in a new comment that makes us confused.
> > 
> > sorry about that.
> > 
> > > You said previously that the mvpp2 was connected to a switch, which
> > > makes us think that you've got some DSA-like setup going on here.
> > > Does your switch drop its serdes link when all the external links
> > > (presumably the 10G SFP+ cages) fail?
> > > 
> > > Both Andrew and myself wish to have a complete picture before we
> > > move forward with this.
> > 
> > full understandable, I'll try by a small picture, which just
> > covers one switch:
> > 
> >         external ports
> >       |  |          |  |
> > *-----------------------------*
> > |     1  1          2  2      |
> > |                             |
> > |           switch            |
> > |                             |
> > |   1   2            1   2    |
> > *-----------------------------*
> >     |   |            |   |
> >     |   |            |   |
> > *----------*     *----------*
> > |   1   2  |     |   1   2  |
> > |          |     |          |
> > |  node 1  | ... |  node 8  |
> > |          |     |          |
> > *----------*     *----------*
> > 
> > External ports a grouped in ports to network 1 and network 2. If one of the
> > external ports has an established link, this link state will be propagated
> > to the internal ports. Same when both external ports of a network are down.
> 
> By propagated, you mean if the external link is down, the link between
> the switch and node 1 will also be forced down, at the SERDES level?

yes

> And if external ports are down, the nodes cannot talk to each other?

correct

> External link down causes the whole in box network to fall apart? That
> seems a rather odd design.

as I'm not an expert in ceph, I can't judge. But I'll bring it up.

> > I have no control over the software running on the switch, therefore I can't
> > enable autoneg on the internal links.
> 
> O.K. So that means using in-band signalling in DT is clearly
> wrong. There is no signalling....
> 
> What you are actually interested in is the sync state of the SERDES?
> The link is up if the SERDES has sync.

yes, that's what I need. How can I do that ?

Thomas.

-- 
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer