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:   Thu, 11 Apr 2019 17:43:57 -0300
From:   Mauro Carvalho Chehab <>
To:     Jonathan Corbet <>
Cc:     Linux Doc Mailing List <>,
        Mauro Carvalho Chehab <>,, Andrew Jeffery <>,
        Benjamin Herrenschmidt <>,
        Guenter Roeck <>,
        Jean Delvare <>,
        Joel Stanley <>,,,,, Liviu Dudau <>,
        Lorenzo Pieralisi <>,
        Michael Ellerman <>,
        Paul Mackerras <>,
        Sudeep Holla <>
Subject: Re: [PATCH v2 00/21] Convert hwmon documentation to ReST

Em Thu, 11 Apr 2019 12:43:24 -0600
Jonathan Corbet <> escreveu:

> On Wed, 10 Apr 2019 16:22:37 -0300
> Mauro Carvalho Chehab <> wrote:
> > This series converts the contents of Documentation/hwmon to ReST
> > format.
> > 
> > PS.: I opted to group the conversion files per groups of maintainer
> > set, as, if I were to generate one patch per file, it would give around
> > 160 patches.
> > 
> > I also added those patches to my development tree at:
> >
> > 
> > If you want to see the results, they're at:
> >  
> This set seems generally good and could probably be applied as-is.  But I
> have to there a reason to not take the last step and actually
> bring this stuff into the Sphinx doc tree?
> We seem to be mostly documenting sysfs files and such.  I am *guessing*
> that perhaps the set should move to Documentation/admin-guide/hwmon?  Or
> have I misunderstood the intended audience here?


Yeah, I'd say that 80% of the contents there are user-faced.

Yet, the main issue with this (and other driver subsystems) is that there's
a mix of userspace and Kernelspace stuff. One somewhat simple case is
the abituguru: it has a "datasheet" file:


This contains programming information for the corresponding drivers,
while abituguru and abituguru3 contains mostly userspace
stuff (still, it also contains the I2C address, with shouldn't mean
anything for the user).

However, if you take a look at w83781d, you'll see a mix of both
userspace and driver developer info there... it has a chapter called
"Data sheet updates", for example, with is probably meaningless for
anyone but the hwmon driver developers.

That's, btw, a pattern that happens a lot inside device driver
documents on almost all subsystems I checked: driver-specific
documentation is usually not split into user-facing/kernel-facing.

While nobody does such split, IMHO, the best would be to keep the
information outside Documentation/admin-guide. But hey! You're
the Doc maintainer. If you prefer to move, I'm perfectly fine
with that.


Powered by blists - more mailing lists