Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v1 0/2] Make fw_devlink=on more forgiving
To:     Saravana Kannan <saravanak@google.com>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Marc Zyngier <maz@kernel.org>,
        Tudor Ambarus <Tudor.Ambarus@microchip.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Android Kernel Team <kernel-team@android.com>
From:   Marek Szyprowski <m.szyprowski@samsung.com>
Message-ID: <71b1ee03-830e-750f-5ed6-ccf5e1cc7810@samsung.com>
Date:   Tue, 2 Feb 2021 09:12:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0)
        Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAGETcx9FokhX+omo07Tgky_+NPH4uYSMiz2OctvK3L3AsGz8rg@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 201P
References: <20210130040344.2807439-1-saravanak@google.com>
        <CGME20210130040932eucas1p21f614520b70e3aecf3bf384a5821e5e8@eucas1p2.samsung.com>
        <CAGETcx941J7Zhrf=ZjO6PW0fiax5VXcV3gbsLQfM_wU_U0EnYw@mail.gmail.com>
        <ca582e9f-bc4d-bb94-f700-1cf9dc897b57@samsung.com>
        <CAGETcx9FokhX+omo07Tgky_+NPH4uYSMiz2OctvK3L3AsGz8rg@mail.gmail.com>
Precedence: bulk

Hi Saravana,

On 01.02.2021 10:02, Saravana Kannan wrote:
> On Mon, Feb 1, 2021 at 12:05 AM Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
>> On 30.01.2021 05:08, Saravana Kannan wrote:
>>> On Fri, Jan 29, 2021 at 8:03 PM Saravana Kannan <saravanak@google.com> wrote:
>>>> This patch series solves two general issues with fw_devlink=on
>>>>
>>>> Patch 1/2 addresses the issue of firmware nodes that look like they'll
>>>> have struct devices created for them, but will never actually have
>>>> struct devices added for them. For example, DT nodes with a compatible
>>>> property that don't have devices added for them.
>>>>
>>>> Patch 2/2 address (for static kernels) the issue of optional suppliers
>>>> that'll never have a driver registered for them. So, if the device could
>>>> have probed with fw_devlink=permissive with a static kernel, this patch
>>>> should allow those devices to probe with a fw_devlink=on. This doesn't
>>>> solve it for the case where modules are enabled because there's no way
>>>> to tell if a driver will never be registered or it's just about to be
>>>> registered. I have some other ideas for that, but it'll have to come
>>>> later thinking about it a bit.
>>>>
>>>> These two patches might remove the need for several other patches that
>>>> went in as fixes for commit e590474768f1 ("driver core: Set
>>>> fw_devlink=on by default"), but I think all those fixes are good
>>>> changes. So I think we should leave those in.
>>>>
>>>> Marek, Geert,
>>>>
>>>> Can you try this series on a static kernel with your OF_POPULATED
>>>> changes reverted? I just want to make sure these patches can identify
>>>> and fix those cases.
>>>>
>>>> Tudor,
>>>>
>>>> You should still make the clock driver fix (because it's a bug), but I
>>>> think this series will fix your issue too (even without the clock driver
>>>> fix). Can you please give this a shot?
>>> Marek, Geert, Tudor,
>>>
>>> Forgot to say that this will probably fix your issues only in a static
>>> kernel. So please try this with a static kernel. If you can also try
>>> and confirm that this does not fix the issue for a modular kernel,
>>> that'd be good too.
>> I've checked those patches on top of linux next-20210129 with
>> c09a3e6c97f0 ("soc: samsung: pm_domains: Convert to regular platform
>> driver") commit reverted.
> Hi Marek,
>
> Thanks for testing!
>
>> Sadly it doesn't help.
> That sucks. I even partly "tested" it out on my platform (that needs
> CONFIG_MODULES) by commenting out the CONFIG_MODULES check. And I saw
> some device links getting dropped.

Well, my fault. I've missed the fact that I have to disable 
CONFIG_MODULES to let it work. This is not really a fix for my case, 
because the exynos_defconfig has modules enabled (mainly for WiFi and 
media drivers). However disabling the CONFIG_MODULES indeed helped a 
bit. Most of the devices got finally probed. There are only 4 left in 
the deferred_devices list:

sound
12e20000.sysmmu
12d00000.hdmi
12c10000.mixer

The last two (12c10000.mixer and 12d00000.hdmi) are consumers of the 
12e20000.sysmmu, which is a consumer of the 10023c20.power-domain. That 
power domain in turn is a consumer (child) of another power domain 
(10023c80.power-domain):

# dmesg | grep 10023c20.power-domain
[    0.354435] platform 10023c20.power-domain: Linked as a consumer to 
10023c80.power-domain
[    0.489573] platform 12d00000.hdmi: Linked as a consumer to 
10023c20.power-domain
[    0.497143] platform 12c10000.mixer: Linked as a consumer to 
10023c20.power-domain
[    0.580874] platform 12e20000.sysmmu: Linked as a consumer to 
10023c20.power-domain
[    0.601655] platform 12e20000.sysmmu: probe deferral - supplier 
10023c20.power-domain not ready
[    2.744884] platform 12c10000.mixer: probe deferral - supplier 
10023c20.power-domain not ready
[    2.766726] platform 12d00000.hdmi: probe deferral - supplier 
10023c20.power-domain not ready

...

So a dependency chain of 2 power domains is still not resolved properly.

I didn't have time to check what's wrong with the sound node. Simple 
grepping of the messages for the 'sound' string don't give any results. 
The above tests has been done on the Odroid U3 board 
(arch/arm/boot/dts/exynos4412-odroidu3.dts).

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland