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.
