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:   Tue, 5 Jan 2021 13:42:56 +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 Mon, Jan 04, 2021 at 08:13:41PM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 04, 2021 at 09:19:30PM +0000, Mark Brown wrote:

> > Like I keep saying the same thing applies to all non-enumerable buses -
> > exactly the same considerations exist for all the other buses like I2C
> > (including the ACPI naming issue you mention below), and for that matter
> > with enumerable buses which can have firmware info.

> And most busses do already have their own bus type. ACPI, I2C, PCI,
> etc. It is just a few that have been squished into platform, notably
> OF.

You're missing the point there.  I2C is enumerated by firmware in
exactly the same way as the platform bus is, it's not discoverable from
the hardware (and similarly for a bunch of other buses).  If we were to
say that we need separate device types for platform devices enumerated
using firmware then by analogy we should do the same for devices on
these other buses that happen to be enumerated by firmware.

I'm not convinced this is actually the design that's being pushed by
Greg here, to the extent anything is being actively pushed.

> But now it begs the question, why not push harder to make 'struct
> device' the generic universal access point and add some resource_get()
> API along these lines so even a platform_device * isn't needed?

We still need a struct device of some kind so the discussions about
exactly which bus type one is supposed to use in which circumstances
remain given that you're not supposed to have raw struct devices.

> Then the path seems much clearer, add a multi-bus-type device_driver
> that has a probe(struct device *) and uses the 'universal api_get()'
> style interface to find the generic 'resources'.

That's exactly how things like mixed I2C/SPI devices work at present,
given that they can usually use regmap to hide register I/O.

> int gpiod_count(struct device *dev, const char *con_id)
> {
> 	int count = -ENOENT;

> 	if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
> 		count = of_gpio_get_count(dev, con_id);
> 	else if (IS_ENABLED(CONFIG_ACPI) && dev && ACPI_HANDLE(dev))
> 		count = acpi_gpio_count(dev, con_id);
> 
> 	if (count < 0)
> 		count = platform_gpio_count(dev, con_id);

> With an actual bus specific virtual function:

>     return dev->bus->gpio_count(dev);

That won't work, you might have a mix of enumeration types for a given
bus type in a single system so you'd need to do this per device.  It's
also not clear to me that it is useful to spread things out like this,
it makes it more hassle to add new APIs since you have to change core
code.

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