Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759706AbcDESdQ (ORCPT ); Tue, 5 Apr 2016 14:33:16 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:45672 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751027AbcDESdN (ORCPT ); Tue, 5 Apr 2016 14:33:13 -0400 Date: Tue, 5 Apr 2016 11:32:55 -0700 From: Mark Brown To: Octavian Purdila 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 Message-ID: <20160405183255.GH1924@sirena.org.uk> References: <20160331172935.GL2350@sirena.org.uk> <20160401140856.GW2350@sirena.org.uk> <20160402162449.GB2350@sirena.org.uk> <20160404160327.GH2350@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X+8siUETKMkW99st" Content-Disposition: inline In-Reply-To: X-Cookie: Even bytes get lonely for a little bit. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 209.65.105.100 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 06/10] spi: add support for ACPI reconfigure notifications X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2142 Lines: 49 --X+8siUETKMkW99st Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 05, 2016 at 02:49:13PM +0300, Octavian Purdila wrote: > If we really want to have a single path for ACPI enumeration we could > do that by using an ACPI SPI bridge driver or scan handlers after > extending the matching mechanisms. But we would still need to modify > the SPI subsystem and I don't think its worth it just to save a call > to acpi_register_spi_devices() from spi_register_master(). It's not specifically for SPI, it's the fact that you're asking every single bus type which might be described in ACPI to handle both hotplug and coldplug paths separately. Given that the code that's being added just seems like trivial boilerplate it seems like we're doing this wrong, we should be factoring this out so there's nothing bus types can get wrong. > Now for parent notification complexity: in the case of SPI we can > easily to this because current ACPI SPI enumeration supports only > direct children as slaves. However, on I2C we can have an unrelated > node as a slave - that is why the I2C scanning searches the whole > namespaces for references to a particular i2c_adapter. So, we would > need to retrieve the parent node from the namespace node information > which means that we will do SPI specific stuff in ACPI generic code. I > don't think it is a big issue, because we already treat SPI / I2C > special, right? Or perhaps the issue is that we can't make our mind up if the bus specific code should go in the bus or in the ACPI core? --X+8siUETKMkW99st Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXBATWAAoJECTWi3JdVIfQXl4H/0BzWIDQKWOqLzpt7x5yOPOl QkkiK0BMXoGfMwzvb6ykmztzT0zkkfFGCCPS3EpGC7TZWQOIaniKavxDyVl0tYo2 0/em4gdafI11N3uns6MCsnP/JU2frcJqoNHdPc0PlrOcFy3aQbwm9Uw/Ya2uFNZJ hhKRX5lym6Pp+3kwFnZSAp+GCvn8cw2wv+AnnrPZY5K4efDY9jUS34NedT9NvywR fZAH72ZuoLwK+dpx1fkPrJg3o71h+nlGm5lEKG+VKfQUcnEBcoTxXJm5CE66emVp cpPs921uqQJPGCwNxuG6L7pPu048F8FdJc29DOVZ8sX3CX0nuSsr8TfTQXtHIAg= =MLeI -----END PGP SIGNATURE----- --X+8siUETKMkW99st--