Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370902

Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

Show all headers | View raw

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?

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-04-04 12:30 +0200
  Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-04 18:10 +0200
    Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-04-04 21:40 +0200
      Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-04 23:20 +0200
        Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-04-05 13:50 +0200
          Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-05 20:40 +0200
            Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-04-05 21:20 +0200
              Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-05 23:30 +0200
      Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-05 20:30 +0200

csiph-web