Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
Em Tue, 16 Apr 2019 20:49:31 -0700 Guenter Roeck escreveu: > On 4/16/19 6:58 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 16 Apr 2019 13:31:14 -0700 > > Guenter Roeck escreveu: > > > >> On Tue, Apr 16, 2019 at 02:19:49PM -0600, Jonathan Corbet wrote: > >>> On Fri, 12 Apr 2019 20:09:16 -0700 > >>> Guenter Roeck wrote: > >>> > The big real-world question is: Is the series good enough for you to > accept, > or do you expect some level of user/kernel separation ? > >>> > >>> I guess it can go in; it's forward progress, even if it doesn't make the > >>> improvements I would like to see. > >>> > >>> The real question, I guess, is who should take it. I've been seeing a > >>> fair amount of activity on hwmon, so I suspect that the potential for > >>> conflicts is real. Perhaps things would go smoother if it went through > >>> your tree? > >>> > >> We'll see a number of conflicts, yes. In terms of timing, this is probably > >> the worst release in the last few years to make such a change. I currently > >> have 9 patches queued in hwmon-next which touch Documentation/hwmon. > >> Of course the changes made in those are all not ReST compatible, and I have > >> no idea what to look out for to make it compatible. So this is going to be > >> fun (in a negative sense) either way. > >> > >> I don't really have a recommendation at this point; I think the best I > >> could > >> do to take the patches which don't generate conflicts and leave the rest > >> alone. But that would also be bad, since the new index file would not match > >> reality. No idea, really, what the best or even a useful approach would be. > >> > >> Maybe automated changes like this (assuming they are indeed automated) > >> can be generated and pushed right after a commit window closes. Would > >> that by any chance be possible ? > > > > No, those patches are hand-maid, but I can surely rebase it on the top of > > your tree. Is your tree already merged at linux-next, or should I use some > > other branch/tree for rebase? > > > > linux-next merges hwmon-next. next-20190416 is missing one patch which touches > Documentation/hwmon, but that should be easy to deal with. Ok, did a rebase on the top of next-20190417. While re-reading the output of the html files, I noticed a few minor issues on some tables and fixed. Thanks, Mauro
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On 4/16/19 6:58 PM, Mauro Carvalho Chehab wrote: Em Tue, 16 Apr 2019 13:31:14 -0700 Guenter Roeck escreveu: On Tue, Apr 16, 2019 at 02:19:49PM -0600, Jonathan Corbet wrote: On Fri, 12 Apr 2019 20:09:16 -0700 Guenter Roeck wrote: The big real-world question is: Is the series good enough for you to accept, or do you expect some level of user/kernel separation ? I guess it can go in; it's forward progress, even if it doesn't make the improvements I would like to see. The real question, I guess, is who should take it. I've been seeing a fair amount of activity on hwmon, so I suspect that the potential for conflicts is real. Perhaps things would go smoother if it went through your tree? We'll see a number of conflicts, yes. In terms of timing, this is probably the worst release in the last few years to make such a change. I currently have 9 patches queued in hwmon-next which touch Documentation/hwmon. Of course the changes made in those are all not ReST compatible, and I have no idea what to look out for to make it compatible. So this is going to be fun (in a negative sense) either way. I don't really have a recommendation at this point; I think the best I could do to take the patches which don't generate conflicts and leave the rest alone. But that would also be bad, since the new index file would not match reality. No idea, really, what the best or even a useful approach would be. Maybe automated changes like this (assuming they are indeed automated) can be generated and pushed right after a commit window closes. Would that by any chance be possible ? No, those patches are hand-maid, but I can surely rebase it on the top of your tree. Is your tree already merged at linux-next, or should I use some other branch/tree for rebase? linux-next merges hwmon-next. next-20190416 is missing one patch which touches Documentation/hwmon, but that should be easy to deal with. Thanks, Guenter
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
Em Tue, 16 Apr 2019 13:31:14 -0700 Guenter Roeck escreveu: > On Tue, Apr 16, 2019 at 02:19:49PM -0600, Jonathan Corbet wrote: > > On Fri, 12 Apr 2019 20:09:16 -0700 > > Guenter Roeck wrote: > > > > > The big real-world question is: Is the series good enough for you to > > > accept, > > > or do you expect some level of user/kernel separation ? > > > > I guess it can go in; it's forward progress, even if it doesn't make the > > improvements I would like to see. > > > > The real question, I guess, is who should take it. I've been seeing a > > fair amount of activity on hwmon, so I suspect that the potential for > > conflicts is real. Perhaps things would go smoother if it went through > > your tree? > > > We'll see a number of conflicts, yes. In terms of timing, this is probably > the worst release in the last few years to make such a change. I currently > have 9 patches queued in hwmon-next which touch Documentation/hwmon. > Of course the changes made in those are all not ReST compatible, and I have > no idea what to look out for to make it compatible. So this is going to be > fun (in a negative sense) either way. > > I don't really have a recommendation at this point; I think the best I could > do to take the patches which don't generate conflicts and leave the rest > alone. But that would also be bad, since the new index file would not match > reality. No idea, really, what the best or even a useful approach would be. > > Maybe automated changes like this (assuming they are indeed automated) > can be generated and pushed right after a commit window closes. Would > that by any chance be possible ? No, those patches are hand-maid, but I can surely rebase it on the top of your tree. Is your tree already merged at linux-next, or should I use some other branch/tree for rebase? Thanks, Mauro
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On Tue, Apr 16, 2019 at 02:19:49PM -0600, Jonathan Corbet wrote: > On Fri, 12 Apr 2019 20:09:16 -0700 > Guenter Roeck wrote: > > > The big real-world question is: Is the series good enough for you to accept, > > or do you expect some level of user/kernel separation ? > > I guess it can go in; it's forward progress, even if it doesn't make the > improvements I would like to see. > > The real question, I guess, is who should take it. I've been seeing a > fair amount of activity on hwmon, so I suspect that the potential for > conflicts is real. Perhaps things would go smoother if it went through > your tree? > We'll see a number of conflicts, yes. In terms of timing, this is probably the worst release in the last few years to make such a change. I currently have 9 patches queued in hwmon-next which touch Documentation/hwmon. Of course the changes made in those are all not ReST compatible, and I have no idea what to look out for to make it compatible. So this is going to be fun (in a negative sense) either way. I don't really have a recommendation at this point; I think the best I could do to take the patches which don't generate conflicts and leave the rest alone. But that would also be bad, since the new index file would not match reality. No idea, really, what the best or even a useful approach would be. Maybe automated changes like this (assuming they are indeed automated) can be generated and pushed right after a commit window closes. Would that by any chance be possible ? Guenter
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On Fri, 12 Apr 2019 20:09:16 -0700 Guenter Roeck wrote: > The big real-world question is: Is the series good enough for you to accept, > or do you expect some level of user/kernel separation ? I guess it can go in; it's forward progress, even if it doesn't make the improvements I would like to see. The real question, I guess, is who should take it. I've been seeing a fair amount of activity on hwmon, so I suspect that the potential for conflicts is real. Perhaps things would go smoother if it went through your tree? Thanks, jon
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On 4/12/19 9:04 AM, Jonathan Corbet wrote: On Thu, 11 Apr 2019 14:07:31 -0700 Guenter Roeck wrote: 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. Same here, but please don't move the files which are kernel facing only. Well, let's step back and think about this. Who is the audience for these documents? That will tell us a lot about where they should really be. What I would prefer to avoid is the status quo where *everything* is in the top-level directory, and where documents are organized for the convenience of their maintainers rather than of their readers. But sometimes I feel like I'm alone in that desire...:) The big real-world question is: Is the series good enough for you to accept, or do you expect some level of user/kernel separation ? Guenter
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On 4/12/19 5:25 PM, Mauro Carvalho Chehab wrote: Em Fri, 12 Apr 2019 09:12:52 -0700 Guenter Roeck escreveu: On 4/12/19 9:04 AM, Jonathan Corbet wrote: On Thu, 11 Apr 2019 14:07:31 -0700 Guenter Roeck wrote: 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. Same here, but please don't move the files which are kernel facing only. Well, let's step back and think about this. Who is the audience for these documents? That will tell us a lot about where they should really be. Most of them are for users, some of them are for driver developers. A few are for both, though that is generally not the intention (and one may argue that driver internal documentation should be moved into the respective driver source). The big issue is really those files that contain both kernel internals and userspace stuff. This is a common pattern. I just finishing converting a lot more documents to ReST and I found the same thing on almost all document directories I touched. What I would prefer to avoid is the status quo where *everything* is in the top-level directory, and where documents are organized for the convenience of their maintainers rather than of their readers. But sometimes I feel like I'm alone in that desire...:) I am fine with separating user pointing from kernel API/driver developer guides, and I agree that it would make a lot of sense. As I said, please just make sure that kernel facing files don't end up in the wrong directory. I like the idea of splitting user faced documents from the rest, but this is not an easy task. On several cases, there are just a couple of paragraphs with things like sysfs entries in the middle of a big file with Kernel internals. Yes, I know. I don't think that cleanup is going to happen anytime soon. Guenter
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
Em Fri, 12 Apr 2019 09:12:52 -0700 Guenter Roeck escreveu: > On 4/12/19 9:04 AM, Jonathan Corbet wrote: > > On Thu, 11 Apr 2019 14:07:31 -0700 > > Guenter Roeck wrote: > > > >>> 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. > >>> > >> > >> Same here, but please don't move the files which are kernel facing only. > > > > Well, let's step back and think about this. Who is the audience for > > these documents? That will tell us a lot about where they should really > > be. > > > > Most of them are for users, some of them are for driver developers. A few > are for both, though that is generally not the intention (and one may argue > that driver internal documentation should be moved into the respective > driver source). The big issue is really those files that contain both kernel internals and userspace stuff. This is a common pattern. I just finishing converting a lot more documents to ReST and I found the same thing on almost all document directories I touched. > > What I would prefer to avoid is the status quo where *everything* is in > > the top-level directory, and where documents are organized for the > > convenience of their maintainers rather than of their readers. But > > sometimes I feel like I'm alone in that desire...:) > > > I am fine with separating user pointing from kernel API/driver developer > guides, and I agree that it would make a lot of sense. As I said, please > just make sure that kernel facing files don't end up in the wrong directory. I like the idea of splitting user faced documents from the rest, but this is not an easy task. On several cases, there are just a couple of paragraphs with things like sysfs entries in the middle of a big file with Kernel internals. Thanks, Mauro
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On 4/12/19 9:04 AM, Jonathan Corbet wrote: On Thu, 11 Apr 2019 14:07:31 -0700 Guenter Roeck wrote: 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. Same here, but please don't move the files which are kernel facing only. Well, let's step back and think about this. Who is the audience for these documents? That will tell us a lot about where they should really be. Most of them are for users, some of them are for driver developers. A few are for both, though that is generally not the intention (and one may argue that driver internal documentation should be moved into the respective driver source). What I would prefer to avoid is the status quo where *everything* is in the top-level directory, and where documents are organized for the convenience of their maintainers rather than of their readers. But sometimes I feel like I'm alone in that desire...:) I am fine with separating user pointing from kernel API/driver developer guides, and I agree that it would make a lot of sense. As I said, please just make sure that kernel facing files don't end up in the wrong directory. Thanks, Guenter
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On Thu, 11 Apr 2019 14:07:31 -0700 Guenter Roeck wrote: > > 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. > > > > Same here, but please don't move the files which are kernel facing only. Well, let's step back and think about this. Who is the audience for these documents? That will tell us a lot about where they should really be. What I would prefer to avoid is the status quo where *everything* is in the top-level directory, and where documents are organized for the convenience of their maintainers rather than of their readers. But sometimes I feel like I'm alone in that desire...:) Thanks, jon
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
Em Thu, 11 Apr 2019 14:07:31 -0700 Guenter Roeck escreveu: > On Thu, Apr 11, 2019 at 05:43:57PM -0300, Mauro Carvalho Chehab wrote: > > 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: > > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon > > > > > > > > If you want to see the results, they're at: > > > > https://www.infradead.org/~mchehab/hwmon/ > > > > > > This set seems generally good and could probably be applied as-is. But I > > > have to ask...is 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: > > > > abituguru-datasheet > > > > 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. > > > > Same here, but please don't move the files which are kernel facing only. > > How do you want to handle this series ? Do you expect it to be pushed > through hwmon, or through Documentation, or do you plan to push yourself ? > > If the series isn't pushed through hwmon, we'll likely have a couple of > conflicts against hwmon-next. Guenter, I won't be pushing it myself. IMO, it makes more sense to apply it at hwmon-next, except if it would cause some conflicts against docs-next. Regards, Mauro
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
On Thu, Apr 11, 2019 at 05:43:57PM -0300, Mauro Carvalho Chehab wrote: > 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: > > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon > > > > > > If you want to see the results, they're at: > > > https://www.infradead.org/~mchehab/hwmon/ > > > > This set seems generally good and could probably be applied as-is. But I > > have to ask...is 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: > > abituguru-datasheet > > 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. > Same here, but please don't move the files which are kernel facing only. How do you want to handle this series ? Do you expect it to be pushed through hwmon, or through Documentation, or do you plan to push yourself ? If the series isn't pushed through hwmon, we'll likely have a couple of conflicts against hwmon-next. Thanks, Guenter
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: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon > > > > If you want to see the results, they're at: > > https://www.infradead.org/~mchehab/hwmon/ > > This set seems generally good and could probably be applied as-is. But I > have to ask...is 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: abituguru-datasheet 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. Thanks, Mauro
Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
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: > https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon > > If you want to see the results, they're at: > https://www.infradead.org/~mchehab/hwmon/ This set seems generally good and could probably be applied as-is. But I have to ask...is 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? Thanks, jon
[PATCH v2 00/21] Convert hwmon documentation to ReST
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:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=hwmon
If you want to see the results, they're at:
https://www.infradead.org/~mchehab/hwmon/
Version 2:
- Fixed broken SOB lines;
- changed submitting-patches.rst to mention that drivers should be
documented as Documentation/hwmon/.rst,
as suggested by Jonathan Neusch�fer.
Mauro Carvalho Chehab (21):
docs: hwmon: k10temp: convert to ReST format
docs: hwmon: vexpress: convert to ReST format
docs: hwmon: menf21bmc: convert to ReST format
docs: hwmon: sch5627: convert to ReST format
docs: hwmon: emc2103: convert to ReST format
docs: hwmon: pc87360: convert to ReST format
docs: hwmon: fam15h_power: convert to ReST format
docs: hwmon: w83791d: convert to ReST format
docs: hwmon: coretemp: convert to ReST format
docs: hwmon: aspeed-pwm-tacho: convert to ReST format
docs: hwmon: ibmpowernv: convert to ReST format
docs: hwmon: asc7621: convert to ReST format
docs: hwmon: ads1015: convert to ReST format
docs: hwmon: dme1737, vt1211: convert to ReST format
docs: hwmon: wm831x, wm8350: convert to ReST format
docs: hwmon: da9052, da9055: convert to ReST format
docs: hwmon: k8temp, w83793: convert to ReST format
docs: hwmon: pmbus files: convert to ReST format
docs: hwmon: misc files: convert to ReST format
docs: hwmon: convert remaining files to ReST format
docs: hwmon: Add an index file and rename docs to *.rst
.../devicetree/bindings/hwmon/g762.txt| 2 +-
Documentation/hwmon/{ab8500 => ab8500.rst}| 10 +-
Documentation/hwmon/abituguru | 92 ---
...guru-datasheet => abituguru-datasheet.rst} | 160 ++--
Documentation/hwmon/abituguru.rst | 113 +++
.../hwmon/{abituguru3 => abituguru3.rst} | 36 +-
Documentation/hwmon/{abx500 => abx500.rst}| 8 +-
...{acpi_power_meter => acpi_power_meter.rst} | 25 +-
Documentation/hwmon/{ad7314 => ad7314.rst}| 9 +
.../hwmon/{adc128d818 => adc128d818.rst} | 7 +-
Documentation/hwmon/{adm1021 => adm1021.rst} | 44 +-
Documentation/hwmon/{adm1025 => adm1025.rst} | 13 +-
Documentation/hwmon/{adm1026 => adm1026.rst} | 24 +-
Documentation/hwmon/{adm1031 => adm1031.rst} | 16 +-
Documentation/hwmon/{adm1275 => adm1275.rst} | 30 +-
Documentation/hwmon/{adm9240 => adm9240.rst} | 50 +-
Documentation/hwmon/{ads1015 => ads1015.rst} | 72 +-
Documentation/hwmon/{ads7828 => ads7828.rst} | 29 +-
Documentation/hwmon/{adt7410 => adt7410.rst} | 49 +-
Documentation/hwmon/{adt7411 => adt7411.rst} | 20 +-
Documentation/hwmon/{adt7462 => adt7462.rst} | 10 +-
Documentation/hwmon/{adt7470 => adt7470.rst} | 8 +-
Documentation/hwmon/{adt7475 => adt7475.rst} | 38 +-
Documentation/hwmon/{amc6821 => amc6821.rst} | 19 +-
Documentation/hwmon/{asb100 => asb100.rst}| 50 +-
Documentation/hwmon/{asc7621 => asc7621.rst} | 146 ++--
...{aspeed-pwm-tacho => aspeed-pwm-tacho.rst} | 2 +
.../hwmon/{coretemp => coretemp.rst} | 46 +-
Documentation/hwmon/{da9052 => da9052.rst}| 40 +-
Documentation/hwmon/{da9055 => da9055.rst}| 20 +-
Documentation/hwmon/{dme1737 => dme1737.rst} | 88 ++-
Documentation/hwmon/{ds1621 => ds1621.rst}| 154 ++--
Documentation/hwmon/{ds620 => ds620.rst} | 12 +-
Documentation/hwmon/{emc1403 => emc1403.rst} | 33 +-
Documentation/hwmon/{emc2103 => emc2103.rst} | 6 +-
.../hwmon/{emc6w201 => emc6w201.rst} | 5 +
Documentation/hwmon/{f71805f => f71805f.rst} | 36 +-
.../hwmon/{f71882fg => f71882fg.rst} | 56 +-
.../hwmon/{fam15h_power => fam15h_power.rst} | 85 ++-
.../hwmon/{ftsteutates => ftsteutates.rst}| 14 +-
Documentation/hwmon/{g760a => g760a.rst} | 4 +
Documentation/hwmon/{g762 => g762.rst}| 67 +-
Documentation/hwmon/{gl518sm => gl518sm.rst} | 21 +-
Documentation/hwmon/{hih6130 => hih6130.rst} | 14 +-
...on-kernel-api.txt => hwmon-kernel-api.rst} | 298
.../hwmon/{ibm-cffps => ibm-cffps.rst}| 3 +
Documentation/hwmon/{ibmaem => ibmaem.rst}| 10 +-
.../hwmon/{ibmpowernv => ibmpowernv.rst} | 3 +
Documentation/hwmon/{ina209 => ina209.rst}| 18 +-
Documentation/hwmon/{ina2xx => ina2xx.rst}| 41 +-
Documentation/hwmon/{ina3221 => ina3221.rst} | 17 +-
Documentation/hwmon/index.rst | 179 +
Documentation/hwmon/{ir35221 => ir35221.rst} | 12 +-
Documentation/hwmon/{it87 => it87.rst}| 102 ++-
Documentation/hwmon/{jc42 => jc42.rst}| 55 +-
Documentation/hwmon/{k10temp => k10temp.rst} | 37 +-
Documentation/hwmon/{k8temp => k8temp.rst}| 17 +-
.../hwmon/{lineage-pem => lineage-pem.rst}| 16 +-
