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/5] Enable fw_devlink=on by default
To:     Marc Zyngier <maz@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Saravana Kannan <saravanak@google.com>
CC:     "Rafael J. Wysocki" <rafael@kernel.org>, <kernel-team@android.com>,
        <linux-kernel@vger.kernel.org>,
        Jisheng Zhang <Jisheng.Zhang@synaptics.com>,
        Kevin Hilman <khilman@baylibre.com>,
        John Stultz <john.stultz@linaro.org>,
        Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
        linux-tegra <linux-tegra@vger.kernel.org>
References: <20201218031703.3053753-1-saravanak@google.com>
 <X/dpkgTnUk+inKHK@kroah.com> <e28e1f38d87c12a3c714a6573beba6e1@kernel.org>
From:   Jon Hunter <jonathanh@nvidia.com>
Message-ID: <ba2fcbfb-d714-2f73-3bd0-962f49363b62@nvidia.com>
Date:   Wed, 13 Jan 2021 15:27:03 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <e28e1f38d87c12a3c714a6573beba6e1@kernel.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


On 13/01/2021 11:11, Marc Zyngier wrote:
> On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
>> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
>>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>>> be broken using logic was one of the last remaining reasons
>>> fw_devlink=3Don couldn't be set by default.
>>>
>>> This series changes fw_devlink so that when a cyclic dependency is foun=
d
>>> in firmware, the links between those devices fallback to permissive mod=
e
>>> behavior. This way, the rest of the system still benefits from
>>> fw_devlink, but the ambiguous cases fallback to permissive mode.
>>>
>>> Setting fw_devlink=3Don by default brings a bunch of benefits (currentl=
y,
>>> only for systems with device tree firmware):
>>> * Significantly cuts down deferred probes.
>>> * Device probe is effectively attempted in graph order.
>>> * Makes it much easier to load drivers as modules without having to
>>> =C2=A0 worry about functional dependencies between modules (depmod is s=
till
>>> =C2=A0 needed for symbol dependencies).
>>>
>>> Greg/Rafael,
>>>
>>> Can we get this pulled into 5.11-rc1 or -rc2 soon please? I expect to
>>> see some issues due to device drivers that aren't following best
>>> practices (they don't expose the device to driver core). Want to
>>> identify those early on and try to have them fixed before 5.11 release.
>>> See [1] for an example of such a case.
>>
>> Now queued up in my tree, will show up in linux-next in a few days,
>> let's see what breaks!=C2=A0 :)
>>
>> And it is scheduled for 5.12-rc1, not 5.11, sorry.
>=20
> For the record, this breaks my rk3399 board, (NanoPC-T4) as no mass
> storage can be discovered (it lives on PCIe):
>=20
> (initramfs) find /sys -name 'waiting_for_supplier'| xargs grep .| egrep
> -v ':0$'
> /sys/devices/platform/ff3d0000.i2c/i2c-4/4-0022/waiting_for_supplier:1
> /sys/devices/platform/f8000000.pcie/waiting_for_supplier:1
> /sys/devices/platform/fe320000.mmc/waiting_for_supplier:1
> /sys/devices/platform/sdio-pwrseq/waiting_for_supplier:1
> /sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/waiting_for_supplier:1
>=20
> Enabling the debug prints in device_links_check_suppliers(), I end up wit=
h
> the dump below (apologies for the size).


I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
are continuously deferred and prevents the board from booting ...

[    2.518334] platform panel: probe deferral - supplier regulator@11 not r=
eady

[    2.525503] platform regulator@1: probe deferral - supplier 4-002d not r=
eady

[    2.533141] platform regulator@3: probe deferral - supplier regulator@10=
1 not ready

[    2.540856] platform regulator@5: probe deferral - supplier regulator@10=
1 not ready

[    2.548589] platform regulator@6: probe deferral - supplier regulator@10=
1 not ready

[    2.556316] platform regulator@7: probe deferral - supplier regulator@10=
1 not ready

[    2.564041] platform regulator@8: probe deferral - supplier regulator@10=
1 not ready

[    2.571743] platform regulator@9: probe deferral - supplier regulator@10=
1 not ready

[    2.579463] platform regulator@10: probe deferral - supplier regulator@1=
01 not ready

[    2.587273] platform regulator@11: probe deferral - supplier regulator@1=
01 not ready

[    2.595088] platform regulator@12: probe deferral - supplier regulator@1=
04 not ready

[    2.603837] platform regulator@102: probe deferral - supplier regulator@=
104 not ready

[    2.611726] platform regulator@103: probe deferral - supplier regulator@=
104 not ready

[    2.620137] platform 3000.pcie: probe deferral - supplier regulator@5 no=
t ready


Cheers
Jon

--=20
nvpublic