linux-kernel - Re: [resend/standalone PATCH v4] Add auxiliary bus support

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 18 Dec 2020 13:17:09 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        alsa-devel@...a-project.org, Kiran Patil <kiran.patil@...el.com>,
        linux-rdma <linux-rdma@...r.kernel.org>,
        Shiraz Saleem <shiraz.saleem@...el.com>,
        Martin Habets <mhabets@...arflare.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Fred Oh <fred.oh@...ux.intel.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Dave Ertman <david.m.ertman@...el.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Netdev <netdev@...r.kernel.org>,
        Leon Romanovsky <leonro@...dia.com>,
        David Miller <davem@...emloft.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Parav Pandit <parav@...lanox.com>, lee.jones@...aro.org
Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support

On Fri, Dec 18, 2020 at 08:10:51AM +0100, Greg KH wrote:
> On Thu, Dec 17, 2020 at 10:19:37PM +0100, Alexandre Belloni wrote:

> > There is something I don't get from the documentation and it is what is
> > this introducing that couldn't already be done using platform drivers
> > and platform devices?

> Because platform drivers and devices should ONLY be for actual platform
> devices.  Do NOT use that interface to fake up a non-platform device
> (i.e. something that is NOT connected to a cpu through a memory-mapped
> or direct-firmware interface).

> Do not abuse the platform code anymore than it currently is, it's bad
> enough what has been done to it over time, let's not make it any worse.

I am not clear on why you're giving direct-firmware devices (which I
assume means things like ARM SCMI where we're talking directly to some
firmware?) a pass here but not for example a GPIO controlled devices.
If this is mainly about improving abstractions it seems like the
boundary here isn't great.  Or perhaps I'm just missing what
direct-firmware is supposed to mean?

In any case, to be clear part of what you're saying here is that all
I2C and SPI MFDs should be rewritten to use this new bus - I've just
copied Lee in again since he keeps getting missed from these threads.
As previously discussed this will need the auxilliary bus extending to
support at least interrupts and possibly also general resources.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)