(snip) : > > > + > > > + /* set HID to this device object */ > > > + acpi_device_set_id(device); > > > + > > > + /* lookup a matching driver */ > > > + (void) bus_for_each_drv(device->dev.bus, NULL, > > > + device, acpi_match_driver); > > > + driver = device->driver; > > > > This path is used when we receive a Notify to a device and a matching > > driver has been registered, but the driver is not bound to the device. > > For example, it may be a newly-added device where we haven't bound a > > driver to it yet. > > > > Is there anything that prevents us from unloading the driver between > > here (the point where we capture the "struct acpi_driver *") and the > > point where we call "driver->ops.sys_notify"? > > Hi Bjorn, > > That's a very good question. I will look into how we protect a driver > from unloading when we try to attach & probe a driver in the > acpi_add_single_object() path, and see if we can use a similar way to > protect it here as well. I have protected this path in version 2, which I just sent out. It calls .sys_notify() directly from bus_for_each_drv(), which protects the driver entry by increasing its reference count while the callback function is being called. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
