Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

On Thu, Apr 14, 2016 at 1:34 PM, Pavel Machek wrote: > On Thu 2016-04-14 13:14:07, Kees Cook wrote: >> On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: >> > Hi! >> > >> >> Since kASLR and Hibernation can not currently coexist at runtime >> >> on x86, the default

[PATCH] Documentation: cgroup: "unshare -C" to unshare cgroup namespace

Use "unshare -C" to be consistent with the unshare utility from util-linux Signed-off-by: Josef Lusticky --- Documentation/cgroup-v2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt index

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

On Thu 2016-04-14 13:14:07, Kees Cook wrote: > On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: > > Hi! > > > >> Since kASLR and Hibernation can not currently coexist at runtime > >> on x86, the default behavior was to disable kASLR by default when > >> CONFIG_HIBERNATION was

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

On Thu, Apr 14, 2016 at 1:01 PM, Pavel Machek wrote: > Hi! > >> Since kASLR and Hibernation can not currently coexist at runtime >> on x86, the default behavior was to disable kASLR by default when >> CONFIG_HIBERNATION was present (to retain original behavior). >> >> The behavior

Re: [PATCH v2] kaslr: allow kASLR to be default over Hibernation

Hi! > Since kASLR and Hibernation can not currently coexist at runtime > on x86, the default behavior was to disable kASLR by default when > CONFIG_HIBERNATION was present (to retain original behavior). > > The behavior of kASLR on arm64 (and soon MIPS) is to be enabled by > default when

[PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate

Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx field. Doing that will ease adaptation of the PWM framework to support atomic update. Signed-off-by: Boris Brezillon --- Patch generated with the following coccinelle script: --->8---

[PATCH v5 01/24] pwm: introduce the pwm_args concept

Currently the PWM core mixes the current PWM state with the per-platform reference config (specified through the PWM lookup table, DT definition or directly hardcoded in PWM drivers). Create a pwm_args struct to store this reference config, so that PWM users can differentiate the current config

[PATCH v5 08/24] fbdev: ssd1307fb: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[PATCH v5 11/24] backlight: lp855x: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[PATCH v5 07/24] regulator: pwm: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[PATCH v5 06/24] leds: pwm: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[PATCH v5 05/24] input: misc: max77693: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[PATCH v5 09/24] backlight: pwm_bl: use pwm_get_args() where appropriate

The PWM framework has clarified the concept of reference PWM config (the platform dependent config retrieved from the DT or the PWM lookup table) and real PWM state. Use pwm_get_args() when the PWM user wants to retrieve this reference config and not the current state. This is part of the rework

[PATCH v5 12/24] backlight: lm3630a: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

Re: [PATCH v5 02/24] pwm: use pwm_get/set_xxx() helpers where appropriate

On 14 April 2016 at 21:17, Boris Brezillon wrote: > Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx > field. Doing that will ease adaptation of the PWM framework to support > atomic update. > > Signed-off-by: Boris Brezillon

[PATCH v5 15/24] drm: i915: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[PATCH v5 18/24] pwm: introduce the pwm_state concept

The PWM state, represented by its period, duty_cycle and polarity, is currently directly stored in the PWM device. Declare a pwm_state structure embedding those field so that we can later use this struct to atomically update all the PWM parameters at once. All pwm_get_xxx() helpers are now

[PATCH v5 22/24] pwm: update documentation

Update the PWM subsystem documentation to reflect the atomic PWM changes. Signed-off-by: Boris Brezillon --- Documentation/pwm.txt | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/pwm.txt

[PATCH v5 20/24] pwm: add the PWM initial state retrieval infra

Add a ->get_state() function to the pwm_ops struct to let PWM drivers initialize the PWM state attached to a PWM device. Signed-off-by: Boris Brezillon --- drivers/pwm/core.c | 3 +++ include/linux/pwm.h | 28 2 files changed,

[PATCH v5 21/24] pwm: add the core infrastructure to allow atomic update

Add an ->apply() method to the pwm_ops struct to allow PWM drivers to implement atomic update. This method will be preferred over the ->enable(), ->disable() and ->config() methods if available. Add the pwm_apply_state() function to the PWM user API. Note that the pwm_apply_state() does not

[PATCH v5 24/24] pwm: add information about polarity, duty cycle and period to debugfs

From: Heiko Stübner The pwm-states make it possible to also output the polarity, duty cycle and period information in the debugfs pwm summary-outout. This makes it easier to gather overview information about pwms without needing to walk through the sysfs attributes of every pwm.

[PATCH v5 13/24] input: misc: max8997: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[PATCH v5 10/24] backlight: lp8788: explicitly apply PWM config extracted from pwm_args

Call pwm_apply_args() just after requesting the PWM device so that the polarity and period are initialized according to the information provided in pwm_args. This is an intermediate state, and pwm_apply_args() should be dropped as soon as the atomic PWM infrastructure is in place and the driver

[PATCH v5 19/24] pwm: move the enabled/disabled info into pwm_state

Prepare the transition to PWM atomic update by moving the enabled/disabled state into the pwm_state struct. This way we can easily update the whole PWM state by copying the new state in the ->state field. Signed-off-by: Boris Brezillon --- drivers/pwm/core.c

[PATCH v5 00/24] pwm: add support for atomic update

Hello, This series adds support for atomic PWM update, or IOW, the capability to update all the parameters of a PWM device (enabled/disabled, period, duty and polarity) in one go. It also adds support for initial PWM state retrieval (or hardware readout), which should allow smooth handover

Re: [PATCH v2] procfs: expose umask in /proc//status

On Thu, Apr 14, 2016 at 2:08 PM, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. > > Add a new status

[PATCH v2] procfs: expose umask in /proc//status

It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add a new status line ("Umask") in /proc//status. It contains the file mode creation mask (umask) in

[PATCH v2] procfs: expose umask in /proc//status

v1 -> v2: - Change printf format to %#04o. - Retest and update examples accordingly. -- It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add

Re: [PATCH v5 01/46] pwm: rcar: make use of pwm_is_enabled()

Hi Thierry On Tue, 12 Apr 2016 13:01:52 +0200 Thierry Reding wrote: > On Wed, Mar 30, 2016 at 10:03:24PM +0200, Boris Brezillon wrote: > > Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a > > new function to test whether a PWM device is enabled

Re: [PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

On Thu, Apr 14, 2016 at 10:34:48AM +0100, Richard W.M. Jones wrote: > It's not possible to read the process umask without also modifying it, > which is what umask(2) does. A library cannot read umask safely, > especially if the main program might be multithreaded. > > Add a new status line

[PATCH] procfs: expose umask in /proc//status (formerly umask2, formerly getumask)

It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add a new status line ("Umask") in /proc//status. It contains the file mode creation mask (umask) in

[PATCH] procfs: expose umask in /proc//status

It's not possible to read the process umask without also modifying it, which is what umask(2) does. A library cannot read umask safely, especially if the main program might be multithreaded. Add a new status line ("Umask") in /proc//status. It contains the file mode creation mask (umask) in

[PATCH 4/4] serial: doc: .break_ctl() may sleep

As mutex_lock() must not be called with interrupts disabled, .break_ctl() may sleep. Reported-by: Peter Hurley Signed-off-by: Geert Uytterhoeven --- Documentation/serial/driver | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 0/4] serial: doc: Low Level Serial API Documentation Improvements (take two)

Hi Greg, Jiri, Jon, Peter, Russell, This patch series contains improvements to the low level serial driver API documentation. It is an incremental update (sort of v2) of "[PATCH 0/9] serial: doc: Low Level Serial API Documentation Improvements", which was already applied to the docs