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: <20221021143058.fg5vet5or4qcnet2@skbuf> Date: Fri, 21 Oct 2022 14:30:59 +0000 From: Vladimir Oltean <vladimir.oltean@....com> To: Maxime Chevallier <maxime.chevallier@...tlin.com> CC: "davem@...emloft.net" <davem@...emloft.net>, Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Luka Perkov <luka.perkov@...tura.hr>, Robert Marko <robert.marko@...tura.hr> Subject: Re: [PATCH net-next v5 1/5] net: dt-bindings: Introduce the Qualcomm IPQESS Ethernet controller On Fri, Oct 21, 2022 at 02:45:52PM +0200, Maxime Chevallier wrote: > + interrupts: > + minItems: 2 > + maxItems: 32 > + description: One interrupt per tx and rx queue, with up to 16 queues. What does the binding require in terms of ordering, exactly? Whose interrupt is the 7th one (GIC_SPI 71 in your example)? RX/TX of which queue? > + > + clocks: > + maxItems: 1 > + > + resets: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + - interrupts > + - clocks > + - resets > + - phy-mode > + > +unevaluatedProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/qcom,gcc-ipq4019.h> > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + #include <dt-bindings/interrupt-controller/irq.h> > + gmac: ethernet@...0000 { > + compatible = "qcom,ipq4019-ess-edma"; > + reg = <0xc080000 0x8000>; > + resets = <&gcc ESS_RESET>; > + clocks = <&gcc GCC_ESS_CLK>; > + interrupts = <GIC_SPI 65 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 66 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 67 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 68 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 69 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 70 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 71 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 72 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 73 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 74 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 76 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 77 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 240 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 241 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 242 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 243 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 244 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 245 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 246 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 247 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 248 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 249 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 250 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 251 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 252 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 253 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 254 IRQ_TYPE_EDGE_RISING>, > + <GIC_SPI 255 IRQ_TYPE_EDGE_RISING>; > + > + phy-mode = "internal"; I think empty lines are typically added between properties and nodes (and between nodes on the same hierarchy), rather than between 2 properties. > + fixed-link { > + speed = <1000>; > + full-duplex; > + pause; > + asym-pause; Any particular reason for "asym-pause"? Looking at the comment above linkmode_resolve_pause(), I don't think it makes any difference to the flow control resolution (link partner AsmDir is "don't care" when we have MAC_SYM_PAUSE in mac_capabilities and the "fixed-link" node - effectively the link partner - also has "pause"). > + }; > + }; > + > +... > -- > 2.37.3 >
Powered by blists - more mailing lists