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]

Message-ID: <20160405212054.GK1924@sirena.org.uk>
Date:	Tue, 5 Apr 2016 14:20:54 -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 10:16:16PM +0300, Octavian Purdila wrote:
> On Tue, Apr 5, 2016 at 9:32 PM, Mark Brown <broonie@...nel.org> wrote:

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

> AFAICS this is exactly the same case for DT: one code path for
> coldplug and one for hotplug.

In the DT case the DT code understands a bit more of what's going on
with the firmware parsing which makes things better (the code in the two
paths is not identical, unlike ACPI) but yes, that's another aspect of
why I'm not thrilled with this - if it's not the hotplug and coldplug
that should be sharing code then perhaps it's along the firmware
interface axis that we need to be sharing things.

> Which makes me think that it is not possible to have a single path for
> both, or maybe its not worth it. Do I miss something obvious?

I think at a very high level what I'm looking at here is that we're
having to write too much boilerplate per firmware interface.  Perhaps
the hotplug vs coldplug path isn't it, it looked like it from your
patch, but there must be something here we're spending too much time on.

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