[PATCH 2/2] cpufreq: Documentation: Updates based on current code
The cpufreq core has gone though lots of updates in recent times, but on many occasions the documentation wasn't updated along with the code. This patch tries to catchup the documentation with the code. Also add Rafael and Viresh as the contributors to the documentation. Based on a patch from Claudio Scordino. Signed-off-by: Claudio Scordino Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/core.txt | 24 +++-- Documentation/cpu-freq/cpu-drivers.txt | 177 +-- Documentation/cpu-freq/cpufreq-stats.txt | 24 ++--- Documentation/cpu-freq/governors.txt | 117 +++- Documentation/cpu-freq/index.txt | 23 ++-- Documentation/cpu-freq/user-guide.txt| 60 ++- 6 files changed, 232 insertions(+), 193 deletions(-) diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index 4bc7287806de..978463a7c81e 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -8,6 +8,8 @@ Dominik Brodowski David Kimdon + Rafael J. Wysocki + Viresh Kumar @@ -36,10 +38,11 @@ speed limits (like LCD drivers on ARM architecture). Additionally, the kernel "constant" loops_per_jiffy is updated on frequency changes here. -Reference counting is done by cpufreq_get_cpu and cpufreq_put_cpu, -which make sure that the cpufreq processor driver is correctly -registered with the core, and will not be unloaded until -cpufreq_put_cpu is called. +Reference counting of the cpufreq policies is done by cpufreq_cpu_get +and cpufreq_cpu_put, which make sure that the cpufreq driver is +correctly registered with the core, and will not be unloaded until +cpufreq_put_cpu is called. That also ensures that the respective cpufreq +policy doesn't get freed while being used. 2. CPUFreq notifiers @@ -69,18 +72,16 @@ These are notified when a new policy is intended to be set. Each The phase is specified in the second argument to the notifier. The third argument, a void *pointer, points to a struct cpufreq_policy -consisting of five values: cpu, min, max, policy and max_cpu_freq. min -and max are the lower and upper frequencies (in kHz) of the new -policy, policy the new policy, cpu the number of the affected CPU; and -max_cpu_freq the maximum supported CPU frequency. This value is given -for informational purposes only. +consisting of several values, including min, max (the lower and upper +frequencies (in kHz) of the new policy). 2.2 CPUFreq transition notifiers -These are notified twice when the CPUfreq driver switches the CPU core -frequency and this change has any external implications. +These are notified twice for each online CPU in the policy, when the +CPUfreq driver switches the CPU core frequency and this change has no +any external implications. The second argument specifies the phase - CPUFREQ_PRECHANGE or CPUFREQ_POSTCHANGE. @@ -90,6 +91,7 @@ The third argument is a struct cpufreq_freqs with the following cpu- number of the affected CPU old- old frequency new- new frequency +flags - flags of the cpufreq driver 3. CPUFreq Table Generation with Operating Performance Point (OPP) == diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 772b94fde264..f71e6be26b83 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -9,6 +9,8 @@ Dominik Brodowski + Rafael J. Wysocki + Viresh Kumar @@ -49,49 +51,65 @@ using cpufreq_register_driver() What shall this struct cpufreq_driver contain? -cpufreq_driver.name - The name of this driver. + .name - The name of this driver. -cpufreq_driver.init - A pointer to the per-CPU initialization - function. + .init - A pointer to the per-policy initialization function. -cpufreq_driver.verify -A pointer to a "verification" function. + .verify - A pointer to a "verification" function. -cpufreq_driver.setpolicy _or_ -cpufreq_driver.target/ -target_index - See below on the differences. + .setpolicy _or_ .fast_switch _or_ .target _or_ .target_index - See + below on the differences. And optionally -cpufreq_driver.exit - A pointer to a per-CPU cleanup - function called during CPU_POST_DEAD - phase of cpu hotplug process. + .flags - Hints for the cpufreq core. -cpufreq_driver.stop_cpu - A pointer to a per-CPU stop function - called during CPU_DOWN_PREPARE phase of - cpu hotplug process. + .driver_data - cpufreq driver specific data. -cpufreq_driver.resume -
[PATCH 1/2] cpufreq: Documentation: Minor reformatting
This patch doesn't change the content of the documentation, but rather reformat it to make it more readable. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/governors.txt | 205 +++ 1 file changed, 112 insertions(+), 93 deletions(-) diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index c15aa75f5227..63eef4cca1b7 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -111,82 +111,96 @@ directory. The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to -switch the frequency very quickly. There are a number of sysfs file -accessible parameters: - -sampling_rate: measured in uS (10^-6 seconds), this is how often you -want the kernel to look at the CPU usage and to make decisions on -what to do about the frequency. Typically this is set to values of -around '1' or more. It's default value is (cmp. with users-guide.txt): -transition_latency * 1000 -Be aware that transition latency is in ns and sampling_rate is in us, so you -get the same sysfs value by default. -Sampling rate should always get adjusted considering the transition latency -To set the sampling rate 750 times as high as the transition latency -in the bash (as said, 1000 is default), do: -echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \ ->ondemand/sampling_rate - -sampling_rate_min: -The sampling rate is limited by the HW transition latency: -transition_latency * 100 -Or by kernel restrictions: -If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed. -If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the -limits depend on the CONFIG_HZ option: -HZ=1000: min=2us (20ms) -HZ=250: min=8us (80ms) -HZ=100: min=20us (200ms) -The highest value of kernel and HW latency restrictions is shown and -used as the minimum sampling rate. - -up_threshold: defines what the average CPU usage between the samplings -of 'sampling_rate' needs to be for the kernel to make a decision on -whether it should increase the frequency. For example when it is set -to its default value of '95' it means that between the checking -intervals the CPU needs to be on average more than 95% in use to then -decide that the CPU frequency needs to be increased. - -ignore_nice_load: this parameter takes a value of '0' or '1'. When -set to '0' (its default), all processes are counted towards the -'cpu utilisation' value. When set to '1', the processes that are -run with a 'nice' value will not count (and thus be ignored) in the -overall usage calculation. This is useful if you are running a CPU -intensive calculation on your laptop that you do not care how long it -takes to complete as you can 'nice' it and prevent it from taking part -in the deciding process of whether to increase your CPU frequency. - -sampling_down_factor: this parameter controls the rate at which the -kernel makes a decision on when to decrease the frequency while running -at top speed. When set to 1 (the default) decisions to reevaluate load -are made at the same interval regardless of current clock speed. But -when set to greater than 1 (e.g. 100) it acts as a multiplier for the -scheduling interval for reevaluating load when the CPU is at its top -speed due to high load. This improves performance by reducing the overhead -of load evaluation and helping the CPU stay at its top speed when truly -busy, rather than shifting back and forth in speed. This tunable has no -effect on behavior at lower speeds/lower CPU loads. - -powersave_bias: this parameter takes a value between 0 to 1000. It -defines the percentage (times 10) value of the target frequency that -will be shaved off of the target. For example, when set to 100 -- 10%, -when ondemand governor would have targeted 1000 MHz, it will target -1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0 -(disabled) by default. -When AMD frequency sensitivity powersave bias driver -- -drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter -defines the workload frequency sensitivity threshold in which a lower -frequency is chosen instead of ondemand governor's original target. -The frequency sensitivity is a hardware reported (on AMD Family 16h -Processors and above) value between 0 to 100% that tells software how -the performance of the workload running on a CPU will change when -frequency changes. A workload with sensitivity of 0% (memory/IO-bound) -will not perform any better on higher core frequency, whereas a -workload with sensitivity of 100% (CPU-bound) will perform better -higher the frequency. When the driver is loaded, this is set to 400 -by default -- for CPUs running workloads with sensitivity value below -40%, a lower frequency is chosen. Unloading the driver or writing 0 -will disable this feature. +switch the frequency very quickly. + +Sysfs files: + +* sampling_rate: + + Measured in uS (10^-
[Resend][PATCH 2/3] PM / core / docs: Convert sleep states API document to reST
From: Rafael J. Wysocki
Move the document describing the system sleep state transitions API
for devices to Documentation/driver-api/pm/, convert it to reST and
update it to use current terminology. Also remove the remaining
reference to the old version of it from pm.h.
The new document still contains references to a couple of documents
in the .txt format that will be converted later.
Signed-off-by: Rafael J. Wysocki
---
Documentation/driver-api/index.rst |1
Documentation/driver-api/pm/conf.py | 10
Documentation/driver-api/pm/devices.rst | 729
Documentation/driver-api/pm/index.rst | 15
Documentation/driver-api/pm/types.rst |5
Documentation/power/devices.txt | 716 ---
include/linux/pm.h |3
7 files changed, 760 insertions(+), 719 deletions(-)
Index: linux-pm/Documentation/driver-api/pm/conf.py
===
--- /dev/null
+++ linux-pm/Documentation/driver-api/pm/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Device Power Management"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'pm.tex', project,
+ 'The kernel development community', 'manual'),
+]
Index: linux-pm/Documentation/driver-api/pm/index.rst
===
--- /dev/null
+++ linux-pm/Documentation/driver-api/pm/index.rst
@@ -0,0 +1,15 @@
+===
+Device Power Management
+===
+
+.. toctree::
+
+ types
+ devices
+
+.. only:: subproject and html
+
+ Indices
+ ===
+
+ * :ref:`genindex`
Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- /dev/null
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -0,0 +1,729 @@
+.. |struct| replace:: :c:type:`struct`
+
+==
+Device Power Management Basics
+==
+
+::
+
+ Copyright (c) 2010-2011 Rafael J. Wysocki , Novell Inc.
+ Copyright (c) 2010 Alan Stern
+ Copyright (c) 2016 Intel Corp., Rafael J. Wysocki
+
+Most of the code in Linux is device drivers, so most of the Linux power
+management (PM) code is also driver-specific. Most drivers will do very
+little; others, especially for platforms with small batteries (like cell
+phones), will do a lot.
+
+This writeup gives an overview of how drivers interact with system-wide
+power management goals, emphasizing the models and interfaces that are
+shared by everything that hooks up to the driver model core. Read it as
+background for the domain-specific work you'd do with any specific driver.
+
+
+Two Models for Device Power Management
+==
+
+Drivers will use one or both of these models to put devices into low-power
+states:
+
+System Sleep model:
+
+ Drivers can enter low-power states as part of entering system-wide
+ low-power states like "suspend" (also known as "suspend-to-RAM"), or
+ (mostly for systems with disks) "hibernation" (also known as
+ "suspend-to-disk").
+
+ This is something that device, bus, and class drivers collaborate on
+ by implementing various role-specific suspend and resume methods to
+ cleanly power down hardware and software subsystems, then reactivate
+ them without loss of data.
+
+ Some drivers can manage hardware wakeup events, which make the system
+ leave the low-power state. This feature may be enabled or disabled
+ using the relevant :file:`/sys/devices/.../power/wakeup` file (for
+ Ethernet drivers the ioctl interface used by ethtool may also be used
+ for this purpose); enabling it may cost some power usage, but let the
+ whole system enter low-power states more often.
+
+Runtime Power Management model:
+
+ Devices may also be put into low-power states while the system is
+ running, independently of other power management activity in principle.
+ However, devices are not generally independent of each other (for
+ example, a parent device cannot be suspended unless all of its child
+ devices have been suspended). Moreover, depending on the bus type the
+ device is on, it may be necessary to carry out some bus-specific
+ operations on the device for this purpose. Devices put into low power
+ states at run time may require special handling during system-wide power
+ transitions (suspend or hibernation).
+
+ For these reasons not only the device driver itself, but also the
+ appropriate subsystem (bus type, device type or device class) driver and
+ the PM core are involved in runtime power management. As in the system
+ sleep power management case, they need to collaborate by implementing
+ various role-specific suspend and resume methods, so that
[PATCH 0/3] PM / docs: linux/pm.h kerneldocs update and conversion of two docs to reST
Hi Everyone, I sent patches [1-2/3] previosly a couple of weeks ago and there have not been any comments since then, so either they are fine by everybody or the timing was particularly bad and no one had the time to look at them. Admittedly, the former is more attractive to me, so I'll assume that this is the case if there are no comments still this time. :-) Patch [1/3] updates kerneldoc comments in include/linux/pm.h (to make the documentation generated out of them look better), patch [2/3] converts Documentation/power/devices.txt to reST, and patch [3/3] does the same thing to Documentation/power/notifiers.txt (the new files go into the driver-api subdir and are hooked up to that manual). If the conversions can be done in a better way (with not much more effort), please let me know. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] PM / sleep / docs: Convert PM notifiers document to reST
From: Rafael J. Wysocki Move the document describing PM notifiers (used during system sleep state transitions) to Documentation/driver-api/pm/, convert it to reST and update it to (a) follow the actual code better and (b) use current terminology. Also replace the remaining references to the old version of it in .txt documents with references to the new one. Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/pm/devices.rst |2 Documentation/driver-api/pm/index.rst |1 Documentation/driver-api/pm/notifiers.rst | 70 ++ Documentation/power/00-INDEX |2 Documentation/power/freezing-of-tasks.txt |3 - Documentation/power/notifiers.txt | 55 --- Documentation/power/pci.txt |2 7 files changed, 75 insertions(+), 60 deletions(-) Index: linux-pm/Documentation/driver-api/pm/notifiers.rst === --- /dev/null +++ linux-pm/Documentation/driver-api/pm/notifiers.rst @@ -0,0 +1,70 @@ += +Suspend/Hibernation Notifiers += + +:: + + Copyright (c) 2016 Intel Corp., Rafael J. Wysocki + +There are some operations that subsystems or drivers may want to carry out +before hibernation/suspend or after restore/resume, but they require the system +to be fully functional, so the drivers' and subsystems' ``->suspend()`` and +``->resume()`` or even ``->prepare()`` and ``->complete()`` callbacks are not +suitable for this purpose. + +For example, device drivers may want to upload firmware to their devices after +resume/restore, but they cannot do it by calling :c:func:`request_firmware()` +from their ``->resume()`` or ``->complete()`` callback routines (user land +processes are frozen at these points). The solution may be to load the firmware +into memory before processes are frozen and upload it from there in the +``->resume()`` routine. A suspend/hibernation notifier may be used for that. + +Subsystems or drivers having such needs can register suspend notifiers that +will be called upon the following events by the PM core: + +``PM_HIBERNATION_PREPARE`` + The system is going to hibernate, tasks will be frozen immediately. This + is different from ``PM_SUSPEND_PREPARE`` below, because in this case + additional work is done between the notifiers and the invocation of PM + callbacks for the "freeze" transition. + +``PM_POST_HIBERNATION`` + The system memory state has been restored from a hibernation image or an + error occurred during hibernation. Device restore callbacks have been + executed and tasks have been thawed. + +``PM_RESTORE_PREPARE`` + The system is going to restore a hibernation image. If all goes well, + the restored image kernel will issue a ``PM_POST_HIBERNATION`` + notification. + +``PM_POST_RESTORE`` + An error occurred during restore from hibernation. Device restore + callbacks have been executed and tasks have been thawed. + +``PM_SUSPEND_PREPARE`` + The system is preparing for suspend. + +``PM_POST_SUSPEND`` + The system has just resumed or an error occurred during suspend. Device + resume callbacks have been executed and tasks have been thawed. + +It is generally assumed that whatever the notifiers do for +``PM_HIBERNATION_PREPARE``, should be undone for ``PM_POST_HIBERNATION``. +Analogously, operations carried out for ``PM_SUSPEND_PREPARE`` should be +reversed for ``PM_POST_SUSPEND``. + +Moreover, if one of the notifiers fails for the ``PM_HIBERNATION_PREPARE`` or +``PM_SUSPEND_PREPARE`` event, the notifiers that have already succeeded for that +event will be called for ``PM_POST_HIBERNATION`` or ``PM_POST_SUSPEND``, +respectively. + +The hibernation and suspend notifiers are called with :c:data:`pm_mutex` held. +They are defined in the usual way, but their last argument is meaningless (it is +always NULL). + +To register and/or unregister a suspend notifier use +:c:func:`register_pm_notifier()` and :c:func:`unregister_pm_notifier()`, +respectively (both defined in :file:`include/linux/suspend.h`). If you don't +need to unregister the notifier, you can also use the :c:func:`pm_notifier()` +macro defined in :file:`include/linux/suspend.h`. Index: linux-pm/Documentation/driver-api/pm/index.rst === --- linux-pm.orig/Documentation/driver-api/pm/index.rst +++ linux-pm/Documentation/driver-api/pm/index.rst @@ -6,6 +6,7 @@ Device Power Management types devices + notifiers .. only:: subproject and html Index: linux-pm/Documentation/driver-api/pm/devices.rst === --- linux-pm.orig/Documentation/driver-api/pm/devices.rst +++ linux-pm/Documentation/driver-api/pm/devices.rst @@ -617,7 +617,7 @@ been thawed. Generally speaking, the PM act
[Resend][PATCH 1/3] PM / core: Update kerneldoc comments in pm.h
From: Rafael J. Wysocki
Refresh the struct dev_pm_ops kerneldoc comment, so that it looks
better and is more readable after processing by Sphinx, and drop
the kerneldoc marker from a few other comments ("PM_EVENT_ messages"
and a couple of enum types declarations) which are not proper
kerneldoc and generally confuse Sphinx.
Also change the comment describing struct dev_pm_domain into
a kerneldoc one.
Signed-off-by: Rafael J. Wysocki
---
include/linux/pm.h | 113 ++---
1 file changed, 57 insertions(+), 56 deletions(-)
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -64,24 +64,7 @@ typedef struct pm_message {
} pm_message_t;
/**
- * struct dev_pm_ops - device PM callbacks
- *
- * Several device power state transitions are externally visible, affecting
- * the state of pending I/O queues and (for drivers that touch hardware)
- * interrupts, wakeups, DMA, and other hardware state. There may also be
- * internal transitions to various low-power modes which are transparent
- * to the rest of the driver stack (such as a driver that's ON gating off
- * clocks which are not in active use).
- *
- * The externally visible transitions are handled with the help of callbacks
- * included in this structure in such a way that two levels of callbacks are
- * involved. First, the PM core executes callbacks provided by PM domains,
- * device types, classes and bus types. They are the subsystem-level callbacks
- * supposed to execute callbacks provided by device drivers, although they may
- * choose not to do that. If the driver callbacks are executed, they have to
- * collaborate with the subsystem-level callbacks to achieve the goals
- * appropriate for the given system transition, given transition phase and the
- * subsystem the device belongs to.
+ * struct dev_pm_ops - device PM callbacks.
*
* @prepare: The principal role of this callback is to prevent new children of
* the device from being registered after it has returned (the driver's
@@ -240,34 +223,6 @@ typedef struct pm_message {
* driver's interrupt handler, which is guaranteed not to run while
* @restore_noirq() is being executed. Analogous to @resume_noirq().
*
- * All of the above callbacks, except for @complete(), return error codes.
- * However, the error codes returned by the resume operations, @resume(),
- * @thaw(), @restore(), @resume_noirq(), @thaw_noirq(), and @restore_noirq(),
do
- * not cause the PM core to abort the resume transition during which they are
- * returned. The error codes returned in those cases are only printed by the
PM
- * core to the system logs for debugging purposes. Still, it is recommended
- * that drivers only return error codes from their resume methods in case of an
- * unrecoverable failure (i.e. when the device being handled refuses to resume
- * and becomes unusable) to allow us to modify the PM core in the future, so
- * that it can avoid attempting to handle devices that failed to resume and
- * their children.
- *
- * It is allowed to unregister devices while the above callbacks are being
- * executed. However, a callback routine must NOT try to unregister the device
- * it was called for, although it may unregister children of that device (for
- * example, if it detects that a child was unplugged while the system was
- * asleep).
- *
- * Refer to Documentation/power/admin-guide/devices.rst for more information
about the role
- * of the above callbacks in the system suspend process.
- *
- * There also are callbacks related to runtime power management of devices.
- * Again, these callbacks are executed by the PM core only for subsystems
- * (PM domains, device types, classes and bus types) and the subsystem-level
- * callbacks are supposed to invoke the driver callbacks. Moreover, the exact
- * actions to be performed by a device driver's callbacks generally depend on
- * the platform and subsystem the device belongs to.
- *
* @runtime_suspend: Prepare the device for a condition in which it won't be
* able to communicate with the CPU(s) and RAM due to power management.
* This need not mean that the device should be put into a low-power state.
@@ -287,11 +242,54 @@ typedef struct pm_message {
* Check these conditions, and return 0 if it's appropriate to let the PM
* core queue a suspend request for the device.
*
- * Refer to Documentation/power/runtime_pm.txt for more information about the
- * role of the above callbacks in device runtime power management.
+ * Several device power state transitions are externally visible, affecting
+ * the state of pending I/O queues and (for drivers that touch hardware)
+ * interrupts, wakeups, DMA, and other hardware state. There may also be
+ * internal transitions to various low-power modes which are transparent
+ * to the rest of the dri
Re: [PATCH] docs: fix "interruptible" misspellings
On 01/05/17 14:21, Kees Cook wrote: > On Thu, Jun 9, 2016 at 1:11 PM, Joe Perches wrote: >> On Thu, 2016-06-09 at 13:29 -0600, Jonathan Corbet wrote: >>> On Wed, 18 May 2016 06:55:45 -0700 Kees Cook wrote: A common misspelling of "interruptible" is "interruptable". This fixes them in the tree and adds the two most common variations to spelling.txt. >> >> $ grep --include=*.[ch] -Proh "\b[A-Za-z]+[ai]ble\b" * | \ >> tr [:upper:] [:lower:] | sort | uniq >> >> gives several more that could be updated like: >> >> avaiable >> avaialable >> avaible >> available >> availible >> availlable >> avalable >> avalaible >> avaliable >> avalible >> avalilable >> aviable >> avialable >> avilable >> [] >> preemptable >> preemptible >> preemtible >> [] >> responsable >> responsible >> resposible >> [] >> unwritable >> unwriteable >> unwrittable >> updatable >> updateable >> upgradable >> upgradeable > > Oooh, yeah, these should get fixed too. Joe, do you have time to build > a full patch for them? > > -Kees > and assignement to correct spelling: assignment -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: fix "interruptible" misspellings
On Thu, Jun 9, 2016 at 12:29 PM, Jonathan Corbet wrote: > On Wed, 18 May 2016 06:55:45 -0700 > Kees Cook wrote: > >> A common misspelling of "interruptible" is "interruptable". This fixes >> them in the tree and adds the two most common variations to spelling.txt. >> >> Suggested-by: Randy Dunlap >> Signed-off-by: Kees Cook >> --- >> Documentation/hid/hiddev.txt | 2 +- >> Documentation/scsi/ChangeLog.lpfc | 2 +- >> Documentation/sysrq.txt | 2 +- >> arch/arc/include/asm/irqflags-arcv2.h | 2 +- >> arch/x86/platform/uv/tlb_uv.c | 2 +- >> drivers/firmware/qcom_scm-32.c| 2 +- >> drivers/gpu/drm/radeon/radeon_fence.c | 12 ++-- >> drivers/hid/Kconfig | 2 +- >> drivers/hid/usbhid/Kconfig| 2 +- >> drivers/input/serio/hil_mlc.c | 2 +- >> drivers/net/ethernet/amd/nmclan_cs.c | 4 ++-- >> drivers/scsi/aacraid/commsup.c| 2 +- >> drivers/tty/serial/mux.c | 2 +- >> fs/ecryptfs/miscdev.c | 2 +- >> mm/kmemleak.c | 2 +- >> scripts/spelling.txt | 2 ++ >> sound/soc/intel/atom/sst/sst_pvt.c| 2 +- >> 17 files changed, 24 insertions(+), 22 deletions(-) > > So I'm a bit nervous about taking this one; I don't normally feel that > the docs tree has the mandate to reach out into the rest of the kernel > this way. Sending them to maintainers individually wouldn't be much > fun. Maybe Jiri (CC'd) can take it for the trivial tree? Thread necromancy! Since this is all in comments, etc, it seems like it'd be okay to go via docs, but trivial is fine by me too. Jiri, can you take this, or should Jon? Thanks! -Kees -- Kees Cook Nexus Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: fix "interruptible" misspellings
On Thu, Jun 9, 2016 at 1:11 PM, Joe Perches wrote: > On Thu, 2016-06-09 at 13:29 -0600, Jonathan Corbet wrote: >> On Wed, 18 May 2016 06:55:45 -0700 Kees Cook wrote: >> > A common misspelling of "interruptible" is "interruptable". This fixes >> > them in the tree and adds the two most common variations to spelling.txt. > > $ grep --include=*.[ch] -Proh "\b[A-Za-z]+[ai]ble\b" * | \ > tr [:upper:] [:lower:] | sort | uniq > > gives several more that could be updated like: > > avaiable > avaialable > avaible > available > availible > availlable > avalable > avalaible > avaliable > avalible > avalilable > aviable > avialable > avilable > [] > preemptable > preemptible > preemtible > [] > responsable > responsible > resposible > [] > unwritable > unwriteable > unwrittable > updatable > updateable > upgradable > upgradeable Oooh, yeah, these should get fixed too. Joe, do you have time to build a full patch for them? -Kees -- Kees Cook Nexus Security -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
On Tue, Jan 03, 2017 at 10:19:29PM +0100, Arnd Bergmann wrote: > On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote: > > On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote: > > > The icn, act2000 and pcbit drivers are all for very old hardware, > > > and it is highly unlikely that anyone is actually still using them > > > on modern kernels, if at all. > > > > > > All three drivers apparently are for hardware that predates PCI > > > being the common connector, as they are ISA-only and active > > > PCI ISDN cards were widely available in the 1990s. > > > > > > Looking through the git logs, it I cannot find any indication of a > > > patch to any of these drivers that has been tested on real hardware, > > > only cleanups or global API changes. > > > > > > Signed-off-by: Arnd Bergmann > > > Acked-by: Karsten Keil > > > > This patch got added in the 4.6 kernel release. As I am now taking > > patches for 4.11-rc1, I figure it is time to just delete the > > drivers/staging/i4l/ directory now, given that no one has really done > > anything with it. If people show up that wish to maintain it, I'll be > > glad to revert it, or if someone really screams in the next week. > > Otherwise it's time to just move on > > Sounds good to me. Ok, now deleted! thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote: > On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote: > > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote: > > > On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote: > > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote: > > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time > > > > > detection of the task type. > > > > > > > > What's wrong with the run-time detection? If it's just to avoid a > > > > negligible overhead, I would rather keep the code simpler by avoiding > > > > duplicating the generic compat_sys_ptrace(). > > > > > > Nothing wrong. This is how Arnd asked me to do. You already asked this > > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html > > > > Hmm, I completely forgot about this ;). There is still an advantage to > > doing run-time checking if we avoid touching core code (less acks to > > gather and less code duplication). > > > > Let's see what Arnd says but the initial patch looked simpler. > > I don't currently have either version of the patch in my inbox > (the archive is on a different machine), but in general I'd still > think it's best to avoid the runtime check for aarch64-ilp32 > altogether. I'd have to look at the overall kernel source to > see if it's worth avoiding one or two instances though, or > if there are an overwhelming number of other checks that we > can't avoid at all. > > Regarding ptrace, I notice that arch/tile doesn't even use > the compat entry point for its ilp32 user space on 64-bit > kernels, it just calls the regular 64-bit one. Would that > help here? ILP32 tasks has unique context that is not like aarch64 or aarch32, so we have to have unique ptrace handler. I prepared the patch for ptrace with runtime ABI detection, as Catalin said, see there: https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670 If it's OK, I'd like to update submission. Yury -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/05/2017 12:22 PM, Dave Hansen wrote: On 01/04/2017 04:26 PM, Khalid Aziz wrote: ... No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte. There is enough space for just one tag per page. DaveM had suggested doing this since the usual case is for a task to set one tag per page even though MMU does not require it. I have implemented this as first pass to start a discussion and get feedback on whether rest of the swapping implementation and other changes look right, hence the patch is "RFC". If this all looks good, I can expand swapping support in a subsequent patch or iteration of this patch to allocate space in mm_context_t possibly to store per cacheline tags. I am open to any other ideas on storing this larger number of version tags. FWIW, This is the kind of thing that would be really useful to point out to reviewers instead of requiring them to ferret it out of the code. It has huge implications for how applications use this feature. Hi Dave, Thanks for taking the time to review this. I appreciate your patience. I will add more details. As for where to store the tags... It's potentially a *lot* of data, so I think it'll be a pain any way you do it. If you, instead, can live with doing things on a PAGE_SIZE granularity like pkeys does, you could just store it in the VMA and have the kernel tag the data at the same time it zeroes the pages. It is very tempting to restrict tags to PAGE_SIZE granularity since it makes code noticeably simpler and that is indeed going to be the majority of cases. Sooner or later somebody would want to use multiple tags per page though. There can be 128 4-bit tags per 8K page which requires 64 bytes of tag storage for each page. This can add up. What I am considering doing is store the tag in swp pte if I find only one tag on the page. A VMA can cover multiple pages and we have unused bits in swp pte. It makes more sense to store the tags in swp pte. If I find more than one tag on the page, I can allocate memory, attach it to a data structure in mm_context_t and store the tags there. I will need to use an rb tree or some other way to keep the data sorted to make it quick to retrieve the tags for one of the millions of pages a task might have. As I said, it gets complex trying to store tags per cacheline as opposed to per page :) -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 04:26 PM, Khalid Aziz wrote: ... > No, we do not have space to stuff PAGE_SIZE/64 version tags in swap pte. > There is enough space for just one tag per page. DaveM had suggested > doing this since the usual case is for a task to set one tag per page > even though MMU does not require it. I have implemented this as first > pass to start a discussion and get feedback on whether rest of the > swapping implementation and other changes look right, hence the patch is > "RFC". If this all looks good, I can expand swapping support in a > subsequent patch or iteration of this patch to allocate space in > mm_context_t possibly to store per cacheline tags. I am open to any > other ideas on storing this larger number of version tags. FWIW, This is the kind of thing that would be really useful to point out to reviewers instead of requiring them to ferret it out of the code. It has huge implications for how applications use this feature. As for where to store the tags... It's potentially a *lot* of data, so I think it'll be a pain any way you do it. If you, instead, can live with doing things on a PAGE_SIZE granularity like pkeys does, you could just store it in the VMA and have the kernel tag the data at the same time it zeroes the pages. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] docs: sphinx-extensions: make rstFlatTable work with docutils 0.13
On Wed, 4 Jan 2017 20:39:20 +0300 Dmitry Shachnev wrote: > Just a small update: the breaking change was reverted [1] in docutils > yesterday, so in the next release (0.13.2) get_column_widths() should return > a list again. > > (My patch should continue working fine.) I'm glad they fixed it, but we'll never know when there will no longer be 0.13 deployments in the wild, so we should keep the change in place indefinitely. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 05/12] mux: support simplified bindings for single-user gpio mux
On 2017-01-04 13:16, Peter Rosin wrote:
> Signed-off-by: Peter Rosin
> ---
> drivers/mux/mux-core.c | 81
> --
> drivers/mux/mux-gpio.c | 56 ++
> include/linux/mux.h| 7 +
> 3 files changed, 89 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> index 21da15a264ad..d887ae1c0e55 100644
> --- a/drivers/mux/mux-core.c
> +++ b/drivers/mux/mux-core.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -288,6 +289,63 @@ static struct mux_chip *of_find_mux_chip_by_node(struct
> device_node *np)
> return dev ? to_mux_chip(dev) : NULL;
> }
>
> +#ifdef CONFIG_MUX_GPIO
> +
> +static int mux_gpio_set(struct mux_control *mux, int state)
> +{
> + struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> + int i;
> +
> + for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> + mux_gpio->val[i] = (state >> i) & 1;
> +
> + gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> +mux_gpio->gpios->desc,
> +mux_gpio->val);
> +
> + return 0;
> +}
> +
> +static const struct mux_control_ops mux_gpio_ops = {
> + .set = mux_gpio_set,
> +};
> +
> +struct mux_chip *mux_gpio_alloc(struct device *dev)
> +{
> + struct mux_chip *mux_chip;
> + struct mux_gpio *mux_gpio;
> + int pins;
> + int ret;
> +
> + pins = gpiod_count(dev, "mux");
> + if (pins < 0)
> + return ERR_PTR(pins);
> +
> + mux_chip = devm_mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
> +pins * sizeof(*mux_gpio->val));
> + if (!mux_chip)
> + return ERR_PTR(-ENOMEM);
> +
> + mux_gpio = mux_chip_priv(mux_chip);
> + mux_gpio->val = (int *)(mux_gpio + 1);
> + mux_chip->ops = &mux_gpio_ops;
> +
> + mux_gpio->gpios = devm_gpiod_get_array(dev, "mux", GPIOD_OUT_LOW);
> + if (IS_ERR(mux_gpio->gpios)) {
> + ret = PTR_ERR(mux_gpio->gpios);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to get gpios\n");
> + return ERR_PTR(ret);
> + }
> + WARN_ON(pins != mux_gpio->gpios->ndescs);
> + mux_chip->mux->states = 1 << pins;
> +
> + return mux_chip;
> +}
> +EXPORT_SYMBOL_GPL(mux_gpio_alloc);
> +
> +#endif /* CONFIG_MUX_GPIO */
> +
> struct mux_control *mux_control_get(struct device *dev, const char *mux_name)
> {
> struct device_node *np = dev->of_node;
> @@ -307,9 +365,28 @@ struct mux_control *mux_control_get(struct device *dev,
> const char *mux_name)
> ret = of_parse_phandle_with_args(np,
>"mux-controls", "#mux-control-cells",
>index, &args);
> +
> +#ifdef CONFIG_MUX_GPIO
> + if (ret == -ENOENT && !mux_name && gpiod_count(dev, "mux") > 0) {
> + mux_chip = mux_gpio_alloc(dev);
> + if (!IS_ERR(mux_chip)) {
> + ret = devm_mux_chip_register(dev, mux_chip);
> + if (ret < 0) {
> + dev_err(dev, "failed to register mux-chip\n");
> + return ERR_PTR(ret);
> + }
> + get_device(&mux_chip->dev);
> + return mux_chip->mux;
> + }
> +
> + ret = PTR_ERR(mux_chip);
> + }
> +#endif
> +
> if (ret) {
> - dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> - np->full_name, mux_name ?: "", index);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "%s: failed to get mux-control %s(%i)\n",
> + np->full_name, mux_name ?: "", index);
> return ERR_PTR(ret);
> }
>
> diff --git a/drivers/mux/mux-gpio.c b/drivers/mux/mux-gpio.c
> index 76b52bc63470..8a7bfbc0c4bb 100644
> --- a/drivers/mux/mux-gpio.c
> +++ b/drivers/mux/mux-gpio.c
> @@ -11,37 +11,12 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> #include
> #include
Instead of moving the mux-gpio guts from mux-gpio.c to mux-core.c, I
will instead make CONFIG_MUX_GPIO a bool option (no module possible)
and call it from the mux-core. That will be cleaner and less of a
break of abstractions in my opinion.
Cheers,
Peter
> -struct mux_gpio {
> - struct gpio_descs *gpios;
> - int *val;
> -};
> -
> -static int mux_gpio_set(struct mux_control *mux, int state)
> -{
> - struct mux_gpio *mux_gpio = mux_chip_priv(mux->chip);
> - int i;
> -
> - for (i = 0; i < mux_gpio->gpios->ndescs; i++)
> - mux_gpio->val[i] = (state >> i) & 1;
> -
> - gpiod_set_array_value_cansleep(mux_gpio->gpios->ndescs,
> -mux_gpio->gpios->desc,
> -mux
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/05/2017 02:37 AM, Jerome Marchand wrote: On 01/04/2017 11:46 PM, Khalid Aziz wrote: ADI is a new feature supported on sparc M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data pages. Upper bits of the address contain the version tag. On M7 processors, upper four bits (bits 63-60) contain the version tag. If a rogue app attempts to access ADI enabled data pages, its access is blocked and processor generates an exception. This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable MCD (Memory Corruption Detection) on selected memory ranges, enable TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI version tags on page swap out/in. It also adds handlers for all traps related to MCD. ADI is not enabled by default for any task. A task must explicitly enable ADI on a memory range and set version tag for ADI to be effective for the task. Signed-off-by: Khalid Aziz Cc: Khalid Aziz --- v2: - Fixed a build error v3: - Removed CONFIG_SPARC_ADI - Replaced prctl commands with mprotect - Added auxiliary vectors for ADI parameters - Enabled ADI for swappable pages Documentation/sparc/adi.txt | 239 arch/sparc/include/asm/adi.h| 6 + arch/sparc/include/asm/adi_64.h | 46 ++ arch/sparc/include/asm/elf_64.h | 8 ++ arch/sparc/include/asm/hugetlb.h| 13 ++ arch/sparc/include/asm/hypervisor.h | 2 + arch/sparc/include/asm/mman.h | 40 +- arch/sparc/include/asm/mmu_64.h | 2 + arch/sparc/include/asm/mmu_context_64.h | 32 + arch/sparc/include/asm/pgtable_64.h | 97 - arch/sparc/include/asm/ttable.h | 10 ++ arch/sparc/include/asm/uaccess_64.h | 120 +++- arch/sparc/include/uapi/asm/asi.h | 5 + arch/sparc/include/uapi/asm/auxvec.h| 8 ++ arch/sparc/include/uapi/asm/mman.h | 2 + arch/sparc/include/uapi/asm/pstate.h| 10 ++ arch/sparc/kernel/Makefile | 1 + arch/sparc/kernel/adi_64.c | 93 + arch/sparc/kernel/entry.h | 3 + arch/sparc/kernel/head_64.S | 1 + arch/sparc/kernel/mdesc.c | 4 + arch/sparc/kernel/process_64.c | 21 +++ arch/sparc/kernel/sun4v_mcd.S | 16 +++ arch/sparc/kernel/traps_64.c| 142 ++- arch/sparc/kernel/ttable_64.S | 6 +- arch/sparc/mm/gup.c | 37 + arch/sparc/mm/tlb.c | 28 arch/x86/kernel/signal_compat.c | 2 +- include/asm-generic/pgtable.h | 5 + include/linux/mm.h | 2 + include/uapi/asm-generic/siginfo.h | 5 +- mm/memory.c | 2 +- mm/rmap.c | 4 +- I haven't actually reviewed the code and looked at why you need set_swp_pte_at() function, but the code that add the generic version of this function need to be separated from the rest of the patch. Also, given the size of this patch, I suspect the rest also need to be broken into more patches. Jerome Sure, I can do that. Code to add new signal codes can be one patch, generic changes to swap infrastructure can be another and I can look for logical breaks for the rest of the sparc specific code. -- Khalid -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)
On 01/04/2017 11:46 PM, Khalid Aziz wrote: > ADI is a new feature supported on sparc M7 and newer processors to allow > hardware to catch rogue accesses to memory. ADI is supported for data > fetches only and not instruction fetches. An app can enable ADI on its > data pages, set version tags on them and use versioned addresses to > access the data pages. Upper bits of the address contain the version > tag. On M7 processors, upper four bits (bits 63-60) contain the version > tag. If a rogue app attempts to access ADI enabled data pages, its > access is blocked and processor generates an exception. > > This patch extends mprotect to enable ADI (TSTATE.mcde), enable/disable > MCD (Memory Corruption Detection) on selected memory ranges, enable > TTE.mcd in PTEs, return ADI parameters to userspace and save/restore ADI > version tags on page swap out/in. It also adds handlers for all traps > related to MCD. ADI is not enabled by default for any task. A task must > explicitly enable ADI on a memory range and set version tag for ADI to > be effective for the task. > > Signed-off-by: Khalid Aziz > Cc: Khalid Aziz > --- > v2: > - Fixed a build error > > v3: > - Removed CONFIG_SPARC_ADI > - Replaced prctl commands with mprotect > - Added auxiliary vectors for ADI parameters > - Enabled ADI for swappable pages > > Documentation/sparc/adi.txt | 239 > > arch/sparc/include/asm/adi.h| 6 + > arch/sparc/include/asm/adi_64.h | 46 ++ > arch/sparc/include/asm/elf_64.h | 8 ++ > arch/sparc/include/asm/hugetlb.h| 13 ++ > arch/sparc/include/asm/hypervisor.h | 2 + > arch/sparc/include/asm/mman.h | 40 +- > arch/sparc/include/asm/mmu_64.h | 2 + > arch/sparc/include/asm/mmu_context_64.h | 32 + > arch/sparc/include/asm/pgtable_64.h | 97 - > arch/sparc/include/asm/ttable.h | 10 ++ > arch/sparc/include/asm/uaccess_64.h | 120 +++- > arch/sparc/include/uapi/asm/asi.h | 5 + > arch/sparc/include/uapi/asm/auxvec.h| 8 ++ > arch/sparc/include/uapi/asm/mman.h | 2 + > arch/sparc/include/uapi/asm/pstate.h| 10 ++ > arch/sparc/kernel/Makefile | 1 + > arch/sparc/kernel/adi_64.c | 93 + > arch/sparc/kernel/entry.h | 3 + > arch/sparc/kernel/head_64.S | 1 + > arch/sparc/kernel/mdesc.c | 4 + > arch/sparc/kernel/process_64.c | 21 +++ > arch/sparc/kernel/sun4v_mcd.S | 16 +++ > arch/sparc/kernel/traps_64.c| 142 ++- > arch/sparc/kernel/ttable_64.S | 6 +- > arch/sparc/mm/gup.c | 37 + > arch/sparc/mm/tlb.c | 28 > arch/x86/kernel/signal_compat.c | 2 +- > include/asm-generic/pgtable.h | 5 + > include/linux/mm.h | 2 + > include/uapi/asm-generic/siginfo.h | 5 +- > mm/memory.c | 2 +- > mm/rmap.c | 4 +- I haven't actually reviewed the code and looked at why you need set_swp_pte_at() function, but the code that add the generic version of this function need to be separated from the rest of the patch. Also, given the size of this patch, I suspect the rest also need to be broken into more patches. Jerome signature.asc Description: OpenPGP digital signature
