netdev - Re: mv88e6240 configuration broken for B850v3

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]

Date:   Tue, 7 Dec 2021 15:24:13 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Martyn Welch <martyn.welch@...labora.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev@...r.kernel.org, kernel@...labora.com
Subject: Re: mv88e6240 configuration broken for B850v3

On Tue, Dec 07, 2021 at 12:58:20AM +0000, Russell King (Oracle) wrote:
> > Anyway, so be it. Essentially, what is the most frustrating is that I
> > haven't been doing anything else for the past 4 hours, and I still
> > haven't understood enough of what you're saying to even understand why
> > it is _relevant_ to Martyn's report. All I understand is that you're
> > also looking in that area of the code for a completely unrelated reason
> > which you've found adequate to mention here and now.
> 
> I hope you realise that _your_ attitude here is frustrating and
> inflamatory. This is _not_ a "completely unrelated reason" - this
> is about getting the right solution to Martyn's problem. I thought
> about doing another detailed reply, but when I got to the part
> about you wanting to check 6390X, I discarded that reply and
> wrote this one instead. You clearly have a total distrust for
> everything that I write in any email, so I just won't bother.

I think getting the right solution to Martyn's problem is the most
important part. I'd be very happy if I understood it too, although that
isn't mandatory, since it may be beyond me but still correct, and I hope
I'm not standing in the way if that is the case.
I've explained my current state of understanding, which is that I saw in
the manual for 6097 that forcing the link is unnecessary for internal
PHY ports regardless of whether the PPU is enabled or not. Yet, DSA will
still force these ports down with your proposed change (because DSA lies
that it is a MLO_AN_FIXED mode despite what's in the device tree), and
it relies on unforcing them in mv88e6xxx_mac_config(), which in itself
makes sense considering the other discussion about kexec and such. But
it appears that it may not unforce them again - because that condition
depends on mv88e6xxx_port_ppu_updates() which may be false. So if it is
false, things are still broken.
It isn't a matter of distrust and I'm sorry that you take it personal,
but your proposed solution doesn't appear to me to have a clear
correlation to the patch that introduced a regression.