Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760140AbcDEVVT (ORCPT ); Tue, 5 Apr 2016 17:21:19 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:46028 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751811AbcDEVVR (ORCPT ); Tue, 5 Apr 2016 17:21:17 -0400 Date: Tue, 5 Apr 2016 14:20:54 -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: <20160405212054.GK1924@sirena.org.uk> References: <20160401140856.GW2350@sirena.org.uk> <20160402162449.GB2350@sirena.org.uk> <20160404160327.GH2350@sirena.org.uk> <20160405183255.GH1924@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rnP2AJ7yb1j09OW/" 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: 2111 Lines: 49 --rnP2AJ7yb1j09OW/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 05, 2016 at 10:16:16PM +0300, Octavian Purdila wrote: > On Tue, Apr 5, 2016 at 9:32 PM, Mark Brown wrote: > > 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. > AFAICS this is exactly the same case for DT: one code path for > coldplug and one for hotplug. In the DT case the DT code understands a bit more of what's going on with the firmware parsing which makes things better (the code in the two paths is not identical, unlike ACPI) but yes, that's another aspect of why I'm not thrilled with this - if it's not the hotplug and coldplug that should be sharing code then perhaps it's along the firmware interface axis that we need to be sharing things. > Which makes me think that it is not possible to have a single path for > both, or maybe its not worth it. Do I miss something obvious? I think at a very high level what I'm looking at here is that we're having to write too much boilerplate per firmware interface. Perhaps the hotplug vs coldplug path isn't it, it looked like it from your patch, but there must be something here we're spending too much time on. --rnP2AJ7yb1j09OW/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXBCwoAAoJECTWi3JdVIfQsHkH/j7eyKHnPB34Mj3uvd2cG5/P xHVEpoy7uAfZ9kV6st7j1OzO/T8rvuPNQN4H8nqPeKAPEzSGP8mWlg8NWLNIbx7o WQmoJFj2QBOHS0Bctj5M729SqlhG+CxyuAjb1E0lqG9cJXWu7SI8JO5gFzkV0lDH oeMlp1KOuim2nkan6o7oxqgixHlH1pp5g8soeRHjzOlMghGBmQNAVO42zieP9GVy JYFxy/8MdcINnS7Vi4TcxngdtHSeLzs6pbzvna6q2ZfsjrMGl7Qai1Brt12rjt7R SElNKtsSMzgOz7t7RbqEyxbc0h4pJJDBn9YiyEzdH8DTwHxL2ehy6VuS+nxmm6Y= =EMam -----END PGP SIGNATURE----- --rnP2AJ7yb1j09OW/--