[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE1zotJbUGBOUF-4-XAx0DUkj55egOMXVn9FzjV3Fdj4MYxD0Q@mail.gmail.com>
Date: Fri, 1 Apr 2016 13:54:28 +0300
From: Octavian Purdila <octavian.purdila@...el.com>
To: Mark Brown <broonie@...nel.org>
Cc: "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 Thu, Mar 31, 2016 at 8:29 PM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Mar 31, 2016 at 12:37:02PM +0300, Octavian Purdila wrote:
>
>> +#if IS_ENABLED(CONFIG_ACPI)
>> +static int acpi_spi_table_load(struct device *dev, const void *data)
>> +{
>> + struct spi_master *master = container_of(dev, struct spi_master, dev);
>> +
>> + acpi_register_spi_devices(master);
>> + return 0;
>> +}
>
> Why do we have a separate code path for this coompared to the initial
> startup? The handling appears to be identical so it seems we should
> drive this from the ACPI code so we don't have to add this to every
> single bus with ACPI bindings.
Hi Mark,
I probably don't fully understand your question, but I don't see a way
of how we can create a new SPI device from generic ACPI code. For
example, in acpi_spi_add_device() we need the spi_master node so that
we can allocate the spi device.
The handling is identical because we don't have yet have a way to
identify what where the new nodes added when a new ACPI table /
overlay has been loaded, so we have to rescan the ACPI namespace under
each controller.
Powered by blists - more mailing lists