[PATCH 1/3] edac.rst: adjust its locations at MAINTAINERS and 00-INDEX
As this file was moved, adjust its location. Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 2 +- MAINTAINERS| 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 903ebc494f29..7d672223f764 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -170,7 +170,7 @@ dynamic-debug-howto.txt - how to use the dynamic debug (dyndbg) feature. early-userspace/ - info about initramfs, klibc, and userspace early during boot. -edac.txt +admin-guide/edac.rst - information on EDAC - Error Detection And Correction efi-stub.txt - How to use the EFI boot stub to bypass GRUB or elilo on EFI systems. diff --git a/MAINTAINERS b/MAINTAINERS index 69820b75b2e0..4456ee8034a3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4475,7 +4475,8 @@ L:linux-e...@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git for-next T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac.git linux_next S: Supported -F: Documentation/edac.txt +F: Documentation/admin-guide/edac.rst +F: Documentation/driver-api/edac.rst F: drivers/edac/ F: include/linux/edac.h -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Improvements at the admin-guide book for EDAC
This series is based on my previous one. The first patch should actually
be folded together with this patch:
[PATCH 10/12] docs-rst: admin-guide: add documentation for EDAC
The other two patches rename the documentation to ras.rst, adds an
introductory chapter describing RAS and improves the EDAC documentation.
Mauro Carvalho Chehab (3):
edac.rst: adjust its locations at MAINTAINERS and 00-INDEX
edac: rename admin-guide documentation to ras.rst and improve it
ras.rst: add a section explaining the dimmX and rankX directories
Documentation/00-INDEX | 4 +-
Documentation/admin-guide/index.rst | 2 +-
Documentation/admin-guide/{edac.rst => ras.rst} | 401 +---
MAINTAINERS | 3 +-
4 files changed, 370 insertions(+), 40 deletions(-)
rename Documentation/admin-guide/{edac.rst => ras.rst} (64%)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] edac: rename admin-guide documentation to ras.rst and improve it
The edac.rst file at admin-guide assumes that the reader has
already deep knowledge on RAS features. However, this may not
be the case. So, rename it to RAS and add an introduction
chapter explaining the main concepts that are used by the
EDAC subsystem and by other RAS drivers within the Kernel.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/00-INDEX | 4 +-
Documentation/admin-guide/index.rst | 2 +-
Documentation/admin-guide/{edac.rst => ras.rst} | 281 +---
MAINTAINERS | 2 +-
4 files changed, 249 insertions(+), 40 deletions(-)
rename Documentation/admin-guide/{edac.rst => ras.rst} (71%)
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 7d672223f764..9497119fc10d 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -170,8 +170,8 @@ dynamic-debug-howto.txt
- how to use the dynamic debug (dyndbg) feature.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
-admin-guide/edac.rst
- - information on EDAC - Error Detection And Correction
+admin-guide/ras.rst
+ - information on Reliability, Availability and Serviceability
efi-stub.txt
- How to use the EFI boot stub to bypass GRUB or elilo on EFI systems.
eisa.txt
diff --git a/Documentation/admin-guide/index.rst
b/Documentation/admin-guide/index.rst
index 5e90d6ce8cac..c4c87bbd19a6 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -32,7 +32,7 @@ Contents:
java
bad-memory
basic-profiling
- edac
+ ras
.. only:: subproject and html
diff --git a/Documentation/admin-guide/edac.rst
b/Documentation/admin-guide/ras.rst
similarity index 71%
rename from Documentation/admin-guide/edac.rst
rename to Documentation/admin-guide/ras.rst
index 7c8c9beb5956..178144a34e01 100644
--- a/Documentation/admin-guide/edac.rst
+++ b/Documentation/admin-guide/ras.rst
@@ -1,18 +1,218 @@
.. include::
-=
+
+Reliability, Availability and Serviceability
+
+
+RAS concepts
+
+
+Reliability, Availability and Serviceability (RAS) is a concept used on
+servers meant to measure their robusteness.
+
+Reliability
+ is the probability that a system will produce correct outputs.
+
+ * Generally measured as Mean Time Between Failures (MTBF)
+ * Enhanced by features that help to avoid, detect and repair hardware faults
+
+Availability
+ is the probability that a system is operational at a given time
+
+ * Generally measured as a percentage of downtime per a period of time
+ * Often uses mechanisms to detect and correct hardware faults in
+runtime;
+
+Serviceability (or maintainability)
+ is the simplicity and speed with which a system can be repaired or
+ maintained
+
+ * Generally measured on Mean Time Between Repair (MTBR)
+
+Improving RAS
+-
+
+In order to reduce systems downtime, a system should be capable of detecting
+hardware errors, and, when possible correcting them in runtime. It should
+also provide mechanisms to detect hardware degradation, in order to warn
+the system administrator to take the action of replacing a component before
+it causes data loss or system downtime.
+
+Among the monitoring measures, the most usual ones include:
+
+* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
+* Memory – add error correction logic (ECC) to detect and correct errors;
+* I/O – add CRC checksums for tranfered data;
+* Storage – RAID, journal file systems, checksums,
+ Self-Monitoring, Analysis and Reporting Technology (SMART).
+
+By monitoring the number of occurrences of error detections, it is possible
+to identify if the probability of hardware errors is increasing, and, on such
+case, do a preventive maintainance to replace a degrated component while
+those errors are correctable.
+
+Types of errors
+---
+
+Most mechanisms used on modern systems use use technologies like Hamming
+Codes that allow error correction when the number of errors on a bit packet
+is below a threshold. If the number of errors is above, those mechanisms
+can indicate with a high degree of confidence that an error happened, but
+they can't correct.
+
+Also, sometimes an error occur on a component that it is not used. For
+example, a part of the memory that it is not currently allocated.
+
+That defines some categories of errors:
+
+* **Correctable Error (CE)** - the error detection mechanism detected and
+ corrected the error. Such errors are usually not fatal, although some
+ Kernel mechanisms allow the system administrator to consider them as fatal.
+
+* **Uncorrected Error (UE)** - the amount of errors happened above the error
+ correction threshold, and the system was unable to auto-correct.
+
+* **Fatal Error** - when an UE error happens on a crit
[PATCH 3/3] ras.rst: add a section explaining the dimmX and rankX directories
Documentation for those are missing at the EDAC description. I guess we end by moving such descriptions in the past to the ABI document (or only added it there), but it means that the EDAC documentation is incomplete. So, add it there. Signed-off-by: Mauro Carvalho Chehab --- Documentation/admin-guide/ras.rst | 120 ++ 1 file changed, 120 insertions(+) diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst index 178144a34e01..2f8706bae5a4 100644 --- a/Documentation/admin-guide/ras.rst +++ b/Documentation/admin-guide/ras.rst @@ -423,6 +423,126 @@ For a description of the sysfs API, please see: Documentation/ABI/testing/sysfs-devices-edac +``dimmX`` or ``rankX`` directories +-- + +The recommended way to use the EDAC subsystem is to look at the information +provided by the ``dimmX`` or ``rankX`` directories [#f5]_. + +A typical EDAC system has the following structure under +``/sys/devices/system/edac/``\ [#f6]_:: + + /sys/devices/system/edac/ + ├── mc + │ ├── mc0 + │ │ ├── ce_count + │ │ ├── ce_noinfo_count + │ │ ├── dimm0 + │ │ │ ├── dimm_dev_type + │ │ │ ├── dimm_edac_mode + │ │ │ ├── dimm_label + │ │ │ ├── dimm_location + │ │ │ ├── dimm_mem_type + │ │ │ ├── size + │ │ │ └── uevent + │ │ ├── max_location + │ │ ├── mc_name + │ │ ├── reset_counters + │ │ ├── seconds_since_reset + │ │ ├── size_mb + │ │ ├── ue_count + │ │ ├── ue_noinfo_count + │ │ └── uevent + │ ├── mc1 + │ │ ├── ce_count + │ │ ├── ce_noinfo_count + │ │ ├── dimm0 + │ │ │ ├── dimm_dev_type + │ │ │ ├── dimm_edac_mode + │ │ │ ├── dimm_label + │ │ │ ├── dimm_location + │ │ │ ├── dimm_mem_type + │ │ │ ├── size + │ │ │ └── uevent + │ │ ├── max_location + │ │ ├── mc_name + │ │ ├── reset_counters + │ │ ├── seconds_since_reset + │ │ ├── size_mb + │ │ ├── ue_count + │ │ ├── ue_noinfo_count + │ │ └── uevent + │ └── uevent + └── uevent + +In the ``dimmX`` directories are EDAC control and attribute files for +this ``X`` memory module: + +- ``size`` - Total memory managed by this csrow attribute file + + This attribute file displays, in count of megabytes, the memory + that this csrow contains. + +- ``dimm_dev_type`` - Device type attribute file + + This attribute file will display what type of DRAM device is + being utilized on this DIMM. + Examples: + + - x1 + - x2 + - x4 + - x8 + +- ``dimm_edac_mode`` - EDAC Mode of operation attribute file + + This attribute file will display what type of Error detection + and correction is being utilized. + +- ``dimm_label`` - memory module label control file + + This control file allows this DIMM to have a label assigned + to it. With this label in the module, when errors occur + the output can provide the DIMM label in the system log. + This becomes vital for panic events to isolate the + cause of the UE event. + + DIMM Labels must be assigned after booting, with information + that correctly identifies the physical slot with its + silk screen label. This information is currently very + motherboard specific and determination of this information + must occur in userland at this time. + +- ``dimm_location`` - location of the memory module + + The location can have up to 3 levels, and describe how the + memory controller identifies the location of a memory module. + Depending on the type of memory and memory controller, it + can be: + + - *csrow* and *channel* - used when the memory controller + doesn't identify a single DIMM - e. g. in ``rankX`` dir; + - *branch*, *channel*, *slot* - typically used on FB-DIMM memory + controllers; + - *channel*, *slot* - used on Nehalem and newer Intel drivers. + +- ``dimm_mem_type`` - Memory Type attribute file + + This attribute file will display what type of memory is currently + on this csrow. Normally, either buffered or unbuffered memory. + Examples: + + - Registered-DDR + - Unbuffered-DDR + +.. [#f5] On some systems, the memory controller doesn't have any logic + to identify the memory module. On such systems, the directory is called ``rankX`` and works on a similar way as the ``csrowX`` directories. + On modern Intel memory controllers, the memory controller identifies the + memory modules directly. On such systems, the directory is called ``dim
Re: [PATCH 02/18] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
Hi Chris, Thank you for comments On Mon, Oct 24, 2016 at 12:36:27PM -0400, Chris Metcalf wrote: > On 10/21/2016 4:33 PM, Yury Norov wrote: > >Based on Andrew Pinski's patch-series. > > > >Signed-off-by: Yury Norov > >--- > > Documentation/arm64/ilp32.txt | 46 > > +++ > > 1 file changed, 46 insertions(+) > > create mode 100644 Documentation/arm64/ilp32.txt > > > >diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt > >new file mode 100644 > >index 000..b96c18f > >--- /dev/null > >+++ b/Documentation/arm64/ilp32.txt > >@@ -0,0 +1,46 @@ > >+ILP32 AARCH64 SYSCALL ABI > >+= > >+ > >+This document describes the ILP32 syscall ABI and where it differs > >+from the generic compat linux syscall interface. > >+ > >+AARCH64/ILP32 userspace can potentially access top halves of registers that > >+are passed as syscall arguments, so such registers (w0-w7) are deloused. > > I'm not sure what "potentially access" here means: I think what you want to > say > is that userspace can pass garbage in the top half, but you should be clearer > about > what you mean here. Yes. Will change. > Also, you shouldn't use "deloused" here, since it's not a term > that's defined elsewhere in the kernel, even though it's been used > colloquially on LKML. > Provide an actual implementation definition, like "have their top 32 bits > zeroed". Agree. In fact 'delouse' is used in the name of corresponding macro in include/linux/compat.h: 29 #ifndef __SC_DELOUSE 30 #define __SC_DELOUSE(t,v) ((t)(unsigned long)(v)) 31 #endif But it's not for documentation. > > >+AARCH64/ILP32 provides next types turned to 64-bit (comparing to AARCH32): > > What does "turned" mean here? And I "next types" isn't standard English; you > want > to say something like "the following types". Likewise later with "next > syscalls". Thanks, will change. Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
patch "vgacon: remove prehistoric macros" added to tty-testing
This is a note to let you know that I've just added the patch titled vgacon: remove prehistoric macros to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the tty-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From b9c8b7fc252cd8e7e629f14bb8a68d54889470da Mon Sep 17 00:00:00 2001 From: Jiri Slaby Date: Mon, 3 Oct 2016 11:18:39 +0200 Subject: vgacon: remove prehistoric macros These macros: * CAN_LOAD_EGA_FONTS * CAN_LOAD_PALETTE * TRIDENT_GLITCH * VGA_CAN_DO_64KB * SLOW_VGA are either always set or always unset. They come from the linux 2.1 times. And given nobody switched them to some configurable options, I assume nobody actually uses them. So remove the macros and leave in place appropriate branches of the conditional code. Signed-off-by: Jiri Slaby Cc: Tomi Valkeinen Cc: Cc: Signed-off-by: Greg Kroah-Hartman --- Documentation/VGA-softcursor.txt | 12 -- drivers/video/console/vgacon.c | 49 2 files changed, 5 insertions(+), 56 deletions(-) diff --git a/Documentation/VGA-softcursor.txt b/Documentation/VGA-softcursor.txt index 70acfbf399eb..2ea8968b64a6 100644 --- a/Documentation/VGA-softcursor.txt +++ b/Documentation/VGA-softcursor.txt @@ -2,13 +2,11 @@ Software cursor for VGAby Pavel Machek ===and Martin Mares Linux now has some ability to manipulate cursor appearance. Normally, you -can set the size of hardware cursor (and also work around some ugly bugs in -those miserable Trident cards--see #define TRIDENT_GLITCH in drivers/video/ -vgacon.c). You can now play a few new tricks: you can make your cursor look -like a non-blinking red block, make it inverse background of the character it's -over or to highlight that character and still choose whether the original -hardware cursor should remain visible or not. There may be other things I have -never thought of. +can set the size of hardware cursor. You can now play a few new tricks: you +can make your cursor look like a non-blinking red block, make it inverse +background of the character it's over or to highlight that character and still +choose whether the original hardware cursor should remain visible or not. +There may be other things I have never thought of. The cursor appearance is controlled by a "[?1;2;3c" escape sequence where 1, 2 and 3 are parameters described below. If you omit any of them, diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c index d13d5d372604..c22a56232b7c 100644 --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -60,15 +60,6 @@ static struct vgastate vgastate; #define BLANK 0x0020 -#define CAN_LOAD_EGA_FONTS /* undefine if the user must not do this */ -#define CAN_LOAD_PALETTE /* undefine if the user must not do this */ - -/* You really do _NOT_ want to define this, unless you have buggy - * Trident VGA which will resize cursor when moving it between column - * 15 & 16. If you define this and your VGA is OK, inverse bug will - * appear. - */ -#undef TRIDENT_GLITCH #define VGA_FONTWIDTH 8 /* VGA does not support fontwidths != 8 */ /* * Interface used by the world @@ -157,18 +148,10 @@ static inline void write_vga(unsigned char reg, unsigned int val) * handlers, thus the write has to be IRQ-atomic. */ raw_spin_lock_irqsave(&vga_lock, flags); - -#ifndef SLOW_VGA v1 = reg + (val & 0xff00); v2 = reg + 1 + ((val << 8) & 0xff00); outw(v1, vga_video_port_reg); outw(v2, vga_video_port_reg); -#else - outb_p(reg, vga_video_port_reg); - outb_p(val >> 8, vga_video_port_val); - outb_p(reg + 1, vga_video_port_reg); - outb_p(val & 0xff, vga_video_port_val); -#endif raw_spin_unlock_irqrestore(&vga_lock, flags); } @@ -426,18 +409,6 @@ static const char *vgacon_startup(void) request_resource(&ioport_resource, &vga_console_resource); -#ifdef VGA_CAN_DO_64KB - /* -* get 64K rather than 32K of video RAM. -* This doesn't actually work on all "VGA" -* controllers (it seems like setting MM=01 -* and COE=1 isn't necessarily a good idea) -*/ - vga_vram_base = 0xa; - vga_vram_size = 0x1; - outb_p(6, VGA_GFX_I); - outb_p(6, VGA_GFX_D); -#end
Re: Documentation/media/uapi/cec/ sporadically unnecessarily rebuilding
Hi Jani, Am 24.10.2016 um 11:04 schrieb Jani Nikula : > I think I saw some of this in the past [1], but then couldn't reproduce > it after all. Now I'm seeing it again. Sporadically > Documentation/media/uapi/cec/ gets rebuilt on successive runs of make > htmldocs, even when nothing has changed. > > Output of 'make SPHINXOPTS="-v -v" htmldocs' attached for both cases. > > Using Sphinx (sphinx-build) 1.4.6 I can't see what's wrong with your "rebuild" file ... loading pickled environment... done building [mo]: targets for 0 po files that are out of date building [html]: targets for 0 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found no targets are out of date. build succeeded. HTMLDocumentation/DocBook/index.html Sphinx loads the cached (pickled) environment and says, that no target was outdated. The build succeeded without any rebuild. IMO it is sane build ... or do I misunderstood you? -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation/media/uapi/cec/ sporadically unnecessarily rebuilding
On Thu, 27 Oct 2016, Markus Heiser wrote: > Hi Jani, > > Am 24.10.2016 um 11:04 schrieb Jani Nikula : > >> I think I saw some of this in the past [1], but then couldn't reproduce >> it after all. Now I'm seeing it again. Sporadically >> Documentation/media/uapi/cec/ gets rebuilt on successive runs of make >> htmldocs, even when nothing has changed. >> >> Output of 'make SPHINXOPTS="-v -v" htmldocs' attached for both cases. >> >> Using Sphinx (sphinx-build) 1.4.6 > > I can't see what's wrong with your "rebuild" file ... > > > loading pickled environment... done > building [mo]: targets for 0 po files that are out of date > building [html]: targets for 0 source files that are out of date > updating environment: 0 added, 0 changed, 0 removed > looking for now-outdated files... none found > no targets are out of date. > build succeeded. > HTMLDocumentation/DocBook/index.html > Awesome, I screwed up the file names, please check again with build-cec-rebuilding.txt <-> build-ok.txt... BR, Jani. > > Sphinx loads the cached (pickled) environment and says, that no > target was outdated. The build succeeded without any rebuild. > IMO it is sane build ... or do I misunderstood you? > > -- Markus -- > -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Oct 21, 2016 at 4:57 PM, wrote: >> -Original Message- >> From: Amir Levy [mailto:amir.jer.l...@intel.com] >> Sent: Wednesday, September 28, 2016 9:44 AM >> To: gre...@linuxfoundation.org >> Cc: andreas.noe...@gmail.com; bhelg...@google.com; cor...@lwn.net; >> linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; >> net...@vger.kernel.org; linux-doc@vger.kernel.org; Limonciello, Mario >> ; thunderbolt-li...@intel.com; >> mika.westerb...@intel.com; tomas.wink...@intel.com; >> xiong.y.zh...@intel.com; Amir Levy >> Subject: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) >> Networking >> >> This driver enables Thunderbolt Networking on non-Apple platforms >> running Linux. >> >> Thunderbolt Networking provides peer-to-peer connections to transfer >> files between computers, perform PC migrations, and/or set up small >> workgroups with shared storage. >> >> This is a virtual connection that emulates an Ethernet adapter that >> enables Ethernet networking with the benefit of Thunderbolt superfast >> medium capability. >> >> Thunderbolt Networking enables two hosts and several devices that >> have a Thunderbolt controller to be connected together in a linear >> (Daisy chain) series from a single port. >> >> Thunderbolt Networking for Linux is compatible with Thunderbolt >> Networking on systems running macOS or Windows and also supports >> Thunderbolt generation 2 and 3 controllers. >> >> Note that all pre-existing Thunderbolt generation 3 features, such as >> USB, Display and other Thunderbolt device connectivity will continue >> to function exactly as they did prior to enabling Thunderbolt Networking. >> >> Code and Software Specifications: >> This kernel code creates a virtual ethernet device for computer to >> computer communication over a Thunderbolt cable. >> The new driver is a separate driver to the existing Thunderbolt driver. >> It is designed to work on systems running Linux that >> interface with Intel Connection Manager (ICM) firmware based >> Thunderbolt controllers that support Thunderbolt Networking. >> The kernel code operates in coordination with the Thunderbolt user- >> space daemon to implement full Thunderbolt networking functionality. >> >> Hardware Specifications: >> Thunderbolt Hardware specs have not yet been published but are used >> where necessary for register definitions. >> >> Changes since v7: >> - Removed debug prints >> - Edited error prints >> - Edited copyright notice >> - Changed the Kconfig patch to be after the code changes >> >> These patches were pushed to GitHub where they can be reviewed more >> comfortably with green/red highlighting: >> https://github.com/01org/thunderbolt-software-kernel-tree >> >> Daemon code: >> https://github.com/01org/thunderbolt-software-daemon >> >> For reference, here's a link to version 6: >> [v7]: https://lkml.org/lkml/2016/9/27/244 >> >> Amir Levy (8): >> thunderbolt: Macro rename >> thunderbolt: Updating the register definitions >> thunderbolt: Communication with the ICM (firmware) >> thunderbolt: Networking state machine >> thunderbolt: Networking transmit and receive >> thunderbolt: Kconfig for Thunderbolt Networking >> thunderbolt: Networking doc >> thunderbolt: Adding maintainer entry >> >> Documentation/00-INDEX |2 + >> Documentation/thunderbolt/networking.txt | 132 ++ >> MAINTAINERS |8 +- >> drivers/thunderbolt/Kconfig | 27 +- >> drivers/thunderbolt/Makefile |3 +- >> drivers/thunderbolt/icm/Makefile |2 + >> drivers/thunderbolt/icm/icm_nhi.c| 1514 >> drivers/thunderbolt/icm/icm_nhi.h| 82 ++ >> drivers/thunderbolt/icm/net.c| 2254 >> ++ >> drivers/thunderbolt/icm/net.h| 287 >> drivers/thunderbolt/nhi_regs.h | 115 +- >> 11 files changed, 4417 insertions(+), 9 deletions(-) >> create mode 100644 Documentation/thunderbolt/networking.txt >> create mode 100644 drivers/thunderbolt/icm/Makefile >> create mode 100644 drivers/thunderbolt/icm/icm_nhi.c >> create mode 100644 drivers/thunderbolt/icm/icm_nhi.h >> create mode 100644 drivers/thunderbolt/icm/net.c >> create mode 100644 drivers/thunderbolt/icm/net.h >> >> -- >> 2.7.4 > > Hi Amir, > > I've tested your v8 series on Dell hardware with Thunderbolt > Controllers again between a Linux and Windows box. > Functionally it's working well. > > Tested-By: Mario Limonciello > > Andreas, > > Following the history of this thread, I believe Greg was still looking for > an ack from you that Amir is using the interface properly. > > Thanks, That I don't know, but this driver does the inverse dmi_match of the current apple driver (dmi_match(DMI_BOARD_VENDOR, "Apple Inc.")), and therefore there should be no interaction between the two. Acked-by: Andreas Noever Cheers, Andreas -- To unsubscribe from this list: send the line
Re: [PATCH 01/18] 32-bit ABI: introduce ARCH_32BIT_OFF_T config option
On Tue, Oct 25, 2016 at 12:22:47AM +0200, Arnd Bergmann wrote: > On Monday, October 24, 2016 12:30:47 PM CEST Chris Metcalf wrote: > > On 10/21/2016 4:33 PM, Yury Norov wrote: > > > All new 32-bit architectures should have 64-bit off_t type, but existing > > > architectures has 32-bit ones. > > > > > > [...] > > > For syscalls sys_openat() and sys_open_by_handle_at() force_o_largefile() > > > is called, to set O_LARGEFILE flag, and this is the only difference > > > comparing to compat versions. All compat ABIs are already turned to use > > > 64-bit off_t, except tile. So, compat versions for this syscalls are not > > > needed anymore. Tile is handled explicitly. > > > > > > [...] > > > --- a/arch/tile/kernel/compat.c > > > +++ b/arch/tile/kernel/compat.c > > > @@ -103,6 +103,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, > > > unsigned int, offset_high, > > > #define compat_sys_readahead sys32_readahead > > > #define sys_llseek compat_sys_llseek > > > > > > +#define sys_openat compat_sys_openat > > > +#define sys_open_by_handle_at compat_sys_open_by_handle_at > > > + > > > /* Call the assembly trampolines where necessary. */ > > > #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn > > > #define sys_clone _sys_clone > > > > This patch accomplishes two goals that could be completely separated. > > It's confusing to have them mixed in the same patch without any > > discussion of why they are in the same patch. > > > > First, you want to modify the default behavior for > > compat syscalls so that the default is sys_openat (etc) rather than > > the existing compat_sys_openat, and then use that new behavior for > > arm64 ILP32. This lets you force O_LARGEFILE for arm64 ILP32 to > > support having a 64-bit off_t at all times. To do that, you fix the > > asm-generic header, and then make tile have a special override. > > This seems reasonable enough. > > > > Second, you introduce ARCH_32BIT_OFF_T basically as a synonym for > > "BITS_PER_WORD == 32", so that new 32-bit architectures can choose not > > to enable it. This is fine in the abstract, but I'm a bit troubled by > > the fact that you are not actually introducing a new 32-bit > > architecture here (just a new 32-bit mode for the arm 64-bit kernel). > > Shouldn't this part of the change wait until someone actually has a > > new 32-bit kernel to drive this forward? > > I asked for this specifically because we identified the problem > during the review of the aarch64 ilp32 code, and it might not > be noticed in the next architecture submission. > > The most important aspect from my perspective is that the new > ilp32 ABI on aarch64 behaves the same way that any native 32-bit > architecture does, and when we change the default, it should > be done for both compat mode and native mode at the same time. > > > If you want to push forward the ARCH_32BIT_OFF_T change in the absence > > of an architecture that supports it, I would think it would be a lot > > less confusing to have these two in separate patches, and make it > > clear that the ARCH_32BIT_OFF_T change is just laying groundwork > > for some hypothetical future architecture. > > > > The existing commit language itself is also confusing. You write "All > > compat ABIs are already turned to use 64-bit off_t, except tile." > > First, I'm not sure what you mean by "turned" here. And, tile is just > > one of many compat ABIs that allow O_LARGEFILE not to be part of the > > open call: see arm64's AArch32 ABI, MIPS o32, s390 31-bit emulation, > > sparc64's 32-bit mode, and of course x86's 32-bit compat mode. > > Presumably your point here is that tile is the only pre-existing > > architecture that #includes to create its compat > > syscall table, and so I think "all except tile" here is particularly > > confusing, since there are no architectures except tile that use the > > __SYSCALL_COMPAT functionality in the current tree. > > Agreed, this could be made clearer, and splitting the patch up > in two also seems reasonable, though I didn't see it as important. > > Arnd In the past it was a separated series of 2 patches, and it was even acked by Arnd, but not submitted. http://lists-archives.com/linux-kernel/28471253-32-bit-abi-introduce-arch_32bit_off_t-config-option.html I can restore that small series in aarch64/ilp32 for next iteration, or resend it separately if you think to submit it before aarch64/ilp32 (which is better, for me). Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 1/8] sched/tune: add detailed documentation
The topic of a single simple power-performance tunable, that is wholly scheduler centric, and has well defined and predictable properties has come up on several occasions in the past. With techniques such as a scheduler driven DVFS, which is now provided mainline via the schedutil governor, we now have a good framework for implementing such a tunable. This patch provides a detailed description of the motivations and design decisions behind the implementation of SchedTune. Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Signed-off-by: Patrick Bellasi --- Documentation/scheduler/sched-tune.txt | 392 + 1 file changed, 392 insertions(+) create mode 100644 Documentation/scheduler/sched-tune.txt diff --git a/Documentation/scheduler/sched-tune.txt b/Documentation/scheduler/sched-tune.txt new file mode 100644 index 000..da7b3eb --- /dev/null +++ b/Documentation/scheduler/sched-tune.txt @@ -0,0 +1,392 @@ + SchedTune Support for CFS Tasks + central, scheduler-driven, power-performance control + (EXPERIMENTAL) + +Abstract + + +The topic of a single simple power-performance tunable, that is wholly +scheduler centric and has well defined and predictable properties, has come up +on several occasions in the past [1,2]. With techniques such as a scheduler +driven DVFS [3], we now have a good framework for implementing such a tunable. + +Scheduler driven DVFS provides the foundation mechanism on top of which it's +possible to differentiate the performance levels based on the specific +requirements of different use-cases. For example, on mobile systems it's likely +to have demanding use-cases which may benefit from running on an higher OPP +than the one currently chosen by schedutil. + +In the past this behavior was provided by changing the governor or by tuning +its the many different parameters of non-mainline governors, now we can achieve +similar behaviors by tuning schedutil. This approach allows also for a more +fine grained control which can be extended to consider the requirement of +specific tasks. + +This document introduces SchedTune and describes the overall ideas behind its +design and implementation. + +Table of Contents += + +1. Motivation +2. Introduction +3. Signal Boosting Strategy +4. OPP selection using boosted CPU utilization +5. Per task group boosting +6. Question and Answers + - What about "auto" mode? + - What about boosting on a congested system? + - How CPUs are boosted when we have tasks with multiple boost values? +7. References + + +1. Motivation += + +schedutil [3] is a new event-driven cpufreq governor which allows the scheduler +to select the optimal DVFS Operating Performance Point (OPP) for running a task +allocated to a CPU. The introduction of schedutil enables running workloads at +the most efficient OPPs. + +However, sometimes it may be desired to intentionally boost the performance of +a workload even if that could imply a reasonable increase in energy +consumption. For example, in order to reduce the response time of a task, we +may want to run the task at a higher OPP than the one actually required by its +CPU bandwidth demand. + +This last requirement is especially important if we consider that schedutil can +potentially replace all currently available CPUFreq policies. Since schedutil +is event based, as opposed to the sampling driven governors, it is already more +responsive at selecting the optimal OPP to run tasks allocated to a CPU. +However, just tracking the actual task utilization demand may not be enough +from a performance standpoint. For example, it is not possible to get +behaviors similar to those provided by the "performance" and "powersave" +CPUFreq governors. + +This document describes an implementation of a tunable, stacked on top of +schedutil, which extends its functionality to support task performance +boosting. + +By "performance boosting" we mean the reduction of the time required to +complete a task activation, i.e. the time elapsed from a task wakeup to its +next deactivation (e.g. because it goes back to sleep or it terminates). +For example, if we consider a simple periodic task which executes the same +workload for 5[ms] every 20[ms] while running at a certain OPP, a boosted +execution of that task should be able to complete each of its activations in +less than 5[ms]. + +Previous attempts to introduce such a boosting feature has not been successful, +mainly because of the complexity of the proposed solution. The approach +described in this document exposes a single simple interface to user-space. +This single knob allows the tuning of system wide scheduler behaviours ranging +from energy efficiency at one end through to incremental performance boosting +at the other end. This tunable affects all tasks. A more advanced extension of +this concept is also provided, which uses CGroups to boost the performan
[RESEND PATCH 2/3] x86/vmware: Add basic paravirt ops support
Add basic paravirt support:
1. set pv_info.name to "VMware hypervisor" to have proper boot log message
Booting paravirtualized kernel on VMware hypervisor
instead of "... on bare hardware"
2. set pv_cpu_ops.io_delay() to empty function - paravirt_nop() to
avoid vm-exits on IO delays.
Signed-off-by: Alexey Makhalov
Acked-by: Alok N Kataria
---
arch/x86/kernel/cpu/vmware.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 480790f..098a524 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -61,6 +61,16 @@ static unsigned long vmware_get_tsc_khz(void)
return vmware_tsc_khz;
}
+#ifdef CONFIG_PARAVIRT
+static void __init vmware_paravirt_ops_setup(void)
+{
+ pv_info.name = "VMware hypervisor";
+ pv_cpu_ops.io_delay = paravirt_nop;
+}
+#else
+#define vmware_paravirt_ops_setup() do {} while (0)
+#endif
+
static void __init vmware_platform_setup(void)
{
uint32_t eax, ebx, ecx, edx;
@@ -94,6 +104,8 @@ static void __init vmware_platform_setup(void)
} else {
pr_warn("Failed to get TSC freq from the hypervisor\n");
}
+
+ vmware_paravirt_ops_setup();
}
/*
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 3/3] x86/vmware: Add paravirt sched clock
Set pv_time_ops.sched_clock to vmware_sched_clock(). It is simplified
version of native_sched_clock() without ring buffer of mult/shift/offset
triplets and preempt toggling.
Since VMware hypervisor provides constant tsc we can use constant
mult/shift/offset triplet calculated at boot time.
no-vmw-sched-clock kernel parameter is added to disable the paravirt
sched clock.
Signed-off-by: Alexey Makhalov
Acked-by: Alok N Kataria
---
Documentation/kernel-parameters.txt | 4
arch/x86/kernel/cpu/vmware.c| 41 +
2 files changed, 45 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 37babf9..b3b2ec0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2754,6 +2754,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page
fault handling.
+ no-vmw-sched-clock
+ [X86,PV_OPS] Disable paravirtualized VMware scheduler
+ clock and use the default one.
+
no-steal-acc[X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 098a524..9b29511 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -24,10 +24,15 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
+
+#undef pr_fmt
+#define pr_fmt(fmt)"vmware: " fmt
#define CPUID_VMWARE_INFO_LEAF 0x4000
#define VMWARE_HYPERVISOR_MAGIC0x564D5868
@@ -62,10 +67,46 @@ static unsigned long vmware_get_tsc_khz(void)
}
#ifdef CONFIG_PARAVIRT
+static struct cyc2ns_data vmware_cyc2ns __ro_after_init;
+static int vmw_sched_clock __initdata = 1;
+
+static __init int setup_vmw_sched_clock(char *s)
+{
+ vmw_sched_clock = 0;
+ return 0;
+}
+early_param("no-vmw-sched-clock", setup_vmw_sched_clock);
+
+static unsigned long long vmware_sched_clock(void)
+{
+ unsigned long long ns;
+
+ ns = mul_u64_u32_shr(rdtsc(), vmware_cyc2ns.cyc2ns_mul,
+vmware_cyc2ns.cyc2ns_shift);
+ ns -= vmware_cyc2ns.cyc2ns_offset;
+ return ns;
+}
+
static void __init vmware_paravirt_ops_setup(void)
{
pv_info.name = "VMware hypervisor";
pv_cpu_ops.io_delay = paravirt_nop;
+
+ if (vmware_tsc_khz && vmw_sched_clock) {
+ unsigned long long tsc_now = rdtsc();
+
+ clocks_calc_mult_shift(&vmware_cyc2ns.cyc2ns_mul,
+ &vmware_cyc2ns.cyc2ns_shift,
+ vmware_tsc_khz,
+ NSEC_PER_MSEC, 0);
+ vmware_cyc2ns.cyc2ns_offset =
+ mul_u64_u32_shr(tsc_now, vmware_cyc2ns.cyc2ns_mul,
+ vmware_cyc2ns.cyc2ns_shift);
+
+ pv_time_ops.sched_clock = vmware_sched_clock;
+ pr_info("using sched offset of %llu ns\n",
+ vmware_cyc2ns.cyc2ns_offset);
+ }
}
#else
#define vmware_paravirt_ops_setup() do {} while (0)
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu()
After aa297292d708, there are separate native calibrations for cpu_khz and tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu() which looks in cpuid leaf 0x16 or msrs for the cpu frequency. Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and tsc_khz may start diverging. tsc_init() now does cpu_khz = x86_platform.calibrate_cpu(); tsc_khz = x86_platform.calibrate_tsc(); if (tsc_khz == 0) tsc_khz = cpu_khz; else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz) cpu_khz = tsc_khz; We want the cpu_khz and tsc_khz to be sync even if they diverge less then 10%. This patch resolves this issue by setting x86_platform.calibrate_cpu to vmware_get_tsc_khz(). Signed-off-by: Alexey Makhalov Acked-by: Alok N Kataria --- arch/x86/kernel/cpu/vmware.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c index 4e34da4b..480790f 100644 --- a/arch/x86/kernel/cpu/vmware.c +++ b/arch/x86/kernel/cpu/vmware.c @@ -83,6 +83,7 @@ static void __init vmware_platform_setup(void) vmware_tsc_khz = tsc_khz; x86_platform.calibrate_tsc = vmware_get_tsc_khz; + x86_platform.calibrate_cpu = vmware_get_tsc_khz; #ifdef CONFIG_X86_LOCAL_APIC /* Skip lapic calibration since we know the bus frequency. */ -- 2.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/32] Create an User's manual and improve development-process book
On Mon, 17 Oct 2016 14:55:37 -0200 Mauro Carvalho Chehab wrote: > This patch series continues the efforts of converting the Linux Kernel > documentation to Sphinx. hm, renaming Documentation/kernel-parameters.txt in linux-next is going to be a pain for the next two months. I have one large patch series which alters that file and I expect more will come. I guess I can cope with that, by staging these patch series after linux-next but that means that I would very much like this patch series of your to be merged *early* after the 4.9 release, please. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/32] Create an User's manual and improve development-process book
On Thu, 27 Oct 2016 13:17:33 -0700 Andrew Morton wrote: > > This patch series continues the efforts of converting the Linux Kernel > > documentation to Sphinx. > > hm, renaming Documentation/kernel-parameters.txt in linux-next is going > to be a pain for the next two months. I have one large patch series > which alters that file and I expect more will come. That's going to be a continuing hassle as we try to bring a bit of order to Documentation/, especially as so much stuff doesn't go through the docs tree. Hopefully this cycle will be done with the most obnoxious moves, anyway. > I guess I can cope with that, by staging these patch series after > linux-next but that means that I would very much like this patch series > of your to be merged *early* after the 4.9 release, please. I've been making a point of getting stuff merged early (for reasons very similar to this) for the last few cycles; will do so again. Alternatively, if you want to pass those particular patches thisaway, I can do the merge and carry them with the rest. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation/media/uapi/cec/ sporadically unnecessarily rebuilding
On 27.10.2016 16:52, Jani Nikula wrote: On Thu, 27 Oct 2016, Markus Heiser wrote: Hi Jani, Am 24.10.2016 um 11:04 schrieb Jani Nikula : I think I saw some of this in the past [1], but then couldn't reproduce it after all. Now I'm seeing it again. Sporadically Documentation/media/uapi/cec/ gets rebuilt on successive runs of make htmldocs, even when nothing has changed. Output of 'make SPHINXOPTS="-v -v" htmldocs' attached for both cases. Using Sphinx (sphinx-build) 1.4.6 I can't see what's wrong with your "rebuild" file ... loading pickled environment... done building [mo]: targets for 0 po files that are out of date building [html]: targets for 0 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found no targets are out of date. build succeeded. HTMLDocumentation/DocBook/index.html Awesome, I screwed up the file names, please check again with build-cec-rebuilding.txt <-> build-ok.txt... Ah, ok .. I can reproduce the error. It seems that sphinx's ".. toctree::" don't like it, if you build a structure where severals ".. toctrees" in the same folder include files of this folder. E.g. if you have "myfolder" with "index.rst", "f1.rst" and "f2.rst" in (content see below) and you rebuild it 5 or more times, the files f1.rst and f2.rst will sporadically rebuild. May I have time to find the bug and send a fix to sphinx. -- Markus -- -- index = .. toctree:: :maxdepth: 1 :numbered: f1 -- f1 == .. toctree:: :maxdepth: 1 :numbered: f2 -- f2 == lorem -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation/kernel-parameters.txt
On Mon, 17 Oct 2016 17:52:46 +0300 Jani Nikula wrote: > I was looking at Documentation/kernel-parameters.txt and figured that > has got to be constantly stale and incomplete. It's really data that > should be autogenerated. I don't think it should just be converted to > Sphinx as-is. So this hasn't gotten a whole lot of response, so I figure I ought to say something... I agree that it would be a good thing to automate the creation of this information. That, of course, requires that somebody do the work to actually make that happen... In the meantime, I did go ahead and apply Mauro's conversion to Sphinx because I didn't see the harm in doing so - it doesn't block the addition of a better solution once we get around to making one. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Kernel.org Helpdesk #31693] miss some documentation on https://www.kernel.org/doc/
On 2016-10-19 10:41:43, markus.hei...@darmarit.de wrote: > Hi kernel.org maintainers, > > sorry for my silly question: I miss the documentation of the > reST (sphinx) content [1] on https://www.kernel.org/doc/ Since > the DocBook files migrated to reST (sphinx) increase > the "htmldocs" at [3] are decreasing. This is now fixed -- please behold: https://www.kernel.org/doc/html/latest/ Regards, -- Konstantin Ryabitsev Senior Systems Administrator Linux Foundation Collab Projects Montréal, Québec -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu()
On Thu, 27 Oct 2016, Alexey Makhalov wrote:
> [RESEND PATCH 1/3] x86/vmware: Use tsc_khz value for calibrate_cpu()
Please don't do that. RESEND is a keyword, when the same patch (series) is
sent again without any modification vs. the first patch (series). A
possible reason to do so is when a patch (series) fell through the cracks
and the author wants to bring it to attention again for the next merge
window.
If you send an updated patch (series) then please add Vn after PATCH, where
n is the version number of the patch (series).
While at it, please add a cover letter [PATCH Vn 0/n] the next time you send a
patch series. git send-email supports that.
> After aa297292d708, there are separate native calibrations for cpu_khz and
What is aa297292d708?
Please make that:
commit aa297292d708 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via
CPUID") .
> tsc_khz. The code sets x86_platform.calibrate_cpu to native_calibrate_cpu()
> which looks in cpuid leaf 0x16 or msrs for the cpu frequency.
Which code? And what has the leaf and the msrs to do with your patch?
> Since we keep the tsc_khz constant (even after vmotion), the cpu_khz and
> tsc_khz may start diverging.
Now you talk about vmware related stuff, right?
> tsc_init() now does
>
> cpu_khz = x86_platform.calibrate_cpu();
> tsc_khz = x86_platform.calibrate_tsc();
> if (tsc_khz == 0)
> tsc_khz = cpu_khz;
> else if (abs(cpu_khz - tsc_khz) * 10 > tsc_khz)
> cpu_khz = tsc_khz;
And here you copy from the referenced commit. How is that helpful?
>
> We want the cpu_khz and tsc_khz to be sync even if they diverge less then
> 10%.
We? We as kernel developers, users, guest running in vmware
> This patch resolves this issue by setting x86_platform.calibrate_cpu to
"This patch" is just bad. We already know that this is a patch, otherwise
you wouldn't have sent it as a patch.
"this issue" - which issue? Your explanation above does not tell anything
what the issue is.
> vmware_get_tsc_khz().
Here is an example of a proper changelog for this (except for my potential
misinterpretation of the crypto message above):
Commit aa297292d708 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via
CPUID") seperated the calibration mechanisms for cpu_khz and tsc_khz.
In a vmware guest this change can lead to divergence between the tsc and
the cpu frequency, because .This causes .
Due to the internal design of the vmware hypervisor it's required to keep tsc and cpu frequency in sync.
Solve this by overriding the x86 platform cpu calibration callback with the
vmware specific tsc calibration function.
So this describes very clearly:
1) The change which causes the problem
2) The problem itself and the resulting malfunction
3) What needs to be achieved to solve the problem
4) A short explanation what the solution is
Documentation/SubmittingPatches has further information about proper change
logs.
> @@ -83,6 +83,7 @@ static void __init vmware_platform_setup(void)
>
> vmware_tsc_khz = tsc_khz;
> x86_platform.calibrate_tsc = vmware_get_tsc_khz;
A comment explaining why you set the cpu calibration to vmware_get_tsc_khz
might be helpful for casual readers and yourself when you look at that code
5 month from now.
> + x86_platform.calibrate_cpu = vmware_get_tsc_khz;
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 3/3] x86/vmware: Add paravirt sched clock
On Thu, 27 Oct 2016, Alexey Makhalov wrote:
> Set pv_time_ops.sched_clock to vmware_sched_clock().
Please do not describe WHAT the patch does, describe why. Describe the
problem you are solving. I can see from the patch
> + pv_time_ops.sched_clock = vmware_sched_clock;
that you set pv_time_ops.sched_clock to vmware_sched_clock().
> It is simplified
> version of native_sched_clock() without ring buffer of mult/shift/offset
> triplets and preempt toggling.
-ENOPARSE
> Since VMware hypervisor provides constant tsc we can use constant
> mult/shift/offset triplet calculated at boot time.
So now you start to explain something which is understandable
> no-vmw-sched-clock kernel parameter is added to disable the paravirt
> sched clock.
I give you another example:
The default sched_clock() implementation is native_sched_clock(). It
contains code to handle non constant frequency TSCs, which creates
overhead for systems with constant frequency TSCs.
The vmware hypervisor guarantees a constant frequency TSC, so
native_sched_clock() is not required and slower than a dedicated function
which operates with one time calculated conversion factors.
Calculate the conversion factors at boot time from the tsc frequency and
install an optimized sched_clock() function via paravirt ops.
The paravirtualized clock can be disabled on the kernel command line with
the new 'no-vmw-sched-clock' option.
Can you see the difference and can you spot the structure similar to the
example I gave you before?
> +static unsigned long long vmware_sched_clock(void)
> +{
> + unsigned long long ns;
> +
> + ns = mul_u64_u32_shr(rdtsc(), vmware_cyc2ns.cyc2ns_mul,
> + vmware_cyc2ns.cyc2ns_shift);
> + ns -= vmware_cyc2ns.cyc2ns_offset;
> + return ns;
> +}
> +
> static void __init vmware_paravirt_ops_setup(void)
> {
> pv_info.name = "VMware hypervisor";
> pv_cpu_ops.io_delay = paravirt_nop;
> +
> + if (vmware_tsc_khz && vmw_sched_clock) {
> + unsigned long long tsc_now = rdtsc();
> +
> + clocks_calc_mult_shift(&vmware_cyc2ns.cyc2ns_mul,
> +&vmware_cyc2ns.cyc2ns_shift,
> +vmware_tsc_khz,
> +NSEC_PER_MSEC, 0);
> + vmware_cyc2ns.cyc2ns_offset =
> + mul_u64_u32_shr(tsc_now, vmware_cyc2ns.cyc2ns_mul,
> + vmware_cyc2ns.cyc2ns_shift);
> +
> + pv_time_ops.sched_clock = vmware_sched_clock;
> + pr_info("using sched offset of %llu ns\n",
> + vmware_cyc2ns.cyc2ns_offset);
If you either do:
if (!vmware_tsc_khz || !vmw_sched_clock)
return;
or
if (vmware_tsc_khz && vmw_sched_clock)
setup_sched_clock();
and split out the code into a seperate function then you spare one
indentation level and some of these hard to read line breaks.
Hint:
static void setup_sched_clock(void)
{
struct cyc2ns_data *d = &vmware_cyc2ns;
clocks_calc_mult_shift(&d->cyc2ns_mul, &d->cyc32ns_shift,
vmware_tsc_khz, NSEC_PER_MSEC, 0);
reduces the lenght of the arguments significantly and makes this stuff sane
to read.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] hwmon: (mcp3021) rework for DT support
Support setting the reference voltage from the device tree.
Rework of driver structure, put chip specific data in a separate
structure and assign it depending on device id from platform data or
DT match.
Signed-off-by: Clemens Gruber
---
Documentation/hwmon/mcp3021 | 6 ++
drivers/hwmon/mcp3021.c | 145
2 files changed, 111 insertions(+), 40 deletions(-)
diff --git a/Documentation/hwmon/mcp3021 b/Documentation/hwmon/mcp3021
index 74a6b72..be252b7 100644
--- a/Documentation/hwmon/mcp3021
+++ b/Documentation/hwmon/mcp3021
@@ -12,6 +12,7 @@ Supported chips:
Authors:
Mingkai Hu
Sven Schuchmann
+ Clemens Gruber
Description
---
@@ -27,3 +28,8 @@ Communication to the MCP3021/MCP3221 is performed using a
2-wire I2C
compatible interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are
available. The default I2C device address is 0x4d (contact the Microchip
factory for additional address options).
+
+The reference voltage used in the conversion can be set through platform data
+in millivolt (for backwards compatibility) or via device tree in microvolt.
+Please refer to Documentation/devicetree/bindings/i2c/mcp3021.txt for details
+about the device tree bindings.
diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index 972444a..a8cf97f 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -4,6 +4,7 @@
* Copyright (C) 2008-2009, 2012 Freescale Semiconductor, Inc.
* Author: Mingkai Hu
* Reworked by Sven Schuchmann
+ * Copyright (C) 2016 Clemens Gruber
*
* This driver export the value of analog input voltage to sysfs, the
* voltage unit is mV. Through the sysfs interface, lm-sensors tool
@@ -22,37 +23,56 @@
#include
#include
#include
+#include
+#include
-/* Vdd info */
+/* Vdd / reference voltage in millivolt */
#define MCP3021_VDD_MAX5500
#define MCP3021_VDD_MIN2700
-#define MCP3021_VDD_REF3300
-
-/* output format */
-#define MCP3021_SAR_SHIFT 2
-#define MCP3021_SAR_MASK 0x3ff
-#define MCP3021_OUTPUT_RES 10 /* 10-bit resolution */
-
-#define MCP3221_SAR_SHIFT 0
-#define MCP3221_SAR_MASK 0xfff
-#define MCP3221_OUTPUT_RES 12 /* 12-bit resolution */
+#define MCP3021_VDD_DEFAULT3300
enum chips {
mcp3021,
mcp3221
};
+struct mcp3021_chip_info {
+ u16 sar_shift;
+ u16 sar_mask;
+ u8 output_res;
+};
+
/*
* Client data (each client gets its own)
*/
struct mcp3021_data {
struct device *hwmon_dev;
- u32 vdd;/* device power supply */
- u16 sar_shift;
- u16 sar_mask;
- u8 output_res;
+ const struct mcp3021_chip_info *chip_info;
+ u32 vdd; /* device power supply and reference voltage in millivolt */
};
+static const struct mcp3021_chip_info mcp3021_chip_info_tbl[] = {
+ [mcp3021] = {
+ .sar_shift = 2,
+ .sar_mask = 0x3ff,
+ .output_res = 10, /* 10-bit resolution */
+ },
+ [mcp3221] = {
+ .sar_shift = 0,
+ .sar_mask = 0xfff,
+ .output_res = 12, /* 12-bit resolution */
+ },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id of_mcp3021_match[] = {
+ { .compatible = "microchip,mcp3021", .data = (void *)mcp3021 },
+ { .compatible = "microchip,mcp3221", .data = (void *)mcp3221 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, of_mcp3021_match);
+#endif
+
static int mcp3021_read16(struct i2c_client *client)
{
struct mcp3021_data *data = i2c_get_clientdata(client);
@@ -73,14 +93,15 @@ static int mcp3021_read16(struct i2c_client *client)
* The ten-bit output code is composed of the lower 4-bit of the
* first byte and the upper 6-bit of the second byte.
*/
- reg = (reg >> data->sar_shift) & data->sar_mask;
+ reg = (reg >> data->chip_info->sar_shift) & data->chip_info->sar_mask;
return reg;
}
static inline u16 volts_from_reg(struct mcp3021_data *data, u16 val)
{
- return DIV_ROUND_CLOSEST(data->vdd * val, 1 << data->output_res);
+ return DIV_ROUND_CLOSEST(data->vdd * val,
+1 << data->chip_info->output_res);
}
static ssize_t show_in_input(struct device *dev, struct device_attribute *attr,
@@ -101,44 +122,85 @@ static ssize_t show_in_input(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR(in0_input, S_IRUGO, show_in_input, NULL);
-static int mcp3021_probe(struct i2c_client *client,
+#ifdef CONFIG_OF
+static int mcp3021_probe_dt(struct i2c_client *client,
const struct i2c_device_id *id)
{
- int err;
- struct mcp3021_data *data = NULL;
+ struct mcp3021_data *data = i2c_get_clientdata(client);
+ struct device_node *np = client->dev.of_node;
+ const struct of_device_id *match;
+ int de
[PATCH v2 3/3] hwmon: (mcp3021) replace S_IRUGO with 0444
Replace S_IRUGO with the better readable 0444. This fixes a checkpatch warning. Signed-off-by: Clemens Gruber --- drivers/hwmon/mcp3021.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c index a8cf97f..97c832d 100644 --- a/drivers/hwmon/mcp3021.c +++ b/drivers/hwmon/mcp3021.c @@ -120,7 +120,7 @@ static ssize_t show_in_input(struct device *dev, struct device_attribute *attr, return sprintf(buf, "%d\n", in_input); } -static DEVICE_ATTR(in0_input, S_IRUGO, show_in_input, NULL); +static DEVICE_ATTR(in0_input, 0444, show_in_input, NULL); #ifdef CONFIG_OF static int mcp3021_probe_dt(struct i2c_client *client, -- 2.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/32] Create an User's manual and improve development-process book
Em Thu, 27 Oct 2016 14:36:07 -0600 Jonathan Corbet escreveu: > On Thu, 27 Oct 2016 13:17:33 -0700 > Andrew Morton wrote: > > > > This patch series continues the efforts of converting the Linux Kernel > > > documentation to Sphinx. > > > > hm, renaming Documentation/kernel-parameters.txt in linux-next is going > > to be a pain for the next two months. I have one large patch series > > which alters that file and I expect more will come. > > That's going to be a continuing hassle as we try to bring a bit of order > to Documentation/, especially as so much stuff doesn't go through the docs > tree. Hopefully this cycle will be done with the most obnoxious moves, > anyway. Perhaps you could use git filter to handle it, with something like (untested): $ git filter-branch -f --tree-filter 'for i in $(git grep -l kernel-parameters.txt); do sed s,Documentation/kernel-parameters.txt,Documentation/admin-guide/kernel-parameters.rst,g $i >a && mv a $i; done' some_origin_branch.. > > I guess I can cope with that, by staging these patch series after > > linux-next but that means that I would very much like this patch series > > of your to be merged *early* after the 4.9 release, please. > > I've been making a point of getting stuff merged early (for reasons very > similar to this) for the last few cycles; will do so again. > > Alternatively, if you want to pass those particular patches thisaway, I > can do the merge and carry them with the rest. > > jon Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] hwmon: (mcp3021) add devicetree bindings documentation
Document the devicetree bindings for the Microchip MCP3021/3221.
Signed-off-by: Clemens Gruber
---
Documentation/devicetree/bindings/hwmon/mcp3021.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/mcp3021.txt
diff --git a/Documentation/devicetree/bindings/hwmon/mcp3021.txt
b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
new file mode 100644
index 000..294318b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/mcp3021.txt
@@ -0,0 +1,21 @@
+mcp3021 properties
+
+Required properties:
+- compatible: Must be one of the following:
+ - "microchip,mcp3021" for mcp3021
+ - "microchip,mcp3221" for mcp3221
+- reg: I2C address
+
+Optional properties:
+
+- reference-voltage-microvolt
+ Reference voltage in microvolt (uV)
+
+Example:
+
+mcp3021@4d {
+ compatible = "microchip,mcp3021";
+ reg = <0x4d>;
+
+ reference-voltage-microvolt = <450>; /* 4.5 V */
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/37] Documentation/BUG-HUNTING: convert to ReST markup
On Wed, 26 Oct 2016 21:14:00 -0200 Mauro Carvalho Chehab wrote: > On a very quick look on the document, it seems that the legacy info > there are at this section of the document: > > - Finding it the old way > > IMHO, we can strip that section completely. At least we agree on that part. > The git bisect section is too small to my taste, as, IMHO, the best would > be if it would be telling about the process, e. g. pointing or C/C the > contents of articles like: Too small? Mauro, it's six lines, one of which reads, in its entirety, "have fun" :) The stuff you propose adding is good, but is it really better than saying "read the git-bisect man page"? That page is pretty clear, especially by the standard of git man pages :) > What do you think about the patch below? I double-checked the > "Fixing the bug" part, and what is there makes sense for me. > I changed it a little bit to make it easier for newbies. Not sure; when's the last time the objdump stuff was really relevant to you? I can certainly see the value of a proper "how to debug the kernel" guide, talking about the *many* facilities we have for kernel debugging at this point. This document isn't that. I've dropped my deletion patch from the series for now (will likely apply the rest shortly), but I still think we need to be more willing to dump old stuff that we can't maintain properly. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] workqueue documentation reformatted
On Mon, 24 Oct 2016 20:04:00 +0200 Silvio Fricke wrote: > v3 -> v4: > * The outdated misc reference in D/index.rst was not removed > > v2 -> v3: > * Introduce a core-api folder > * move workqueue.rst to core-api > * reflect change in 00-index and workqueue.h OK, we're getting there. I'd like to apply this, but... - I can't get it to apply; what kernel did you do this set against? Can I get it done against docs-next, by any chance? - Part 2 (the workqueue.h changes) are probably best routed through Tejun's tree. They are independent of the rest anyway. - Don't forget to adjust MAINTAINERS for the new location for the workqueue doc. So can I bug you for just one more iteration on this? Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: update intro of documentation
On Mon, 24 Oct 2016 14:25:27 +0200 Greg KH wrote: > I don't have any objection to the changes, please take them through your > documentation tree: I have now done so. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/37] Documentation/BUG-HUNTING: convert to ReST markup
Em Thu, 27 Oct 2016 16:51:22 -0600 Jonathan Corbet escreveu: > On Wed, 26 Oct 2016 21:14:00 -0200 > Mauro Carvalho Chehab wrote: > > > On a very quick look on the document, it seems that the legacy info > > there are at this section of the document: > > > > - Finding it the old way > > > > IMHO, we can strip that section completely. > > At least we agree on that part. > > > The git bisect section is too small to my taste, as, IMHO, the best would > > be if it would be telling about the process, e. g. pointing or C/C the > > contents of articles like: > > Too small? Mauro, it's six lines, one of which reads, in its entirety, > "have fun" :) Heh ;) > The stuff you propose adding is good, but is it really > better than saying "read the git-bisect man page"? That page is pretty > clear, especially by the standard of git man pages :) Yeah, git bisect man page is good, but let me take one step back and explain my selfish desire on having it documented, and check if we're at the same page ;-) The main reason I jumped into user and process doc conversion is that, every time someone has problems reporting bugs or submitting patches, I need to seek at the Internet and point to some place that would help him to proceed. Ok, I answer the guy to read the man page, but this could sound unpolite ;) Also, a newbie may not have it installed, or have some other problem, with would take me more time to explain what I meant. So, I prefer to point them to: read this URL: http://foo/doc, as I can verify what's there and be sure that it will solve the issue. So, at least the way I see, I prefer to have a quick and dirty instructions there, with some html references pointing to more detailed explanations, as I know that the bare minimum is documented, and if the user still has doubts, he can jump into a detailed explanation. > > > What do you think about the patch below? I double-checked the > > "Fixing the bug" part, and what is there makes sense for me. > > I changed it a little bit to make it easier for newbies. > > Not sure; when's the last time the objdump stuff was really relevant to > you? In my case, I always compile kernels with DEBUG_INFO enabled, so I only use gdb to get the source lines when an OOPS happens. Yet, from time to time, ARM users report bugs there, with Kernels compiled without DEBUG_INFO. For such users, objdump is interesting. > I can certainly see the value of a proper "how to debug the kernel" > guide, talking about the *many* facilities we have for kernel debugging at > this point. This document isn't that. Good point. Do you have any suggestions about what else should be included? Looking on what we've converted already, IMHO, we could put on such guide: https://mchehab.fedorapeople.org/kernel_docs/admin-guide/dynamic-debug-howto.html https://mchehab.fedorapeople.org/kernel_docs/dev-tools/kasan.html And perhaps add a guide about the Kernel Hacking options at the Kconfig menu. Anything else? I can try to draft something to add there after KS. > I've dropped my deletion patch from the series for now (will likely apply > the rest shortly), but I still think we need to be more willing to dump old > stuff that we can't maintain properly. OK, thanks! The rest are OK from my side. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ABI conversion to ReST - Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Hi Jon, Em Sun, 23 Oct 2016 09:20:00 -0200 Mauro Carvalho Chehab escreveu: > Em Sat, 22 Oct 2016 08:56:29 -0200 > Mauro Carvalho Chehab escreveu: > > > How many special-case commands are we going to need to run? Does it > > > really need to go beyond what parse-headers is doing now? > > > > Right now, we have actually 2 such cases: kernel-doc and parse-headers. > > > > I also use a set of perl scripts that I manually run, on each Kernel > > version, to update the cards list of several drivers. It is a total of > > 9 such scripts. > > I ended by adding a few more scripts, as ivtv, tm6000 and gspca > cardlists were missing. As result, all three had some documentation > gaps. > > As an example of such scripts, I added a PoC patch at my development > tree, at the lkml-books-v2 branch: > > https://git.linuxtv.org/mchehab/experimental.git/log/?h=lkml-books-v2 > > Patch follows. Today, I converted the EDAC documentation to ReST, but there is one left over: the EDAC documentation under Documentation/ABI. I suspect this is something for discussions at the KS too, but let me put some insights about the ABI directory. It is probably worth to add at the admin's guide or as a separate guide at least for configfs and sysfs, but: 1) manually converting all those files would be very painful; 2) a patch series with such conversion would be very hard to be merged, as it would likely cause all sorts of conflicts with maintainers' trees that update it. 2) the actual format there is a database, with is not too nice for an Admin's guide; So, if we're willing to create a guide with the userspace API defined there, it is probably better to write a parser script that would convert it into a documentation, without requiring any changes there. As defined at Documentation/ABI/README, this is actually a database with those fields: What, Date, KernelVersion, Contact, Description and Users. An user-face documentation would probably require only a few of those fields (like What and Description), but the entries should be probably sorted by the What field. So, I suspect it wouldn't be hard to write a perl script to parse it and generate an ABI guide. On the other hand, we might need to fix some documents, if the parser fails due to some typo. Comments? Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kernel.org Helpdesk #31693] miss some documentation on https://www.kernel.org/doc/
Am 27.10.2016 um 23:12 schrieb Konstantin Ryabitsev via RT : > On 2016-10-19 10:41:43, markus.hei...@darmarit.de wrote: >> Hi kernel.org maintainers, >> >> sorry for my silly question: I miss the documentation of the >> reST (sphinx) content [1] on https://www.kernel.org/doc/ Since >> the DocBook files migrated to reST (sphinx) increase >> the "htmldocs" at [3] are decreasing. > > This is now fixed -- please behold: > https://www.kernel.org/doc/html/latest/ Great, thanks a lot! --Markus-- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kernel.org Helpdesk #31693] miss some documentation on https://www.kernel.org/doc/
Am 27.10.2016 um 23:12 schrieb Konstantin Ryabitsev via RT : > On 2016-10-19 10:41:43, markus.hei...@darmarit.de wrote: >> Hi kernel.org maintainers, >> >> sorry for my silly question: I miss the documentation of the >> reST (sphinx) content [1] on https://www.kernel.org/doc/ Since >> the DocBook files migrated to reST (sphinx) increase >> the "htmldocs" at [3] are decreasing. > > This is now fixed -- please behold: > https://www.kernel.org/doc/html/latest/ Great, thanks a lot! --Markus-- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation/kernel-parameters.txt
On Thu, 27 Oct 2016, Jonathan Corbet wrote: > On Mon, 17 Oct 2016 17:52:46 +0300 > Jani Nikula wrote: > >> I was looking at Documentation/kernel-parameters.txt and figured that >> has got to be constantly stale and incomplete. It's really data that >> should be autogenerated. I don't think it should just be converted to >> Sphinx as-is. > > So this hasn't gotten a whole lot of response, so I figure I ought to say > something... I agree that it would be a good thing to automate the > creation of this information. That, of course, requires that somebody do > the work to actually make that happen... I was hoping on some feedback on the approaches themselves... but I guess that'd first require patches people could then vehemently oppose. :p > In the meantime, I did go ahead > and apply Mauro's conversion to Sphinx because I didn't see the harm in > doing so - it doesn't block the addition of a better solution once we get > around to making one. Mauro's conversion that just puts all the parameter descriptions into a preformatted text block seems fine; I did intend to say it's not worth the effort to go through it all and manually convert to some nice formatting. (Of course, that is not at all what I wrote. [1]) BR, Jani. [1] https://en.wikipedia.org/wiki/Wiio%27s_laws -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ABI conversion to ReST - Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
On Thu, Oct 27, 2016 at 10:34:05PM -0200, Mauro Carvalho Chehab wrote: > As defined at Documentation/ABI/README, this is actually a database > with those fields: > > What, Date, KernelVersion, Contact, Description and Users. > > An user-face documentation would probably require only a few of those > fields (like What and Description), but the entries should be > probably sorted by the What field. > > So, I suspect it wouldn't be hard to write a perl script to parse it > and generate an ABI guide. On the other hand, we might need to fix > some documents, if the parser fails due to some typo. That sounds like a good plan to me, and patches to fix up typos to keep things being able to be parsed properly should be fine. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
