Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1368106 > unrolled thread

[RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-03-31 11:40 +0200
    Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-03-31 19:40 +0200
      Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications Octavian Purdila <octavian.purdila@intel.com> - 2016-04-01 13:00 +0200
        Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-01 16:10 +0200
          Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-01 21:30 +0200
            Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure  notifications Mark Brown <broonie@kernel.org> - 2016-04-02 18:30 +0200

#1368106 — [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

This allows the SPI core to enumerate devices from ACPI tables that
are dynamically loaded after the SPI master device has been probed.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
---
 drivers/spi/spi.c | 36 +++++++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 47eff80..8751f02 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1619,7 +1619,8 @@ static acpi_status acpi_spi_add_device(acpi_handle handle, u32 level,
 
 	if (acpi_bus_get_device(handle, &adev))
 		return AE_OK;
-	if (acpi_bus_get_status(adev) || !adev->status.present)
+	if (acpi_bus_get_status(adev) || !adev->status.present ||
+	    acpi_device_enumerated(adev))
 		return AE_OK;
 
 	spi = spi_alloc_device(master);
@@ -1645,6 +1646,8 @@ static acpi_status acpi_spi_add_device(acpi_handle handle, u32 level,
 	if (spi->irq < 0)
 		spi->irq = acpi_dev_gpio_irq_get(adev, 0);
 
+	adev->flags.visited = true;
+
 	adev->power.flags.ignore_parent = true;
 	strlcpy(spi->modalias, acpi_device_hid(adev), sizeof(spi->modalias));
 	if (spi_add_device(spi)) {
@@ -2698,6 +2701,35 @@ static struct notifier_block spi_of_notifier = {
 extern struct notifier_block spi_of_notifier;
 #endif /* IS_ENABLED(CONFIG_OF_DYNAMIC) */
 
+#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;
+}
+
+static int acpi_spi_notify(struct notifier_block *nb, unsigned long value,
+			   void *arg)
+{
+	switch (value) {
+	case ACPI_RECONFIG_TABLE_LOAD:
+		class_find_device(&spi_master_class, NULL, NULL,
+				  acpi_spi_table_load);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+static struct notifier_block spi_acpi_notifier = {
+	.notifier_call = acpi_spi_notify,
+};
+#else
+extern struct notifier_block spi_acpi_notifier;
+#endif
+
 static int __init spi_init(void)
 {
 	int	status;
@@ -2718,6 +2750,8 @@ static int __init spi_init(void)
 
 	if (IS_ENABLED(CONFIG_OF_DYNAMIC))
 		WARN_ON(of_reconfig_notifier_register(&spi_of_notifier));
+	if (IS_ENABLED(CONFIG_ACPI))
+		WARN_ON(acpi_reconfig_notifier_register(&spi_acpi_notifier));
 
 	return 0;
 
-- 
1.9.1

[toc] | [next] | [standalone]

#1368491 — Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1369197

On Thu, Mar 31, 2016 at 8:29 PM, Mark Brown <broonie@kernel.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.

[toc] | [prev] | [next] | [standalone]

#1369344 — Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

[Multipart message — attachments visible in raw view] — view raw

On Fri, Apr 01, 2016 at 01:54:28PM +0300, Octavian Purdila wrote:

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

Right, but the same applies to initial enumeration so we also have to
manually instantiate ACPI devices on startup.  Why do we need to do
that?

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

That's not the point.  The point is that since the handling is identical
why are we handling it through exactly the same code?

[toc] | [prev] | [next] | [standalone]

#1369550

On Fri, Apr 1, 2016 at 4:08 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Apr 01, 2016 at 01:54:28PM +0300, Octavian Purdila wrote:
>
>> 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.
>
> Right, but the same applies to initial enumeration so we also have to
> manually instantiate ACPI devices on startup.  Why do we need to do
> that?
>
>> 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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#1369976 — Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web