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: <1e4b602d-5ed8-19a3-2cd1-b3fe27e7ff8d@gmail.com>
Date:   Tue, 27 Apr 2021 09:50:33 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Cristian Marussi <cristian.marussi@....com>,
        Jim Quinlan <james.quinlan@...adcom.com>,
        Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Al Cooper <alcooperx@...il.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/27/2021 9:39 AM, Sudeep Holla wrote:
> On Tue, Apr 27, 2021 at 09:24:55AM -0700, Florian Fainelli wrote:
> 
> [...]
> 
>> This is a self inflicted problem that we have in that the bootloader
>> provides a Device Tree to the kernel which is massaged in different ways
>> and intends to stay backwards compatible as much as possible. And indeed
>> after removing the 'mboxes' property gets us going with fw_devlink=on.
>>
> 
> I assume the bootloader checks the presence of SMC support and modifies
> the DT node accordingly. Can't it remove the mbox properties as it make
> no sense with SMC compatible ? However ...

The bootloader has always assumed the SMC support was there from the day
we introduced it because it was. What changed is the way we advertised
to Linux that support. We used to have a custom mailbox driver that
would be pretty much what the ARM SMC transport eventually came to be.

Since we still support earlier kernels that were deployed with the old
mailbox we cannot arbitrarily break that setup, especially as our
customers tend to be slow in picking up new kernel versions, fortunately
before they get to 5.13 we can mandate a new bootloader that may not be
compatible with their 4.1 kernel anymore, or at least not without some
backporting of the ARM SMC transport, that's all fair IMHO.

> 
>>>
>>> 2. IIUC, the fw_devlink might use information from DT to establish the
>>>    dependency and having mailbox information in this context may be
>>>    considered wrong as there is no dependency if it is using SMC.
>>
>> Right, unfortunately, short of having some special casing for SCMI and
>> checking that if we have both an "arm,smc-id" and "mboxes" phandle we
>> should prefer the former, there is not probably much that can be done
>> here. Do we want to do that?
> 
> I *think* we could do that in the SCMI drivers, but:
> 1. I am not sure if that helps fw_devlinks if they are deriving the info
>    purely based on DT
> 2. I am also afraid that someone might come up with exactly opposite
>    requirement that let us prefer mailbox over SMC as they would use
>    SMC only if h/w lacks proper mailbox support. I fear that we will get
>    into rabbit hole trying to do something like that.

That is true, and to get to the SCMI driver, even the base protocol you
must have been probed, so we have a nice chicken and egg problem. I
highly appreciate your time understanding the context and trying to find
a solution it is pretty clear that we must fix our FDT now.
-- 
Florian