linux-kernel - Re: [PATCH v4 2/5] dt-bindings: net: dsa: qca,ar9331 switch documentation

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: <20191217084412.GB6994@lunn.ch>
Date:   Tue, 17 Dec 2019 09:44:12 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org,
        Jay Cliburn <jcliburn@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Chris Snook <chris.snook@...il.com>,
        linux-kernel@...r.kernel.org, Ralf Baechle <ralf@...ux-mips.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paul Burton <paul.burton@...s.com>,
        Rob Herring <robh+dt@...nel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        James Hogan <jhogan@...nel.org>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        linux-mips@...r.kernel.org,
        Vivien Didelot <vivien.didelot@...il.com>
Subject: Re: [PATCH v4 2/5] dt-bindings: net: dsa: qca,ar9331 switch
 documentation

> I spend some tine on investigating and testing it. So, the result is
> pretty simple. It looks like *MII lines of ethernet controller GMAC0 and
> MAC of switch port5 are just connected together and wired to the PHY4.
> Something like this:
> 
> GMAC1-->switch--mac5-+--->phy4
>                      ^
> GMAC0---------------/
> 
> 
> So, both of MACs can be enabled at same time and introduce resource
> conflict. If one is enabled, other one should be set in to reset mode.
> 
> The questions are:
> - how this can be reflected in devicetree?
> - how this can be properly implemented in kernel?

That is, er, interesting.

So in device tree, i would use a phy-handle in GMAC1 or GMAC0 to point
to phy4. I don't think there is anything you can do in DT to prevent
both GMAC0 and GMAC1 having a phandle to phy4, other than adding a
comment in the binding. You could ask Rob if DT schema provides any
sorts of checks like this? But i doubt it.

In the driver, it would be good to check if two MACs try to connect to
one PHY. This in general should not happen, so maybe you can add a
check to the core, in phylib and/or phylink. Just watch out for
cpsw. It connects two PHYs to one MAC. Just don't make the assumption
one MAC and one PHY is correct, everything else is wrong.

    Andrew