On Thu, Apr 14, 2016 at 09:17:27PM +0200, Boris Brezillon wrote:
> 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.
Acked-by: Mark Brown
signature.asc
Description: PGP signat
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 behavior was to disable kASLR
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 4cc07ce..929af1c 100644
---
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 present (to retai
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 of kASLR on arm6
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 selected
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---
virtual patch
@@
struct pwm_device *p;
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
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 fr
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
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 ma
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
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
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
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
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
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 ma
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 generated with the following cocc
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 ma
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 ma
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 ma
Before the introduction of pwm_args, the core was resetting the PWM period
and polarity states to the reference values (those provided through the
DT, a PWM lookup table or hardcoded in the driver).
Now that all PWM users are correctly using pwm_args to configure their
PWM device, we can safely re
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, 31 insertions(+)
diff --git a/drivers
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 impleme
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 b/Documentation/pwm.txt
index ca895fd..789b
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 guara
Replace legacy pwm_get/set_xxx() and pwm_config/enable/disable() calls
by pwm_get/apply_state().
Signed-off-by: Boris Brezillon
---
drivers/pwm/core.c | 5 -
drivers/pwm/sysfs.c | 61 +++--
2 files changed, 40 insertions(+), 26 deletions(-)
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.
Signed-off-by: H
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 ma
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 ma
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 | 13 +
include/linux/pw
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 betwee
On Tue, Apr 12, 2016 at 05:12:55PM -0500, ttha...@opensource.altera.com wrote:
> This patch set adds the memory initialization functions for Altera's
> Arria10 peripherals, the first of which is the Ethernet EDAC. The
> first 3 patches add the memory initialization functionality. The
> last 3 patch
On 04/14/2016 01: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 line ("Umask") in /proc//stat
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 line ("Umask") in /p
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 octa
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
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 or not without
> > manipul
On 04/14/2016 11:34 AM, 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 ("Umask") in /proc//stat
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 ("Umas
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 octa
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 octa
Document that .throttle() and .unthrottle() are relevant only if
hardware assisted flow control is enabled.
Signed-off-by: Geert Uytterhoeven
---
Documentation/serial/driver | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 0336
Document that .(un)throttle() are serialized with each other, and with
termios modification by the tty layer.
Reported-by: Peter Hurley
Signed-off-by: Geert Uytterhoeven
---
Documentation/serial/driver | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/seria
Commit 834392a7d92677ff ("serial: doc: Un-document non-existing
uart_write_console()") removed a paragraph about a helper function that
seemed to never exist.
Peter Hurley pointed out that the function does exist, but is called
differently. Re-add the paragraph, with the function name corrected.
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 a/Documentation/serial/driver b/Documentation/serial/driver
index 7fb
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 tree.
[ +cc: linux-doc, kent ]
On Tue, 12 Apr 2016, Marc MERLIN wrote:
> On Mon, Mar 28, 2016 at 6:09 PM, Eric Wheeler
> wrote:
> > git pull https://bitbucket.org/ewheelerinc/linux
> > v4.6-rc1-bcache-documentation
>
> Hi Eric,
>
> Do I have a way to find out if your patch was pulled?
I've not see
Hi Emil,
On 13 April 2016 at 20:15, Emil Velikov wrote:
> Hi Xinliang,
>
> On 11 April 2016 at 09:55, Xinliang Liu wrote:
>
>> +static int kirin_drm_connectors_register(struct drm_device *dev)
>> +{
>> + struct drm_connector *connector;
>> + struct drm_connector *failed_connector;
>>
49 matches
Mail list logo
