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:	Tue, 5 Apr 2016 11:32:55 -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 Tue, Apr 05, 2016 at 02:49:13PM +0300, Octavian Purdila wrote:

> If we really want to have a single path for ACPI enumeration we could
> do that by using an ACPI SPI bridge driver or scan handlers after
> extending the matching mechanisms. But we would still need to modify
> the SPI subsystem and I don't think its worth it just to save a call
> to acpi_register_spi_devices() from spi_register_master().

It's not specifically for SPI, it's the fact that you're asking every
single bus type which might be described in ACPI to handle both hotplug
and coldplug paths separately.  Given that the code that's being added
just seems like trivial boilerplate it seems like we're doing this
wrong, we should be factoring this out so there's nothing bus types can
get wrong.

> Now for parent notification complexity: in the case of SPI we can
> easily to this because current ACPI SPI enumeration supports only
> direct children as slaves. However, on I2C we can have an unrelated
> node as a slave - that is why the I2C scanning searches the whole
> namespaces for references to a particular i2c_adapter. So, we would
> need to retrieve the parent node from the namespace node information
> which means that we will do SPI specific stuff in ACPI generic code. I
> don't think it is a big issue, because we already treat SPI / I2C
> special, right?

Or perhaps the issue is that we can't make our mind up if the bus
specific code should go in the bus or in the ACPI core?

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)