netdev - Re: [PATCH net 0/4] net: dsa: mv88e6xxx: Amethyst (6393X) fixes

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: <a01c7092-2642-4091-a085-07272b450471@alliedtelesis.co.nz>
Date: Mon, 9 Dec 2024 09:23:26 +1300
From: Chris Packham <chris.packham@...iedtelesis.co.nz>
To: Tobias Waldekranz <tobias@...dekranz.com>, davem@...emloft.net,
 kuba@...nel.org
Cc: andrew@...n.ch, f.fainelli@...il.com, olteanv@...il.com,
 netdev@...r.kernel.org, linux@...linux.org.uk
Subject: Re: [PATCH net 0/4] net: dsa: mv88e6xxx: Amethyst (6393X) fixes

Hi Tobias,

On 07/12/2024 02:07, Tobias Waldekranz wrote:
> This series provides a set of bug fixes discovered while bringing up a
> new board using mv88e6393x chips.
>
> 1/4 adds logging of low-level I/O errors that where previously only
> logged at a much higher layer, e.g. "probe failed" or "failed to add
> VLAN", at which time the origin of the error was long gone. Not
> exactly a bugfix, though still suitable for -net IMHO; but I'm also
> happy to send it via net-next instead if that makes more sense.
>
> 2/4 fixes an issue I've never seen on any other board. At first I
> assumed that there was some board-specific issue, but we've not been
> able to find one. If you give the chip enough time, it will eventually
> signal "PPU Polling" and everything else will work as
> expected. Therefore I assume that all is in order, and that we simply
> need to increase the timeout.
>
> 3/4 just broadens Chris' original fix to apply to all chips. Though I
> have obviously not tested this on every supported device, I can't see
> how this could possibly be chip specific. Was there some specific
> reason for originally limiting the set of chips that this applied to?

I think it was mainly because I didn't have a 88e639xx to test with 
(much like you) so I kept the change isolated to the hardware I did have 
access to.

The original thread that kicked the original series off was 
https://lore.kernel.org/netdev/72e8e25a-db0d-275f-e80e-0b74bf112832@alliedtelesis.co.nz/

Since the only difference is the mode == MLO_AN_INBAND check I think 
your change is reasonably safe.

>
> 4/4 can only be supported on the Amethyst, which can control the
> ieee-multicast policy per-port, rather than via a global setting as
> it's done on the older families.
>
> Tobias Waldekranz (4):
>    net: dsa: mv88e6xxx: Improve I/O related error logging
>    net: dsa: mv88e6xxx: Give chips more time to activate their PPUs
>    net: dsa: mv88e6xxx: Never force link on in-band managed MACs
>    net: dsa: mv88e6xxx: Limit rsvd2cpu policy to user ports on 6393X
>
>   drivers/net/dsa/mv88e6xxx/chip.c    | 92 ++++++++++++++++-------------
>   drivers/net/dsa/mv88e6xxx/chip.h    |  6 +-
>   drivers/net/dsa/mv88e6xxx/global1.c | 19 +++++-
>   drivers/net/dsa/mv88e6xxx/port.c    | 48 +++++++--------
>   drivers/net/dsa/mv88e6xxx/port.h    |  1 -
>   5 files changed, 97 insertions(+), 69 deletions(-)
>