[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121016062603.GG8670@opensource.wolfsonmicro.com>
Date: Tue, 16 Oct 2012 15:26:05 +0900
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Christopher Heiny <Cheiny@...aptics.com>,
Anton Vorontsov <anton.vorontsov@...aro.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jean Delvare <khali@...ux-fr.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Linux Input <linux-input@...r.kernel.org>,
Allie Xiong <axiong@...aptics.com>,
Vivian Ly <vly@...aptics.com>,
Daniel Rosenberg <daniel.rosenberg@...aptics.com>,
Joerie de Gram <j.de.gram@...il.com>,
Wolfram Sang <w.sang@...gutronix.de>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Linus Walleij <linus.walleij@...ricsson.com>,
Naveen Kumar Gaddipati <naveen.gaddipati@...ricsson.com>,
Alexandra Chin <alexandra.chin@...synaptics.com>
Subject: Re: [RFC PATCH 01/06] input/rmi4: Public header and documentation
On Thu, Oct 11, 2012 at 05:32:59PM +0200, Linus Walleij wrote:
> On Thu, Oct 11, 2012 at 5:41 AM, Christopher Heiny <Cheiny@...aptics.com> wrote:
> > In previous patch submissions, we always used these warning functions.
> > But in the feedback on those patches, we were asked to just make
> > sysfs show/store NULL if the attribute is write/read only. However,
> > during their development process, our customers want to see the
> > warnings if the attributes are accessed incorrectly. So we made
> > these warnings a debug option.
> Basically my stance is that you should not lower yourself to the
> level of others not getting the point of your technical solution
> by making unelegant compromises, what
> you should do is to bring them up to your level so they
> understand that your solution is elegant.
It seems like what you really want to do is add a debug feature to sysfs
which will optionally complain loudly at bad accesses; obviously it's
not something that should be there all the time as running then handling
an error is a perfectly legitimate thing to do. As with the /CS
handling it'd mean it was handled at an appropriate level and could be
reused elsewhere (it might also help make it clear to your customers why
this is generally bad form).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists