Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default""

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Al Cooper <alcooperx@gmail.com>,
	Jim Quinlan <james.quinlan@broadcom.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Michael Walle <michael@walle.cc>,
	Jon Hunter <jonathanh@nvidia.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Android Kernel Team <kernel-team@android.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default""
Date: Tue, 27 Apr 2021 09:05:43 +0200	[thread overview]
Message-ID: <CAMuHMdXS+GO=E26vaeNvQ+L7zm=mOK0FXoWGL79adL+9Hx1E3A@mail.gmail.com> (raw)
In-Reply-To: <23ab7a11-330c-4d3d-00c1-984c5248464e@gmail.com>

Hi Florian,

On Mon, Apr 26, 2021 at 11:48 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 4/26/21 2:33 PM, Saravana Kannan wrote:
> > On Mon, Apr 26, 2021 at 1:51 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >> On 3/2/21 1:11 PM, Saravana Kannan wrote:
> >>> This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df.
> >>>
> >>> Since all reported issues due to fw_devlink=on should be addressed by
> >>> this series, revert the revert. fw_devlink=on Take II.
> >>>
> >>> Signed-off-by: Saravana Kannan <saravanak@google.com>
> >>
> >> This change breaks booting on SCMI-based platforms such as ARCH_BRCMSTB.
> >> If I revert this change or boot with fw_devlink=permissive, then our
> >> systems boot again. From a quick look, the SCMI clock provider was never
> >> probed which means that our UART driver never got a chance to get its
> >> clock and we have no console -> timeout.
> >
> > We explicitly landed changes to handle this condition. So we'll see if
> > this is what is happening.
> >
> >> Al, AFAICT you had started to analyze this before in the context of
> >> SCMI, do you mind sharing what you had found?
> >>
> >> Saravana, is there any debugging output that we can help provide?
> >
> > Thanks for the report. Couple of things that can help:
> > 1. Example DTS file (the final board file so that I can get the full DT view).
>
> Attached BCX972160DV.dts which is one such system.
>
> > 2. Point out the UART device node and the SCMI device node that you
> > suspect is causing the issue.
>
> The SCMI provider node is brcm_scmi@0 and its sub-node protocol@14 is
> the clock provider. The UART node is /rdb/serial@840c000.

I guess dependencies on SCMI sub-nodes are not handled correctly?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds