On Sunday, November 08, 2015 05:26:03 PM Dan Williams wrote: > On Sun, Nov 8, 2015 at 4:49 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > On Saturday, November 07, 2015 10:57:17 AM Dan Williams wrote: > >> Rafael, awaiting your ack... > > > > Well, this seems to be entirely NFIT-related. > > > > Is there anything in particular you want me to look at? > > > > This might be more relevant for a follow-on patch, but I wonder if the > core should be guaranteeing that the ->notify() callback occurs under > device_lock(). In the case of NFIT it seems possible for the notify > event to race ->add() or ->remove(), but maybe I missed some other > guarantee? No, you didn't. I'd rather drop the ->notify callback completely, because it's kind of confusing, as there are other (non-ACPI) drivers that need to receive ACPI notifications too and they have to use the raw ACPICA's acpi_install_notify_handler() interface. Having a special interface for that for ACPI drivers only doesn't make much sense to me. That said, the ACPICA's notify handling code is inherently racy with respect to module unload, so potentially dangerous in any modular code. IMO, a generic module-safe wrapper around that code is needed, but since I haven't had the time to introduce one for quite a while, I guess it would be fine to add device locking around ->notify in acpi_bus_notify(), at least for the time being. Thanks, Rafael -- 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
