From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752846AbbJMUHI (ORCPT ); Tue, 13 Oct 2015 16:07:08 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:57216 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752305AbbJMUHF (ORCPT ); Tue, 13 Oct 2015 16:07:05 -0400 Date: Tue, 13 Oct 2015 21:07:00 +0100 From: Mark Brown To: Anatol Pomozov Cc: LKML Message-ID: <20151013200700.GM14956@sirena.org.uk> References: <1444758415-5190-1-git-send-email-anatol.pomozov@gmail.com> <20151013175519.GL14956@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1hVIwB4NpNcOOTEe" Content-Disposition: inline In-Reply-To: X-Cookie: Do you like "TENDER VITTLES"? User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH] regmap: Add a config option for making regmap debugfs writable 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 --1hVIwB4NpNcOOTEe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 13, 2015 at 11:33:13AM -0700, Anatol Pomozov wrote: > On Tue, Oct 13, 2015 at 10:55 AM, Mark Brown wrote: > > This is deliberately not a Kconfig option because it is a terrible idea > > to do this in production and making it either selectable or the default > > is an invitation to abuse. > What kind of abuse are you talking about? Using it as a standard interface to control systems in production rather than having appropriate support in the relevant driver. > Having an easy way of modifying chip registers is extremely useful > during bringup / driver development. And during device development > phase I regularly have situations when I need to change a register to > see if it fixes an issue. Sometimes I need to test it remotely when > users located at another end of the Earth. This is exactly the sort of use case this feature is intended for, and is the sort of situation where a custom kernel is not going to be any kind of practical problem. > Current kernel source suggests I need to modify regmap-debugfs.c > directly. But my kernel tree is shared by multiply products and some > of the products in production already. I do not want to enable > writable remap for production products. I would like to have a > per-product compile-time configuration and .config serves exactly this > purpose. Feel free to make that modification in your local tree if you want it, I'm not going to take it for upstream. > > We want to place a barrier here so that > > users know that this is something that they have taken a decision to > > enable, not something that is in any way supported (this is also why we > > taint the kernel when people do write). > Honestly I am not convinced. Why to put obstacles on a feature that is > very useful during development? We don't want people complaining when someone misprograms their PMIC or battery charger in a production system because a debug feature got left on by mistake (both components that frequently use regmap and both components that have the capacity to physically damage the system), or have someone decide that the way to tune their system is to turn on this option and bang on the hardware from userspace bypassing the driver. It's really handy for debug but it's terrible for system robustness and stability. The whole point is that this is only intended to be used during development while modifying the kernel, if you're able to do that it's not a meningful obstacle. --1hVIwB4NpNcOOTEe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWHWRfAAoJECTWi3JdVIfQWXIH/3L4n0y5naWXCpehz3Q70XRm 4U2k5AdGUwguq5mDUfTpOQDpRty3NQTtkmNUAPdzISLUWhUlZBBgGF0yaZxT67UV 2nwv9p9kbfC3uqIFw/JAXrmJ8zpK9/H3WHf6D5j3BaWhbaBQKWu8SZDR4Ej1pyCj KFwpqRiavGNM1XOq0dSy3qlplOTfOEoBoA421c1uP+dbGtI2EoQkOCD+tU6g9eQN T0d+DRWsgLLCl/tlfkVkApsyFbevT3CBAer/Tuiotavgsb0dgRbxoVIxI3tRXUjg 6oewCAXf/B/SvxBiXPDQ/gcAWOim3Hq4l/yMhDu8l6jSqNlggBg0n9WL++NfPlE= =oBjS -----END PGP SIGNATURE----- --1hVIwB4NpNcOOTEe--