Messages in this thread | | | Date | Mon, 4 Apr 2016 23:18:56 +0200 | Subject | Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications | From | "Rafael J. Wysocki" <> |
| |
On Mon, Apr 4, 2016 at 9:34 PM, Octavian Purdila <octavian.purdila@intel.com> wrote: > On Mon, Apr 4, 2016 at 7:03 PM, Mark Brown <broonie@kernel.org> wrote: >> On Mon, Apr 04, 2016 at 01:25:56PM +0300, Octavian Purdila wrote: >>> On Sat, Apr 2, 2016 at 7:24 PM, Mark Brown <broonie@kernel.org> wrote: >> >>> > What I don't understand is why the flow on inital probe isn't simply to >>> > register the controller which then triggers the walk of the children. >>> > That way any bus that supports initial probe also supports hotplug >>> > without needing to go and manually add a second code path. >> >>> Do you mean register the notifier per controller instead of per >>> subsystem? Either way we need changes at the subsystem level and I >>> choose to follow the device tree implementation for consistency. >> >> No! I mean use the exact same callback you've got now for everything. >> >>> The other reason is that (pending other ACPICA changes) we can add >>> other notification events in the future such as node added or removed >>> (just like device tree), and in that case the probe and hotplug >>> handling would be different (and a bit more efficient). >> >> Why is probe different to hotplug? We don't need to do that in the >> normal driver model. > > There might be some confusion with the term, I am referring to slave > hotplug, not controller hotplug. > > The way I see it, there are two logical operations: probe of a > controller and the associated enumeration of the SPI slaves for that > bus and "hotplug" of new SPI slaves and the enumeration of those > particular slaves. > > When we probe the controller we search DT/ACPI and enumerate all the > slaves for *that* controller. > > When a slave hotplug happens for device tree we get a device node > notification and we can instantiate the SPI slave based on that info. > In case of ACPI, (at this point) we get a global callback and in that > callback we need to iterate through *all* controllers.
Is that really necessary?
The namespace rescan could notify the parent of a new node in acpi_default_enumeration(), couldn't it?
| |