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: <23ab7a11-330c-4d3d-00c1-984c5248464e@gmail.com>
Date:   Mon, 26 Apr 2021 14:47:52 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     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>,
        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>,
        Android Kernel Team <kernel-team@...roid.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by
 default""

On 4/26/21 2:33 PM, Saravana Kannan wrote:
> On Mon, Apr 26, 2021 at 1:51 PM Florian Fainelli <f.fainelli@...il.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@...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.
> 
> 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@...c000.

> 3. Boot logs with dev_dbg changed to dev_info in device_link_add() and
> device_links_check_suppliers()

OK, I did not want to modify the kernel so I just enabled dynamic debug
prints from the command line, if this is too verbose let me know.

Thank you for your prompt response.
-- 
Florian

View attachment "fw_devlink_on.log" of type "text/x-log" (55204 bytes)

Download attachment "BCX972160DV.dts" of type "audio/vnd.dts" (29985 bytes)