From: "Heiko Stübner" <heiko@sntech.de>
To: FUKAUMI Naoki <naoki@radxa.com>,
Diederik de Haas <didi.debian@cknow.org>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
macromorgan@hotmail.com, jonas@kwiboo.se, andyshrk@163.com,
devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
dsimic@manjaro.org
Subject: Re: [PATCH] arm64: dts: rockchip: add support for device tree overlays for Radxa devices
Date: Fri, 29 Nov 2024 15:07:57 +0100 [thread overview]
Message-ID: <3674598.hdfAi7Kttb@diego> (raw)
In-Reply-To: <D5YO8QULYWDR.I3T73UCTD0WF@cknow.org>
Am Freitag, 29. November 2024, 13:46:12 CET schrieb Diederik de Haas:
> Hi,
>
> On Fri Nov 29, 2024 at 1:20 PM CET, Heiko Stübner wrote:
> > Am Freitag, 29. November 2024, 01:24:19 CET schrieb FUKAUMI Naoki:
> > > since Radxa devices use device tree overlays[1][2][3], make base .dts
> > > support them.
> >
> > this essentially doubles the sizes of generated DTBs.
> >
> > In previous iterations there were concerns that this might overload
> > allocated memory in legacy firmware that might still run on people's
> > devices.
> >
> > I'm not sure if someone did look deeper into that meanwhile and you
> > can't of course not require people to update u-boot just for a kernel
> > upgrade. Hence previous overlays do not enable those options but instead
> > depend on "distributions" to handle that.
> >
> > So I'm definitly not sure how to proceed with this.
>
> In my recollection this was brought up when the restructuring of the arm
> (not arm64) dts 'tree' was discussed.
> So hopefully Rob can recall the details?
>
> But IIRC, the objection was about enabling it *globally* and instead it
> should be done more granually, be it on the SoC manufacturer level
> ('rockchip') or on the SoC ('rk3588') or on the board level as is
> proposed in this patch.
>
> e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> is where it got enabled for RPi devices
>
> I can't speak for the Debian kernel team, but the general approach is:
> get it fixed (or in this case enabled) *upstream*.
> That's why Aurelien Jarno (who's a DD) send it upstream.
I actually meant that less broadly and way more Rockchip-specific ;-)
I.e. I think it was Dragan that brought it up that old firmware binaries
(u-boot, tf-a, ...) may occupy memory regions that may run over by an
overly large dtb, but can't find the mail right now.
Hence when unsuspecting people update their kernel on a
(i.e. Radxa-)device with really old firmware there might be a possibility
that stuff may break when the dtb handed around doubles in size.
Heiko
next prev parent reply other threads:[~2024-11-29 14:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 0:24 [PATCH] arm64: dts: rockchip: add support for device tree overlays for Radxa devices FUKAUMI Naoki
2024-11-29 12:20 ` Heiko Stübner
2024-11-29 12:46 ` Diederik de Haas
2024-11-29 14:07 ` Heiko Stübner [this message]
2024-11-29 15:18 ` Diederik de Haas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3674598.hdfAi7Kttb@diego \
--to=heiko@sntech.de \
--cc=andyshrk@163.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=didi.debian@cknow.org \
--cc=dsimic@manjaro.org \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=macromorgan@hotmail.com \
--cc=naoki@radxa.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox