public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <florian.fainelli@broadcom.com>
To: "Pali Rohár" <pali@kernel.org>, "Greg KH" <greg@kroah.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Backporting commits for generating rpi dtb symbols to stable
Date: Mon, 17 Jul 2023 12:38:41 +0200	[thread overview]
Message-ID: <f214c0a0-c9f6-bfbb-3d75-2a2f7602083f@broadcom.com> (raw)
In-Reply-To: <20230716195150.ppa6vdjogjevlzgq@pali>

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]



On 7/16/2023 9:51 PM, Pali Rohár wrote:
> 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.

Maybe "next" should have not been taken as designating linux-next, but 
whichever kernel version you are currently using wait for 6.5 final and 
use it since it does contains Aurelien's commits.

> And as I wrote in previous email,
> I do not need here dt-overlay support. I wanted to get rid off that
> warning messages.

The motivation does not seem appropriate to warrant a stable backport, 
besides as noted in the commit message including relocation information 
inflates the resulting .dtb files, which could be seen as a regression.
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4221 bytes --]

  reply	other threads:[~2023-07-17 10:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-16 16:24 Backporting commits for generating rpi dtb symbols to stable Pali Rohár
2023-07-16 16:32 ` Greg KH
2023-07-16 16:38   ` Pali Rohár
2023-07-16 19:08     ` Greg KH
2023-07-16 19:51       ` Pali Rohár
2023-07-17 10:38         ` Florian Fainelli [this message]
2023-07-16 19:47 ` Aurelien Jarno
2023-07-16 19:55   ` Pali Rohár

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=f214c0a0-c9f6-bfbb-3d75-2a2f7602083f@broadcom.com \
    --to=florian.fainelli@broadcom.com \
    --cc=aurelien@aurel32.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=stable@vger.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