On 1/24/24 09:16, Sumit Garg wrote:
Hi,
How do you propose to handle fixes to DTs which are applied to
linux-stable releases ? For example, if Linux 6.6(.0) ships a DT which
has some defect that is fixed in 6.6.1, how will that fix get into
U-Boot DTs ?
This fix would also be in the latest Linux tags, so I think it would
find its way here - as I understand it patches aren't accepted into
Linux stable unless they land in torvalds tree.
See the devicetree-rebasing.git:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/refs/
That only contains refs for release versions (v6.6-dts, v6.7-dts etc),
not any follow-up updates from linux-stable (like current 6.6.13 etc).
Here we should only consider fixes which are critical to U-Boot. I
think -u-boot.dtsi files would be suitable to carry those fixes until
next uprev. However, if there is a fix affecting many platforms than
we can consider pulling that standalone too.
That would mean extra duplicate work -- the critical fixes have already
been selected into linux-stable, that work is already done, I don't
think it makes sense to re-do it again.
Furthermore, I do not like the new necessity to start porting those
fixes from linux-stable and converting them to adjustments to
*-u-boot.dtsi files, this is tedious and error prone, so it would have
to be automated.
But I still think it is much better to simply take the fixes directly
from linux-stable as-is instead.
Would this require syncing in -rc versions of Linux DTs to get the
latest fixes in ?
Syncing -rc versions makes U-Boot more prone to DT ABI breakages. So
its a chicken and egg problem as per your comments below. However, we
can revisit our syncing strategy based on how the current one pans
out.
Assume that there is some large breaking change in Linux 6.(n+1),
something which would be problematic for specific U-Boot platform
(e.g. i.MX) or would require a lot of work to sort out, will there be
a way to temporarily pin DTs for specific platform to older DT version
until that is resolved (e.g. pin to 6.n) ?
(Upstream) devicetree has to be forwards and backwards compatible, were
such a breaking change to get merged without prior discussion with DT
users (i.e. U-Boot) then I think the correct course of action would be
to revert it.
Not really, this could be a perfectly valid change, and would work for
Linux just fine, it might simply be pulling in something which is not
supported by U-Boot just yet and therefore syncing the DTs into U-Boot
would break U-Boot on that platform . Using older version of DTs for a
platform could work as a stopgap measure until the functionality is
implemented. Is this possible ?
For this particular reason we want to pull once during beginning on
U-Boot next window and allow sufficient time for platform maintainers
to adapt to it. However, OF_UPSTREAM=n can be an alternative for a
stopgap solution.
That pull would break other peoples platforms. It would be no different
than adding broken patch into the code base. What I think would be an
option is that there is a pull (as in patch) and people should be able
to test it before it is applied. If one platform is severely affected
while other platforms are fine, the one platform should be able to use
the current working version of DTs, while the other platforms should not
be blocked by it. Is that what OF_UPSTREAM=n does ?
As far as I understand OF_UPSTREAM=n, it would require re-importing DTs
into the codebase ?
On a tangential note: as I understand it, DTs built from dt-rebasing are
still subject to U-Boot customisations via the "-u-boot.dtsi" include
files, this allows for dealing with incompatibilities due to missing
features in U-Boot.
Would it be possible to auto-update those -u-boot.dtsi files during
sync, to minimize the resulting DT blob delta before/after update, and
thus also minimize the likelihood of causing breakage ?
In the long run the DT community would like to avoid any DT ABI
breakages at all. Rob is already working on a DT ABI check tool and
seeking inputs for what could be an ABI break [1] from U-Boot
perspective too. Feel free to provide your inputs.
Along with that we wouldn't need -u-boot.dtsi files once we make
U-Boot fully compliant with DT bindings. Until that point U-Boot
platform maintainers have to keep their -u-boot.dtsi files updated
corresponding to latest DT rebasing releases.
I think upstreaming the bootph* properties would still take a while, but
is not relevant to the aforementioned question.
Assume there is a sync, would the current in-tree -u-boot.dtsi files get
updated to work correctly with the newly synced DTs ?
