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;
MIME-Version: 1.0
References: <20210302211133.2244281-1-saravanak@google.com>
 <20210302211133.2244281-4-saravanak@google.com> <60989b90-7f8a-5306-e7d7-c5461bc9ac68@gmail.com>
In-Reply-To: <60989b90-7f8a-5306-e7d7-c5461bc9ac68@gmail.com>
From:   Saravana Kannan <saravanak@google.com>
Date:   Mon, 26 Apr 2021 14:33:18 -0700
Message-ID: <CAGETcx_ayXd1uDR6WHWxLmskYwOSjyynNi3Rt8irRUrfnr266w@mail.gmail.com>
Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default""
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     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>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Android Kernel Team <kernel-team@android.com>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Apr 26, 2021 at 1:51 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> Hi Saravana,
>
> Adding Sudeep and Christian, Al and Jim.
>
> 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).
2. Point out the UART device node and the SCMI device node that you
suspect is causing the issue.
3. Boot logs with dev_dbg changed to dev_info in device_link_add() and
device_links_check_suppliers()

Thanks,
Saravana