On 7/25/23 11:47 PM, Tom Rini wrote:
On Tue, Jul 25, 2023 at 09:09:34AM -0500, Nishanth Menon wrote:
On 15:56-20230725, Maxime Ripard wrote:
Hi,
On Tue, Jul 25, 2023 at 07:58:56AM -0500, Nishanth Menon wrote:
Update the am62 and am625 device-trees from linux v6.3-rc5 This needed the followin tweaks to the u-boot specific dtsi as well:
- Switch tick-timer to the main_timer as it's now defined in the main dtsi
- Secure proxies are defined in Soc dtsis
- Drop duplicate nodes - u-boot.dtsi is includes in r5-sk, no need for either the definitions from main.dtsi OR duplication from u-boot.dtsi
- Add mdio pins to the cpsw3g pinctrl in u-boot dtsi. It moved to a subnode in the linux dtsi that u-boot doesn't use/support
Cc: Francesco Dolcini francesco@dolcini.it Cc: Sjoerd Simons sjoerd@collabora.com Cc: Wadim Egorov w.egorov@phytec.de Signed-off-by: Nishanth Menon nm@ti.com
I decided not to pick up changes from Roger and Maxime as they are'nt regression fixes, instead the fixups can be done on top of the basic sync.
This breaks Linux network interfaces so I very much considers this a regression.
The current u-boot.dtsi I am confused - pinctrl mdio is still a problem, is'nt it? https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/k3-am625-sk-u-boot... The follow on fixups from both your and Roger's series should fix things up, correct?
I'm a little confused here too. For each of these cases, what happens?
- Today, one of these platforms, we pass the kernel the in-memory U-Boot device tree. And if this is functional for networking, how/why?
In here, the mdio pinctrl configuration is present only in one node (CPSW). So there is no conflict when the in-memory DT is passed by U-Boot to kernel.
- "Tomorrow", one of these platforms, with Nishanth's series applied, we pass the in-memory U-Boot device tree
In this case, the DT passed by U-Boot has the mdio pinctrl info present in two nodes - one in CPSW and other in MDIO. This causes failure in Linux as both nodes refer to same pinctrl configuration.
- Today or "Tomorrow", we continue to pass a device tree loaded from SD/whatever that matches the kernel. This should work, and I think is what's assumed to be the only functional option right now
Kernel DT has mdio pinctrl info only in one node (MDIO). So passing a DT that matches the kernel does not cause any issue.