lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 5 Mar 2019 12:11:41 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Marek Behun <marek.behun@....cz>, Tony Lindgren <tony@...mide.com>,
        Shawn Guo <shawnguo@...nel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 bus+gpio 3/5] bus: moxtet: Add sysfs documentation

On Mon, Mar 4, 2019 at 1:08 PM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Fri, Mar 1, 2019 at 4:15 PM Marek Behun <marek.behun@....cz> wrote:
>
> > On Fri, 1 Mar 2019 15:34:26 +0100
> > Linus Walleij <linus.walleij@...aro.org> wrote:
> >
> > > > +What:          /sys/bus/moxtet/devices/moxtet-<name>.<addr>/output_value
> > > > +Date:          March 2019
> > > > +KernelVersion: 5.2
> > > > +Contact:       Marek BehĂșn <marek.behun@....cz>
> > > > +Description:   (RW) Read last written value or write value to the
> > > > module on
> > > > +               this Moxtet address. Format: %x
> > >
> > > What is the usecase for these?
> > >
> > > If this is for debugging it should be in debugfs rather than in sysfs.
> > >
> > > If it is here for random userspace drivers, we need some good
> > > explanation as to why they can't just be kernel drivers.

I had the same thought, and then saw you already commented.

> > Hmm, it was for debugging purposes but the ability to write there is
> > not needed anymore... Shall I make it read/only? Or completely remove
> > it?
>
> I would either remove it or move it to debugfs.

How about removing it for the initial submission? Then we
can see if it's still needed later and discuss how it should be
done when we need it.

     Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