linux-kernel - Re: Sorting out the RTL9300 dt-bindings

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: <98a7fdf5-585f-47a7-bb28-5cef43f7ac76@kernel.org>
Date: Sun, 9 Feb 2025 15:40:12 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>, Rob Herring <robh@...nel.org>,
 "lee@...nel.org" <lee@...nel.org>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Sorting out the RTL9300 dt-bindings

On 04/02/2025 23:39, Chris Packham wrote:
> Hi,
> 
> As Krzysztof points out in [1] I seem to have made a bit of a mess with 
> the mfd binding for the RTL9300 Ethernet switch with integrated CPU. I'm 
> spinning up this email thread separately so as not to unnecessarily spam 
> the netdev folks and to maybe appease google so it doesn't automatically 
> get flagged as junk.
> 
> First off sorry for not providing a more complete binding initially, 
> Krzysztof suggested doing so a few times but I was concentrating on 
> landing the drivers.
> 
> The RTL9300 has these basic blocks:
> - rtl9300
>    |- cpu@0 - mips34kc
>    |- soc@...00000
>      |- intc
>      |- spi-nor
>      |- spi-nand
>      |- timer
>      |- gpio
>      `- uart
>    `- switch@...00000
>       |- ethernet-ports
>       |- mdio
>       |- i2c
>       |- reset
>       `- led/gpio
> 
> The CPU/soc can be disabled and the switch managed by an external CPU 
> (register access over SPI I think, the docs are a bit vague).
> 
> I think I probably inferred too much from mfd/mscc,ocelot.yaml when I 
> created mfd/realtek,rtl9301-switch.yaml.


... and to recap to others for context, the problem is that switch is
simple-mfd and most of the switch children have bus addresses (MMIO of
the switch region) but ethernet-ports does not.

This will work fine, but is discouraged style.

Considering also that some of the children - like syscon-reboot or i2c -
take one or few registers as address space, maybe adding MMIO for
children was not necessary at all.

>From implementation point of view, this MMIO is not really used, because
children anyway get and use regmap from the parent, right?

> 
> I still think the switch@...00000 needs to be "syscon", "simple-mfd" as 
> that's how the reset and i2c blocks work and they're pretty independent 
> of everything else.
> 
> I've currently described the mdio interface as a device on a simple bus 
> although it could just be handled as a descendant of the switch block 
> that a driver looks up as a child node (I've tried to keep the mdio 
> driver independent for now but that's an implementation detail). It does 
> need to reach out to the ethernet-ports to figure out the mapping of 
> port to phy so it isn't independent.
> 
> I see a couple of paths forward
> - keep adding the switch stuff to the mfd/realtek,rtl9301-switch.yaml

I think that's the way to go.

> - move mfd/realtek,rtl9301-switch.yaml to net/realtek,rtl9301-switch.yaml

This you can do anyway. MFD in bindings is rather placeholder for
complex devices where we cannot assign one, common function. In your
case you call it switch, so it could be placed in net in the first place.


> - keep mfd/realtek,rtl9301-switch.yaml with the i2c and reboot but have 
> a $ref to a new binding under net/ (not sure what that'd look like).
> 
> There's only one in-tree user of this so I don't think we need to be too 
> concerned about backwards compatibility. Downstream openwrt handles 
> these devices way differently already.


Best regards,
Krzysztof