Message-ID: <0fa79232-18f7-af96-e116-a71b735a903d@gmail.com>
Date:   Sat, 25 Feb 2023 17:58:24 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.8.0
Subject: Re: Raspberry Pi 4B: Failed to create device link with
 soc:firmware:gpio
Content-Language: en-US
To:     Saravana Kannan <saravanak@google.com>
Cc:     Stefan Wahren <stefan.wahren@i2se.com>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel <linux-kernel@vger.kernel.org>,
        Android Kernel Team <kernel-team@android.com>
References: <03b70a8a-0591-f28b-a567-9d2f736f17e5@gmail.com>
 <CAGETcx-KLfxKae6-Kc74gOu2fiuu+5528j_TNEaY21U3_yZO0w@mail.gmail.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
In-Reply-To: <CAGETcx-KLfxKae6-Kc74gOu2fiuu+5528j_TNEaY21U3_yZO0w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 2/25/2023 4:01 PM, Saravana Kannan wrote:
> On Sat, Feb 25, 2023 at 7:38 AM Florian Fainelli <f.fainelli@gmail.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