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

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

Date:   Mon, 21 Dec 2020 18:51:40 +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 04:58:56PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +0000, Mark Brown wrote:
> 
> > Historically people did try to create custom bus types, as I have
> > pointed out before there was then pushback that these were duplicating
> > the platform bus so everything uses platform bus.

> Yes, I vaugely remember..

> I don't know what to say, it seems Greg doesn't share this view of
> platform devices as a universal device.

He did at the time, he seems to have changed his mind at some point for
unclear reasons 

> Reading between the lines, I suppose things would have been happier
> with some kind of inheritance scheme where platform device remained as
> only instantiated directly in board files, while drivers could bind to
> OF/DT/ACPI/FPGA/etc device instantiations with minimal duplication &
> boilerplate.

Like I said in my previous message that is essentially what we have now.
It's not worded in quite that way but it's how all the non-enumerable
buses work.  

BTW I did have a bit of a scan through some of the ACPI devices and for
a good proportion of them it seems fairly clear that they are not
platform devices at all - they were mostly interacting with ACPI
firmware functionality rather than hardware, something you can't really
do with FDT at all.

> > I can't tell the difference between what it's doing and what SOF is
> > doing, the code I've seen is just looking at the system it's running
> > on and registering a fixed set of client devices.  It looks slightly
> > different because it's registering a device at a time with some wrapper
> > functions involved but that's what the code actually does.

> SOF's aux bus usage in general seems weird to me, but if you think
> it fits the mfd scheme of primarily describing HW to partition vs
> describing a SW API then maybe it should use mfd.

> The only problem with mfd as far as SOF is concerned was Greg was not
> happy when he saw PCI stuff in the MFD subsystem.

This is a huge part of the problem here - there's no clearly articulated
logic, it's all coming back to these sorts of opinion statements about
specific cases which aren't really something you can base anything on.
Personally I'm even struggling to identify a practical problem that
we're trying to solve here.  Like Alexandre says what would an
mfd_driver actually buy us?

> MFD still doesn't fit what mlx5 and others in the netdev area are
> trying to do. Though it could have been soe-horned it would have been
> really weird to create a platform device with an empty HW resource
> list. At a certain point the bus type has to mean *something*!

I have some bad news for you about the hardware description problem
space.  Among other things we have a bunch of platform devices that
don't have any resources exposed through the resource API but are still
things like chips on a board, doing some combination of exposing
resources for other devices (eg, a fixed voltage regulator) and
consuming things like clocks or GPIOs that don't appear in the resource
API.  We *could* make a new bus type and move all these things over to
that but it is not clear what the upside of doing that would be,
especially given the amount of upheval it would generate and the
classification issues that will inevitably result.

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