On Monday, November 09, 2015 10:24:00 PM Rafael J. Wysocki wrote: > 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. And in acpi_device_notify() for that matter. 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
