On Thu, Feb 01, 2018 at 11:36:04AM +0000, Daniel Thompson wrote: > On Wed, Jan 31, 2018 at 01:51:21PM +0200, Jani Nikula wrote: > > On Wed, 31 Jan 2018, Daniel Thompson <daniel.thomp...@linaro.org> wrote: > > > On Fri, Jan 26, 2018 at 08:20:08PM +0530, Aishwarya Pant wrote: > > >> Add documentation for sysfs interfaces of lp8788 backlight driver by > > >> looking through the code and the git commit history. > > >> > > >> Signed-off-by: Aishwarya Pant <aishp...@gmail.com> > > >> --- > > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788 | 10 ++++++++++ > > >> 1 file changed, 10 insertions(+) > > >> create mode 100644 > > >> Documentation/ABI/testing/sysfs-class-backlight-lp8788 > > >> > > >> diff --git a/Documentation/ABI/testing/sysfs-class-backlight-lp8788 > > >> b/Documentation/ABI/testing/sysfs-class-backlight-lp8788 > > >> new file mode 100644 > > >> index 000000000000..c0e565c8d63d > > >> --- /dev/null > > >> +++ b/Documentation/ABI/testing/sysfs-class-backlight-lp8788 > > >> @@ -0,0 +1,10 @@ > > >> +sysfs interface for Texas Instruments lp8788 mfd backlight driver > > >> +----------------------------------------------------------------- > > >> + > > >> +What: /sys/class/backlight/<backlight>/bl_ctl_mode > > >> +Date: Feb, 2013 > > >> +KernelVersion: v3.10 > > >> +Contact: Milo Kim <milo....@ti.com> > > >> +Description: > > >> + (RO) Displays whether the brightness is controlled by > > >> the PWM > > >> + input("PWM based") or the I2C register("Register > > >> based"). > > > > > > I rather dislike drivers with this type of "bonus" sysfs controls. I'm > > > struggling to come up with any reason why the userspace would want to > > > read this control (and I think bl_ctl_mode gets the fewest hits after > > > searching with google hits of any search I've tried) . It looks to me > > > like this is debug information that should never have gone into sysfs > > > at all. > > > > Agreed. I think the same holds for the other extra sysfs attributes. At > > worst, having these prevents the backlight class from adding the names > > later on, which is just backwards. > > The problem is that they do exist... > > For controls which appear to be misplaced debug attributes I think I am > happy to nuke the values entirely. It is extremely improbable that any > userspace will notice. > > Unfortunately some of the controls look like they could be poked by an > custom userspace so I'm quite so confident about nuking these ones...and if we > don't nuke we should document (so thanks Aishwarya!). >
Hi Thanks for reviewing. Should I take it to assume that we would like to keep the debug-like attributes in documentation for now? Aishwarya > > Daniel.