Hi Finn,
On Tue, May 8, 2018 at 1:44 AM, Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
On Mon, 7 May 2018, I wrote:
On Sun, 6 May 2018, Greg Kroah-Hartman wrote:
Why not just have an "bus is registered" flag in your driver
register function that refuses to let drivers register with the
driver core if it isn't set?
Perhaps that should happen in the core driver_register() function.
BUG_ON is frowned upon, after all. Would that be acceptable?
I don't understand what you mean here, perhaps make a patch to show it?
As an alternative to your suggestion (add flag to avoid the BUG_ON):
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -148,7 +148,10 @@ int driver_register(struct device_driver *drv)
int ret;
struct device_driver *other;
- BUG_ON(!drv->bus->p);
+ if (!drv->bus->p) {
+ WARN_ONCE(1, "Cannot register driver with invalid bus\n");
+ return -EPROBE_DEFER;
+ }
if ((drv->bus->probe && drv->probe) ||
(drv->bus->remove && drv->remove) ||
That rushed example I gave above seems to be confusing the issue. Sorry
about that. (See sioux-core.c for the code that motivated it.)
This example is the sort of flag removal that I had in mind --
diff --git a/drivers/base/driver.c b/drivers/base/driver.c
index ba912558a510..4ee22fb3db92 100644
--- a/drivers/base/driver.c
+++ b/drivers/base/driver.c
@@ -148,7 +148,8 @@ int driver_register(struct device_driver *drv)
int ret;
struct device_driver *other;
- BUG_ON(!drv->bus->p);
+ if (!drv->bus->p)
+ return -ENODEV;
If this is meant to handle the case where the device driver is registered
before the bus is registered, while the latter can still happen later,
then you want to return -EPROBE_DEFER.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
