From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754003AbdBDK41 (ORCPT ); Sat, 4 Feb 2017 05:56:27 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:35298 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753811AbdBDK40 (ORCPT ); Sat, 4 Feb 2017 05:56:26 -0500 Date: Sat, 4 Feb 2017 11:56:14 +0100 From: Mark Brown To: Dmitry Torokhov Cc: Liam Girdwood , linux-kernel@vger.kernel.org, Bjorn Andersson Message-ID: <20170204105614.ebbzeg7s3uhpgkrg@sirena.org.uk> References: <20170203231619.8013-1-dmitry.torokhov@gmail.com> <20170203231619.8013-4-dmitry.torokhov@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6k7guzwed5p36fmq" Content-Disposition: inline In-Reply-To: <20170203231619.8013-4-dmitry.torokhov@gmail.com> X-Cookie: Must be over 21. User-Agent: NeoMutt/20161126 (1.7.1) X-SA-Exim-Connect-IP: 2001:67c:1810:f051:e387:5dab:49ba:da3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: No (on mezzanine.sirena.org.uk); Unknown failure Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --6k7guzwed5p36fmq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 03, 2017 at 03:16:19PM -0800, Dmitry Torokhov wrote: > Make it possible to use the bulk API with optional supplies, by allowing > the consumer to marking supplies as optional in the regulator_bulk_data. So, I know I took the version Bjorn sent before (which was subsequently reverted) but based on further reflection and having seen people trying to use it I really don't think this is a good idea and that the revert was the best thing to do. The idiomatic use of bulk operations is to treat the entire block of regulators en masse, this is not possible when some of the regulators are optional. You *can* peer into the structure and special case things but it then makes further uses of the bulk API on the same block of regulators not work which isn't good. As I said earlier making it easy to just transparently mix optional regulators in is something I'd expect to see commonly associated with abuse of the optional API as a mechanism for not implementing sensible error handling. --6k7guzwed5p36fmq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAliVs00ACgkQJNaLcl1U h9DmvAgAhthXFpEDpQOf3puig3T+0ufNOsQu4HR1K/WjEa5A2kHkhZMNxLZZFwAD tdD58aOwbqmvnzXl2IfcMs2ePBugwBtnj4FnA7aRd2uOoynf39zBlxZzvRpDbSBt Ix2nn+Lp1VoRwqXNRoxuDrnLwIV3g1cGfSAptyJ02UnCEAYZiUFgGlr6UV+2Ffes JjVsY6Q+WNgOCwYFJohQxVf77TFOzvtqz8+JssbtoMSnGYLOWSP6lpa9Hhx9FNK2 jdaLy/Sjxsp2s8lxzJ5ewr1QYrGhfqj2paoyP5qopzq4Ct+6X9IvjqS+fCYkKsDy hc7h1JzvFZ4NRX90aPOqQl4y4JRUWg== =iiDl -----END PGP SIGNATURE----- --6k7guzwed5p36fmq--