netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 18 Dec 2020 15:52:04 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        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>,
        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 10:08:54AM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote:

> > As previously discussed this will need the auxilliary bus extending to
> > support at least interrupts and possibly also general resources.

> I thought the recent LWN article summed it up nicely, auxillary bus is
> for gluing to subsystems together using a driver specific software API
> to connect to the HW, MFD is for splitting a physical HW into disjoint
> regions of HW.

This conflicts with the statements from Greg about not using the
platform bus for things that aren't memory mapped or "direct firmware",
a large proportion of MFD subfunctions are neither at least in so far as
I can understand what direct firmware means.

To be honest I don't find the LWN article clarifies things particularly
here, the rationale appears to involve some misconceptions about what
MFDs look like.  It looks like it assumes that MFD functions have
physically separate register sets for example which is not a reliable
feature of MFDs, nor is the assumption that there's no shared
functionality which appears to be there.  It also appears to assume that
MFD subfunctions can clearly be described by ACPI (where it would be
unidiomatic, we just don't see this happening for the MFDs that appear
on ACPI systems and I'm not sure bindings exist within ACPI) or DT
(where even where subfunctions are individually described it's rarely
doing more than enumerating that things exist).

> Maybe there is some overlap, but if you want to add HW representations
> to the general auxillary device then I think you are using it for the
> wrong thing.

Even for the narrowest use case for auxiliary devices that I can think
of I think the assumption that nobody will ever design something which
can wire an interrupt intended to be serviced by a subfunction is a bit
optimistic.  If Greg's statements about not using platform buses for
MMIO or direct firmware devices are accurate then those cases already
exist, if nothing else a common subfunction for MFDs is an interrupt
controller.

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