[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE1zotL7X+di4rHecRW_G-45wUPbbNb9jvn3C_zjD4XttZ4v3w@mail.gmail.com>
Date: Tue, 5 Apr 2016 22:16:16 +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 Tue, Apr 5, 2016 at 9:32 PM, Mark Brown <broonie@...nel.org> wrote:
> 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.
>
AFAICS this is exactly the same case for DT: one code path for
coldplug and one for hotplug.
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?
Powered by blists - more mailing lists