linux-kernel - Re: [PATCHv2 0/3] arm64 xilinx zynqmp firmware interface

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: <45e58860-cb8c-75f2-60bf-140aa3704169@arm.com>
Date:   Thu, 17 Aug 2017 10:12:22 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Michal Simek <michal.simek@...inx.com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Marc Zyngier <marc.zyngier@....com>, Arnd Bergmann <arnd@...db.de>,
        Sudeep Holla <sudeep.holla@....com>, edgar.iglesias@...inx.com,
        Rob Herring <robh@...nel.org>,
        Punnaiah Choudary Kalluri 
        <punnaiah.choudary.kalluri@...inx.com>,
        Jean Delvare <jdelvare@...e.de>,
        Dinh Nguyen <dinguyen@...nsource.altera.com>,
        Rob Herring <robh+dt@...nel.org>,
        Tero Kristo <t-kristo@...com>,
        Catalin Marinas <catalin.marinas@....com>,
        Olof Johansson <olof@...om.net>,
        Sören Brinkmann <soren.brinkmann@...inx.com>,
        Kevin Hilman <khilman@...libre.com>,
        Nishanth Menon <nm@...com>,
        Thierry Reding <treding@...dia.com>,
        Kevin Brodsky <kevin.brodsky@....com>,
        Will Deacon <will.deacon@....com>, devicetree@...r.kernel.org,
        Alexander Graf <agraf@...e.de>,
        Moritz Fischer <mdf@...nel.org>,
        Michal Simek <monstr@...str.eu>,
        Mark Rutland <mark.rutland@....com>,
        Carlo Caione <carlo@...lessm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        linux-kernel@...r.kernel.org,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCHv2 0/3] arm64 xilinx zynqmp firmware interface



On 17/08/17 09:42, Michal Simek wrote:
> On 17.8.2017 09:52, Marc Zyngier wrote:
>> On 17/08/17 07:10, Michal Simek wrote:
>>> On 16.8.2017 17:39, Marc Zyngier wrote:
>>>> On 16/08/17 13:24, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> xilinx is using this interface for very long time and we can't merge our
>>>>> driver changes to Linux because of missing communication layer with
>>>>> firmware. This interface was developed before scpi and scmi was
>>>>> available. In connection to power management scpi and scmi are missing
>>>>> pieces which we already use. There is a separate discussion how to
>>>>> extend scmi to support all our use cases.
>>>>
>>>> So maybe we should wait and see where this discussion is going before we
>>>> merge yet another firmware interface?
>>>
>>> It will take a lot of time when this discussion ends and I can't see any
>>> benefit to hold all
>>
>> Well, so far, the benefit of this series is exactly nil, as the code it
>> brings is *unused*. It is impossible to review in isolation.
>>
> 
> Ok. I will add others drivers to this series that's not a problem.
> 
>> In the meantime, you can continue finding out how *not* to have to merge
>> this code, and instead focus on using the infrastructure we already
>> have, or at least influence the infrastructure that is being designed.
>> It will be much better than dumping yet another slab of "I'm so
>> different" code that is going to ultimately bitrot.
> 
> I am happy to look the better proposed way. SCPI is ancient and SCMI is
> replacement and not merged yet. We already had a call with arm and
> Sudeep was on it too where outcome from that was that we can't use that
> because it doesn't support what we need to support now.
> 

OK, none of the specifics were discussed in the meeting to conclude that
SCMI can't be used. My takeaway from the meeting was Xilinx has this
interface for long and being deployed in various systems. I would like
to get into specifics before discarding SCMI as unusable. What bothers
me more is that why was that not raised during the specification review
which was quite a long period IMO ? I tend to think Xilinx never
bothered to look/review the specification as this f/w interface was
already there.

However I still can't see why this was posted once we started pushing
out SCMI patches especially given that this f/w interface was there for
long and no attempts were made in past to upstream this.

Also I am not dismissing the series yet, but if I find that SCMI can be
used(after getting specifics from this series myself), I will at-least
argue against the "SCMI can't be used" argument.

-- 
Regards,
Sudeep