On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson
[off-list ref] wrote:

On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote:

quoted

On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski [off-list ref] wrote:

quoted

On 8/5/20 4:16 PM, Steev Klimaszewski wrote:

quoted

On 8/5/20 3:19 PM, Saravana Kannan wrote:

quoted

On Wed, Aug 5, 2020 at 12:44 AM John Stultz [off-list ref] wrote:

quoted

<sigh>
So this is where I bashfully admit I didn't get a chance to try this
patch series out, as I had success with a much older version of
Saravana's macro magic.

But unfortunately, now that this has landed in mainline, I'm seeing
boot regressions on db845c. :( This is in the non-modular case,
building the driver in.

Does that mean the modular version is working? Or you haven't tried
that yet? I'll wait for your reply before I try to fix it. I don't
have the hardware, but it should be easy to guess this issue looking
at the code delta.

For what it's worth, I saw this too on the Lenovo C630 (started on -next
around 20200727, but I didn't track it down as, well, there's less way
to get debug output on the C630.

In my testing, module or built-in doesn't matter, but reverting does
allow me to boot again.

Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted
boots, however, module (on the c630 at least) doesn't boot whether it's
a module or built-in.

You may need to set deferred_probe_timeout=30 to give things a bit
more grace time to load.

With the risk of me reading more into this than what you're saying,
please don't upstream anything that depend this parameter to be
increased.

Compiling any of these drivers as module should not require the user to
pass additional kernel command line parameters in order to get their
device to boot.

So, ideally I agree, and Saravana's fw_devlink work should allow us to
avoid it. But the reality is that it is already required (at least in
configurations heavily using modules) to give more time for modules
loaded to resolve missing dependencies after init begins (due to
changes in the driver core to fail loading after init so that optional
dt links aren't eternally looked for). This was seen when trying to
enable the qualcom clk drivers to modules.

It doesn't seem necessary in this case, but I suggested it here as
I've got it enabled by default in my AOSP builds so that the
module-heavy configs for GKI boot properly (even if Saravana's
fw_devlink work is disabled).

thanks
-john

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel