* Re: [PATCH v3 01/10] Documentations: dt-bindings: Add documents of generic PECI bus, adapter and client drivers
From: Jae Hyun Yoo @ 2018-04-16 23:06 UTC (permalink / raw)
To: Rob Herring
Cc: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery, linux-hwmon, devicetree,
linux-doc, openbmc, linux-kernel, linux-arm-kernel
In-Reply-To: <20180416175936.4vcse73mrnyk242m@rob-hp-laptop>
Hi Rob,
Thanks for sharing your time. Please see my answers inline.
On 4/16/2018 10:59 AM, Rob Herring wrote:
> On Tue, Apr 10, 2018 at 11:32:03AM -0700, Jae Hyun Yoo wrote:
>> This commit adds documents of generic PECI bus, adapter and client drivers.
>
> "dt-bindings: ..." for the subject prefix please.
>
Sure, I'll change the subject.
>>
>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
>> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
>> Reviewed-by: James Feist <james.feist@linux.intel.com>
>> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
>> Cc: Alan Cox <alan@linux.intel.com>
>> Cc: Andrew Jeffery <andrew@aj.id.au>
>> Cc: Andrew Lunn <andrew@lunn.ch>
>> Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Fengguang Wu <fengguang.wu@intel.com>
>> Cc: Greg KH <gregkh@linuxfoundation.org>
>> Cc: Guenter Roeck <linux@roeck-us.net>
>> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
>> Cc: Jean Delvare <jdelvare@suse.com>
>> Cc: Joel Stanley <joel@jms.id.au>
>> Cc: Julia Cartwright <juliac@eso.teric.us>
>> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
>> Cc: Milton Miller II <miltonm@us.ibm.com>
>> Cc: Pavel Machek <pavel@ucw.cz>
>> Cc: Randy Dunlap <rdunlap@infradead.org>
>> Cc: Stef van Os <stef.van.os@prodrive-technologies.com>
>> Cc: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
>> ---
>> .../devicetree/bindings/peci/peci-adapter.txt | 23 ++++++++++++++++++++
>> .../devicetree/bindings/peci/peci-bus.txt | 15 +++++++++++++
>> .../devicetree/bindings/peci/peci-client.txt | 25 ++++++++++++++++++++++
>
> This should be all one document.
>
Okay. I'll combine them into one document.
>> 3 files changed, 63 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/peci/peci-adapter.txt
>> create mode 100644 Documentation/devicetree/bindings/peci/peci-bus.txt
>> create mode 100644 Documentation/devicetree/bindings/peci/peci-client.txt
>>
>> diff --git a/Documentation/devicetree/bindings/peci/peci-adapter.txt b/Documentation/devicetree/bindings/peci/peci-adapter.txt
>> new file mode 100644
>> index 000000000000..9221374f6b11
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/peci/peci-adapter.txt
>> @@ -0,0 +1,23 @@
>> +Generic device tree configuration for PECI adapters.
>> +
>> +Required properties:
>> +- compatible : Should contain hardware specific definition strings that can
>> + match an adapter driver implementation.
>> +- reg : Should contain PECI controller registers location and length.
>
> No need for these 2 here.
>
Will drop these 2.
>> +- #address-cells : Should be <1>.
>> +- #size-cells : Should be <0>.
>
> Some details on the addressing for PECI would be good.
>
It is for the PECI client address. Will add details.
>> +
>> +Example:
>> + peci: peci@10000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10000000 0x1000>;
>> +
>
> This part of the example is not relevant. Just start with the adapter
> node.
>
Will remove that part. Thanks!
>> + peci0: peci-bus@0 {
>> + compatible = "soc,soc-peci";
>> + reg = <0x0 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>> diff --git a/Documentation/devicetree/bindings/peci/peci-bus.txt b/Documentation/devicetree/bindings/peci/peci-bus.txt
>> new file mode 100644
>> index 000000000000..90bcc791ccb0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/peci/peci-bus.txt
>> @@ -0,0 +1,15 @@
>> +Generic device tree configuration for PECI buses.
>> +
>> +Required properties:
>> +- compatible : Should be "simple-bus".
>
> I don't understand what this has to do with PECI? "simple-bus" already
> has a defined meaning.
>
Maybe I'm wrong but I intended to show this node is an umbrella node of
a PECI bus subsystem. What should I use then?
>> +- #address-cells : Should be <1>.
>> +- #size-cells : Should be <1>.
>> +- ranges : Should contain PECI controller registers ranges.
>> +
>> +Example:
>> + peci: peci@10000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x10000000 0x1000>;
>> + };
>> diff --git a/Documentation/devicetree/bindings/peci/peci-client.txt b/Documentation/devicetree/bindings/peci/peci-client.txt
>> new file mode 100644
>> index 000000000000..8e2bfd8532f6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/peci/peci-client.txt
>> @@ -0,0 +1,25 @@
>> +Generic device tree configuration for PECI clients.
>> +
>> +Required properties:
>> +- compatible : Should contain target device specific definition strings that can
>> + match a client driver implementation.
>
> Bindings are for h/w, not client drivers.
>
> How are PECI devices defined?
>
Got it. I'll correct the description. PECI client device is Intel CPU
which is connected through a PECI bus.
>> +- reg : Should contain address of a client CPU. Address range of CPU
>> + clients is starting from 0x30 based on PECI specification.
>> + <0x30> .. <0x37> (depends on the PECI_OFFSET_MAX definition)
>
> 8 devices should be enough for anyone...
>
> Where is PECI_OFFSET_MAX defined?
>
PECI_OFFSET_MAX is defined in include/linux/peci.h based on the maximum
CPU numbers of the current IA generation. I'll remove the unnecessary
details. A setting out of range would be handled accordingly in kernel.
>> +
>> +Example:
>> + peci-bus@0 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + < more properties >
>> +
>> + function@cpu0 {
>
> Not a valid node name. "function@30" is what it probably should be. For
> a new bus you can define unit-address format you like, but it must be
> based on the contents of reg. However, it doesn't look like you should
> create anything special here.
>
Got it. I'll fix these node name like function@30 and function@31.
Thanks a lot for your comments!
-Jae
>> + compatible = "device,function";
>> + reg = <0x30>;
>> + };
>> +
>> + function@cpu1 {
>> + compatible = "device,function";
>> + reg = <0x31>;
>> + };
>> + };
>> --
>> 2.16.2
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] docs: kernel-parameters.txt: Fix whitespace
From: Randy Dunlap @ 2018-04-16 22:03 UTC (permalink / raw)
To: Thymo van Beers, corbet; +Cc: linux-doc, linux-kernel
In-Reply-To: <20180416214939.GA11304@thinkpad>
On 04/16/18 14:49, Thymo van Beers wrote:
> Some lines used spaces instead of tabs at line start.
> This can cause mangled lines in editors due to inconsistency.
>
> Replace spaces for tabs where appropriate.
>
> Signed-off-by: Thymo van Beers <thymovanbeers@gmail.com>
> ---
> Changes in v2:
> - Rebase against docs-next
> - Fix indentation modifications
>
> Documentation/admin-guide/kernel-parameters.txt | 136 ++++++++++++------------
> 1 file changed, 68 insertions(+), 68 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 3487be79847c..f625f65c286f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
Most of the patch is OK IMO, but not the intel_pstate part:
The 2-space extra indents work fine here, while the extra tab makes a lot of the
lines go beyond the 80-column mark.
> @@ -1650,39 +1650,39 @@
> 0 disables intel_idle and fall back on acpi_idle.
> 1 to 9 specify maximum depth of C-state.
>
> - intel_pstate= [X86]
> - disable
> - Do not enable intel_pstate as the default
> - scaling driver for the supported processors
> - passive
> - Use intel_pstate as a scaling driver, but configure it
> - to work with generic cpufreq governors (instead of
> - enabling its internal governor). This mode cannot be
> - used along with the hardware-managed P-states (HWP)
> - feature.
> - force
> - Enable intel_pstate on systems that prohibit it by default
> - in favor of acpi-cpufreq. Forcing the intel_pstate driver
> - instead of acpi-cpufreq may disable platform features, such
> - as thermal controls and power capping, that rely on ACPI
> - P-States information being indicated to OSPM and therefore
> - should be used with caution. This option does not work with
> - processors that aren't supported by the intel_pstate driver
> - or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> - no_hwp
> - Do not enable hardware P state control (HWP)
> - if available.
> - hwp_only
> - Only load intel_pstate on systems which support
> - hardware P state control (HWP) if available.
> - support_acpi_ppc
> - Enforce ACPI _PPC performance limits. If the Fixed ACPI
> - Description Table, specifies preferred power management
> - profile as "Enterprise Server" or "Performance Server",
> - then this feature is turned on by default.
> - per_cpu_perf_limits
> - Allow per-logical-CPU P-State performance control limits using
> - cpufreq sysfs interface
> + intel_pstate= [X86]
> + disable
> + Do not enable intel_pstate as the default
> + scaling driver for the supported processors
> + passive
> + Use intel_pstate as a scaling driver, but configure it
> + to work with generic cpufreq governors (instead of
> + enabling its internal governor). This mode cannot be
> + used along with the hardware-managed P-states (HWP)
> + feature.
> + force
> + Enable intel_pstate on systems that prohibit it by default
> + in favor of acpi-cpufreq. Forcing the intel_pstate driver
> + instead of acpi-cpufreq may disable platform features, such
> + as thermal controls and power capping, that rely on ACPI
> + P-States information being indicated to OSPM and therefore
> + should be used with caution. This option does not work with
> + processors that aren't supported by the intel_pstate driver
> + or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> + no_hwp
> + Do not enable hardware P state control (HWP)
> + if available.
> + hwp_only
> + Only load intel_pstate on systems which support
> + hardware P state control (HWP) if available.
> + support_acpi_ppc
> + Enforce ACPI _PPC performance limits. If the Fixed ACPI
> + Description Table, specifies preferred power management
> + profile as "Enterprise Server" or "Performance Server",
> + then this feature is turned on by default.
> + per_cpu_perf_limits
> + Allow per-logical-CPU P-State performance control limits using
> + cpufreq sysfs interface
>
> intremap= [X86-64, Intel-IOMMU]
> on enable Interrupt Remapping (default)
> @@ -2027,7 +2027,7 @@
> * [no]ncqtrim: Turn off queued DSM TRIM.
>
> * nohrst, nosrst, norst: suppress hard, soft
> - and both resets.
> + and both resets.
I would leave that line above indented like the one after "rstonce" below.
>
> * rstonce: only attempt one reset during
> hot-unplug link recovery
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] docs: kernel-parameters.txt: Fix whitespace
From: Thymo van Beers @ 2018-04-16 21:49 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, linux-kernel
Some lines used spaces instead of tabs at line start.
This can cause mangled lines in editors due to inconsistency.
Replace spaces for tabs where appropriate.
Signed-off-by: Thymo van Beers <thymovanbeers@gmail.com>
---
Changes in v2:
- Rebase against docs-next
- Fix indentation modifications
Documentation/admin-guide/kernel-parameters.txt | 136 ++++++++++++------------
1 file changed, 68 insertions(+), 68 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 3487be79847c..f625f65c286f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -106,11 +106,11 @@
use by PCI
Format: <irq>,<irq>...
- acpi_mask_gpe= [HW,ACPI]
+ acpi_mask_gpe= [HW,ACPI]
Due to the existence of _Lxx/_Exx, some GPEs triggered
by unsupported hardware/firmware features can result in
- GPE floodings that cannot be automatically disabled by
- the GPE dispatcher.
+ GPE floodings that cannot be automatically disabled by
+ the GPE dispatcher.
This facility can be used to prevent such uncontrolled
GPE floodings.
Format: <int>
@@ -472,10 +472,10 @@
for platform specific values (SB1, Loongson3 and
others).
- ccw_timeout_log [S390]
+ ccw_timeout_log [S390]
See Documentation/s390/CommonIO for details.
- cgroup_disable= [KNL] Disable a particular controller
+ cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
The effects of cgroup_disable=foo are:
- foo isn't auto-mounted if you mount all cgroups in
@@ -641,8 +641,8 @@
hvc<n> Use the hypervisor console device <n>. This is for
both Xen and PowerPC hypervisors.
- If the device connected to the port is not a TTY but a braille
- device, prepend "brl," before the device type, for instance
+ If the device connected to the port is not a TTY but a braille
+ device, prepend "brl," before the device type, for instance
console=brl,ttyS0
For now, only VisioBraille is supported.
@@ -662,7 +662,7 @@
consoleblank= [KNL] The console blank (screen saver) timeout in
seconds. A value of 0 disables the blank timer.
- Defaults to 0.
+ Defaults to 0.
coredump_filter=
[KNL] Change the default value for
@@ -730,7 +730,7 @@
or memory reserved is below 4G.
cryptomgr.notests
- [KNL] Disable crypto self-tests
+ [KNL] Disable crypto self-tests
cs89x0_dma= [HW,NET]
Format: <dma>
@@ -746,7 +746,7 @@
Format: <port#>,<type>
See also Documentation/input/devices/joystick-parport.rst
- ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
+ ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See
Documentation/admin-guide/dynamic-debug-howto.rst for
details. Deprecated, see dyndbg.
@@ -833,7 +833,7 @@
causing system reset or hang due to sending
INIT from AP to BSP.
- disable_ddw [PPC/PSERIES]
+ disable_ddw [PPC/PSERIES]
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
@@ -1188,7 +1188,7 @@
parameter will force ia64_sal_cache_flush to call
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
- forcepae [X86-32]
+ forcepae [X86-32]
Forcefully enable Physical Address Extension (PAE).
Many Pentium M systems disable PAE but may have a
functionally usable PAE implementation.
@@ -1247,7 +1247,7 @@
gamma= [HW,DRM]
- gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
+ gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
Format: off | on
default: on
@@ -1341,11 +1341,11 @@
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
- hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
- terminal devices. Valid values: 0..8
- hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
- If specified, z/VM IUCV HVC accepts connections
- from listed z/VM user IDs only.
+ hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
+ terminal devices. Valid values: 0..8
+ hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
+ If specified, z/VM IUCV HVC accepts connections
+ from listed z/VM user IDs only.
keep_bootcon [KNL]
Do not unregister boot console at start. This is only
@@ -1353,11 +1353,11 @@
between unregistering the boot console and initializing
the real console.
- i2c_bus= [HW] Override the default board specific I2C bus speed
- or register an additional I2C bus that is not
- registered from board initialization code.
- Format:
- <bus_id>,<clkrate>
+ i2c_bus= [HW] Override the default board specific I2C bus speed
+ or register an additional I2C bus that is not
+ registered from board initialization code.
+ Format:
+ <bus_id>,<clkrate>
i8042.debug [HW] Toggle i8042 debug mode
i8042.unmask_kbd_data
@@ -1386,7 +1386,7 @@
Default: only on s2r transitions on x86; most other
architectures force reset to be always executed
i8042.unlock [HW] Unlock (ignore) the keylock
- i8042.kbdreset [HW] Reset device connected to KBD port
+ i8042.kbdreset [HW] Reset device connected to KBD port
i810= [HW,DRM]
@@ -1548,13 +1548,13 @@
programs exec'd, files mmap'd for exec, and all files
opened for read by uid=0.
- ima_template= [IMA]
+ ima_template= [IMA]
Select one of defined IMA measurements template formats.
Formats: { "ima" | "ima-ng" | "ima-sig" }
Default: "ima-ng"
ima_template_fmt=
- [IMA] Define a custom template format.
+ [IMA] Define a custom template format.
Format: { "field1|...|fieldN" }
ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage
@@ -1597,7 +1597,7 @@
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
- int_pln_enable [x86] Enable power limit notification interrupt
+ int_pln_enable [x86] Enable power limit notification interrupt
integrity_audit=[IMA]
Format: { "0" | "1" }
@@ -1650,39 +1650,39 @@
0 disables intel_idle and fall back on acpi_idle.
1 to 9 specify maximum depth of C-state.
- intel_pstate= [X86]
- disable
- Do not enable intel_pstate as the default
- scaling driver for the supported processors
- passive
- Use intel_pstate as a scaling driver, but configure it
- to work with generic cpufreq governors (instead of
- enabling its internal governor). This mode cannot be
- used along with the hardware-managed P-states (HWP)
- feature.
- force
- Enable intel_pstate on systems that prohibit it by default
- in favor of acpi-cpufreq. Forcing the intel_pstate driver
- instead of acpi-cpufreq may disable platform features, such
- as thermal controls and power capping, that rely on ACPI
- P-States information being indicated to OSPM and therefore
- should be used with caution. This option does not work with
- processors that aren't supported by the intel_pstate driver
- or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
- no_hwp
- Do not enable hardware P state control (HWP)
- if available.
- hwp_only
- Only load intel_pstate on systems which support
- hardware P state control (HWP) if available.
- support_acpi_ppc
- Enforce ACPI _PPC performance limits. If the Fixed ACPI
- Description Table, specifies preferred power management
- profile as "Enterprise Server" or "Performance Server",
- then this feature is turned on by default.
- per_cpu_perf_limits
- Allow per-logical-CPU P-State performance control limits using
- cpufreq sysfs interface
+ intel_pstate= [X86]
+ disable
+ Do not enable intel_pstate as the default
+ scaling driver for the supported processors
+ passive
+ Use intel_pstate as a scaling driver, but configure it
+ to work with generic cpufreq governors (instead of
+ enabling its internal governor). This mode cannot be
+ used along with the hardware-managed P-states (HWP)
+ feature.
+ force
+ Enable intel_pstate on systems that prohibit it by default
+ in favor of acpi-cpufreq. Forcing the intel_pstate driver
+ instead of acpi-cpufreq may disable platform features, such
+ as thermal controls and power capping, that rely on ACPI
+ P-States information being indicated to OSPM and therefore
+ should be used with caution. This option does not work with
+ processors that aren't supported by the intel_pstate driver
+ or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
+ no_hwp
+ Do not enable hardware P state control (HWP)
+ if available.
+ hwp_only
+ Only load intel_pstate on systems which support
+ hardware P state control (HWP) if available.
+ support_acpi_ppc
+ Enforce ACPI _PPC performance limits. If the Fixed ACPI
+ Description Table, specifies preferred power management
+ profile as "Enterprise Server" or "Performance Server",
+ then this feature is turned on by default.
+ per_cpu_perf_limits
+ Allow per-logical-CPU P-State performance control limits using
+ cpufreq sysfs interface
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)
@@ -2027,7 +2027,7 @@
* [no]ncqtrim: Turn off queued DSM TRIM.
* nohrst, nosrst, norst: suppress hard, soft
- and both resets.
+ and both resets.
* rstonce: only attempt one reset during
hot-unplug link recovery
@@ -2215,7 +2215,7 @@
[KNL,SH] Allow user to override the default size for
per-device physically contiguous DMA buffers.
- memhp_default_state=online/offline
+ memhp_default_state=online/offline
[KNL] Set the initial state for the memory hotplug
onlining policy. If not specified, the default value is
set according to the
@@ -2762,7 +2762,7 @@
[X86,PV_OPS] Disable paravirtualized VMware scheduler
clock and use the default one.
- no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting.
+ no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
@@ -2823,7 +2823,7 @@
notsc [BUGS=X86-32] Disable Time Stamp Counter
nowatchdog [KNL] Disable both lockup detectors, i.e.
- soft-lockup and NMI watchdog (hard-lockup).
+ soft-lockup and NMI watchdog (hard-lockup).
nowb [ARM]
@@ -2843,7 +2843,7 @@
If the dependencies are under your control, you can
turn on cpu0_hotplug.
- nps_mtm_hs_ctr= [KNL,ARC]
+ nps_mtm_hs_ctr= [KNL,ARC]
This parameter sets the maximum duration, in
cycles, each HW thread of the CTOP can run
without interruptions, before HW switches it.
@@ -2984,7 +2984,7 @@
pci=option[,option...] [PCI] various PCI subsystem options:
earlydump [X86] dump PCI config space before the kernel
- changes anything
+ changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
the hardware directly. Use this if your machine
@@ -3072,7 +3072,7 @@
is enabled by default. If you need to use this,
please report a bug.
nocrs [X86] Ignore PCI host bridge windows from ACPI.
- If you need to use this, please report a bug.
+ If you need to use this, please report a bug.
routeirq Do IRQ routing for all PCI devices.
This is normally done in pci_enable_device(),
so this option is a temporary workaround
@@ -4391,7 +4391,7 @@
usbcore.initial_descriptor_timeout=
[USB] Specifies timeout for the initial 64-byte
- USB_REQ_GET_DESCRIPTOR request in milliseconds
+ USB_REQ_GET_DESCRIPTOR request in milliseconds
(default 5000 = 5.0 seconds).
usbcore.nousb [USB] Disable the USB subsystem
--
2.16.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] docs: kernel-parameters.txt: Fix whitespace
From: Thymo van Beers @ 2018-04-16 21:48 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-kernel
In-Reply-To: <20180416140846.0effe6ad@lwn.net>
On Mon, Apr 16, 2018 at 02:08:46PM -0600, Jonathan Corbet wrote:
> On Mon, 16 Apr 2018 17:45:01 +0200
> Thymo van Beers <thymovanbeers@gmail.com> wrote:
>
> > Some lines used spaces instead of tabs at line start.
> > This can cause mangled lines in editors due to inconsistency.
> >
> > Replace spaces for tabs where appropriate.
>
> Seems like a fine idea. The patch doesn't apply, though; can you please
> make a version against current docs-next? (Or against 4.17-rc1 will work
> too).
>
> Also...
>
> > domain
> > - Isolate from the general SMP balancing and scheduling
> > - algorithms. Note that performing domain isolation this way
> > - is irreversible: it's not possible to bring back a CPU to
> > - the domains once isolated through isolcpus. It's strongly
> > - advised to use cpusets instead to disable scheduler load
> > - balancing through the "cpuset.sched_load_balance" file.
> > - It offers a much more flexible interface where CPUs can
> > - move in and out of an isolated set anytime.
> > -
> > - You can move a process onto or off an "isolated" CPU via
> > - the CPU affinity syscalls or cpuset.
> > - <cpu number> begins at 0 and the maximum value is
> > - "number of CPUs in system - 1".
> > + Isolate from the general SMP balancing and scheduling
> > + algorithms. Note that performing domain isolation this way
> > + is irreversible: it's not possible to bring back a CPU to
> > + the domains once isolated through isolcpus. It's strongly
> > + advised to use cpusets instead to disable scheduler load
> > + balancing through the "cpuset.sched_load_balance" file.
> > + It offers a much more flexible interface where CPUs can
> > + move in and out of an isolated set anytime.
> > +
> > + You can move a process onto or off an "isolated" CPU via
> > + the CPU affinity syscalls or cpuset.
> > + <cpu number> begins at 0 and the maximum value is
> > + "number of CPUs in system - 1".
>
> This would appear to have changed the indentation of some of the text?
>
> Thanks,
>
> jon
Thanks for the comment.
I will rebase against docs-next. Hadn't realised my tree wasn't
up-to-date.
Upon reviewing that section I see that was intentional indentation and
not some tab/space mix up.
Both will be fixed in v2.
- Thymo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Jonathan Corbet @ 2018-04-16 20:35 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrew Morton, Andrey Ryabinin, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Tony Luck, Fenghua Yu, Ralf Baechle,
James Hogan, Michael Ellerman, Alexander Viro, linux-kernel,
linux-doc, kasan-dev, linux-alpha, linux-ia64, linux-mips,
linuxppc-dev, linux-fsdevel, linux-mm
In-Reply-To: <20180415173655.GB31176@rapoport-lnx>
On Sun, 15 Apr 2018 20:36:56 +0300
Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> I didn't mean we should keep it as unorganized jumble of stuff and I agree
> that splitting the documentation by audience is better because developers
> are already know how to find it :)
>
> I just thought that putting the doc into the place should not be done
> immediately after mechanical ReST conversion but rather after improving the
> contents.
OK, this is fine. I'll go ahead and apply the set, but then I'll be
watching to see that the other improvements come :)
In applying the set, there was a significant set of conflicts with
vm/hmm.rst; hopefully I've sorted those out properly.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] docs: kernel-parameters.txt: Fix whitespace
From: Jonathan Corbet @ 2018-04-16 20:08 UTC (permalink / raw)
To: Thymo van Beers; +Cc: linux-doc, linux-kernel
In-Reply-To: <20180416154458.GA24716@thinkpad>
On Mon, 16 Apr 2018 17:45:01 +0200
Thymo van Beers <thymovanbeers@gmail.com> wrote:
> Some lines used spaces instead of tabs at line start.
> This can cause mangled lines in editors due to inconsistency.
>
> Replace spaces for tabs where appropriate.
Seems like a fine idea. The patch doesn't apply, though; can you please
make a version against current docs-next? (Or against 4.17-rc1 will work
too).
Also...
> domain
> - Isolate from the general SMP balancing and scheduling
> - algorithms. Note that performing domain isolation this way
> - is irreversible: it's not possible to bring back a CPU to
> - the domains once isolated through isolcpus. It's strongly
> - advised to use cpusets instead to disable scheduler load
> - balancing through the "cpuset.sched_load_balance" file.
> - It offers a much more flexible interface where CPUs can
> - move in and out of an isolated set anytime.
> -
> - You can move a process onto or off an "isolated" CPU via
> - the CPU affinity syscalls or cpuset.
> - <cpu number> begins at 0 and the maximum value is
> - "number of CPUs in system - 1".
> + Isolate from the general SMP balancing and scheduling
> + algorithms. Note that performing domain isolation this way
> + is irreversible: it's not possible to bring back a CPU to
> + the domains once isolated through isolcpus. It's strongly
> + advised to use cpusets instead to disable scheduler load
> + balancing through the "cpuset.sched_load_balance" file.
> + It offers a much more flexible interface where CPUs can
> + move in and out of an isolated set anytime.
> +
> + You can move a process onto or off an "isolated" CPU via
> + the CPU affinity syscalls or cpuset.
> + <cpu number> begins at 0 and the maximum value is
> + "number of CPUs in system - 1".
This would appear to have changed the indentation of some of the text?
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Changed .txt to .rst in Documentation/sound/*.rst
From: Jonathan Corbet @ 2018-04-16 20:02 UTC (permalink / raw)
To: Christina Quast; +Cc: linux-doc
In-Reply-To: <CA+JAYfTAWHAp3W6VEzZx+PW7dbiz6K3Tv5mGHFiNbOiYy6g+3A@mail.gmail.com>
On Wed, 11 Apr 2018 18:33:26 +0200
Christina Quast <cquast@baylibre.com> wrote:
> Here is a small fixup for the documentation. Unless it's too trivial to
> change it.
Applied, thanks.
In the future, though, please send patches inline rather than as
attachments; that way I don't have to clean things up to apply them.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] coresight: Add section for integration with the perf tools
From: Randy Dunlap @ 2018-04-16 19:48 UTC (permalink / raw)
To: Mathieu Poirier, linux-arm-kernel, corbet
Cc: linux-doc, linux-kernel, Ben.Gainey
In-Reply-To: <1523907327-20979-3-git-send-email-mathieu.poirier@linaro.org>
On 04/16/2018 12:35 PM, Mathieu Poirier wrote:
> Adding a section that document how to use the Coresight framework and
> drivers from the perf tools.
>
> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> Documentation/trace/coresight.txt | 50 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
> index 710c75b6c73f..8caae8050a60 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -187,9 +187,18 @@ that can be performed on them (see "struct coresight_ops"). The
> specific to that component only. "Implementation defined" customisations are
> expected to be accessed and controlled using those entries.
>
> +
> How to use the tracer modules
> -----------------------------
>
> +There is two ways to use the Coresight framework: 1) using the perf cmd line
There are two ways
> +tools and 2) interacting directly with the Coresight devices using the sysFS
> +interface. Preference is given to the former as using the sysFS interface
> +requires a deep understanding of the Coresight HW. The following sections
> +provide details on using both methods.
> +
> +1) Using the sysFS interface:
> +
> Before trace collection can start, a coresight sink needs to be identify.
identified.
> There is no limit on the amount of sinks (nor sources) that can be enabled at
> any given moment. As a generic operation, all device pertaining to the sink
> @@ -295,6 +304,47 @@ Instruction 13570831 0x8026B584 E28DD00C false ADD
> Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> Timestamp Timestamp: 17107041535
>
> +2) Using perf framework:
> +
> +Coresight tracers are represented using the Perf framework's Performance
> +Monitoring Unit (PMU) abstraction. As such the perf framework takes charge of
> +controlling when tracing gets enabled based on when the process of interest is
> +scheduled. When configured in a system, Coresight PMUs will be listed when
> +queried by the perf command line tool:
> +
> + linaro@linaro-nano:~$ ./perf list pmu
> +
> + List of pre-defined events (to be used in -e):
> +
> + cs_etm// [Kernel PMU event]
> +
> + linaro@linaro-nano:~$
> +
> +Regardless of the number of tracers available in a system (usually equal to the
> +amount of processor core), the "cs_etm" PMU will be listed only once.
? cores),
> +
> +A Coresight PMU works the same way as any other PMUs, i.e the name of the PMU is
any other PMU, i.e.
> +listed along with configuration options within forward slashes '/'. Since a
> +Coresight system will typically have more than one sink, the name of the sink to
> +work with needs to be specified as an event option. Names for sink to choose
> +from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
> +
> + root@linaro-nano:~# ls /sys/bus/coresight/devices/
> + 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> + 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> + 20070000.etr 20120000.replicator 220c0000.funnel
> + 23040000.etm 23140000.etm 23340000.etm
> +
> + root@linaro-nano:~# perf record -e cs_etm/@20070000.etr/u --per-thread program
> +
> +The syntax within the forward slashes '/' is important. The '@' character
> +tells the parser that a sink is about to be specified and that this is the IP
Can we get away from using "IP" and call it a device or (hardware) module or
something more descriptive?
> +to use for the trace session.
> +
> +More information on the above and other example on how to use Coresight with
> +the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
> +repository [3].
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/3] coresight: Remove obsolete reference to "owner" in CoreSight descriptor
From: Mathieu Poirier @ 2018-04-16 19:35 UTC (permalink / raw)
To: linux-arm-kernel, corbet; +Cc: linux-doc, linux-kernel, Ben.Gainey
In-Reply-To: <1523907327-20979-1-git-send-email-mathieu.poirier@linaro.org>
Field "owner" of struct coresight_desc has been removed a while back but
the documentation was not updated to reflect the changes.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
Documentation/trace/coresight.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 6f0120c3a4f1..710c75b6c73f 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,9 +187,6 @@ that can be performed on them (see "struct coresight_ops"). The
specific to that component only. "Implementation defined" customisations are
expected to be accessed and controlled using those entries.
-Last but not least, "struct module *owner" is expected to be set to reflect
-the information carried in "THIS_MODULE".
-
How to use the tracer modules
-----------------------------
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] coresight: Add section for integration with the perf tools
From: Mathieu Poirier @ 2018-04-16 19:35 UTC (permalink / raw)
To: linux-arm-kernel, corbet; +Cc: linux-doc, linux-kernel, Ben.Gainey
In-Reply-To: <1523907327-20979-1-git-send-email-mathieu.poirier@linaro.org>
Adding a section that document how to use the Coresight framework and
drivers from the perf tools.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
Documentation/trace/coresight.txt | 50 +++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 710c75b6c73f..8caae8050a60 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -187,9 +187,18 @@ that can be performed on them (see "struct coresight_ops"). The
specific to that component only. "Implementation defined" customisations are
expected to be accessed and controlled using those entries.
+
How to use the tracer modules
-----------------------------
+There is two ways to use the Coresight framework: 1) using the perf cmd line
+tools and 2) interacting directly with the Coresight devices using the sysFS
+interface. Preference is given to the former as using the sysFS interface
+requires a deep understanding of the Coresight HW. The following sections
+provide details on using both methods.
+
+1) Using the sysFS interface:
+
Before trace collection can start, a coresight sink needs to be identify.
There is no limit on the amount of sinks (nor sources) that can be enabled at
any given moment. As a generic operation, all device pertaining to the sink
@@ -295,6 +304,47 @@ Instruction 13570831 0x8026B584 E28DD00C false ADD
Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
Timestamp Timestamp: 17107041535
+2) Using perf framework:
+
+Coresight tracers are represented using the Perf framework's Performance
+Monitoring Unit (PMU) abstraction. As such the perf framework takes charge of
+controlling when tracing gets enabled based on when the process of interest is
+scheduled. When configured in a system, Coresight PMUs will be listed when
+queried by the perf command line tool:
+
+ linaro@linaro-nano:~$ ./perf list pmu
+
+ List of pre-defined events (to be used in -e):
+
+ cs_etm// [Kernel PMU event]
+
+ linaro@linaro-nano:~$
+
+Regardless of the number of tracers available in a system (usually equal to the
+amount of processor core), the "cs_etm" PMU will be listed only once.
+
+A Coresight PMU works the same way as any other PMUs, i.e the name of the PMU is
+listed along with configuration options within forward slashes '/'. Since a
+Coresight system will typically have more than one sink, the name of the sink to
+work with needs to be specified as an event option. Names for sink to choose
+from are listed in sysFS under ($SYSFS)/bus/coresight/devices:
+
+ root@linaro-nano:~# ls /sys/bus/coresight/devices/
+ 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
+ 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
+ 20070000.etr 20120000.replicator 220c0000.funnel
+ 23040000.etm 23140000.etm 23340000.etm
+
+ root@linaro-nano:~# perf record -e cs_etm/@20070000.etr/u --per-thread program
+
+The syntax within the forward slashes '/' is important. The '@' character
+tells the parser that a sink is about to be specified and that this is the IP
+to use for the trace session.
+
+More information on the above and other example on how to use Coresight with
+the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
+repository [3].
+
How to use the STM module
-------------------------
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] coresight: Refresh documenation
From: Mathieu Poirier @ 2018-04-16 19:35 UTC (permalink / raw)
To: linux-arm-kernel, corbet; +Cc: linux-doc, linux-kernel, Ben.Gainey
Now that the perf tools CoreSight support is upstream this set adds
documentation to go with it and move things around so that topics
are located together.
Mathieu Poirier (3):
coresight: Remove obsolete reference to "owner" in CoreSight
descriptor
coresight: Add section for integration with the perf tools
coresight: Grouping all perf tools oriented section together
Documentation/trace/coresight.txt | 101 ++++++++++++++++++++++++++++----------
1 file changed, 74 insertions(+), 27 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] coresight: Grouping all perf tools oriented section together
From: Mathieu Poirier @ 2018-04-16 19:35 UTC (permalink / raw)
To: linux-arm-kernel, corbet; +Cc: linux-doc, linux-kernel, Ben.Gainey
In-Reply-To: <1523907327-20979-1-git-send-email-mathieu.poirier@linaro.org>
This patch groups together section pertaining to the perf tools. That way
everything is at the same place rather than spread out.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
Documentation/trace/coresight.txt | 72 +++++++++++++++++++--------------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.txt
index 8caae8050a60..32c5b159e8fc 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -345,42 +345,7 @@ More information on the above and other example on how to use Coresight with
the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
repository [3].
-How to use the STM module
--------------------------
-
-Using the System Trace Macrocell module is the same as the tracers - the only
-difference is that clients are driving the trace capture rather
-than the program flow through the code.
-
-As with any other CoreSight component, specifics about the STM tracer can be
-found in sysfs with more information on each entry being found in [1]:
-
-root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
-enable_source hwevent_select port_enable subsystem uevent
-hwevent_enable mgmt port_select traceid
-root@genericarmv8:~#
-
-Like any other source a sink needs to be identified and the STM enabled before
-being used:
-
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
-root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
-
-From there user space applications can request and use channels using the devfs
-interface provided for that purpose by the generic STM API:
-
-root@genericarmv8:~# ls -l /dev/20100000.stm
-crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
-root@genericarmv8:~#
-
-Details on how to use the generic STM API can be found here [2].
-
-[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
-[2]. Documentation/trace/stm.txt
-
-
-Using perf tools
-----------------
+2.1) AutoFDO analysis using the perf tools:
perf can be used to record and analyze trace of programs.
@@ -428,3 +393,38 @@ sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tuto
$ taskset -c 2 ./sort_autofdo
Bubble sorting array of 30000 elements
5806 ms
+
+
+How to use the STM module
+-------------------------
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the code.
+
+As with any other CoreSight component, specifics about the STM tracer can be
+found in sysfs with more information on each entry being found in [1]:
+
+root@genericarmv8:~# ls /sys/bus/coresight/devices/20100000.stm
+enable_source hwevent_select port_enable subsystem uevent
+hwevent_enable mgmt port_select traceid
+root@genericarmv8:~#
+
+Like any other source a sink needs to be identified and the STM enabled before
+being used:
+
+root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20010000.etf/enable_sink
+root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/20100000.stm/enable_source
+
+From there user space applications can request and use channels using the devfs
+interface provided for that purpose by the generic STM API:
+
+root@genericarmv8:~# ls -l /dev/20100000.stm
+crw------- 1 root root 10, 61 Jan 3 18:11 /dev/20100000.stm
+root@genericarmv8:~#
+
+Details on how to use the generic STM API can be found here [2].
+
+[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
+[2]. Documentation/trace/stm.txt
+[3]. https://github.com/Linaro/perf-opencsd
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 07/10] Documentation: dt-bindings: Add documents for PECI hwmon client drivers
From: Rob Herring @ 2018-04-16 18:14 UTC (permalink / raw)
To: Jae Hyun Yoo
Cc: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery, linux-kernel, linux-doc,
devicetree, linux-hwmon, linux-arm-kernel, openbmc
In-Reply-To: <20180410183212.16787-8-jae.hyun.yoo@linux.intel.com>
On Tue, Apr 10, 2018 at 11:32:09AM -0700, Jae Hyun Yoo wrote:
> This commit adds dt-bindings documents for PECI cputemp and dimmtemp client
> drivers.
"dt-bindings: hwmon: ..." for the subject.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Reviewed-by: James Feist <james.feist@linux.intel.com>
> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Julia Cartwright <juliac@eso.teric.us>
> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Cc: Milton Miller II <miltonm@us.ibm.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Stef van Os <stef.van.os@prodrive-technologies.com>
> Cc: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
> ---
> .../devicetree/bindings/hwmon/peci-cputemp.txt | 24 +++++++++++++++++++++
> .../devicetree/bindings/hwmon/peci-dimmtemp.txt | 25 ++++++++++++++++++++++
> 2 files changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
> create mode 100644 Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
> new file mode 100644
> index 000000000000..d5530ef9cfd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
> @@ -0,0 +1,24 @@
> +Bindings for Intel PECI (Platform Environment Control Interface) cputemp driver.
> +
> +Required properties:
> +- compatible : Should be "intel,peci-cputemp".
> +- reg : Should contain address of a client CPU. Address range of CPU
> + clients is starting from 0x30 based on PECI specification.
> + <0x30> .. <0x37> (depends on the PECI_OFFSET_MAX definition)
Again, where is PECI_OFFSET_MAX defined? It can't depend on something in
the kernel.
> +
> +Example:
> + peci-bus@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + < more properties >
> +
> + peci-cputemp@cpu0 {
> + compatible = "intel,peci-cputemp";
> + reg = <0x30>;
> + };
> +
> + peci-cputemp@cpu1 {
> + compatible = "intel,peci-cputemp";
> + reg = <0x31>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt b/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
> new file mode 100644
> index 000000000000..56e5deb61e5c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
> @@ -0,0 +1,25 @@
> +Bindings for Intel PECI (Platform Environment Control Interface) dimmtemp
> +driver.
> +
> +Required properties:
> +- compatible : Should be "intel,peci-dimmtemp".
> +- reg : Should contain address of a client CPU. Address range of CPU
> + clients is starting from 0x30 based on PECI specification.
> + <0x30> .. <0x37> (depends on the PECI_OFFSET_MAX definition)
> +
> +Example:
> + peci-bus@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + < more properties >
> +
> + peci-dimmtemp@cpu0 {
unit-address is wrong.
It is a different bus from cputemp? Otherwise, you have conflicting
addresses. If that's the case, probably should make it clear by showing
different host adapters for each example.
> + compatible = "intel,peci-dimmtemp";
> + reg = <0x30>;
> + };
> +
> + peci-dimmtemp@cpu1 {
> + compatible = "intel,peci-dimmtemp";
> + reg = <0x31>;
> + };
> + };
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 04/10] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs
From: Rob Herring @ 2018-04-16 18:10 UTC (permalink / raw)
To: Jae Hyun Yoo
Cc: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery, linux-kernel, linux-doc,
devicetree, linux-hwmon, linux-arm-kernel, openbmc
In-Reply-To: <20180410183212.16787-5-jae.hyun.yoo@linux.intel.com>
On Tue, Apr 10, 2018 at 11:32:06AM -0700, Jae Hyun Yoo wrote:
> This commit adds a dt-bindings document of PECI adapter driver for Aspeed
> AST24xx/25xx SoCs.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Reviewed-by: James Feist <james.feist@linux.intel.com>
> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Julia Cartwright <juliac@eso.teric.us>
> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Cc: Milton Miller II <miltonm@us.ibm.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Stef van Os <stef.van.os@prodrive-technologies.com>
> Cc: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
> ---
> .../devicetree/bindings/peci/peci-aspeed.txt | 60 ++++++++++++++++++++++
> 1 file changed, 60 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/peci/peci-aspeed.txt
>
> diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.txt b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> new file mode 100644
> index 000000000000..4598bb8c20fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.txt
> @@ -0,0 +1,60 @@
> +Device tree configuration for PECI buses on the AST24XX and AST25XX SoCs.
> +
> +Required properties:
> +- compatible : Should be "aspeed,ast2400-peci" or "aspeed,ast2500-peci"
> + - aspeed,ast2400-peci: Aspeed AST2400 family PECI
> + controller
> + - aspeed,ast2500-peci: Aspeed AST2500 family PECI
> + controller
> +- reg : Should contain PECI controller registers location and
> + length.
> +- #address-cells : Should be <1>.
> +- #size-cells : Should be <0>.
> +- interrupts : Should contain PECI controller interrupt.
> +- clocks : Should contain clock source for PECI controller.
> + Should reference clkin.
> +- clock_frequency : Should contain the operation frequency of PECI controller
> + in units of Hz.
> + 187500 ~ 24000000
This is the frequency of the bus or used to derive it? It would be
better to specify the bus frequency instead and have the driver
calculate its internal freq. And then use "bus-frequency" instead.
> +
> +Optional properties:
> +- msg-timing-nego : Message timing negotiation period. This value will
> + determine the period of message timing negotiation to be
> + issued by PECI controller. The unit of the programmed
> + value is four times of PECI clock period.
> + 0 ~ 255 (default: 1)
> +- addr-timing-nego : Address timing negotiation period. This value will
> + determine the period of address timing negotiation to be
> + issued by PECI controller. The unit of the programmed
> + value is four times of PECI clock period.
> + 0 ~ 255 (default: 1)
> +- rd-sampling-point : Read sampling point selection. The whole period of a bit
> + time will be divided into 16 time frames. This value will
> + determine the time frame in which the controller will
> + sample PECI signal for data read back. Usually in the
> + middle of a bit time is the best.
> + 0 ~ 15 (default: 8)
> +- cmd_timeout_ms : Command timeout in units of ms.
> + 1 ~ 60000 (default: 1000)
s/_/-/
All these either need vendor prefixes or should be standard properties
for PECI adapters. I think probably the latter case. If so, the first
2 should probably be in units of clocks (not 4 clocks). And they should
then be documented in the common PECI binding doc.
> +
> +Example:
> + peci: peci@1e78b000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x1e78b000 0x60>;
No need to show this part in examples.
> +
> + peci0: peci-bus@0 {
> + compatible = "aspeed,ast2500-peci";
> + reg = <0x0 0x60>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <15>;
> + clocks = <&clk_clkin>;
> + clock-frequency = <24000000>;
> + msg-timing-nego = <1>;
> + addr-timing-nego = <1>;
> + rd-sampling-point = <8>;
> + cmd-timeout-ms = <1000>;
> + };
> + };
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 01/10] Documentations: dt-bindings: Add documents of generic PECI bus, adapter and client drivers
From: Rob Herring @ 2018-04-16 17:59 UTC (permalink / raw)
To: Jae Hyun Yoo
Cc: Alan Cox, Andrew Jeffery, Andrew Lunn, Andy Shevchenko,
Arnd Bergmann, Benjamin Herrenschmidt, Fengguang Wu, Greg KH,
Guenter Roeck, Haiyue Wang, James Feist, Jason M Biils,
Jean Delvare, Joel Stanley, Julia Cartwright, Miguel Ojeda,
Milton Miller II, Pavel Machek, Randy Dunlap, Stef van Os,
Sumeet R Pawnikar, Vernon Mauery, linux-hwmon, devicetree,
linux-doc, openbmc, linux-kernel, linux-arm-kernel
In-Reply-To: <20180410183212.16787-2-jae.hyun.yoo@linux.intel.com>
On Tue, Apr 10, 2018 at 11:32:03AM -0700, Jae Hyun Yoo wrote:
> This commit adds documents of generic PECI bus, adapter and client drivers.
"dt-bindings: ..." for the subject prefix please.
>
> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
> Reviewed-by: Haiyue Wang <haiyue.wang@linux.intel.com>
> Reviewed-by: James Feist <james.feist@linux.intel.com>
> Reviewed-by: Vernon Mauery <vernon.mauery@linux.intel.com>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Andrew Jeffery <andrew@aj.id.au>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Fengguang Wu <fengguang.wu@intel.com>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jason M Biils <jason.m.bills@linux.intel.com>
> Cc: Jean Delvare <jdelvare@suse.com>
> Cc: Joel Stanley <joel@jms.id.au>
> Cc: Julia Cartwright <juliac@eso.teric.us>
> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
> Cc: Milton Miller II <miltonm@us.ibm.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Stef van Os <stef.van.os@prodrive-technologies.com>
> Cc: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
> ---
> .../devicetree/bindings/peci/peci-adapter.txt | 23 ++++++++++++++++++++
> .../devicetree/bindings/peci/peci-bus.txt | 15 +++++++++++++
> .../devicetree/bindings/peci/peci-client.txt | 25 ++++++++++++++++++++++
This should be all one document.
> 3 files changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/peci/peci-adapter.txt
> create mode 100644 Documentation/devicetree/bindings/peci/peci-bus.txt
> create mode 100644 Documentation/devicetree/bindings/peci/peci-client.txt
>
> diff --git a/Documentation/devicetree/bindings/peci/peci-adapter.txt b/Documentation/devicetree/bindings/peci/peci-adapter.txt
> new file mode 100644
> index 000000000000..9221374f6b11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/peci/peci-adapter.txt
> @@ -0,0 +1,23 @@
> +Generic device tree configuration for PECI adapters.
> +
> +Required properties:
> +- compatible : Should contain hardware specific definition strings that can
> + match an adapter driver implementation.
> +- reg : Should contain PECI controller registers location and length.
No need for these 2 here.
> +- #address-cells : Should be <1>.
> +- #size-cells : Should be <0>.
Some details on the addressing for PECI would be good.
> +
> +Example:
> + peci: peci@10000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10000000 0x1000>;
> +
This part of the example is not relevant. Just start with the adapter
node.
> + peci0: peci-bus@0 {
> + compatible = "soc,soc-peci";
> + reg = <0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/peci/peci-bus.txt b/Documentation/devicetree/bindings/peci/peci-bus.txt
> new file mode 100644
> index 000000000000..90bcc791ccb0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/peci/peci-bus.txt
> @@ -0,0 +1,15 @@
> +Generic device tree configuration for PECI buses.
> +
> +Required properties:
> +- compatible : Should be "simple-bus".
I don't understand what this has to do with PECI? "simple-bus" already
has a defined meaning.
> +- #address-cells : Should be <1>.
> +- #size-cells : Should be <1>.
> +- ranges : Should contain PECI controller registers ranges.
> +
> +Example:
> + peci: peci@10000000 {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10000000 0x1000>;
> + };
> diff --git a/Documentation/devicetree/bindings/peci/peci-client.txt b/Documentation/devicetree/bindings/peci/peci-client.txt
> new file mode 100644
> index 000000000000..8e2bfd8532f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/peci/peci-client.txt
> @@ -0,0 +1,25 @@
> +Generic device tree configuration for PECI clients.
> +
> +Required properties:
> +- compatible : Should contain target device specific definition strings that can
> + match a client driver implementation.
Bindings are for h/w, not client drivers.
How are PECI devices defined?
> +- reg : Should contain address of a client CPU. Address range of CPU
> + clients is starting from 0x30 based on PECI specification.
> + <0x30> .. <0x37> (depends on the PECI_OFFSET_MAX definition)
8 devices should be enough for anyone...
Where is PECI_OFFSET_MAX defined?
> +
> +Example:
> + peci-bus@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + < more properties >
> +
> + function@cpu0 {
Not a valid node name. "function@30" is what it probably should be. For
a new bus you can define unit-address format you like, but it must be
based on the contents of reg. However, it doesn't look like you should
create anything special here.
> + compatible = "device,function";
> + reg = <0x30>;
> + };
> +
> + function@cpu1 {
> + compatible = "device,function";
> + reg = <0x31>;
> + };
> + };
> --
> 2.16.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] docs: kernel-parameters.txt: Fix whitespace
From: Thymo van Beers @ 2018-04-16 15:45 UTC (permalink / raw)
To: corbet; +Cc: linux-doc, linux-kernel
Some lines used spaces instead of tabs at line start.
This can cause mangled lines in editors due to inconsistency.
Replace spaces for tabs where appropriate.
Signed-off-by: Thymo van Beers <thymovanbeers@gmail.com>
---
Documentation/admin-guide/kernel-parameters.txt | 168 ++++++++++++------------
1 file changed, 84 insertions(+), 84 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..3aa8eed85f39 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -106,11 +106,11 @@
use by PCI
Format: <irq>,<irq>...
- acpi_mask_gpe= [HW,ACPI]
+ acpi_mask_gpe= [HW,ACPI]
Due to the existence of _Lxx/_Exx, some GPEs triggered
by unsupported hardware/firmware features can result in
- GPE floodings that cannot be automatically disabled by
- the GPE dispatcher.
+ GPE floodings that cannot be automatically disabled by
+ the GPE dispatcher.
This facility can be used to prevent such uncontrolled
GPE floodings.
Format: <int>
@@ -472,10 +472,10 @@
for platform specific values (SB1, Loongson3 and
others).
- ccw_timeout_log [S390]
+ ccw_timeout_log [S390]
See Documentation/s390/CommonIO for details.
- cgroup_disable= [KNL] Disable a particular controller
+ cgroup_disable= [KNL] Disable a particular controller
Format: {name of the controller(s) to disable}
The effects of cgroup_disable=foo are:
- foo isn't auto-mounted if you mount all cgroups in
@@ -641,8 +641,8 @@
hvc<n> Use the hypervisor console device <n>. This is for
both Xen and PowerPC hypervisors.
- If the device connected to the port is not a TTY but a braille
- device, prepend "brl," before the device type, for instance
+ If the device connected to the port is not a TTY but a braille
+ device, prepend "brl," before the device type, for instance
console=brl,ttyS0
For now, only VisioBraille is supported.
@@ -662,7 +662,7 @@
consoleblank= [KNL] The console blank (screen saver) timeout in
seconds. A value of 0 disables the blank timer.
- Defaults to 0.
+ Defaults to 0.
coredump_filter=
[KNL] Change the default value for
@@ -730,7 +730,7 @@
or memory reserved is below 4G.
cryptomgr.notests
- [KNL] Disable crypto self-tests
+ [KNL] Disable crypto self-tests
cs89x0_dma= [HW,NET]
Format: <dma>
@@ -746,7 +746,7 @@
Format: <port#>,<type>
See also Documentation/input/devices/joystick-parport.rst
- ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
+ ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See
Documentation/admin-guide/dynamic-debug-howto.rst for
details. Deprecated, see dyndbg.
@@ -833,7 +833,7 @@
causing system reset or hang due to sending
INIT from AP to BSP.
- disable_ddw [PPC/PSERIES]
+ disable_ddw [PPC/PSERIES]
Disable Dynamic DMA Window support. Use this if
to workaround buggy firmware.
@@ -1188,7 +1188,7 @@
parameter will force ia64_sal_cache_flush to call
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
- forcepae [X86-32]
+ forcepae [X86-32]
Forcefully enable Physical Address Extension (PAE).
Many Pentium M systems disable PAE but may have a
functionally usable PAE implementation.
@@ -1247,7 +1247,7 @@
gamma= [HW,DRM]
- gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
+ gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
Format: off | on
default: on
@@ -1341,14 +1341,14 @@
x86-64 are 2M (when the CPU supports "pse") and 1G
(when the CPU supports the "pdpe1gb" cpuinfo flag).
- hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
- terminal devices. Valid values: 0..8
- hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
- If specified, z/VM IUCV HVC accepts connections
- from listed z/VM user IDs only.
+ hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
+ terminal devices. Valid values: 0..8
+ hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs.
+ If specified, z/VM IUCV HVC accepts connections
+ from listed z/VM user IDs only.
- hwthread_map= [METAG] Comma-separated list of Linux cpu id to
- hardware thread id mappings.
+ hwthread_map= [METAG] Comma-separated list of Linux cpu id to
+ hardware thread id mappings.
Format: <cpu>:<hwthread>
keep_bootcon [KNL]
@@ -1357,11 +1357,11 @@
between unregistering the boot console and initializing
the real console.
- i2c_bus= [HW] Override the default board specific I2C bus speed
- or register an additional I2C bus that is not
- registered from board initialization code.
- Format:
- <bus_id>,<clkrate>
+ i2c_bus= [HW] Override the default board specific I2C bus speed
+ or register an additional I2C bus that is not
+ registered from board initialization code.
+ Format:
+ <bus_id>,<clkrate>
i8042.debug [HW] Toggle i8042 debug mode
i8042.unmask_kbd_data
@@ -1390,7 +1390,7 @@
Default: only on s2r transitions on x86; most other
architectures force reset to be always executed
i8042.unlock [HW] Unlock (ignore) the keylock
- i8042.kbdreset [HW] Reset device connected to KBD port
+ i8042.kbdreset [HW] Reset device connected to KBD port
i810= [HW,DRM]
@@ -1546,13 +1546,13 @@
programs exec'd, files mmap'd for exec, and all files
opened for read by uid=0.
- ima_template= [IMA]
+ ima_template= [IMA]
Select one of defined IMA measurements template formats.
Formats: { "ima" | "ima-ng" | "ima-sig" }
Default: "ima-ng"
ima_template_fmt=
- [IMA] Define a custom template format.
+ [IMA] Define a custom template format.
Format: { "field1|...|fieldN" }
ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage
@@ -1595,7 +1595,7 @@
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
- int_pln_enable [x86] Enable power limit notification interrupt
+ int_pln_enable [x86] Enable power limit notification interrupt
integrity_audit=[IMA]
Format: { "0" | "1" }
@@ -1648,39 +1648,39 @@
0 disables intel_idle and fall back on acpi_idle.
1 to 9 specify maximum depth of C-state.
- intel_pstate= [X86]
- disable
- Do not enable intel_pstate as the default
- scaling driver for the supported processors
- passive
- Use intel_pstate as a scaling driver, but configure it
- to work with generic cpufreq governors (instead of
- enabling its internal governor). This mode cannot be
- used along with the hardware-managed P-states (HWP)
- feature.
- force
- Enable intel_pstate on systems that prohibit it by default
- in favor of acpi-cpufreq. Forcing the intel_pstate driver
- instead of acpi-cpufreq may disable platform features, such
- as thermal controls and power capping, that rely on ACPI
- P-States information being indicated to OSPM and therefore
- should be used with caution. This option does not work with
- processors that aren't supported by the intel_pstate driver
- or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
- no_hwp
- Do not enable hardware P state control (HWP)
- if available.
- hwp_only
- Only load intel_pstate on systems which support
- hardware P state control (HWP) if available.
- support_acpi_ppc
- Enforce ACPI _PPC performance limits. If the Fixed ACPI
- Description Table, specifies preferred power management
- profile as "Enterprise Server" or "Performance Server",
- then this feature is turned on by default.
- per_cpu_perf_limits
- Allow per-logical-CPU P-State performance control limits using
- cpufreq sysfs interface
+ intel_pstate= [X86]
+ disable
+ Do not enable intel_pstate as the default
+ scaling driver for the supported processors
+ passive
+ Use intel_pstate as a scaling driver, but configure it
+ to work with generic cpufreq governors (instead of
+ enabling its internal governor). This mode cannot be
+ used along with the hardware-managed P-states (HWP)
+ feature.
+ force
+ Enable intel_pstate on systems that prohibit it by default
+ in favor of acpi-cpufreq. Forcing the intel_pstate driver
+ instead of acpi-cpufreq may disable platform features, such
+ as thermal controls and power capping, that rely on ACPI
+ P-States information being indicated to OSPM and therefore
+ should be used with caution. This option does not work with
+ processors that aren't supported by the intel_pstate driver
+ or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
+ no_hwp
+ Do not enable hardware P state control (HWP)
+ if available.
+ hwp_only
+ Only load intel_pstate on systems which support
+ hardware P state control (HWP) if available.
+ support_acpi_ppc
+ Enforce ACPI _PPC performance limits. If the Fixed ACPI
+ Description Table, specifies preferred power management
+ profile as "Enterprise Server" or "Performance Server",
+ then this feature is turned on by default.
+ per_cpu_perf_limits
+ Allow per-logical-CPU P-State performance control limits using
+ cpufreq sysfs interface
intremap= [X86-64, Intel-IOMMU]
on enable Interrupt Remapping (default)
@@ -1765,21 +1765,21 @@
specified in the flag list (default: domain):
nohz
- Disable the tick when a single task runs.
+ Disable the tick when a single task runs.
domain
- Isolate from the general SMP balancing and scheduling
- algorithms. Note that performing domain isolation this way
- is irreversible: it's not possible to bring back a CPU to
- the domains once isolated through isolcpus. It's strongly
- advised to use cpusets instead to disable scheduler load
- balancing through the "cpuset.sched_load_balance" file.
- It offers a much more flexible interface where CPUs can
- move in and out of an isolated set anytime.
-
- You can move a process onto or off an "isolated" CPU via
- the CPU affinity syscalls or cpuset.
- <cpu number> begins at 0 and the maximum value is
- "number of CPUs in system - 1".
+ Isolate from the general SMP balancing and scheduling
+ algorithms. Note that performing domain isolation this way
+ is irreversible: it's not possible to bring back a CPU to
+ the domains once isolated through isolcpus. It's strongly
+ advised to use cpusets instead to disable scheduler load
+ balancing through the "cpuset.sched_load_balance" file.
+ It offers a much more flexible interface where CPUs can
+ move in and out of an isolated set anytime.
+
+ You can move a process onto or off an "isolated" CPU via
+ the CPU affinity syscalls or cpuset.
+ <cpu number> begins at 0 and the maximum value is
+ "number of CPUs in system - 1".
The format of <cpu-list> is described above.
@@ -2004,7 +2004,7 @@
* [no]ncqtrim: Turn off queued DSM TRIM.
* nohrst, nosrst, norst: suppress hard, soft
- and both resets.
+ and both resets.
* rstonce: only attempt one reset during
hot-unplug link recovery
@@ -2192,7 +2192,7 @@
[KNL,SH] Allow user to override the default size for
per-device physically contiguous DMA buffers.
- memhp_default_state=online/offline
+ memhp_default_state=online/offline
[KNL] Set the initial state for the memory hotplug
onlining policy. If not specified, the default value is
set according to the
@@ -2729,7 +2729,7 @@
[X86,PV_OPS] Disable paravirtualized VMware scheduler
clock and use the default one.
- no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting.
+ no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting.
steal time is computed, but won't influence scheduler
behaviour
@@ -2790,7 +2790,7 @@
notsc [BUGS=X86-32] Disable Time Stamp Counter
nowatchdog [KNL] Disable both lockup detectors, i.e.
- soft-lockup and NMI watchdog (hard-lockup).
+ soft-lockup and NMI watchdog (hard-lockup).
nowb [ARM]
@@ -2810,7 +2810,7 @@
If the dependencies are under your control, you can
turn on cpu0_hotplug.
- nps_mtm_hs_ctr= [KNL,ARC]
+ nps_mtm_hs_ctr= [KNL,ARC]
This parameter sets the maximum duration, in
cycles, each HW thread of the CTOP can run
without interruptions, before HW switches it.
@@ -2951,7 +2951,7 @@
pci=option[,option...] [PCI] various PCI subsystem options:
earlydump [X86] dump PCI config space before the kernel
- changes anything
+ changes anything
off [X86] don't probe for the PCI bus
bios [X86-32] force use of PCI BIOS, don't access
the hardware directly. Use this if your machine
@@ -3039,7 +3039,7 @@
is enabled by default. If you need to use this,
please report a bug.
nocrs [X86] Ignore PCI host bridge windows from ACPI.
- If you need to use this, please report a bug.
+ If you need to use this, please report a bug.
routeirq Do IRQ routing for all PCI devices.
This is normally done in pci_enable_device(),
so this option is a temporary workaround
@@ -4363,7 +4363,7 @@
usbcore.initial_descriptor_timeout=
[USB] Specifies timeout for the initial 64-byte
- USB_REQ_GET_DESCRIPTOR request in milliseconds
+ USB_REQ_GET_DESCRIPTOR request in milliseconds
(default 5000 = 5.0 seconds).
usbcore.nousb [USB] Disable the USB subsystem
--
2.16.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC 01/10] PCI: dwc: Add MSI-X callbacks handler
From: Kishon Vijay Abraham I @ 2018-04-16 9:29 UTC (permalink / raw)
To: Gustavo Pimentel, bhelgaas, lorenzo.pieralisi, Joao.Pinto,
jingoohan1, adouglas, niklas.cassel, jesper.nilsson
Cc: linux-pci, linux-doc, linux-kernel
In-Reply-To: <77b7b2687e9618d3f7d1f11c3fc6ecec9a9442ef.1523379766.git.gustavo.pimentel@synopsys.com>
Hi Gustavo,
On Tuesday 10 April 2018 10:44 PM, Gustavo Pimentel wrote:
> Changes the pcie_raise_irq function signature, namely the interrupt_num
> variable type from u8 to u16 to accommodate the MSI-X maximum interrupts
> of 2048.
>
> Implements a PCIe config space capability iterator function to search and
> save the MSI and MSI-X pointers. With this method the code becomes more
> generic and flexible.
>
> Implements MSI-X set/get functions for sysfs interface in order to change
> the EP entries number.
>
> Implements EP MSI-X interface for triggering interruptions.
>
> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
> ---
> drivers/pci/dwc/pci-dra7xx.c | 2 +-
> drivers/pci/dwc/pcie-artpec6.c | 2 +-
> drivers/pci/dwc/pcie-designware-ep.c | 145 ++++++++++++++++++++++++++++++++-
> drivers/pci/dwc/pcie-designware-plat.c | 6 +-
> drivers/pci/dwc/pcie-designware.h | 23 +++++-
> 5 files changed, 173 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/dwc/pci-dra7xx.c b/drivers/pci/dwc/pci-dra7xx.c
> index ed8558d..5265725 100644
> --- a/drivers/pci/dwc/pci-dra7xx.c
> +++ b/drivers/pci/dwc/pci-dra7xx.c
> @@ -369,7 +369,7 @@ static void dra7xx_pcie_raise_msi_irq(struct dra7xx_pcie *dra7xx,
> }
>
> static int dra7xx_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> - enum pci_epc_irq_type type, u8 interrupt_num)
> + enum pci_epc_irq_type type, u16 interrupt_num)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pci);
> diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
> index e66cede..96dc259 100644
> --- a/drivers/pci/dwc/pcie-artpec6.c
> +++ b/drivers/pci/dwc/pcie-artpec6.c
> @@ -428,7 +428,7 @@ static void artpec6_pcie_ep_init(struct dw_pcie_ep *ep)
> }
>
> static int artpec6_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> - enum pci_epc_irq_type type, u8 interrupt_num)
> + enum pci_epc_irq_type type, u16 interrupt_num)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c b/drivers/pci/dwc/pcie-designware-ep.c
> index 15b22a6..874d4c2 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -40,6 +40,44 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> __dw_pcie_ep_reset_bar(pci, bar, 0);
> }
>
> +void dw_pcie_ep_find_cap_addr(struct dw_pcie_ep *ep)
> +{
This should be implemented in a generic way similar to pci_find_capability().
It'll be useful when we try to implement other capabilities as well.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning
From: Boqun Feng @ 2018-04-16 6:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, Peter Zijlstra, Ingo Molnar, Andrea Parri,
Paul E. McKenney, Jonathan Corbet, open list:DOCUMENTATION
In-Reply-To: <0ed9bece-4e63-de49-8be5-0ebab83c9769@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 9317 bytes --]
On Sat, Apr 14, 2018 at 05:38:54PM -0700, Randy Dunlap wrote:
> Hi,
>
Hello Randy,
> Just a few typos etc. below...
>
Thanks! I fixed those typos according to your comments.
> On 04/11/2018 06:50 AM, Boqun Feng wrote:
> > Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> > ---
> > Documentation/locking/lockdep-design.txt | 178 +++++++++++++++++++++++++++++++
> > 1 file changed, 178 insertions(+)
> >
> > diff --git a/Documentation/locking/lockdep-design.txt b/Documentation/locking/lockdep-design.txt
> > index 9de1c158d44c..6bb9e90e2c4f 100644
> > --- a/Documentation/locking/lockdep-design.txt
> > +++ b/Documentation/locking/lockdep-design.txt
> > @@ -284,3 +284,181 @@ Run the command and save the output, then compare against the output from
> > a later run of this command to identify the leakers. This same output
> > can also help you find situations where runtime lock initialization has
> > been omitted.
> > +
> > +Recursive read locks:
> > +---------------------
> > +
> > +Lockdep now is equipped with deadlock detection for recursive read locks.
> > +
> > +Recursive read locks, as their name indicates, are the locks able to be
> > +acquired recursively. Unlike non-recursive read locks, recursive read locks
> > +only get blocked by current write lock *holders* other than write lock
> > +*waiters*, for example:
> > +
> > + TASK A: TASK B:
> > +
> > + read_lock(X);
> > +
> > + write_lock(X);
> > +
> > + read_lock(X);
> > +
> > +is not a deadlock for recursive read locks, as while the task B is waiting for
> > +the lock X, the second read_lock() doesn't need to wait because it's a recursive
> > +read lock. However if the read_lock() is non-recursive read lock, then the above
> > +case is a deadlock, because even if the write_lock() in TASK B can not get the
> > +lock, but it can block the second read_lock() in TASK A.
> > +
> > +Note that a lock can be a write lock (exclusive lock), a non-recursive read
> > +lock (non-recursive shared lock) or a recursive read lock (recursive shared
> > +lock), depending on the lock operations used to acquire it (more specifically,
> > +the value of the 'read' parameter for lock_acquire()). In other words, a single
> > +lock instance has three types of acquisition depending on the acquisition
> > +functions: exclusive, non-recursive read, and recursive read.
> > +
> > +To be concise, we call that write locks and non-recursive read locks as
> > +"non-recursive" locks and recursive read locks as "recursive" locks.
> > +
> > +Recursive locks don't block each other, while non-recursive locks do (this is
> > +even true for two non-recursive read locks). A non-recursive lock can block the
> > +corresponding recursive lock, and vice versa.
> > +
> > +A deadlock case with recursive locks involved is as follow:
> > +
> > + TASK A: TASK B:
> > +
> > + read_lock(X);
> > + read_lock(Y);
> > + write_lock(Y);
> > + write_lock(X);
> > +
> > +Task A is waiting for task B to read_unlock() Y and task B is waiting for task
> > +A to read_unlock() X.
> > +
> > +Dependency types and strong dependency paths:
> > +---------------------------------------------
> > +In order to detect deadlocks as above, lockdep needs to track different dependencies.
> > +There are 4 categories for dependency edges in the lockdep graph:
> > +
> > +1) -(NN)->: non-recursive to non-recursive dependency. "X -(NN)-> Y" means
> > + X -> Y and both X and Y are non-recursive locks.
> > +
> > +2) -(RN)->: recursive to non-recursive dependency. "X -(RN)-> Y" means
> > + X -> Y and X is recursive read lock and Y is non-recursive lock.
> > +
> > +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means
> > + X -> Y and X is non-recursive lock and Y is recursive lock.
> > +
> > +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means
> > + X -> Y and both X and Y are recursive locks.
> > +
> > +Note that given two locks, they may have multiple dependencies between them, for example:
> > +
> > + TASK A:
> > +
> > + read_lock(X);
> > + write_lock(Y);
> > + ...
> > +
> > + TASK B:
> > +
> > + write_lock(X);
> > + write_lock(Y);
> > +
> > +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> > +
> > +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for -(N*)->,
> > +-(*R)-> and -(R*)->
> > +
> > +A "path" is a series of conjunct dependency edges in the graph. And we define a
> > +"strong" path, which indicates the strong dependency throughout each dependency
> > +in the path, as the path that doesn't have two conjunct edges (dependencies) as
> > +-(*R)-> and -(R*)->. In other words, a "strong" path is a path from a lock
> > +walking to another through the lock dependencies, and if X -> Y -> Z in the
> > +path (where X, Y, Z are locks), if the walk from X to Y is through a -(NR)-> or
> > +-(RR)-> dependency, the walk from Y to Z must not be through a -(RN)-> or
> > +-(RR)-> dependency, otherwise it's not a strong path.
> > +
> > +We will see why the path is called "strong" in next section.
> > +
> > +Recursive Read Deadlock Detection:
> > +----------------------------------
> > +
> > +We now prove two things:
> > +
> > +Lemma 1:
> > +
> > +If there is a closed strong path (i.e. a strong cirle), then there is a
>
> ?? circle
>
> > +combination of locking sequences that causes deadlock. I.e. a strong circle is
> > +sufficient for deadlock detection.
> > +
> > +Lemma 2:
> > +
> > +If there is no closed strong path (i.e. strong cirle), then there is no
>
> ?? circle
>
> > +combination of locking sequences that could cause deadlock. I.e. strong
> > +circles are necessary for deadlock detection.
> > +
> > +With these two Lemmas, we can easily say a closed strong path is both sufficient
> > +and necessary for deadlocks, therefore a closed strong path is equivalent to
> > +deadlock possibility. As a closed strong path stands for a dependency chain that
> > +could cause deadlocks, so we call it "strong", considering there are dependency
> > +circles that won't cause deadlocks.
> > +
> > +Proof for sufficiency (Lemma 1):
> > +
> > +Let's say we have a strong cirlce:
>
> circle:
>
> > +
> > + L1 -> L2 ... -> Ln -> L1
> > +
> > +, which means we have dependencies:
> > +
> > + L1 -> L2
> > + L2 -> L3
> > + ...
> > + Ln-1 -> Ln
> > + Ln -> L1
> > +
> > +We now can construct a combination of locking sequences that cause deadlock:
> > +
> > +Firstly let's make one CPU/task get the L1 in L1 -> L2, and then another get
> > +the L2 in L2 -> L3, and so on. After this, all of the Lx in Lx -> Lx+1 are
> > +held by different CPU/tasks.
> > +
> > +And then because we have L1 -> L2, so the holder of L1 is going to acquire L2
> > +in L1 -> L2, however since L2 is already held by another CPU/task, plus L1 ->
> > +L2 and L2 -> L3 are not *R and R* (the definition of strong), therefore the
> > +holder of L1 can not get L2, it has to wait L2's holder to release.
> > +
> > +Moreover, we can have a similar conclusion for L2's holder: it has to wait L3's
> > +holder to release, and so on. We now can proof that Lx's holder has to wait for
>
> prove
>
> > +Lx+1's holder to release, and note that Ln+1 is L1, so we have a circular
> > +waiting scenario and nobody can get progress, therefore a deadlock.
> > +
> > +Proof for necessary (Lemma 2):
> > +
> > +Lemma 2 is equivalent to: If there is a deadlock scenario, then there must be a
> > +strong circle in the dependency graph.
> > +
> > +According to Wikipedia[1], if there is a deadlock, then there must be a circular
> > +waiting scenario, means there are N CPU/tasks, where CPU/task P1 is waiting for
> > +a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waiting
> > +for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting
> > +for L1 and holding Ln, so we will have Ln -> L1 in the dependency graph. Similarly,
> > +we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we
> > +have a circle:
> > +
> > + Ln -> L1 -> L2 -> ... -> Ln
> > +
> > +, and now let's prove the circle is strong:
> > +
> > +For a lock Lx, Px contributes the dependency Lx-1 -> Lx and Px+1 contributes
> > +the dependency Lx -> Lx+1, and since Px is waiting for Px+1 to release Lx,
> > +so Lx can not be both recursive in Lx -> Lx+1 and Lx-1 -> Lx, because recursive
> > +locks don't block each other, therefore Lx-1 -> Lx and Lx -> Lx+1 can not be a
> > +-(*R)-> -(R*)-> pair, and this is true for any lock in the circle, therefore,
> > +the circle is strong.
> > +
> > +References:
> > +-----------
> > +[1]: https://en.wikipedia.org/wiki/Deadlock
> > +[2]: Shibu, K. (2009). Intro To Embedded Systems (1st ed.). Tata McGraw-Hill
> >
> I would also change all /can not/ to /cannot/...
Agreed. I will use 'cannot' for any future version, thanks a lot!
Regards,
Boqun
>
> --
> ~Randy
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/5] FireWire: clean up kernel-doc, add Documentation chapter
From: Takashi Sakamoto @ 2018-04-16 2:10 UTC (permalink / raw)
To: Randy Dunlap, linux1394-devel; +Cc: Stefan Richter, linux-doc, Randy Dunlap
In-Reply-To: <20180414012722.17420-1-rd.dunlab@gmail.com>
Hi,
On Apr 14 2018 10:27, Randy Dunlap wrote:
> This patch series cleans up kernel-doc warnings in several
> FireWire source files and then adds a Documentation driver-api
> chapter for FireWire.
>
> [PATCH v3 1/5] FireWire: clean up firewire-cdev.h kernel-doc
> [PATCH v3 2/5] FireWire: clean up core-iso.c kernel-doc
> [PATCH v3 3/5] FireWire: clean up core-transaction.c kernel-doc
> [PATCH v3 4/5] FireWire: add a Documentation driver-api chapter
> [PATCH v3 5/5] FireWire: add driver-api Introduction section
>
> Documentation/driver-api/firewire.rst | 50 +++++++++++++++++++++++-
> Documentation/driver-api/index.rst | 1
> drivers/firewire/core-iso.c | 7 +++
> drivers/firewire/core-transaction.c | 10 ++++
> include/uapi/linux/firewire-cdev.h | 22 ++++++----
> 5 files changed, 81 insertions(+), 9 deletions(-)
I reviewed all of the five patches.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
We're on development cycle for v4.18. Your patchset will be merged into
mainline in next merge window by pull request from Stefan.
Thanks
Takashi Sakamoto
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] filter.txt: update 'tools/net/' to 'tools/bpf/'
From: David Miller @ 2018-04-16 0:45 UTC (permalink / raw)
To: shhuiw; +Cc: ast, daniel, corbet, netdev, linux-doc
In-Reply-To: <20180415080712.2213-1-shhuiw@foxmail.com>
From: Wang Sheng-Hui <shhuiw@foxmail.com>
Date: Sun, 15 Apr 2018 16:07:12 +0800
> The tools are located at tootls/bpf/ instead of tools/net/.
> Update the filter.txt doc.
>
> Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com>
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] VFS: simplify seq_file iteration code and interface
From: NeilBrown @ 2018-04-15 22:42 UTC (permalink / raw)
To: Alexander Viro, Jonathan Corbet; +Cc: linux-doc, linux-kernel, linux-fsdevel
[-- Attachment #1: Type: text/plain, Size: 11207 bytes --]
The documentation for seq_file suggests that it is necessary to be
able to move the iterator to a given offset, however that is not the
case. If the iterator is stored in the private data and is stable
from one read() syscall to the next, it is only necessary to support
first/next interactions. Implementing this in a client is a little
clumsy.
- if ->start() is given a pos of zero, it should go to start of
sequence.
- if ->start() is given the name pos that was given to the most recent
next() or start(), it should restore the iterator to state just
before that last call
- if ->start is given another number, it should set the iterator one
beyond the start just before the last ->start or ->next call.
Also, the documentation says that the implementation can interpret the
pos however it likes (other than zero meaning start), but seq_file
increments the pos sometimes which does impose on the implementation.
This patch simplifies the interface for first/next iteration and
simplifies the code, while maintaining complete backward
compatability. Now:
- if ->start() is given a pos of zero, it should return an iterator
placed at the start of the sequence
- if ->start() is given a non-zero pos, it should return the iterator
in the same state it was after the last ->start or ->next.
This is particularly useful for interators which walk the multiple
chains in a hash table, e.g. using rhashtable_walk*. See
fs/gfs2/glock.c and drivers/staging/lustre/lustre/llite/vvp_dev.c
A large part of achieving this is to *always* call ->next after ->show
has successfully stored all of an entry in the buffer. Never just
increment the index instead.
Also:
- always pass &m->index to ->start() and ->next(), never a temp
variable
- don't clear ->from when ->count is zero, as ->from is dead when
->count is zero.
Some ->next functions do not increment *pos when they return NULL.
To maintain compatability with this, we still need to increment
m->index in one place, if ->next didn't increment it.
Note that such ->next functions are buggy and should be fixed.
A simple demonstration is
dd if=/proc/swaps bs=1000 skip=1
Choose any block size larger than the size of /proc/swaps.
This will always show the whole last line of /proc/swaps.
This patch doesn't work around buggy next() functions for this case.
Signed-off-by: NeilBrown <neilb@suse.com>
---
Documentation/filesystems/seq_file.txt | 63 ++++++++++++++++++++++------------
fs/seq_file.c | 53 +++++++++++-----------------
2 files changed, 62 insertions(+), 54 deletions(-)
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index 9de4303201e1..d412b236a9d6 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -66,23 +66,39 @@ kernel 3.10. Current versions require the following update
The iterator interface
-Modules implementing a virtual file with seq_file must implement a simple
-iterator object that allows stepping through the data of interest.
-Iterators must be able to move to a specific position - like the file they
-implement - but the interpretation of that position is up to the iterator
-itself. A seq_file implementation that is formatting firewall rules, for
-example, could interpret position N as the Nth rule in the chain.
-Positioning can thus be done in whatever way makes the most sense for the
-generator of the data, which need not be aware of how a position translates
-to an offset in the virtual file. The one obvious exception is that a
-position of zero should indicate the beginning of the file.
+Modules implementing a virtual file with seq_file must implement an
+iterator object that allows stepping through the data of interest
+during a "session" (roughly one read() system call). If the iterator
+is able to move to a specific position - like the file they implement,
+though with freedom to map the position number to a sequence location
+in whatever way is convenient - the iterator need only exist
+transiently during a session. If the iterator cannot easily find a
+numerical position but works well with a first/next interface, the
+iterator can be stored in the private data area and continue from one
+session to the next.
+
+A seq_file implementation that is formatting firewall rules from a
+table, for example, could provide a simple iterator that interprets
+position N as the Nth rule in the chain. A seq_file implementation
+that presents the content of a, potentially volatile, linked list
+might record a pointer into that list, providing that can be done
+without risk of the current location being removed.
+
+Positioning can thus be done in whatever way makes the most sense for
+the generator of the data, which need not be aware of how a position
+translates to an offset in the virtual file. The one obvious exception
+is that a position of zero should indicate the beginning of the file.
The /proc/sequence iterator just uses the count of the next number it
will output as its position.
-Four functions must be implemented to make the iterator work. The first,
-called start() takes a position as an argument and returns an iterator
-which will start reading at that position. For our simple sequence example,
+Four functions must be implemented to make the iterator work. The
+first, called start(), starts a session and takes a position as an
+argument, returning an iterator which will start reading at that
+position. The pos passed to start() will always be either zero, or
+the most recent pos used in the previous session.
+
+For our simple sequence example,
the start() function looks like:
static void *ct_seq_start(struct seq_file *s, loff_t *pos)
@@ -101,11 +117,12 @@ implementations; in most cases the start() function should check for a
"past end of file" condition and return NULL if need be.
For more complicated applications, the private field of the seq_file
-structure can be used. There is also a special value which can be returned
-by the start() function called SEQ_START_TOKEN; it can be used if you wish
-to instruct your show() function (described below) to print a header at the
-top of the output. SEQ_START_TOKEN should only be used if the offset is
-zero, however.
+structure can be used to hold state from session to session. There is
+also a special value which can be returned by the start() function
+called SEQ_START_TOKEN; it can be used if you wish to instruct your
+show() function (described below) to print a header at the top of the
+output. SEQ_START_TOKEN should only be used if the offset is zero,
+however.
The next function to implement is called, amazingly, next(); its job is to
move the iterator forward to the next position in the sequence. The
@@ -121,9 +138,13 @@ complete. Here's the example version:
return spos;
}
-The stop() function is called when iteration is complete; its job, of
-course, is to clean up. If dynamic memory is allocated for the iterator,
-stop() is the place to free it.
+The stop() function closes a session; its job, of course, is to clean
+up. If dynamic memory is allocated for the iterator, stop() is the
+place to free it; if a lock was taken by start(), stop() must release
+that lock. The value that *pos was set to by the last next() call
+before stop() is remembered, and used for the first start() call of
+the next session unless lseek() has been called on the file; in that
+case next start() will be asked to start at position zero.
static void ct_seq_stop(struct seq_file *s, void *v)
{
diff --git a/fs/seq_file.c b/fs/seq_file.c
index eea09f6d8830..fe030a0777d0 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -87,23 +87,22 @@ EXPORT_SYMBOL(seq_open);
static int traverse(struct seq_file *m, loff_t offset)
{
- loff_t pos = 0, index;
+ loff_t pos = 0;
int error = 0;
void *p;
m->version = 0;
- index = 0;
+ m->index = 0;
m->count = m->from = 0;
- if (!offset) {
- m->index = index;
+ if (!offset)
return 0;
- }
+
if (!m->buf) {
m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
if (!m->buf)
return -ENOMEM;
}
- p = m->op->start(m, &index);
+ p = m->op->start(m, &m->index);
while (p) {
error = PTR_ERR(p);
if (IS_ERR(p))
@@ -120,20 +119,15 @@ static int traverse(struct seq_file *m, loff_t offset)
if (pos + m->count > offset) {
m->from = offset - pos;
m->count -= m->from;
- m->index = index;
break;
}
pos += m->count;
m->count = 0;
- if (pos == offset) {
- index++;
- m->index = index;
+ p = m->op->next(m, p, &m->index);
+ if (pos == offset)
break;
- }
- p = m->op->next(m, p, &index);
}
m->op->stop(m, p);
- m->index = index;
return error;
Eoverflow:
@@ -157,7 +151,6 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
{
struct seq_file *m = file->private_data;
size_t copied = 0;
- loff_t pos;
size_t n;
void *p;
int err = 0;
@@ -220,16 +213,11 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
size -= n;
buf += n;
copied += n;
- if (!m->count) {
- m->from = 0;
- m->index++;
- }
if (!size)
goto Done;
}
/* we need at least one record in buffer */
- pos = m->index;
- p = m->op->start(m, &pos);
+ p = m->op->start(m, &m->index);
while (1) {
err = PTR_ERR(p);
if (!p || IS_ERR(p))
@@ -240,8 +228,7 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
if (unlikely(err))
m->count = 0;
if (unlikely(!m->count)) {
- p = m->op->next(m, p, &pos);
- m->index = pos;
+ p = m->op->next(m, p, &m->index);
continue;
}
if (m->count < m->size)
@@ -253,29 +240,33 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
if (!m->buf)
goto Enomem;
m->version = 0;
- pos = m->index;
- p = m->op->start(m, &pos);
+ p = m->op->start(m, &m->index);
}
m->op->stop(m, p);
m->count = 0;
goto Done;
Fill:
/* they want more? let's try to get some more */
- while (m->count < size) {
+ while (1) {
size_t offs = m->count;
- loff_t next = pos;
- p = m->op->next(m, p, &next);
+ loff_t pos = m->index;
+
+ p = m->op->next(m, p, &m->index);
+ if (pos == m->index)
+ /* Buggy ->next function */
+ m->index++;
if (!p || IS_ERR(p)) {
err = PTR_ERR(p);
break;
}
+ if (m->count >= size)
+ break;
err = m->op->show(m, p);
if (seq_has_overflowed(m) || err) {
m->count = offs;
if (likely(err <= 0))
break;
}
- pos = next;
}
m->op->stop(m, p);
n = min(m->count, size);
@@ -284,11 +275,7 @@ ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t *ppos)
goto Efault;
copied += n;
m->count -= n;
- if (m->count)
- m->from = n;
- else
- pos++;
- m->index = pos;
+ m->from = n;
Done:
if (!copied)
copied = err;
--
2.14.0.rc0.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Mike Rapoport @ 2018-04-15 17:36 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Morton, Andrey Ryabinin, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Tony Luck, Fenghua Yu, Ralf Baechle,
James Hogan, Michael Ellerman, Alexander Viro, linux-kernel,
linux-doc, kasan-dev, linux-alpha, linux-ia64, linux-mips,
linuxppc-dev, linux-fsdevel, linux-mm
In-Reply-To: <20180413135551.0e6d1b12@lwn.net>
On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> Sorry for the silence, I'm pedaling as fast as I can, honest...
>
> On Sun, 1 Apr 2018 09:38:58 +0300
> Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
>
> > My thinking was to start with mechanical RST conversion and then to start
> > working on the contents and ordering of the documentation. Some of the
> > existing files, e.g. ksm.txt, can be moved as is into the appropriate
> > places, others, like transhuge.txt should be at least split into admin/user
> > and developer guides.
> >
> > Another problem with many of the existing mm docs is that they are rather
> > developer notes and it wouldn't be really straight forward to assign them
> > to a particular topic.
>
> All this sounds good.
>
> > I believe that keeping the mm docs together will give better visibility of
> > what (little) mm documentation we have and will make the updates easier.
> > The documents that fit well into a certain topic could be linked there. For
> > instance:
>
> ...but this sounds like just the opposite...?
>
> I've had this conversation with folks in a number of subsystems.
> Everybody wants to keep their documentation together in one place - it's
> easier for the developers after all. But for the readers I think it's
> objectively worse. It perpetuates the mess that Documentation/ is, and
> forces readers to go digging through all kinds of inappropriate material
> in the hope of finding something that tells them what they need to know.
>
> So I would *really* like to split the documentation by audience, as has
> been done for a number of other kernel subsystems (and eventually all, I
> hope).
>
> I can go ahead and apply the RST conversion, that seems like a step in
> the right direction regardless. But I sure hope we don't really have to
> keep it as an unorganized jumble of stuff...
I didn't mean we should keep it as unorganized jumble of stuff and I agree
that splitting the documentation by audience is better because developers
are already know how to find it :)
I just thought that putting the doc into the place should not be done
immediately after mechanical ReST conversion but rather after improving the
contents. Although I'd agree that part of the documentation in
Documentation/vm is in pretty good shape already.
> Thanks,
>
> jon
>
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Mike Rapoport @ 2018-04-15 17:29 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jonathan Corbet, Andrew Morton, Andrey Ryabinin,
Richard Henderson, Ivan Kokshaysky, Matt Turner, Tony Luck,
Fenghua Yu, Ralf Baechle, James Hogan, Michael Ellerman,
Alexander Viro, linux-kernel, linux-doc, kasan-dev, linux-alpha,
linux-ia64, linux-mips, linuxppc-dev, linux-fsdevel, linux-mm
In-Reply-To: <20180413202108.GA30271@bombadil.infradead.org>
On Fri, Apr 13, 2018 at 01:21:08PM -0700, Matthew Wilcox wrote:
> On Fri, Apr 13, 2018 at 01:55:51PM -0600, Jonathan Corbet wrote:
> > > I believe that keeping the mm docs together will give better visibility of
> > > what (little) mm documentation we have and will make the updates easier.
> > > The documents that fit well into a certain topic could be linked there. For
> > > instance:
> >
> > ...but this sounds like just the opposite...?
> >
> > I've had this conversation with folks in a number of subsystems.
> > Everybody wants to keep their documentation together in one place - it's
> > easier for the developers after all. But for the readers I think it's
> > objectively worse. It perpetuates the mess that Documentation/ is, and
> > forces readers to go digging through all kinds of inappropriate material
> > in the hope of finding something that tells them what they need to know.
> >
> > So I would *really* like to split the documentation by audience, as has
> > been done for a number of other kernel subsystems (and eventually all, I
> > hope).
> >
> > I can go ahead and apply the RST conversion, that seems like a step in
> > the right direction regardless. But I sure hope we don't really have to
> > keep it as an unorganized jumble of stuff...
>
> I've started on Documentation/core-api/memory.rst which covers just
> memory allocation. So far it has the Overview and GFP flags sections
> written and an outline for 'The slab allocator', 'The page allocator',
> 'The vmalloc allocator' and 'The page_frag allocator'. And typing this
> up, I realise we need a 'The percpu allocator'. I'm thinking that this
> is *not* the right document for the DMA memory allocators (although it
> should link to that documentation).
>
> I suspect the existing Documentation/vm/ should probably stay as an
> unorganised jumble of stuff. Developers mostly talking to other MM
> developers. Stuff that people outside the MM fraternity should know
> about needs to be centrally documented. By all means convert it to
> ReST ... I don't much care, and it may make it easier to steal bits
> or link to it from the organised documentation.
The existing Documentation/vm contains different types of documents. Some
are indeed "Developers mostly talking to other MM developers". Some are
really user/administrator guides. Others are somewhat in between.
I took another look at what's there and I think we can actually move part
of Documentation/vm to Documentation/admin-guide. We can add
Documentation/admin-guide/vm/ and title it "Memory Management Tuning" or
something like that. And several files, e.g. hugetlbpage, ksm, soft-dirty
can be moved there.
--
Sincerely yours,
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] filter.txt: update 'tools/net/' to 'tools/bpf/'
From: Wang Sheng-Hui @ 2018-04-15 8:07 UTC (permalink / raw)
To: ast, daniel, corbet, netdev, linux-doc
The tools are located at tootls/bpf/ instead of tools/net/.
Update the filter.txt doc.
Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com>
---
Documentation/networking/filter.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index a4508ec1816b..fd55c7de9991 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -169,7 +169,7 @@ access to BPF code as well.
BPF engine and instruction set
------------------------------
-Under tools/net/ there's a small helper tool called bpf_asm which can
+Under tools/bpf/ there's a small helper tool called bpf_asm which can
be used to write low-level filters for example scenarios mentioned in the
previous section. Asm-like syntax mentioned here has been implemented in
bpf_asm and will be used for further explanations (instead of dealing with
@@ -359,7 +359,7 @@ $ ./bpf_asm -c foo
In particular, as usage with xt_bpf or cls_bpf can result in more complex BPF
filters that might not be obvious at first, it's good to test filters before
attaching to a live system. For that purpose, there's a small tool called
-bpf_dbg under tools/net/ in the kernel source directory. This debugger allows
+bpf_dbg under tools/bpf/ in the kernel source directory. This debugger allows
for testing BPF filters against given pcap files, single stepping through the
BPF code on the pcap's packets and to do BPF machine register dumps.
@@ -483,7 +483,7 @@ Example output from dmesg:
[ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00
[ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3
-In the kernel source tree under tools/net/, there's bpf_jit_disasm for
+In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
generating disassembly out of the kernel log's hexdump:
# ./bpf_jit_disasm
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC tip/locking/lockdep v6 01/20] lockdep/Documention: Recursive read lock detection reasoning
From: Randy Dunlap @ 2018-04-15 0:38 UTC (permalink / raw)
To: Boqun Feng, linux-kernel
Cc: Peter Zijlstra, Ingo Molnar, Andrea Parri, Paul E. McKenney,
Jonathan Corbet, open list:DOCUMENTATION
In-Reply-To: <20180411135110.9217-2-boqun.feng@gmail.com>
Hi,
Just a few typos etc. below...
On 04/11/2018 06:50 AM, Boqun Feng wrote:
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
> Documentation/locking/lockdep-design.txt | 178 +++++++++++++++++++++++++++++++
> 1 file changed, 178 insertions(+)
>
> diff --git a/Documentation/locking/lockdep-design.txt b/Documentation/locking/lockdep-design.txt
> index 9de1c158d44c..6bb9e90e2c4f 100644
> --- a/Documentation/locking/lockdep-design.txt
> +++ b/Documentation/locking/lockdep-design.txt
> @@ -284,3 +284,181 @@ Run the command and save the output, then compare against the output from
> a later run of this command to identify the leakers. This same output
> can also help you find situations where runtime lock initialization has
> been omitted.
> +
> +Recursive read locks:
> +---------------------
> +
> +Lockdep now is equipped with deadlock detection for recursive read locks.
> +
> +Recursive read locks, as their name indicates, are the locks able to be
> +acquired recursively. Unlike non-recursive read locks, recursive read locks
> +only get blocked by current write lock *holders* other than write lock
> +*waiters*, for example:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> +
> + write_lock(X);
> +
> + read_lock(X);
> +
> +is not a deadlock for recursive read locks, as while the task B is waiting for
> +the lock X, the second read_lock() doesn't need to wait because it's a recursive
> +read lock. However if the read_lock() is non-recursive read lock, then the above
> +case is a deadlock, because even if the write_lock() in TASK B can not get the
> +lock, but it can block the second read_lock() in TASK A.
> +
> +Note that a lock can be a write lock (exclusive lock), a non-recursive read
> +lock (non-recursive shared lock) or a recursive read lock (recursive shared
> +lock), depending on the lock operations used to acquire it (more specifically,
> +the value of the 'read' parameter for lock_acquire()). In other words, a single
> +lock instance has three types of acquisition depending on the acquisition
> +functions: exclusive, non-recursive read, and recursive read.
> +
> +To be concise, we call that write locks and non-recursive read locks as
> +"non-recursive" locks and recursive read locks as "recursive" locks.
> +
> +Recursive locks don't block each other, while non-recursive locks do (this is
> +even true for two non-recursive read locks). A non-recursive lock can block the
> +corresponding recursive lock, and vice versa.
> +
> +A deadlock case with recursive locks involved is as follow:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> + read_lock(Y);
> + write_lock(Y);
> + write_lock(X);
> +
> +Task A is waiting for task B to read_unlock() Y and task B is waiting for task
> +A to read_unlock() X.
> +
> +Dependency types and strong dependency paths:
> +---------------------------------------------
> +In order to detect deadlocks as above, lockdep needs to track different dependencies.
> +There are 4 categories for dependency edges in the lockdep graph:
> +
> +1) -(NN)->: non-recursive to non-recursive dependency. "X -(NN)-> Y" means
> + X -> Y and both X and Y are non-recursive locks.
> +
> +2) -(RN)->: recursive to non-recursive dependency. "X -(RN)-> Y" means
> + X -> Y and X is recursive read lock and Y is non-recursive lock.
> +
> +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means
> + X -> Y and X is non-recursive lock and Y is recursive lock.
> +
> +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means
> + X -> Y and both X and Y are recursive locks.
> +
> +Note that given two locks, they may have multiple dependencies between them, for example:
> +
> + TASK A:
> +
> + read_lock(X);
> + write_lock(Y);
> + ...
> +
> + TASK B:
> +
> + write_lock(X);
> + write_lock(Y);
> +
> +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> +
> +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for -(N*)->,
> +-(*R)-> and -(R*)->
> +
> +A "path" is a series of conjunct dependency edges in the graph. And we define a
> +"strong" path, which indicates the strong dependency throughout each dependency
> +in the path, as the path that doesn't have two conjunct edges (dependencies) as
> +-(*R)-> and -(R*)->. In other words, a "strong" path is a path from a lock
> +walking to another through the lock dependencies, and if X -> Y -> Z in the
> +path (where X, Y, Z are locks), if the walk from X to Y is through a -(NR)-> or
> +-(RR)-> dependency, the walk from Y to Z must not be through a -(RN)-> or
> +-(RR)-> dependency, otherwise it's not a strong path.
> +
> +We will see why the path is called "strong" in next section.
> +
> +Recursive Read Deadlock Detection:
> +----------------------------------
> +
> +We now prove two things:
> +
> +Lemma 1:
> +
> +If there is a closed strong path (i.e. a strong cirle), then there is a
?? circle
> +combination of locking sequences that causes deadlock. I.e. a strong circle is
> +sufficient for deadlock detection.
> +
> +Lemma 2:
> +
> +If there is no closed strong path (i.e. strong cirle), then there is no
?? circle
> +combination of locking sequences that could cause deadlock. I.e. strong
> +circles are necessary for deadlock detection.
> +
> +With these two Lemmas, we can easily say a closed strong path is both sufficient
> +and necessary for deadlocks, therefore a closed strong path is equivalent to
> +deadlock possibility. As a closed strong path stands for a dependency chain that
> +could cause deadlocks, so we call it "strong", considering there are dependency
> +circles that won't cause deadlocks.
> +
> +Proof for sufficiency (Lemma 1):
> +
> +Let's say we have a strong cirlce:
circle:
> +
> + L1 -> L2 ... -> Ln -> L1
> +
> +, which means we have dependencies:
> +
> + L1 -> L2
> + L2 -> L3
> + ...
> + Ln-1 -> Ln
> + Ln -> L1
> +
> +We now can construct a combination of locking sequences that cause deadlock:
> +
> +Firstly let's make one CPU/task get the L1 in L1 -> L2, and then another get
> +the L2 in L2 -> L3, and so on. After this, all of the Lx in Lx -> Lx+1 are
> +held by different CPU/tasks.
> +
> +And then because we have L1 -> L2, so the holder of L1 is going to acquire L2
> +in L1 -> L2, however since L2 is already held by another CPU/task, plus L1 ->
> +L2 and L2 -> L3 are not *R and R* (the definition of strong), therefore the
> +holder of L1 can not get L2, it has to wait L2's holder to release.
> +
> +Moreover, we can have a similar conclusion for L2's holder: it has to wait L3's
> +holder to release, and so on. We now can proof that Lx's holder has to wait for
prove
> +Lx+1's holder to release, and note that Ln+1 is L1, so we have a circular
> +waiting scenario and nobody can get progress, therefore a deadlock.
> +
> +Proof for necessary (Lemma 2):
> +
> +Lemma 2 is equivalent to: If there is a deadlock scenario, then there must be a
> +strong circle in the dependency graph.
> +
> +According to Wikipedia[1], if there is a deadlock, then there must be a circular
> +waiting scenario, means there are N CPU/tasks, where CPU/task P1 is waiting for
> +a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waiting
> +for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting
> +for L1 and holding Ln, so we will have Ln -> L1 in the dependency graph. Similarly,
> +we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we
> +have a circle:
> +
> + Ln -> L1 -> L2 -> ... -> Ln
> +
> +, and now let's prove the circle is strong:
> +
> +For a lock Lx, Px contributes the dependency Lx-1 -> Lx and Px+1 contributes
> +the dependency Lx -> Lx+1, and since Px is waiting for Px+1 to release Lx,
> +so Lx can not be both recursive in Lx -> Lx+1 and Lx-1 -> Lx, because recursive
> +locks don't block each other, therefore Lx-1 -> Lx and Lx -> Lx+1 can not be a
> +-(*R)-> -(R*)-> pair, and this is true for any lock in the circle, therefore,
> +the circle is strong.
> +
> +References:
> +-----------
> +[1]: https://en.wikipedia.org/wiki/Deadlock
> +[2]: Shibu, K. (2009). Intro To Embedded Systems (1st ed.). Tata McGraw-Hill
>
I would also change all /can not/ to /cannot/...
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox