Devicetree
 help / color / mirror / Atom feed
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



  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