Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> writes:
> On Tue, Aug 25, 2015 at 08:33:55AM -0400, Jes Sorensen wrote:
>> Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> 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.romer@xxxxxxxxxx>
>> >> ---
>> >> 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 .....
> Yes, this is the bus driver, struct bus_type. Maybe the following might
> be a better approach where the struct bus_type internals are not touched
> yet it will server the purpose.
Replacing it with a global variable? Ehm sorry, but no thanks!
NACK
Jes
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
