linux-kernel - Re: Raspberry Pi 4B: Failed to create device link with soc:firmware:gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Feb 2023 17:58:24 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Stefan Wahren <stefan.wahren@...e.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: Raspberry Pi 4B: Failed to create device link with
 soc:firmware:gpio



On 2/25/2023 4:01 PM, Saravana Kannan wrote:
> On Sat, Feb 25, 2023 at 7:38 AM Florian Fainelli <f.fainelli@...il.com> wrote:
>>
>> Hi Saravana,
>>
>> Using v6.2-10217-ga93e884edf61v my Raspberry Pi 4B issues the following
>> for the "extended GPIO" provider:
>>
>> [    5.969855] uart-pl011 fe201000.serial: Failed to create device link
>> with soc:firmware:gpio
> 
> Outside of this error, is it actually breaking anything? 

There is just this warning, there does not appear to be a functional issue.

> Also, can you
> pull in this patch and tell me what it says? I want to know what the
> flags are.
> https://lore.kernel.org/lkml/20230225064148.274376-1-saravanak@google.com/
> 
> Can you also change every pr_debug and dev_dbg in drivers/base/core.c
> to an info and then give me the logs as an attachment?

Sure will do.

> 
>> The kernel configuration I am using can be found here:
>>
>> https://gist.github.com/ffainelli/4eb83740c25b10f75b54560f8c8febb1
>>
>> And the DTS is arch/arm*/boot/dts/bcm2711-rpi-4-b.dts
> 
> Ah, is this yet another case of a DTS that's not upstream? Don't
> worry, I'll still look at it as it might point to some existing
> upstream issue too.

This is with the upstream DTS file under that directory, I used * to 
denote that this was used equally for both arm and arm64.

Thanks!
-- 
Florian