Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 16 Jul 2023 21:51:50 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali@kernel.org>
To:     Greg KH <greg@kroah.com>
Cc:     Aurelien Jarno <aurelien@aurel32.net>,
        Florian Fainelli <florian.fainelli@broadcom.com>,
        stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Backporting commits for generating rpi dtb symbols to stable
Message-ID: <20230716195150.ppa6vdjogjevlzgq@pali>
References: <20230716162444.zzvkm4rh7s7lu37x@pali>
 <2023071644-earflap-amazingly-3989@gregkh>
 <20230716163852.jnd4u4ylvifgmpby@pali>
 <2023071611-lustiness-rename-8b47@gregkh>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2023071611-lustiness-rename-8b47@gregkh>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Sunday 16 July 2023 21:08:38 Greg KH wrote:
> On Sun, Jul 16, 2023 at 06:38:52PM +0200, Pali Rohár wrote:
> > On Sunday 16 July 2023 18:32:42 Greg KH wrote:
> > > On Sun, Jul 16, 2023 at 06:24:44PM +0200, Pali Rohár wrote:
> > > > Hello,
> > > > 
> > > > I see that raspberry pi bootloader throws ton of warnings when supplied
> > > > DTB file does not contain /__symbols__/ node.
> > > > 
> > > > On RPI 1B rev1 it looks like this:
> > > > 
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > dterror: no symbols found
> > > > 
> > > > Bootloader also propagates these warnings to kernel via dtb property
> > > > chosen/user-warnings and they can be read by simple command:
> > > > 
> > > > $ cat /sys/firmware/devicetree/base/chosen/user-warnings
> > > > ...
> > > > 
> > > > Upstream Linux kernel build process by default does not generate
> > > > /__symbols__/ node for DTB files, but DTB files provided by raspberrypi
> > > > foundation have them for a longer time.
> > > > 
> > > > I wanted to look at this issue, but I figured out that it is already
> > > > solved by just recent Aurelien's patches:
> > > > 
> > > > e925743edc0d ("arm: dts: bcm: Enable device-tree overlay support for RPi devices")
> > > > 3cdba279c5e9 ("arm64: dts: broadcom: Enable device-tree overlay support for RPi devices")
> > > > 
> > > > My testing showed that /__symbols__/ node is required by rpi bootloader
> > > > for overlay support even when overlayed DTB file does not use any DTB
> > > > symbol (and reference everything via full node path). So seems that
> > > > /__symbols__/ node is crucial for rpi bootloader even when symbols from
> > > > them are not used at all.
> > > > 
> > > > So I would like to ask, would you consider backporting these two
> > > > raspberry pi specific patches to stable kernel trees? Upstream kernel
> > > > would get rid of those bootloader warnings and also allow users to use
> > > > overlayed dtbs...
> > > 
> > > What kernel tree(s) should these be applied to?  What trees did you test
> > > them for?
> > > 
> > > Also, adding dt-overlay support does not seem like a stable kernel fix,
> > > as this isn't a bugfix from what I can tell, right?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > I wanted to discuss what do you think about it. As I wrote my motivation
> > was to understood and get rid of those warnings "dterror: no symbols
> > found" from bootloader when using DTB files from mainline kernel (as
> > opposite of the DTB files from rpi foundation). And fix for it was just
> > to generate DTB files from kernel via dtc's -@ parameter, same what are
> > doing those mentioned patches (but they describe different problem for
> > which is same fix). I thought that fixing those bootloader warnings is a
> > bugfix.
> 
> Why not just use the next kernel version instead?  What's forcing you to
> use an older stable kernel that didn't have dt-overlay support?
> 
> thanks,
> 
> greg k-h

Why not use the next kernel? It is pretty simple, next is the
development tree, not for production. And as I wrote in previous email,
I do not need here dt-overlay support. I wanted to get rid off that
warning messages.