HI Marc,
Gentle reminder!
Are you happy with the open comment's disposition? I can send a next version of
patch if we have a closure on current set of comments.
Thanks,
Ramesh
> -Original Message-
> From: Ramesh Shanmugasundaram
> Sent: 01 April 2016 13:49
> To: Ramesh Shanmugasundaram
On 13 April 2016 at 00:08, Daniel Vetter wrote:
> On Mon, Apr 11, 2016 at 04:55:33PM +0800, Xinliang Liu wrote:
>> This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
>> Current testing and support board is Hikey board which is one of Linaro
>> 96boards. It is an arm64 open source
On Tue, Apr 12, 2016 at 3:31 PM, Al Viro wrote:
> On Tue, Apr 12, 2016 at 09:54:44AM -0700, Kees Cook wrote:
>> Providing human-readable (and audit-parsable) strings for the READING_*
>> enums is needed by some LSMs.
>>
>> Signed-off-by: Kees Cook
>> ---
>> fs/exec.c | 19 ++
On Tue, Apr 12, 2016 at 09:54:44AM -0700, Kees Cook wrote:
> Providing human-readable (and audit-parsable) strings for the READING_*
> enums is needed by some LSMs.
>
> Signed-off-by: Kees Cook
> ---
> fs/exec.c | 19 +++
> include/linux/fs.h | 1 +
> 2 files changed, 2
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 at build time. S
From: Thor Thayer
In preparation for additional memory module ECCs, the
IRQ declaration is being made available to everyone.
Move it outside of the OCRAM only area.
Signed-off-by: Thor Thayer
---
drivers/edac/altera_edac.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff -
From: Thor Thayer
In preparation for additional memory module ECCs, add the
memory initialization functions.
Signed-off-by: Thor Thayer
---
drivers/edac/altera_edac.c | 152
drivers/edac/altera_edac.h |3 +
2 files changed, 155 insertions(+)
d
From: Thor Thayer
Add the device tree entries needed to support the Altera Ethernet
FIFO buffer EDAC on the Arria10 chip.
Signed-off-by: Thor Thayer
---
arch/arm/boot/dts/socfpga_arria10.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/
From: Thor Thayer
Add the device tree bindings needed to support the Altera Ethernet
FIFO buffers on the Arria10 chip.
Signed-off-by: Thor Thayer
---
.../bindings/arm/altera/socfpga-eccmgr.txt | 24
1 file changed, 24 insertions(+)
diff --git a/Documentation/dev
From: Thor Thayer
In preparation for the Arria10 ECC modules, check the status
of the parent in the device tree to ensure the block is enabled.
Skip if no parent phandle is set in the device tree.
Signed-off-by: Thor Thayer
---
drivers/edac/altera_edac.c |9 +
1 file changed, 9 ins
From: Thor Thayer
Add Altera Arria10 Ethernet FIFO memory EDAC support.
Signed-off-by: Thor Thayer
---
drivers/edac/Kconfig |7 ++
drivers/edac/altera_edac.c | 153
drivers/edac/altera_edac.h | 14
3 files changed, 174 insertions(+
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 patches add Ethernet EDAC support.
[PATCH 1/6] EDAC, altera: Check parent status for Arria1
Quoting Kees Cook (keesc...@chromium.org):
> This LSM enforces that kernel-loaded files (modules, firmware, etc)
> must all come from the same filesystem, with the expectation that
> such a filesystem is backed by a read-only device such as dm-verity
> or CDROM. This allows systems that have a veri
Quoting Kees Cook (keesc...@chromium.org):
> Providing human-readable (and audit-parsable) strings for the READING_*
> enums is needed by some LSMs.
>
> Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
> ---
> fs/exec.c | 19 +++
> include/linux/fs.h | 1 +
> 2 files
Quoting Kees Cook (keesc...@chromium.org):
> Use a common error reporting function for Yama violation reports, and give
> more detail into the process command lines.
>
> Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
> ---
> security/yama/yama_lsm.c | 31 +--
> 1
Quoting Kees Cook (keesc...@chromium.org):
> Allocate a NULL-terminated file path with special characters escaped,
> safe for logging.
>
> Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
> ---
> include/linux/string_helpers.h | 3 +++
> lib/string_helpers.c | 30 +++
Quoting Kees Cook (keesc...@chromium.org):
> Provide an escaped (but readable: no inter-argument NULLs) commandline
> safe for logging.
>
> Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
> ---
> include/linux/string_helpers.h | 1 +
> lib/string_helpers.c | 34
Quoting Kees Cook (keesc...@chromium.org):
> Handle allocating and escaping a string safe for logging.
>
> Signed-off-by: Kees Cook
Acked-by: Serge Hallyn
> ---
> include/linux/string_helpers.h | 2 ++
> lib/string_helpers.c | 28
> 2 files changed, 30
On 4/8/2016 12:34 PM, Chris Metcalf wrote:
However, this makes me wonder if "strict" mode should be the default
for task isolation?? That way task isolation really doesn't conflict
semantically with migration. And we could provide a "weak" mode, or a
"kernel-friendly" mode, or some such nomencl
On 11/04/16 19:03, Kees Cook wrote:
> On Mon, Apr 11, 2016 at 1:00 AM, James Morse wrote:
>> On 06/04/16 20:44, Kees Cook wrote:
>>> When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
>>> one or the other must be chosen at boot-time. Until now, hibernation
>>> was selected when
It tries to "match" drivers for each interface (not "much").
Signed-off-by: Diego Herranz
---
Documentation/usb/gadget_multi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/usb/gadget_multi.txt
b/Documentation/usb/gadget_multi.txt
index 7d66a86..5faf514 100
Use a common error reporting function for Yama violation reports, and give
more detail into the process command lines.
Signed-off-by: Kees Cook
---
security/yama/yama_lsm.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/security/yama/yama_ls
This provides the mini-LSM "loadpin" that intercepts the now consolidated
kernel_file_read LSM hook so that a system can keep all loads coming from
a single trusted filesystem. This is what Chrome OS uses to pin kernel
module and firmware loading to the read-only crypto-verified dm-verity
partition
Providing human-readable (and audit-parsable) strings for the READING_*
enums is needed by some LSMs.
Signed-off-by: Kees Cook
---
fs/exec.c | 19 +++
include/linux/fs.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/fs/exec.c b/fs/exec.c
index c4010b8207a1..05e
Allocate a NULL-terminated file path with special characters escaped,
safe for logging.
Signed-off-by: Kees Cook
---
include/linux/string_helpers.h | 3 +++
lib/string_helpers.c | 30 ++
2 files changed, 33 insertions(+)
diff --git a/include/linux/string_h
This LSM enforces that kernel-loaded files (modules, firmware, etc)
must all come from the same filesystem, with the expectation that
such a filesystem is backed by a read-only device such as dm-verity
or CDROM. This allows systems that have a verified and/or unchangeable
filesystem to enforce modu
Handle allocating and escaping a string safe for logging.
Signed-off-by: Kees Cook
---
include/linux/string_helpers.h | 2 ++
lib/string_helpers.c | 28
2 files changed, 30 insertions(+)
diff --git a/include/linux/string_helpers.h b/include/linux/string_h
Provide an escaped (but readable: no inter-argument NULLs) commandline
safe for logging.
Signed-off-by: Kees Cook
---
include/linux/string_helpers.h | 1 +
lib/string_helpers.c | 34 ++
2 files changed, 35 insertions(+)
diff --git a/include/linux/strin
On Mon, Apr 11, 2016 at 04:55:33PM +0800, Xinliang Liu wrote:
> This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
> Current testing and support board is Hikey board which is one of Linaro
> 96boards. It is an arm64 open source board. For more information about
> this board, pleas
On Fri, 8 Apr 2016 17:12:27 +0200
Markus Heiser wrote:
> motivated by this MT, I implemented a toolchain to migrate the kernel’s
> DocBook XML documentation to reST markup.
>
> It converts 99% of the docs well ... to gain an impression how
> kernel-docs could benefit from, visit my sphkerneld
On Tue, Apr 12, 2016 at 03:16:13PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > > pwm->period field is not supposed to be changed by PWM users. The only
> > > ones authorized to change it are the PWM
On Tue, Apr 12, 2016 at 03:16:53PM +0100, Lee Jones wrote:
> On Tue, 12 Apr 2016, Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > > The PWM period will be set when calling pwm_config. Remove this useless
> > > call to pwm_set_period(), which might m
On Tue, 12 Apr 2016, Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> > pwm->period field is not supposed to be changed by PWM users. The only
> > ones authorized to change it are the PWM core and PWM drivers.
> >
> > Signed-off-by: Boris Brezillon
> > -
On Tue, 12 Apr 2016 16:05:46 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 15:11:18 +0200
> > Thierry Reding wrote:
> >
> > > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 Apr 2016 14:
On Tue, 12 Apr 2016, Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> > The PWM period will be set when calling pwm_config. Remove this useless
> > call to pwm_set_period(), which might mess up with the internal PWM state.
> >
> > Signed-off-by: Boris Bre
On Tue, Apr 12, 2016 at 03:26:44PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 15:11:18 +0200
> Thierry Reding wrote:
>
> > On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 Apr 2016 14:21:41 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Tue, Apr 12,
On Thu, Apr 07, 2016 at 09:54:16AM -0600, Naveen Kaje wrote:
> The ARMv8.0 architecture reserves several system register
> encodings for future use. These encodings should behave
> as read-only and always return zero on a read. The Kryo core
> errantly causes an instruction abort upon an AArch64
>
On Tue, 12 Apr 2016 15:11:18 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 14:21:41 +0200
> > Thierry Reding wrote:
> >
> > > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 Apr 2016 13:
On Tue, Apr 12, 2016 at 03:06:27PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:39:12 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > Currently the PWM core mixes the current PWM state with the per-platform
> > > reference confi
On Tue, Apr 12, 2016 at 02:45:08PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 14:21:41 +0200
> Thierry Reding wrote:
>
> > On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > > On Tue, 12 Apr 2016 13:49:04 +0200
> > > Thierry Reding wrote:
> > >
> > > > On Wed, Mar 30,
On Tue, 12 Apr 2016 13:39:12 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > 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 hard
On Tue, 12 Apr 2016 14:20:29 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:04:12PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 13:39:12 +0200
> > Thierry Reding wrote:
> >
> > > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > > Currently the PWM core
On Tue, 12 Apr 2016 14:21:41 +0200
Thierry Reding wrote:
> On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> > On Tue, 12 Apr 2016 13:49:04 +0200
> > Thierry Reding wrote:
> >
> > > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > > The PWM state, represen
On Tue, Apr 12, 2016 at 02:17:18PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:49:04 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > > The PWM state, represented by its period, duty_cycle and polarity,
> > > is currently directly
On Tue, Apr 12, 2016 at 02:04:12PM +0200, Boris Brezillon wrote:
> On Tue, 12 Apr 2016 13:39:12 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > > Currently the PWM core mixes the current PWM state with the per-platform
> > > reference confi
On Tue, 12 Apr 2016 13:49:04 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> > 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
On Tue, 12 Apr 2016 13:39:12 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> > 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 hard
On Wed, Mar 30, 2016 at 10:03:39PM +0200, Boris Brezillon wrote:
[...]
> @@ -145,7 +146,11 @@ static inline void pwm_get_state(const struct pwm_device
> *pwm,
>
> static inline bool pwm_is_enabled(const struct pwm_device *pwm)
> {
> - return test_bit(PWMF_ENABLED, &pwm->flags);
> + str
On Wed, Mar 30, 2016 at 10:03:38PM +0200, Boris Brezillon wrote:
> 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 a
On Tue, Apr 12, 2016 at 01:32:55PM +0200, Boris Brezillon wrote:
> Hi Thierry,
>
> On Tue, 12 Apr 2016 13:22:46 +0200
> Thierry Reding wrote:
>
> > On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> > > PWM devices are not protected against concurrent accesses. The lock in
> > >
On Wed, Mar 30, 2016 at 10:03:28PM +0200, Boris Brezillon wrote:
> 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
Hi Thierry,
On Tue, 12 Apr 2016 13:22:46 +0200
Thierry Reding wrote:
> On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> > PWM devices are not protected against concurrent accesses. The lock in
> > pwm_device might let PWM users think it is, but it's actually only
> > protecting
On Wed, Mar 30, 2016 at 10:03:27PM +0200, Boris Brezillon wrote:
> PWM devices are not protected against concurrent accesses. The lock in
> pwm_device might let PWM users think it is, but it's actually only
> protecting the enabled state.
>
> Removing this lock should be fine as long as all PWM us
On Wed, Mar 30, 2016 at 10:03:26PM +0200, Boris Brezillon wrote:
> pwm->period field is not supposed to be changed by PWM users. The only
> ones authorized to change it are the PWM core and PWM drivers.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/video/backlight/lm3630a_bl.c | 3 +--
> 1
On Wed, Mar 30, 2016 at 10:03:25PM +0200, Boris Brezillon wrote:
> The PWM period will be set when calling pwm_config. Remove this useless
> call to pwm_set_period(), which might mess up with the internal PWM state.
>
> Signed-off-by: Boris Brezillon
> Acked-by: Lee Jones
> ---
> drivers/video/
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
> manipulating PWM internal fields.
> Hiding this is necessary if we want to smoothly mo
On Tue, 12 Apr 2016 11:09:38 +0100
Mark Brown wrote:
> On Tue, Apr 12, 2016 at 10:37:22AM +0200, Boris Brezillon wrote:
> > Mark Brown wrote:
> > > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
>
> > > I'm not sure there's a strong one, we don't really use the class device
>
On Tue, Apr 12, 2016 at 10:37:22AM +0200, Boris Brezillon wrote:
> Mark Brown wrote:
> > On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
> > I'm not sure there's a strong one, we don't really use the class device
> > for anything, but without doing a full audit I couldn't guarant
Hi Markus,
On 04/08/16 17:12, Markus Heiser wrote:
> Hi kernel-doc authors,
>
> motivated by this MT, I implemented a toolchain to migrate the kernel’s
> DocBook XML documentation to reST markup.
>
> It converts 99% of the docs well ... to gain an impression how
> kernel-docs could benefit fr
Hi Mark,
On Tue, 12 Apr 2016 05:42:03 +0100
Mark Brown wrote:
> On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:
>
> > Is there any reason for calling set_machine_constraints() after
> > device_register() in regulator_register()?
>
> I'm not sure there's a strong one, we don't
60 matches
Mail list logo
