Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932443AbcDAKye (ORCPT ); Fri, 1 Apr 2016 06:54:34 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37803 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932413AbcDAKya (ORCPT ); Fri, 1 Apr 2016 06:54:30 -0400 MIME-Version: 1.0 In-Reply-To: <20160331172935.GL2350@sirena.org.uk> References: <1459417026-6697-1-git-send-email-octavian.purdila@intel.com> <1459417026-6697-7-git-send-email-octavian.purdila@intel.com> <20160331172935.GL2350@sirena.org.uk> Date: Fri, 1 Apr 2016 13:54:28 +0300 Message-ID: Subject: Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications From: Octavian Purdila To: Mark Brown Cc: "Rafael J. Wysocki" , Len Brown , Matt Fleming , Wolfram Sang , Joel Becker , Christoph Hellwig , "linux-acpi@vger.kernel.org" , linux-efi@vger.kernel.org, linux-i2c , linux-spi@vger.kernel.org, lkml , Irina Tirdea Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1124 Lines: 28 On Thu, Mar 31, 2016 at 8:29 PM, Mark Brown 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.