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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 Apr 2016 13:25:56 +0300
From:	Octavian Purdila <octavian.purdila@...el.com>
To:	Mark Brown <broonie@...nel.org>
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 Sat, Apr 2, 2016 at 7:24 PM, Mark Brown <broonie@...nel.org> wrote:
> 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.

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.

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).