From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933943AbbDWKgj (ORCPT ); Thu, 23 Apr 2015 06:36:39 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:55587 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965224AbbDWKf4 (ORCPT ); Thu, 23 Apr 2015 06:35:56 -0400 Date: Thu, 23 Apr 2015 11:35:45 +0100 From: Mark Brown To: Dmitry Torokhov Cc: Doug Anderson , LKML Message-ID: <20150423103545.GS22845@sirena.org.uk> References: <20150422201112.GN22845@sirena.org.uk> <20150422205644.GB29953@dtor-ws> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7ufiXnXZuEWu9ktD" Content-Disposition: inline In-Reply-To: <20150422205644.GB29953@dtor-ws> X-Cookie: Your present plans will be successful. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Enabling regulators form userspace 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 --7ufiXnXZuEWu9ktD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 22, 2015 at 01:56:44PM -0700, Dmitry Torokhov wrote: > On Wed, Apr 22, 2015 at 09:11:12PM +0100, Mark Brown wrote: > > There's already a userspace consumer driver you can bind for test > > purposes which could be used here. > Thanks for the pointer, but I do not think this would work for this use > case, mainly because the controllers in question often impose timing > constraints on the supplies. I.e. while holding reset GPIO you turn on > vdd and then, after at least X msec, avdd, and then release reset GPIO. This really sounds like you should be writing a device driver here, even if it's just a little module you write separately to the actual device driver used in real systems. > > I'm not keen on having something in there as a standard feature, it's > > just this massive "abuse me" flag - there's not really much of a > > production use case for it but lots of "let's just hack around our buggy > > drivers" use case. > I would contend that the drivers are not necessarily buggy: we just do > not want to encumber the kernel driver with all the details about test > interface that is very much controller specific (i.e. we can't easily > generalize it for all permutations of Atmel/Cypress/Eantech/Stnaptics > etc controllers) and that is not going to be used during normal > operation. However it is very much a production issue as these test > utilities are used during factory runs to ensure quality of produced > hardware. It's not about the quality of an individual driver, it's about the potential for misuse - making the kernel interfaces such that it's easy to do the right thing and hard to do the wrong thing. Having the ability to just bang on this stuff from userspace seems like it's encouraging problematic behaviour. --7ufiXnXZuEWu9ktD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVOMsAAAoJECTWi3JdVIfQVUMH/R7RlqrAyFnUF7AuYrnhWNl1 f1+E9uE6Xfa1J6fgwYWz4gqnx/wOEhOZrs0yIkihBX4kyA05vIM0Bg5zvLh+g4nQ hsdhxUJg1gRio1q+cDsq4jvcUx+ATKYVIQT6LjbLn6GlZ845Dy2kjkGWMcNben7I CdiF+eG1I2AI4pd4M62oK3fAiuo9TovVcMK1xE72LJrAydWh0xjrxlRef5Q/+gU0 jJgHra08OKbF2Ptk/VeVrjThsJREtghELMKpSv40Md6PCId7mc8tBd5qZD39xtJ4 CGibiVVppy9EPJ65hzwd8E/cj0Z1J3uvWJgXtVA2IJEUgUm/QW8FH+Uz+S5TP8Y= =SHn9 -----END PGP SIGNATURE----- --7ufiXnXZuEWu9ktD--