Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756256AbcDDTfA (ORCPT ); Mon, 4 Apr 2016 15:35:00 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:34406 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754746AbcDDTe6 (ORCPT ); Mon, 4 Apr 2016 15:34:58 -0400 MIME-Version: 1.0 In-Reply-To: <20160404160327.GH2350@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> <20160402162449.GB2350@sirena.org.uk> <20160404160327.GH2350@sirena.org.uk> Date: Mon, 4 Apr 2016 22:34:56 +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" , "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: 1833 Lines: 38 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.