linux-kernel - Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <60989b90-7f8a-5306-e7d7-c5461bc9ac68@gmail.com>
Date:   Mon, 26 Apr 2021 13:51:06 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Al Cooper <alcooperx@...il.com>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>
Cc:     Michael Walle <michael@...le.cc>,
        Jon Hunter <jonathanh@...dia.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Guenter Roeck <linux@...ck-us.net>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by
 default""

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@...gle.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.

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?

Thank you!
-- 
Florian