diff mbox series

[RFC,09/12] drivers: base: reintroduce find_bus()

Message ID 20210208222203.22335-10-info@metux.net
State New
Headers show
Series [RFC,01/12] of: base: improve error message in of_phandle_iterator_next() | expand

Commit Message

Enrico Weigelt, metux IT consult Feb. 8, 2021, 10:22 p.m. UTC
---
 drivers/base/bus.c         | 14 ++++++++++----
 include/linux/device/bus.h |  2 ++
 2 files changed, 12 insertions(+), 4 deletions(-)

Comments

Greg KH Feb. 13, 2021, 10:20 a.m. UTC | #1
On Mon, Feb 08, 2021 at 11:22:00PM +0100, Enrico Weigelt, metux IT consult wrote:
> ---

>  drivers/base/bus.c         | 14 ++++++++++----

>  include/linux/device/bus.h |  2 ++

>  2 files changed, 12 insertions(+), 4 deletions(-)


Um, no.
Enrico Weigelt, metux IT consult Feb. 23, 2021, 8:13 p.m. UTC | #2
On 13.02.21 11:20, Greg KH wrote:
> On Mon, Feb 08, 2021 at 11:22:00PM +0100, Enrico Weigelt, metux IT consult wrote:

>> ---

>>   drivers/base/bus.c         | 14 ++++++++++----

>>   include/linux/device/bus.h |  2 ++

>>   2 files changed, 12 insertions(+), 4 deletions(-)

> 

> Um, no.


Why not ? Do you have a better idea ?

What I actually need is a way to unbdind a specific device, identified
by bus name and device name. The problem to be solved here is dropping
devices that have been enumerated in a bad way by firmware (ACPI in this
case), and then recreating it in a clean, consistent way.

If there was a variant of bus_find_device_by_name() which takes the name
instead of ptr to the bus, that would also be okay for me.


--mtx

-- 
-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
Greg KH Feb. 24, 2021, 8 a.m. UTC | #3
On Tue, Feb 23, 2021 at 09:13:26PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 13.02.21 11:20, Greg KH wrote:
> > On Mon, Feb 08, 2021 at 11:22:00PM +0100, Enrico Weigelt, metux IT consult wrote:
> > > ---
> > >   drivers/base/bus.c         | 14 ++++++++++----
> > >   include/linux/device/bus.h |  2 ++
> > >   2 files changed, 12 insertions(+), 4 deletions(-)
> > 
> > Um, no.
> 
> Why not ? Do you have a better idea ?
> 
> What I actually need is a way to unbdind a specific device, identified
> by bus name and device name. The problem to be solved here is dropping
> devices that have been enumerated in a bad way by firmware (ACPI in this
> case), and then recreating it in a clean, consistent way.

Have the firmware code do it itself, do nto try to "reach across" like
this.

And what problem are you really trying to solve here by doing this?

thanks,

greg k-h
Enrico Weigelt, metux IT consult Feb. 24, 2021, 3:30 p.m. UTC | #4
On 24.02.21 09:00, Greg KH wrote:

> Have the firmware code do it itself, do nto try to "reach across" like
> this.

By "firmware code" you mean Linux acpi core or the board's bios ?

a) Fixing BIOS would be the cleanest solution, but we cant expect all
    users to do field upgrades. Many of the devices (eg. the customer,
    I've originally wrote the apu board driver for, deployed them in
    really remote locations, sometimes even just reachable by ship,
    heli or horse, litterally)

b) Explicit blacklisting somewhere in apci enumeration code could work,
    but I really hate the idea of such board and bios version specific
    quirks in a place, completely unrelated to the actual board driver.

Actually, I'm also hoping to find a proper way for having those things
in one file per board, in the future. (probably not applicable for
early stuff, or _OSI(Linux), etc)

> And what problem are you really trying to solve here by doing this?

