[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Apr 2016 09:03:27 -0700
From: Mark Brown <broonie@...nel.org>
To: Octavian Purdila <octavian.purdila@...el.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>,
Matt Fleming <matt@...eblueprint.co.uk>,
Wolfram Sang <wsa@...-dreams.de>,
Joel Becker <jlbec@...lplan.org>,
Christoph Hellwig <hch@....de>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
linux-efi@...r.kernel.org, linux-i2c <linux-i2c@...r.kernel.org>,
linux-spi@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
Irina Tirdea <irina.tirdea@...el.com>
Subject: Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure
notifications
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@...nel.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.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists