From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbcDAT0n (ORCPT ); Fri, 1 Apr 2016 15:26:43 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:36091 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751930AbcDAT0l (ORCPT ); Fri, 1 Apr 2016 15:26:41 -0400 MIME-Version: 1.0 In-Reply-To: <20160401140856.GW2350@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> <20160401140856.GW2350@sirena.org.uk> Date: Fri, 1 Apr 2016 21:26:38 +0200 X-Google-Sender-Auth: ODWhz2a4IbJSEkExjV2NBQsUUmk Message-ID: Subject: Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications From: "Rafael J. Wysocki" To: Mark Brown Cc: Octavian Purdila , "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 On Fri, Apr 1, 2016 at 4:08 PM, Mark Brown 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.