From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030398AbbDWRuV (ORCPT ); Thu, 23 Apr 2015 13:50:21 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:57250 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030371AbbDWRuL (ORCPT ); Thu, 23 Apr 2015 13:50:11 -0400 Date: Thu, 23 Apr 2015 18:50:00 +0100 From: Mark Brown To: Doug Anderson Cc: Dmitry Torokhov , LKML Message-ID: <20150423175000.GX22845@sirena.org.uk> References: <20150422201112.GN22845@sirena.org.uk> <20150422205644.GB29953@dtor-ws> <20150423103545.GS22845@sirena.org.uk> <20150423160807.GA34808@dtor-ws> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JbpSbCMiCLmwdpgc" Content-Disposition: inline In-Reply-To: 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 --JbpSbCMiCLmwdpgc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 23, 2015 at 09:52:40AM -0700, Doug Anderson wrote: > Personally, I have been annoyed several times by the lack of an easy > way to control regulators from userspace. While doing development of > regulator code it is very handy to be able to change the voltages from > userspace so I can probe them with a scope. I have a terribly hacky / > wrong CL that I > actually wrote for this. Note that userspace consumers were a bit > cumbersome for this purpose. There's a test consumer in mainline for precisely this purpose, I used to use it a lot when I was doing bringup of regulator drivers on evaluation boards - look at virtual.c (which is separate to the userspace consumer in that it throws usability to the wind, though some trivial shell scripts fix that). > I wonder whether we could achieve "safety" and "don't abuse" problems > by doing something like: > 1. Put the interface in "debugfs", not sysfs. Hopefully folks know > that userspace isn't supposed to rely on debugfs. ...though perhaps > userspace in the factory (test tools) are OK to use it as long as they > understand that it is fragile (API may change) and dangerous (could > shoot yourself in the foot). I'm not optimistic about this achieving the desired results, we export too much stuff through debugfs that's useful in production so all it really does is give us a bit more ability to say "I told you so". > 2. Require a config option to enable it with suitable warnings in the > KConfig option. > 3. Force the user to write a "y" into a file named > "i_know_this_is_unsafe", or something of the sort. Writing this could > write a suitable warning to the kernel log saying "If you let the > magic smoke out, don't blame me". I don't think either of those accomplishes anything meaningful, it's not like we've got a good track record on getting people to pay attention to warnings or do transitions. With echoing into a file I'd just expect to see patches turning off the warning because of course everyone thinks that their own use case is totally sensible, reasonable and well thought through (and some of them actually are). Like I say I think if we're delegating this to userspace we should actively choose to do so, not just throw everything over the wall. --JbpSbCMiCLmwdpgc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVOTDHAAoJECTWi3JdVIfQ/+EIAIBY1J0MJpki5JMPUF+oroW6 UWWBrUA6Z7MYHwWHVqIj5GdhVomqoCuZgEhZUW3JRT3z1YbLiJL6IByZrYH1y0as agvxp2xz9fzEp0Sukj/kyslk1a5TvR/qhFcHQJZCPk8lT7dDPGVl29MKUQieP+Ao /yzvALOSj2O4N9F2SS0+AtpLPFsy/ipxhOqU9+NsQBYVXvs+v5Su2iCKxjFC9X1B yPPWpgYjs6qdKQ4sRlcWfzudJwmUyVKgPPXx//vxfY5w+eUUZfNO5OVbDw6OxBv6 cvAaO8bmZ6XWGapk5wLa8/dyr0Pv+pzn4dyXHrZJ4FhCa9/LFKpDhyHQlmTfM9c= =ForM -----END PGP SIGNATURE----- --JbpSbCMiCLmwdpgc--