linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6511c88d-7876-4f69-81f1-1206056d061a@gmx.net>
Date: Thu, 17 Apr 2025 00:39:22 +0200
From: Stefan Wahren <wahrenst@....net>
To: Andrew Lunn <andrew@...n.ch>
Cc: Lukasz Majewski <lukma@...x.de>, 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,

Am 16.04.25 um 23:58 schrieb Andrew Lunn:
>>> -		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.
>
>        Andrew
i wasn't aware how critical possible overlapping memory regions are. I 
was just surprised because it wasn't mention in the commit message. As 
long as everyone is fine with this approach, please ignore my last comment.

Regards