netdev - Re: [net-next v5 2/6] ARM: dts: nxp: mxs: Adjust the imx28.dtsi L2 switch description

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250417083334.69b565b0@wsk>
Date: Thu, 17 Apr 2025 08:33:34 +0200
From: Lukasz Majewski <lukma@...x.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Stefan Wahren <wahrenst@....net>, Andrew Lunn <andrew+netdev@...n.ch>,
 davem@...emloft.net, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
 <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Richard Cochran
 <richardcochran@...il.com>, netdev@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, Simon Horman
 <horms@...nel.org>
Subject: Re: [net-next v5 2/6] ARM: dts: nxp: mxs: Adjust the imx28.dtsi L2
 switch description

Hi Andrew,

> > > -		eth_switch: switch@...f8000 {
> > > -			reg = <0x800f8000 0x8000>;
> > > +		eth_switch: switch@...f0000 {
> > > +			compatible = "nxp,imx28-mtip-switch";
> > > +			reg = <0x800f0000 0x20000>;
> > > +			interrupts = <100>, <101>, <102>;
> > > +			clocks = <&clks 57>, <&clks 57>, <&clks
> > > 64>, <&clks 35>;
> > > +			clock-names = "ipg", "ahb", "enet_out",
> > > "ptp"; status = "disabled";  
> > from my understanding of device tree this file should describe the
> > hardware, not the software implementation. After this change the
> > switch memory region overlaps the existing mac0 and mac1 nodes.
> > 
> > Definition in the i.MX28 reference manual:
> > ENET MAC0 ENET 0x800F0000 - 0x800F3FFF 16KB
> > ENET MAC1 ENET 0x800F4000 - 0x800F7FFF 16KB
> > ENT Switch SWITCH 0x800F8000 - 0x800FFFFF 32KB
> > 
> > I'm not the expert how to solve this properly. Maybe two node
> > references to mac0 and mac1 under eth_switch in order to allocate
> > the memory regions separately.  
> 
> I get what you are saying about describing the hardware, but...
> 
> The hardware can be used in two different ways.
> 
> 1) Two FEC devices, and the switch it left unused.
> 
> For this, it makes sense that each FEC has its own memory range, there
> are two entries, and each has a compatible, since there are two
> devices.
> 
> 2) A switch and MAC conglomerate device, which makes use of all three
>    blocks in a single driver.
> 
> The three hardware blocks have to be used as one consistent whole, by
> a single driver. There is one compatible for the whole. Given the
> ranges are contiguous, it makes little sense to map them individually,
> it would just make the driver needlessly more complex.
> 
> It should also be noted that 1) and 2) are mutually exclusive, so i
> don't think it matters the address ranges overlap. Bad things are
> going to happen independent of this if you enable both at once.
> 

+1

>       Andrew


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...x.de

Content of type "application/pgp-signature" skipped