The problem is that *some* bios versions (that came much later, after
pcengines-apuv2 driver went into production) added a few things that
the driver is already doing - different versions doing it differently
(eg. even enumerating gpio connected leds with completely different
names, etc), and still some gpio connected devices missing. Some
versions (just forgot, which one it's been exactly) even enumerate
*some* gpios (and LEDs behind them) as a different device, whose Linux
driver just happens to work. Meanwhile I can't find any reference of
that in the coreboot source, anymore.

As you can see: bios is anything but reliable on that platform.

What I'm trying to achieve: the kernel should behave exactly the
same, no matter what board revision, bios version, kernel version,
etc. (there should be especially no need to have special per-board
quirks in userland, depending on board rev, bios version, kernel
version).

If you've got a better solution, I'll be glad to hear it.


--mtx
Greg KH Feb. 24, 2021, 4:28 p.m. UTC | #5
On Wed, Feb 24, 2021 at 04:30:42PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 24.02.21 09:00, Greg KH wrote:

> 

> > Have the firmware code do it itself, do nto try to "reach across" like

> > this.

> 

> By "firmware code" you mean Linux acpi core or the board's bios ?


either.

> a) Fixing BIOS would be the cleanest solution, but we cant expect all

>    users to do field upgrades. Many of the devices (eg. the customer,

>    I've originally wrote the apu board driver for, deployed them in

>    really remote locations, sometimes even just reachable by ship,

>    heli or horse, litterally)

> 

> b) Explicit blacklisting somewhere in apci enumeration code could work,

>    but I really hate the idea of such board and bios version specific

>    quirks in a place, completely unrelated to the actual board driver.


We have quirks all over the place, that's normal and how we handle
broken hardware/bios al the time.

> Actually, I'm also hoping to find a proper way for having those things

> in one file per board, in the future. (probably not applicable for

> early stuff, or _OSI(Linux), etc)


I don't know what "things" you are referring to here at all.

> > And what problem are you really trying to solve here by doing this?

> 

> The problem is that *some* bios versions (that came much later, after

> pcengines-apuv2 driver went into production) added a few things that

> the driver is already doing - different versions doing it differently

> (eg. even enumerating gpio connected leds with completely different

> names, etc), and still some gpio connected devices missing. Some

> versions (just forgot, which one it's been exactly) even enumerate

> *some* gpios (and LEDs behind them) as a different device, whose Linux

> driver just happens to work. Meanwhile I can't find any reference of

> that in the coreboot source, anymore.


I have no idea what you are talking about here, you did not describe a
problem :(

> As you can see: bios is anything but reliable on that platform.


I do not understand.

> What I'm trying to achieve: the kernel should behave exactly the

> same, no matter what board revision, bios version, kernel version,

> etc. (there should be especially no need to have special per-board

> quirks in userland, depending on board rev, bios version, kernel

> version).

> 

> If you've got a better solution, I'll be glad to hear it.


I really do not understand the problem, sorry.

greg k-h
diff mbox series

Patch

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 450d3ed6cf1f..a06ae2786092 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -754,13 +754,19 @@  EXPORT_SYMBOL_GPL(device_reprobe);
  *
  * Note that kset_find_obj increments bus' reference count.
  */
-#if 0
-struct bus_type *find_bus(char *name)
+struct bus_type *find_bus(const char *name)
 {
 	struct kobject *k = kset_find_obj(bus_kset, name);
-	return k ? to_bus(k) : NULL;
+	struct subsys_private *subsys_priv;
+
+	if (!k)
+		return NULL;
+
+	subsys_priv = container_of(to_kset(k), struct subsys_private, subsys);
+
+	return subsys_priv->bus;
 }
-#endif  /*  0  */
+EXPORT_SYMBOL_GPL(find_bus);
 
 static int bus_add_groups(struct bus_type *bus,
 			  const struct attribute_group **groups)
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 36a1dae26c95..b4cbcfe176c5 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -254,6 +254,8 @@  void bus_sort_breadthfirst(struct bus_type *bus,
 			   int (*compare)(const struct device *a,
 					  const struct device *b));
 
+struct bus_type *find_bus(const char *name);
+
 /**
  * bus_unregister_device_by_name - remove device by bus id from specific bus
  *                                 and unregister it from device core