Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756330AbcDDVTD (ORCPT ); Mon, 4 Apr 2016 17:19:03 -0400 Received: from mail-lb0-f196.google.com ([209.85.217.196]:35152 "EHLO mail-lb0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751587AbcDDVS7 (ORCPT ); Mon, 4 Apr 2016 17:18:59 -0400 MIME-Version: 1.0 In-Reply-To: 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> <20160402162449.GB2350@sirena.org.uk> <20160404160327.GH2350@sirena.org.uk> Date: Mon, 4 Apr 2016 23:18:56 +0200 X-Google-Sender-Auth: bdqFeg-rwSdzxT3IURaYA1fuwC4 Message-ID: Subject: Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications From: "Rafael J. Wysocki" To: Octavian Purdila Cc: Mark Brown , "Rafael J. Wysocki" , "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: 2100 Lines: 45 On Mon, Apr 4, 2016 at 9:34 PM, Octavian Purdila wrote: > On Mon, Apr 4, 2016 at 7:03 PM, Mark Brown wrote: >> On Mon, Apr 04, 2016 at 01:25:56PM +0300, Octavian Purdila wrote: >>> On Sat, Apr 2, 2016 at 7:24 PM, Mark Brown wrote: >> >>> > 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. >> >>> Do you mean register the notifier per controller instead of per >>> subsystem? Either way we need changes at the subsystem level and I >>> choose to follow the device tree implementation for consistency. >> >> No! I mean use the exact same callback you've got now for everything. >> >>> The other reason is that (pending other ACPICA changes) we can add >>> other notification events in the future such as node added or removed >>> (just like device tree), and in that case the probe and hotplug >>> handling would be different (and a bit more efficient). >> >> Why is probe different to hotplug? We don't need to do that in the >> normal driver model. > > There might be some confusion with the term, I am referring to slave > hotplug, not controller hotplug. > > The way I see it, there are two logical operations: probe of a > controller and the associated enumeration of the SPI slaves for that > bus and "hotplug" of new SPI slaves and the enumeration of those > particular slaves. > > When we probe the controller we search DT/ACPI and enumerate all the > slaves for *that* controller. > > When a slave hotplug happens for device tree we get a device node > notification and we can instantiate the SPI slave based on that info. > In case of ACPI, (at this point) we get a global callback and in that > callback we need to iterate through *all* controllers. Is that really necessary? The namespace rescan could notify the parent of a new node in acpi_default_enumeration(), couldn't it?