[PATCH 3/3] arm: dts: k3-am62: Bump dtsi from linux v6.5-rc1

[Nishanth Menon]

On 10:15-20230726, Maxime Ripard wrote:
> On Wed, Jul 26, 2023 at 11:26:05AM +0530, Ravi Gunasekaran wrote:
> > 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 at dolcini.it>
> > >>>> Cc: Sjoerd Simons <sjoerd at collabora.com>
> > >>>> Cc: Wadim Egorov <w.egorov at phytec.de>
> > >>>> Signed-off-by: Nishanth Menon <nm at 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.dtsi#L132
> > >> 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.
> 
> Yeah, exactly. The "Tomorrow" case probably makes it functional for
> U-Boot but breaks Linux in the process. It was functional in Linux
> before because it has everything needed to set up the network and didn't
> rely on U-Boot for that at all.
> 

https://github.com/nmenon/fix-k3-dt-u-boot/commits/fdt-fixup-s1-am625-rev3.1
If we are willing to add the dependency of:

https://lore.kernel.org/r/20230724-ti-mdio-pinmux-v4-1-18541f976501@kernel.org
https://lore.kernel.org/r/20230722193151.117345-2-rogerq@kernel.org
https://lore.kernel.org/r/20230722193151.117345-3-rogerq@kernel.org

Tom,

I need some guidance here - i can squash the fixup if the
dependencies queued.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D