[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160402162449.GB2350@sirena.org.uk>
Date: Sat, 2 Apr 2016 09:24:49 -0700
From: Mark Brown <broonie@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Octavian Purdila <octavian.purdila@...el.com>,
"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 Fri, Apr 01, 2016 at 09:26:38PM +0200, Rafael J. Wysocki wrote:
> On Fri, Apr 1, 2016 at 4:08 PM, Mark Brown <broonie@...nel.org> wrote:
> > That's not the point. The point is that since the handling is identical
> > why are we handling it through exactly the same code?
> I think that during the initial enumeration the controller driver's
> probe walks the children and creates device objects for them. When a
> table is loaded later, the controller driver has been probed already
> and there needs to be a way to trigger a walk over the (new) children
> from it.
> Or a hook somewhere around acpi_platform_notify() is needed.
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.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists