[PATCH 00/31] rockchip: rk3399: Sync DT with linux v6.8 and update defconfigs

[Sumit Garg]

On Mon, 1 Apr 2024 at 15:54, Jonas Karlman <jonas at kwiboo.se> wrote:
>
> On 2024-04-01 12:08, Sumit Garg wrote:
> > On Mon, 1 Apr 2024 at 15:15, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>
> >> Hi Sumit,
> >>
> >> On 2024-04-01 10:52, Sumit Garg wrote:
> >>> Hi Jonas,
> >>>
> >>> On Mon, 1 Apr 2024 at 01:59, Jonas Karlman <jonas at kwiboo.se> wrote:
> >>>>
> >>>> This series adds support for new clocks used in linux v6.8 device trees,
> >>>> enables use of FIT signature check for checksum validation and fixes
> >>>> loading FIT from SD-card when loading FIT from eMMC fails.
> >>>>
> >>>> After this series it should be possible to move RK3399 boards to use
> >>>> OF_UPSTREAM in a future patch once dts/upstream move to a v6.8+ tag.
> >>>>
> >>>
> >>> Thanks for putting this effort together. A switch to v6.8 tag for
> >>> OF_UPSTREAM will happen as part of patch [1]. So if you want to save
> >>> further effort then you can just rebase with a switch to OF_UPSTREAM
> >>> once that patch [1] lands in next.
> >>
> >> Because this is a jump of device tree files from v5.14-rc1 to v6.8,
> >> reviewability and being able to cherry-pick these changes to my
> >> rk3xxx-2024.04 branch, I think it is much more appropriate to first sync
> >> everything to v6.8 and then in a separate series move to OF_UPSTREAM.
> >> Else it can be very hard to understand some of the changes that has been
> >> and was needed to be made to u-boot.dtsi files.
> >
> > That's fair given it's a long pending DT sync.
> >
> >>
> >> Reviewability is one of the shortcomings with a switch to OF_UPSTREAM.
> >
> > I suppose the reasoning behind this thinking can be that people are
> > used to reviewing DTs alongside driver changes. However, these patches
> > aren't actual DT changes but rather DT imports which IMHO is a
> > distraction for the reviewer. The actual DT can be looked into
> > dts/upstream/ directory while reviewing the changes.
>
> Things like following was easier to spot when reviewing DT syncs:
> - A property that U-Boot depends on gets removed, as in [1].

That seems to be due to DT bindings compliance check where DT bindings
are the ABI. Although it is unfortunate due to dependency on legacy
DT, now we have the same dtbs_check in U-Boot too:

$ make <target>_defconfig
$ make -j`nproc` dtbs_check

This shall keep U-Boot in compliance with DT bindings and help avoid
such dependencies.

> - Some DT changes can break changes that has been made to u-boot.dtsi
>   files, e.g. a symbol to a node is no longer available in upstream but
>   referenced in u-boot.dtsi files (happened in this series).

Node names aren't a DT ABI so we should expect some changes there.

> - Changes in DT may require a workaround in a u-boot.dtsi file.
> - u-boot.dtsi contains workarounds that has not yet been upstream but
>   can be removed in a future DT sync.

Agree, we should try to minimize modifications via u-boot.dtsi
especially all the bootph* related properties should be posted
upstream.

> - Driver incompatibilities due to initial driver imported from vendor
>   ended up not fully compatible with upstream linux driver / dt-binding.

Given all the above and the big jump in DT sync for Rockchip
platforms, I am fine with the transition being step by step.

-Sumit

>
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4d08b19629495b29601991d09d07865694c25199
>