netdev - Re: commit 65ac79e181 breaks our ksz9567

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:   Thu, 18 Aug 2022 14:34:20 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
Cc:     Network Development <netdev@...r.kernel.org>,
        Arun Ramadoss <arun.ramadoss@...rochip.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: commit 65ac79e181 breaks our ksz9567

On Thu, Aug 18, 2022 at 01:03:13PM +0200, Rasmus Villemoes wrote:
> We have a board in development which includes a ksz9567 switch, whose
> cpu port is connected to a lan7801 usb chip. This works fine up until
> 5.18, but is broken in 5.19. The kernel log contains
> 
>  ksz9477-switch 4-005f lan1 (uninitialized): validation of gmii with
> support 00000000,00000000,000062ff and advertisement
> 00000000,00000000,000062ff failed: -EINVAL
>  ksz9477-switch 4-005f lan1 (uninitialized): failed to connect to PHY: -EINVAL
>  ksz9477-switch 4-005f lan1 (uninitialized): error -22 setting up PHY for tree 0, switch 0, port 0
> 
> and similar lines for the other four ports.
> 
> Bisecting points at
> 
> commit 65ac79e1812016d7c5760872736802f985ec7455
> Author: Arun Ramadoss <arun.ramadoss@...rochip.com>
> Date:   Tue May 17 15:13:32 2022 +0530
> 
>     net: dsa: microchip: add the phylink get_caps
> 
> Our DT is, I think, pretty standard, and as I said works fine with 5.18:

Depends on what you mean by "pretty standard", see this change set which
I'll resubmit soon (today):
https://patchwork.kernel.org/project/netdevbpf/cover/20220806141059.2498226-1-vladimir.oltean@nxp.com/

> 
>         ksz9567: switch@5f {
>                 compatible = "microchip,ksz9567";
>                 reg = <0x5f>;
>                 status = "okay";
> 
>                 ports {
>                         #address-cells = <1>;
>                         #size-cells = <0>;
> 
>                         port@0 {
>                                 reg = <0>;
>                                 label = "lan1";
>                         };
>   ....
>                         port@6 {
>                                 reg = <6>;
>                                 label = "cpu";
>                                 ethernet = <&ethernet3>;
>                                 fixed-link {
>                                         speed = <1000>;
>                                         full-duplex;
>                                 };

The CPU port has no phy-mode. Good luck figuring out it's an RGMII mode.
(not related to the reported breakage though, which complains about
missing phy-mode on the LAN ports)

>                         };
>                 };
> 
> ...
>         ethernet3: ethernet@2 {
>                 compatible = "usb424,7801";
>                 reg = <2>;
>                 phy-mode = "rgmii-id";
> 
>                 mdio {
>                         compatible = "lan78xx-mdiobus";
>                         #address-cells = <1>;
>                         #size-cells = <0>;
>                 };
> 
>                 fixed-link {
>                         speed = <1000>;
>                         full-duplex;
>                 };
>         };
> 
> Any clues?
> 
> Thanks,
> Rasmus