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
| ||
|
Message-ID: <ec63b5aa-3dec-3c27-e987-25e36b1632ba@linaro.org> Date: Tue, 4 Oct 2022 13:19:33 +0200 From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> To: Colin Foster <colin.foster@...advantage.com>, linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, netdev@...r.kernel.org Cc: Russell King <linux@...linux.org.uk>, Linus Walleij <linus.walleij@...aro.org>, UNGLinuxDriver@...rochip.com, Alexandre Belloni <alexandre.belloni@...tlin.com>, Claudiu Manoil <claudiu.manoil@....com>, Lee Jones <lee@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Rob Herring <robh+dt@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, "David S. Miller" <davem@...emloft.net>, Vladimir Oltean <olteanv@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Vivien Didelot <vivien.didelot@...il.com>, Andrew Lunn <andrew@...n.ch> Subject: Re: [PATCH v3 net-next 12/14] dt-bindings: net: dsa: ocelot: add ocelot-ext documentation On 26/09/2022 02:29, Colin Foster wrote: > The ocelot-ext driver is another sub-device of the Ocelot / Felix driver > system, which currently supports the four internal copper phys. > > Signed-off-by: Colin Foster <colin.foster@...advantage.com> > --- > > v3 > * Remove "currently supported" verbage > The Seville and Felix 9959 all list their supported modes following > the sentence "The following PHY interface types are supported". > During V2, I had used "currently supported" to suggest more interface > modes are around the corner, though this had raised questions. > > The suggestion was to drop the entire sentence. I did leave the > modified sentence there because it exactly matches the other two > supported products. > > v2 > * New patch > > --- > .../bindings/net/dsa/mscc,ocelot.yaml | 59 +++++++++++++++++++ > 1 file changed, 59 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml > index 8d93ed9c172c..49450a04e589 100644 > --- a/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml > +++ b/Documentation/devicetree/bindings/net/dsa/mscc,ocelot.yaml > @@ -54,9 +54,22 @@ description: | > - phy-mode = "1000base-x": on ports 0, 1, 2, 3 > - phy-mode = "2500base-x": on ports 0, 1, 2, 3 > > + VSC7412 (Ocelot-Ext): > + > + The Ocelot family consists of four devices, the VSC7511, VSC7512, VSC7513, > + and the VSC7514. The VSC7513 and VSC7514 both have an internal MIPS > + processor that natively support Linux. Additionally, all four devices > + support control over external interfaces, SPI and PCIe. The Ocelot-Ext > + driver is for the external control portion. > + > + The following PHY interface types are supported: > + > + - phy-mode = "internal": on ports 0, 1, 2, 3 > + > properties: > compatible: > enum: > + - mscc,vsc7512-switch > - mscc,vsc9953-switch > - pci1957,eef0 > > @@ -258,3 +271,49 @@ examples: > }; > }; > }; > + # Ocelot-ext VSC7512 > + - | > + spi { > + soc@0 { soc in spi is a bit confusing. Does it even pass the tests? You have unit address but no reg. > + compatible = "mscc,vsc7512"; > + #address-cells = <1>; > + #size-cells = <1>; > + > + ethernet-switch@0 { > + compatible = "mscc,vsc7512-switch"; > + reg = <0 0>; 0 is the address on which soc bus? > + > + ethernet-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + label = "cpu"; > + ethernet = <&mac_sw>; > + phy-handle = <&phy0>; > + phy-mode = "internal"; > + }; > + > + port@1 { > + reg = <1>; > + label = "swp1"; > + phy-mode = "internal"; > + phy-handle = <&phy1>; > + }; > + > + port@2 { > + reg = <2>; > + phy-mode = "internal"; > + phy-handle = <&phy2>; > + }; > + > + port@3 { > + reg = <3>; > + phy-mode = "internal"; > + phy-handle = <&phy3>; > + }; How is this example different than previous one (existing soc example)? If by compatible and number of ports, then there is no much value here. > + }; > + }; > + }; > + }; Best regards, Krzysztof
Powered by blists - more mailing lists