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: <a1970cb5-1cf1-d38a-3de3-c782c23fc8ac@arm.com>
Date:   Thu, 17 Aug 2017 08:52:27 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Michal Simek <michal.simek@...inx.com>,
        linux-arm-kernel@...ts.infradead.org, Arnd Bergmann <arnd@...db.de>
Cc:     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>,
        Sudeep Holla <sudeep.holla@....com>,
        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 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.

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.

> 
> 
>>> This simply patch is not adding any power management features but only
>>> adding minimum functionality which are needed for drivers.
>>
>> I don't get it. 600 lines of firmware interface that isn't used by
>> anything? Or is it? Needed by which driver?
> 
> I can send that drivers for review. pinctrl, fpga manager, nvmem driver,
> clock, serdes phy and reset drivers.
> But this driver need to come first because they depend on this.
My take is: no users, no use.

And if you need to hack all these drivers to hook into your specific
firmware interface, I feel that you're doing it wrong. We have common
APIs for device drivers. If these APIs are not good enough, we extend
them. But designing drivers for a given firmware interface?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...