Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754887AbbFEQyJ (ORCPT ); Fri, 5 Jun 2015 12:54:09 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:43994 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754661AbbFEQyD (ORCPT ); Fri, 5 Jun 2015 12:54:03 -0400 Date: Fri, 5 Jun 2015 17:53:59 +0100 From: Mark Brown To: Richard Fitzgerald Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, patches@opensource.wolfsonmicro.com Message-ID: <20150605165358.GW14071@sirena.org.uk> References: <1433514886-11884-1-git-send-email-rf@opensource.wolfsonmicro.com> <1433514886-11884-3-git-send-email-rf@opensource.wolfsonmicro.com> <20150605152537.GU14071@sirena.org.uk> <20150605155347.GA21615@opensource.wolfsonmicro.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ADUFSHE2qQv+ehpq" Content-Disposition: inline In-Reply-To: <20150605155347.GA21615@opensource.wolfsonmicro.com> X-Cookie: The end of labor is to gain leisure. 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: [PATCH 2/2] regmap: Fix permissions on debugfs cache controls 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: 2643 Lines: 61 --ADUFSHE2qQv+ehpq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jun 05, 2015 at 04:53:54PM +0100, Richard Fitzgerald wrote: > On Fri, Jun 05, 2015 at 04:25:37PM +0100, Mark Brown wrote: > > Honestly it wasn't supposed to be working at all. We can have a > > discussion about if it makes sense for it to work, that's not a totally > > unreasonable thing though I'd really want to taint the kernel if anyone > > actually does it (particularly for cache only) since it seems even more > > likely to interact poorly with drivers than random register writes. > > We'll also want to sync the cache when transitioning from cache only to > > normal operation I think, or provide a way of doing that. > We use writability of these all the time for all sorts of debugging so > it would be bad for us if it actually stopped being writeable. Sure, like I say it's not totally unreasonable. > Our expectations are that you're on your own if you fiddle with the > cache settings via debugfs. Other people's might be different. But that's > the current behaviour so if anyone is currently using the accidental > writability this patch will preserve that behaviour (broken or not). > And if they aren't using it, it doesn't matter. This is why we want it to taint - it doesn't stop people doing anything, it just means that if they report bugs (potentially in something totally unrelated) then any oopses or whatever will say someone was doing something behind the back of the kernel which might've broken the world. > I think it's preferable to avoid changing the behaviour of regmap > as a side effect of improving debugfs and worry later, separately, > about whether to improve the way regmap handles this. The current behaviour is a bug in regmap. --ADUFSHE2qQv+ehpq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVcdQmAAoJECTWi3JdVIfQYQQH/RodbVZCIgKihsTOttuGw/A7 RbCfWMZ2wllenzB3uuHq9aUrOdZj7n5kTeqoqMlUH3uQQ5plveXCdMOqOOPWFa9z DdHJ7b9tyzcmqD8YA5ZJCiBgFfFsB3yzEdZBljxJyBq0Rv0NWF5VPWCCvw89PXB9 CQjGl01M8iJ0t9xjPFvVlLSc230oYTrw5z+xMPf4Cba9aC228l38xzrdBW9NGE26 PEy9YXNgvkX7sFGRB6Enn8p+tOpdP2Xg+sl8L7MY+/3i36vCMPbzE0WqXMx338sa FmfiKiCXEKyMNPGVC8Xpfq68MHIACntIgb5ubUlHTBEieiPaNI1AKPNoB3uf/Ow= =YA/e -----END PGP SIGNATURE----- --ADUFSHE2qQv+ehpq-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/