Sudip Mukherjee <sudipm.mukher...@gmail.com> writes: > On Tue, Aug 18, 2015 at 03:14:02PM -0400, Benjamin Romer wrote: >> In cases where visorbus is compiled directly into the kernel, if >> visorbus registration fails for any reason, it is still possible for >> other drivers to call visorbus_register_visor_driver(), which could >> cause an oops. Prevent this by returning an error code when the bus >> hasn't been registered. >> >> Signed-off-by: Benjamin Romer <benjamin.ro...@unisys.com> >> --- >> drivers/staging/unisys/visorbus/visorbus_main.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c >> b/drivers/staging/unisys/visorbus/visorbus_main.c >> index 7905ea9..ad2b1ac 100644 >> --- a/drivers/staging/unisys/visorbus/visorbus_main.c >> +++ b/drivers/staging/unisys/visorbus/visorbus_main.c >> @@ -863,6 +863,9 @@ int visorbus_register_visor_driver(struct visor_driver >> *drv) >> { >> int rc = 0; >> >> + if (!visorbus_type.p) >> + return -ENODEV; /*can't register on a nonexistent bus*/ >> + > IIRC, Greg once told that we should not be working with the internal > data structures of struct bus_type.
If you looked at the code you would have noticed this is in fact the bus driver, and visorbus_type is defined in this file. I guess we could tell visorbus_main.c to not touch visorbus_type by deleting the file completely ..... _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel