[PATCH 2/2] tracing: Handle tracing_map_alloc_elts() error path correctly

If tracing_map_elt_alloc() fails, it will return ERR_PTR() instead of NULL, so change the check to IS_ERROR(). We also need to set the failed entry in the map->elts array to NULL instead of ERR_PTR() so tracing_map_free_elts() doesn't try freeing an ERR_PTR(). tracing_map_free_elts() should also

[PATCH 2/2] tracing: Handle tracing_map_alloc_elts() error path correctly

If tracing_map_elt_alloc() fails, it will return ERR_PTR() instead of NULL, so change the check to IS_ERROR(). We also need to set the failed entry in the map->elts array to NULL instead of ERR_PTR() so tracing_map_free_elts() doesn't try freeing an ERR_PTR(). tracing_map_free_elts() should also

[PATCH 0/2] A couple hist trigger fixes

These are a couple of small fixes for problems pointed out by Dan Carpenter. patch 1, pointed out by Smatch though not actually a bug, cleans up the code to explicitly check for something that was implied. Thanks to Steve Rostedt for suggesting the fix. patch 2 fixes a PTR_ERR problem similar

[PATCH 0/2] A couple hist trigger fixes

These are a couple of small fixes for problems pointed out by Dan Carpenter. patch 1, pointed out by Smatch though not actually a bug, cleans up the code to explicitly check for something that was implied. Thanks to Steve Rostedt for suggesting the fix. patch 2 fixes a PTR_ERR problem similar

Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version

On 04/21/2016 07:37 AM, Alexey Klimov wrote: > Hi Al, > > I hope you don't mind if I put few minor questions here. > > On Mon, Apr 18, 2016 at 8:32 PM, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel

Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version

On 04/21/2016 07:37 AM, Alexey Klimov wrote: > Hi Al, > > I hope you don't mind if I put few minor questions here. > > On Mon, Apr 18, 2016 at 8:32 PM, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel documentation for the

Re: [patch] tracing: checking for NULL instead of IS_ERR()

Hi Dan, On 04/23/2016 05:23 AM, Dan Carpenter wrote: tracing_map_elt_alloc() returns ERR_PTRs on error, never NULL. Fixes: 08d43a5fa063 ('tracing: Add lock-free tracing_map') Signed-off-by: Dan Carpenter diff --git a/kernel/trace/tracing_map.c

Re: [patch] tracing: checking for NULL instead of IS_ERR()

Hi Dan, On 04/23/2016 05:23 AM, Dan Carpenter wrote: tracing_map_elt_alloc() returns ERR_PTRs on error, never NULL. Fixes: 08d43a5fa063 ('tracing: Add lock-free tracing_map') Signed-off-by: Dan Carpenter diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index

Re: [PATCH 6/6] intel_sgx: TODO file for the staging area

On Mon, Apr 25, 2016 at 10:54:26AM -0700, Greg KH wrote: > On Mon, Apr 25, 2016 at 08:34:13PM +0300, Jarkko Sakkinen wrote: > > Signed-off-by: Jarkko Sakkinen > > --- > > drivers/staging/intel_sgx/TODO | 25 + > > 1 file changed, 25

Re: [PATCH 6/6] intel_sgx: TODO file for the staging area

On Mon, Apr 25, 2016 at 10:54:26AM -0700, Greg KH wrote: > On Mon, Apr 25, 2016 at 08:34:13PM +0300, Jarkko Sakkinen wrote: > > Signed-off-by: Jarkko Sakkinen > > --- > > drivers/staging/intel_sgx/TODO | 25 + > > 1 file changed, 25 insertions(+) > > create mode 100644

[PATCH v2] printk: Add kernel parameter to disable writes to /dev/kmsg

Over the weekend my server was acting funny. The display wasn't working well, and I assumed that a driver was going bad. I went to look at the kernel dmesg, but the buffer only had the following over and over: [226062.401405] systemd-logind[3511]: Removed session 4168. [226063.381051]

[PATCH v2] printk: Add kernel parameter to disable writes to /dev/kmsg

Over the weekend my server was acting funny. The display wasn't working well, and I assumed that a driver was going bad. I went to look at the kernel dmesg, but the buffer only had the following over and over: [226062.401405] systemd-logind[3511]: Removed session 4168. [226063.381051]

Re: printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, Apr 25, 2016 at 01:06:29PM -0400, Steven Rostedt wrote: > Over the weekend my server was acting funny. The display wasn't working > well, and I assumed that a driver was going bad. I went to look at the > kernel dmesg, but the buffer only had the following over and over: > >

Re: printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, Apr 25, 2016 at 01:06:29PM -0400, Steven Rostedt wrote: > Over the weekend my server was acting funny. The display wasn't working > well, and I assumed that a driver was going bad. I went to look at the > kernel dmesg, but the buffer only had the following over and over: > >

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Apr 25, 2016 at 09:19:13PM +0300, Yury Norov wrote: > On Mon, Apr 25, 2016 at 06:26:56PM +0100, Catalin Marinas wrote: > > On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote: > > > --- a/arch/arm64/kernel/entry.S > > > +++ b/arch/arm64/kernel/entry.S > > > @@ -715,9 +715,13 @@

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Apr 25, 2016 at 09:19:13PM +0300, Yury Norov wrote: > On Mon, Apr 25, 2016 at 06:26:56PM +0100, Catalin Marinas wrote: > > On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote: > > > --- a/arch/arm64/kernel/entry.S > > > +++ b/arch/arm64/kernel/entry.S > > > @@ -715,9 +715,13 @@

Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version

On 04/19/2016 05:15 AM, Lorenzo Pieralisi wrote: > On Mon, Apr 18, 2016 at 01:32:22PM -0600, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel documentation for the use of ACPI was written >> for the 5.1 version of the spec.

Re: [PATCH v4] ARM64: ACPI: Update documentation for latest specification version

On 04/19/2016 05:15 AM, Lorenzo Pieralisi wrote: > On Mon, Apr 18, 2016 at 01:32:22PM -0600, Al Stone wrote: >> The ACPI 6.1 specification was recently released at the end of January >> 2016, but the arm64 kernel documentation for the use of ACPI was written >> for the 5.1 version of the spec.

Re: [PATCH] tpm: check for TPM_CHIP_FLAG_TPM2 before calling tpm2_shutdown()

On Mon, Apr 25, 2016 at 11:57:20AM -0600, Jason Gunthorpe wrote: > On Mon, Apr 25, 2016 at 12:21:30PM +0300, Jarkko Sakkinen wrote: > > Signed-off-by: Jarkko Sakkinen > > Reported-by: Stefan Berger > > drivers/char/tpm/tpm-chip.c | 3

Re: [PATCH] tpm: check for TPM_CHIP_FLAG_TPM2 before calling tpm2_shutdown()

On Mon, Apr 25, 2016 at 11:57:20AM -0600, Jason Gunthorpe wrote: > On Mon, Apr 25, 2016 at 12:21:30PM +0300, Jarkko Sakkinen wrote: > > Signed-off-by: Jarkko Sakkinen > > Reported-by: Stefan Berger > > drivers/char/tpm/tpm-chip.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > >

[PATCH v2 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

The CCSR_SSI_SOR is a register that clears the TX and/or the RX fifo on the i.MX SSI port. The fsl_ssi_trigger writes this register in order to clear the fifo at trigger time. However, since the CCSR_SSI_SOR register is not in the volatile list, the caching mechanism prevented the register write

[PATCH v2 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

The CCSR_SSI_SOR is a register that clears the TX and/or the RX fifo on the i.MX SSI port. The fsl_ssi_trigger writes this register in order to clear the fifo at trigger time. However, since the CCSR_SSI_SOR register is not in the volatile list, the caching mechanism prevented the register write

Re: [PATCH 2/5] iio: inv_mpu6050: Remove inv_mpu6050_hw.num_reg

On 24/04/16 12:12, Jonathan Cameron wrote: > On 20/04/16 14:15, Crestez Dan Leonard wrote: >> This field was unused and incorrect for mpu6500. >> >> Signed-off-by: Crestez Dan Leonard . > This one I think I can safely take :) > > Good spot Applied. Thanks, >> --- >>

Re: [PATCH 2/5] iio: inv_mpu6050: Remove inv_mpu6050_hw.num_reg

On 24/04/16 12:12, Jonathan Cameron wrote: > On 20/04/16 14:15, Crestez Dan Leonard wrote: >> This field was unused and incorrect for mpu6500. >> >> Signed-off-by: Crestez Dan Leonard . > This one I think I can safely take :) > > Good spot Applied. Thanks, >> --- >>

Re: [PATCH] printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, 25 Apr 2016 20:32:50 +0200 Borislav Petkov wrote: > On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote: > > [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which > > may make this fail filters. ] > > > > Over the weekend my server was

Re: [PATCH] printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, 25 Apr 2016 20:32:50 +0200 Borislav Petkov wrote: > On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote: > > [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which > > may make this fail filters. ] > > > > Over the weekend my server was acting funny. The

Re: [PATCH 1/5] iio: inv_mpu6050: Cleanup hw_info mapping

On 24/04/16 12:10, Jonathan Cameron wrote: > On 20/04/16 14:15, Crestez Dan Leonard wrote: >> The hw_info array was indexed by enum inv_devices chip_type despite the >> fact that the enumeration had more members than the array and was >> ordered differently. >> >> The patch cleans this up and adds

Re: [PATCH 1/5] iio: inv_mpu6050: Cleanup hw_info mapping

On 24/04/16 12:10, Jonathan Cameron wrote: > On 20/04/16 14:15, Crestez Dan Leonard wrote: >> The hw_info array was indexed by enum inv_devices chip_type despite the >> fact that the enumeration had more members than the array and was >> ordered differently. >> >> The patch cleans this up and adds

cgroup namespace and user namespace interactions

Hello, The new cgroup namespace currently only allows for superficial interaction with the user namespace (it checks against the namespace it was created in whether or not a user has the right capabilities before allowing mounting, and things like that). However, there is one glaring feature that

cgroup namespace and user namespace interactions

Hello, The new cgroup namespace currently only allows for superficial interaction with the user namespace (it checks against the namespace it was created in whether or not a user has the right capabilities before allowing mounting, and things like that). However, there is one glaring feature that

Re: [RFC] Add missing #include

On Mon, 25 Apr 2016 19:10:55 +0100 Eric Engestrom wrote: > ARRAY_SIZE uses BUILD_BUG_ON_ZERO, which is undefined is you don't > include linux/bug.h first, which just happened to me. > > Is there any reason this include isn't here? A quick grep found 595 > other files

Re: [RFC] Add missing #include

On Mon, 25 Apr 2016 19:10:55 +0100 Eric Engestrom wrote: > ARRAY_SIZE uses BUILD_BUG_ON_ZERO, which is undefined is you don't > include linux/bug.h first, which just happened to me. > > Is there any reason this include isn't here? A quick grep found 595 > other files using a define from bug.h

Re: [PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions

Den 25.04.2016 18:38, skrev Ville Syrjälä: On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote: On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote: Den 25.04.2016 15:02, skrev Ville Syrjälä: On Mon, Apr 25,

Re: [PATCH v2 1/8] drm/rect: Add some drm_clip_rect utility functions

Den 25.04.2016 18:38, skrev Ville Syrjälä: On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote: On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote: Den 25.04.2016 15:02, skrev Ville Syrjälä: On Mon, Apr 25,

Re: [PATCH] [RFC] net: dsa: mv88e6xxx: Pre-initialize err in mv88e6xxx_port_bridge_join()

Hi Geert, Geert Uytterhoeven writes: > Hi Vivien, > > On Mon, Apr 25, 2016 at 7:31 PM, Vivien Didelot > wrote: >> Geert Uytterhoeven writes: >>> On Mon, Apr 25, 2016 at 5:03 PM, Vivien Didelot >>>

Re: [PATCH] [RFC] net: dsa: mv88e6xxx: Pre-initialize err in mv88e6xxx_port_bridge_join()

Hi Geert, Geert Uytterhoeven writes: > Hi Vivien, > > On Mon, Apr 25, 2016 at 7:31 PM, Vivien Didelot > wrote: >> Geert Uytterhoeven writes: >>> On Mon, Apr 25, 2016 at 5:03 PM, Vivien Didelot >>> wrote: Geert Uytterhoeven writes: > drivers/net/dsa/mv88e6xxx.c: In function

Re: [PATCH] printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote: > [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which > may make this fail filters. ] > > Over the weekend my server was acting funny. The display wasn't working > well, and I assumed that a driver was going

Re: [PATCH] printk: Add kernel parameter to disable writes to /dev/kmsg

On Mon, Apr 25, 2016 at 01:08:53PM -0400, Steven Rostedt wrote: > [ Sorry for the resend, I forgot to add "[PATCH]" to the subject, which > may make this fail filters. ] > > Over the weekend my server was acting funny. The display wasn't working > well, and I assumed that a driver was going

Re: [PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

On Mon, Apr 25, 2016 at 11:06 AM, Mark Brown wrote: > On Mon, Apr 25, 2016 at 10:50:24AM -0700, Caleb Crome wrote: > >> Due to caching, SOR wasn't written when it should have been. This >> patch simply adds SOR to the volatile list. > > Could you expand on when it wasn't

Re: [PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

On Mon, Apr 25, 2016 at 11:06 AM, Mark Brown wrote: > On Mon, Apr 25, 2016 at 10:50:24AM -0700, Caleb Crome wrote: > >> Due to caching, SOR wasn't written when it should have been. This >> patch simply adds SOR to the volatile list. > > Could you expand on when it wasn't written and why it

RE: [PATCH 5/5] iio: inv_mpu6050: Add explicit support for MPU9150

This looks good to me. Acked-by: Ge Gao -Original Message- From: Jonathan Cameron [mailto:ji...@kernel.org] Sent: Sunday, April 24, 2016 4:16 AM To: Crestez Dan Leonard; linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter

RE: [PATCH 5/5] iio: inv_mpu6050: Add explicit support for MPU9150

This looks good to me. Acked-by: Ge Gao -Original Message- From: Jonathan Cameron [mailto:ji...@kernel.org] Sent: Sunday, April 24, 2016 4:16 AM To: Crestez Dan Leonard; linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter

RE: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code.

I was planning to define all these bits in a separate future patch. Would you rather prefer the magic numbers defined before fixing the bugs? I guess I can do that. Is something like this acceptable? /* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */ struct cp210x_flow_ctl {

RE: [EXT] Re: [PATCH RESEND 3/5] USB: serial: cp210x: Added comments to CRTSCT flag code.

I was planning to define all these bits in a separate future patch. Would you rather prefer the magic numbers defined before fixing the bugs? I guess I can do that. Is something like this acceptable? /* CP210X_GET_FLOW/CP210X_SET_FLOW read/write these 0x10 bytes */ struct cp210x_flow_ctl {

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Apr 25, 2016 at 06:26:56PM +0100, Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote: > > --- a/arch/arm64/kernel/entry.S > > +++ b/arch/arm64/kernel/entry.S > > @@ -715,9 +715,13 @@ ENDPROC(ret_from_fork) > > */ > > .align 6 > > el0_svc: > > -

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

On Mon, Apr 25, 2016 at 06:26:56PM +0100, Catalin Marinas wrote: > On Wed, Apr 06, 2016 at 01:08:42AM +0300, Yury Norov wrote: > > --- a/arch/arm64/kernel/entry.S > > +++ b/arch/arm64/kernel/entry.S > > @@ -715,9 +715,13 @@ ENDPROC(ret_from_fork) > > */ > > .align 6 > > el0_svc: > > -

Re: [alsa-devel] [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

> On Apr 25, 2016, at 5:55 AM, Mark Brown wrote: > > If the clock code is worth splitting off into a separate driver that's > what drivers/mfd is for. I have my doubts that it’s worth splitting off into a separate driver. There’s not a lot of use for it outside of the

Re: [alsa-devel] [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec

> On Apr 25, 2016, at 5:55 AM, Mark Brown wrote: > > If the clock code is worth splitting off into a separate driver that's > what drivers/mfd is for. I have my doubts that it’s worth splitting off into a separate driver. There’s not a lot of use for it outside of the internals of the

Re: [PATCH V3 1/1] perf hists: clear dummy entry accumulated period

On Sun, Apr 24, 2016 at 11:28:09PM -0700, kan.li...@intel.com wrote: > From: Kan Liang > > The accumulated period for dummy entry should also be 0. > Otherwise, the total overhead could be overcounted. > [perf]$ perf record -e '{LLC-load-misses,cpu/instructions/}' >

Re: [PATCH V3 1/1] perf hists: clear dummy entry accumulated period

On Sun, Apr 24, 2016 at 11:28:09PM -0700, kan.li...@intel.com wrote: > From: Kan Liang > > The accumulated period for dummy entry should also be 0. > Otherwise, the total overhead could be overcounted. > [perf]$ perf record -e '{LLC-load-misses,cpu/instructions/}' > --call-graph=lbr ./tchain >

Re: [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 04/25/2016 09:09 PM, Dmitry Safonov wrote: On 04/25/2016 08:14 PM, Dmitry Safonov wrote: On 04/25/2016 07:53 PM, Andy Lutomirski wrote: On Mon, Apr 25, 2016 at 9:12 AM, Dmitry Safonov wrote: As the task isn't executing at the moment of {GET,SET}REGS, return regset

Re: [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 04/25/2016 09:09 PM, Dmitry Safonov wrote: On 04/25/2016 08:14 PM, Dmitry Safonov wrote: On 04/25/2016 07:53 PM, Andy Lutomirski wrote: On Mon, Apr 25, 2016 at 9:12 AM, Dmitry Safonov wrote: As the task isn't executing at the moment of {GET,SET}REGS, return regset that corresponds to code

[RFC] Add missing #include

ARRAY_SIZE uses BUILD_BUG_ON_ZERO, which is undefined is you don't include linux/bug.h first, which just happened to me. Is there any reason this include isn't here? A quick grep found 595 other files using a define from bug.h without ever including it. If this is a simple mistake and was

Re: [PATCH] xfs: idle aild if the AIL is pushed up to the target LSN

Am Montag, den 25.04.2016, 10:24 -0400 schrieb Brian Foster: > On Mon, Apr 25, 2016 at 09:42:43AM +0200, Lucas Stach wrote: > > > > The current logic only idles aild if the AIL is empty, rescheduling > > the worker with a timeout of 50ms otherwise. If the target LSN > > isn't > > moved forward,

[RFC] Add missing #include

ARRAY_SIZE uses BUILD_BUG_ON_ZERO, which is undefined is you don't include linux/bug.h first, which just happened to me. Is there any reason this include isn't here? A quick grep found 595 other files using a define from bug.h without ever including it. If this is a simple mistake and was

Re: [PATCH] xfs: idle aild if the AIL is pushed up to the target LSN

Am Montag, den 25.04.2016, 10:24 -0400 schrieb Brian Foster: > On Mon, Apr 25, 2016 at 09:42:43AM +0200, Lucas Stach wrote: > > > > The current logic only idles aild if the AIL is empty, rescheduling > > the worker with a timeout of 50ms otherwise. If the target LSN > > isn't > > moved forward,

Re: [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 04/25/2016 08:14 PM, Dmitry Safonov wrote: On 04/25/2016 07:53 PM, Andy Lutomirski wrote: On Mon, Apr 25, 2016 at 9:12 AM, Dmitry Safonov wrote: As the task isn't executing at the moment of {GET,SET}REGS, return regset that corresponds to code selector. So, for i386

Re: [RFC 3/3] x86/ptrace: down with test_thread_flag(TIF_IA32)

On 04/25/2016 08:14 PM, Dmitry Safonov wrote: On 04/25/2016 07:53 PM, Andy Lutomirski wrote: On Mon, Apr 25, 2016 at 9:12 AM, Dmitry Safonov wrote: As the task isn't executing at the moment of {GET,SET}REGS, return regset that corresponds to code selector. So, for i386 elf binary that changed

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

Florian Westphal : [...] > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > index d0084d4..a3200ea 100644 > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > +++

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

Florian Westphal : [...] > diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > index d0084d4..a3200ea 100644 > --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c > +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c [...] > @@

Re: [PATCH 3/5] iio: inv_mpu6050: Check WHO_AM_I register on probe

On 25/04/16 12:17, Crestez Dan Leonard wrote: > On 04/24/2016 02:14 PM, Jonathan Cameron wrote: >> On 20/04/16 14:15, Crestez Dan Leonard wrote: >>> This can be used to distinguish mpu6500. This is a warning rather than >>> an error because the differences are mostly irrelevant and it's nice to

Re: [PATCH 3/5] iio: inv_mpu6050: Check WHO_AM_I register on probe

On 25/04/16 12:17, Crestez Dan Leonard wrote: > On 04/24/2016 02:14 PM, Jonathan Cameron wrote: >> On 20/04/16 14:15, Crestez Dan Leonard wrote: >>> This can be used to distinguish mpu6500. This is a warning rather than >>> an error because the differences are mostly irrelevant and it's nice to

Re: [PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

On Mon, Apr 25, 2016 at 10:50:24AM -0700, Caleb Crome wrote: > Due to caching, SOR wasn't written when it should have been. This > patch simply adds SOR to the volatile list. Could you expand on when it wasn't written and why it needed to be please? signature.asc Description: PGP signature

Re: [PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

On Mon, Apr 25, 2016 at 10:50:24AM -0700, Caleb Crome wrote: > Due to caching, SOR wasn't written when it should have been. This > patch simply adds SOR to the volatile list. Could you expand on when it wasn't written and why it needed to be please? signature.asc Description: PGP signature

Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

On Mon, 25 Apr 2016, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 05:27:19PM -0700, Vikas Shivappa wrote: +static inline void mbm_set_rccount( + struct perf_event *event, struct rmid_read *rr) That's horrible style, the 'normal' style is something like: static

Re: [PATCH 2/4] perf/x86/mbm: Store bytes counted for mbm during recycle

On Mon, 25 Apr 2016, Peter Zijlstra wrote: On Fri, Apr 22, 2016 at 05:27:19PM -0700, Vikas Shivappa wrote: +static inline void mbm_set_rccount( + struct perf_event *event, struct rmid_read *rr) That's horrible style, the 'normal' style is something like: static

[PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

Due to caching, SOR wasn't written when it should have been. This patch simply adds SOR to the volatile list. Signed-off-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index

[PATCH 1/1] ASoC: fsl_ssi: add CCSR_SSI_SOR to volatile register list

Due to caching, SOR wasn't written when it should have been. This patch simply adds SOR to the volatile list. Signed-off-by: Caleb Crome --- sound/soc/fsl/fsl_ssi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c index 216e3cb..2f3bf9c

Re: [PATCH] tpm: check for TPM_CHIP_FLAG_TPM2 before calling tpm2_shutdown()

On Mon, Apr 25, 2016 at 12:21:30PM +0300, Jarkko Sakkinen wrote: > Signed-off-by: Jarkko Sakkinen > Reported-by: Stefan Berger > drivers/char/tpm/tpm-chip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-By: Jason

linux-next: perf issue on big.LITTLE since 26657848502b7847

Hi, When booting an arm64 defconfig linux-next (next-20160422) on an ARM Juno system, I hit a WARN_ON_ONCE in perf_pmu_register (see backtrace at the end of this email). This was introduced by commit 26657848502b7847 ("perf/core: Verify we have a single perf_hw_context PMU") where we forcefully

Re: [PATCH] tpm: check for TPM_CHIP_FLAG_TPM2 before calling tpm2_shutdown()

On Mon, Apr 25, 2016 at 12:21:30PM +0300, Jarkko Sakkinen wrote: > Signed-off-by: Jarkko Sakkinen > Reported-by: Stefan Berger > drivers/char/tpm/tpm-chip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Reviewed-By: Jason Gunthorpe Fixes: 20e0152393b41 ("tpm: fix crash in tpm_tis

linux-next: perf issue on big.LITTLE since 26657848502b7847

Hi, When booting an arm64 defconfig linux-next (next-20160422) on an ARM Juno system, I hit a WARN_ON_ONCE in perf_pmu_register (see backtrace at the end of this email). This was introduced by commit 26657848502b7847 ("perf/core: Verify we have a single perf_hw_context PMU") where we forcefully

Re: [PATCH v3 00/18] wcn36xx fixes

Bjorn Andersson writes: > The bulk of the following patches have been sitting in Eugene's Github tree > for > quite some time. They fix various issues existing in the mainline drivers, so > they should be merged there too. > > Also included are two new fixes, of my

Applied "regulator: rk808: remove linear range definitions with a single range" to the regulator tree

The patch regulator: rk808: remove linear range definitions with a single range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Re: [PATCH v3 00/18] wcn36xx fixes

Bjorn Andersson writes: > The bulk of the following patches have been sitting in Eugene's Github tree > for > quite some time. They fix various issues existing in the mainline drivers, so > they should be merged there too. > > Also included are two new fixes, of my own; the important one being

Applied "regulator: rk808: remove linear range definitions with a single range" to the regulator tree

The patch regulator: rk808: remove linear range definitions with a single range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "spi: return error if kmap'd buffers passed to spi_map_buf()" to the spi tree

The patch spi: return error if kmap'd buffers passed to spi_map_buf() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "spi: return error if kmap'd buffers passed to spi_map_buf()" to the spi tree

The patch spi: return error if kmap'd buffers passed to spi_map_buf() has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: refactor valid_ops_mask checking code" to the regulator tree

The patch regulator: refactor valid_ops_mask checking code has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "regulator: refactor valid_ops_mask checking code" to the regulator tree

The patch regulator: refactor valid_ops_mask checking code has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Re: random(4) changes

Am Montag, 25. April 2016, 10:38:25 schrieb Andi Kleen: Hi Andi, > On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote: > > Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen: > > > > Hi Andi, > > > > > Sandy Harris writes: > > > > > > There is also

Re: random(4) changes

Am Montag, 25. April 2016, 10:38:25 schrieb Andi Kleen: Hi Andi, > On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote: > > Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen: > > > > Hi Andi, > > > > > Sandy Harris writes: > > > > > > There is also the third problem of

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On Mon, Apr 25, 2016 at 08:34:10PM +0300, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by > applications to set aside private regions of code and data. The code > outside the enclave is disallowed to access the memory inside the > enclave by the CPU access

Re: [PATCH 3/6] intel_sgx: driver for Intel Secure Guard eXtensions

On Mon, Apr 25, 2016 at 08:34:10PM +0300, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by > applications to set aside private regions of code and data. The code > outside the enclave is disallowed to access the memory inside the > enclave by the CPU access

Re: [PATCH 6/6] intel_sgx: TODO file for the staging area

On Mon, Apr 25, 2016 at 08:34:13PM +0300, Jarkko Sakkinen wrote: > Signed-off-by: Jarkko Sakkinen > --- > drivers/staging/intel_sgx/TODO | 25 + > 1 file changed, 25 insertions(+) > create mode 100644 drivers/staging/intel_sgx/TODO > >

Re: [RFC] The Linux Scheduler: a Decade of Wasted Cores Report

On Mon, 2016-04-25 at 11:34 +0200, Peter Zijlstra wrote: > On Sat, Apr 23, 2016 at 06:38:25PM -0700, Brendan Gregg wrote: > >  > > Their proof of concept patches are online[1]. I tested them and saw > > 0% > > improvements on the systems I tested, for some simple workloads[2]. > > I > > tested 1

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Mon, Apr 25, 2016 at 08:34:07PM +0300, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by > applications to set aside private regions of code and data. The code > outside the enclave is disallowed to access the memory inside the > enclave by the CPU access

Re: [PATCH 6/6] intel_sgx: TODO file for the staging area

On Mon, Apr 25, 2016 at 08:34:13PM +0300, Jarkko Sakkinen wrote: > Signed-off-by: Jarkko Sakkinen > --- > drivers/staging/intel_sgx/TODO | 25 + > 1 file changed, 25 insertions(+) > create mode 100644 drivers/staging/intel_sgx/TODO > > diff --git

Re: [RFC] The Linux Scheduler: a Decade of Wasted Cores Report

On Mon, 2016-04-25 at 11:34 +0200, Peter Zijlstra wrote: > On Sat, Apr 23, 2016 at 06:38:25PM -0700, Brendan Gregg wrote: > >  > > Their proof of concept patches are online[1]. I tested them and saw > > 0% > > improvements on the systems I tested, for some simple workloads[2]. > > I > > tested 1

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Mon, Apr 25, 2016 at 08:34:07PM +0300, Jarkko Sakkinen wrote: > Intel(R) SGX is a set of CPU instructions that can be used by > applications to set aside private regions of code and data. The code > outside the enclave is disallowed to access the memory inside the > enclave by the CPU access

Re: [PATCH] [RFC] net: dsa: mv88e6xxx: Pre-initialize err in mv88e6xxx_port_bridge_join()

Hi Vivien, On Mon, Apr 25, 2016 at 7:31 PM, Vivien Didelot wrote: > Geert Uytterhoeven writes: >> On Mon, Apr 25, 2016 at 5:03 PM, Vivien Didelot >> wrote: >>> Geert Uytterhoeven

Re: [PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver

On 25 April 2016 at 18:08, Liviu Dudau wrote: > On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote: >> On 25 April 2016 at 15:19, Liviu Dudau wrote: >> > Add MAINTAINERS entry for ARM Mali-DP driver and update the >> > HDLCD file matching

Re: [PATCH v2 3/3] MAINTAINERS: Add entry for Mali-DP driver

On 25 April 2016 at 18:08, Liviu Dudau wrote: > On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote: >> On 25 April 2016 at 15:19, Liviu Dudau wrote: >> > Add MAINTAINERS entry for ARM Mali-DP driver and update the >> > HDLCD file matching pattern to cover only HDLCD rather than >> >

Re: [PATCH] [RFC] net: dsa: mv88e6xxx: Pre-initialize err in mv88e6xxx_port_bridge_join()

Hi Vivien, On Mon, Apr 25, 2016 at 7:31 PM, Vivien Didelot wrote: > Geert Uytterhoeven writes: >> On Mon, Apr 25, 2016 at 5:03 PM, Vivien Didelot >> wrote: >>> Geert Uytterhoeven writes: drivers/net/dsa/mv88e6xxx.c: In function ‘mv88e6xxx_port_bridge_join’:

Re: [PATCH 1/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

Hello, Roman. On Mon, Apr 25, 2016 at 07:39:52PM +0200, Roman Penyaev wrote: > Ok, that's clear now. Thanks. I was confused also by a spin lock, which > is being released just after clear pending: > >set_work_pool_and_clear_pending(work, pool->id); >spin_unlock_irq(>lock); >... >

Re: [PATCH 1/1] [RFC] workqueue: fix ghost PENDING flag while doing MQ IO

Hello, Roman. On Mon, Apr 25, 2016 at 07:39:52PM +0200, Roman Penyaev wrote: > Ok, that's clear now. Thanks. I was confused also by a spin lock, which > is being released just after clear pending: > >set_work_pool_and_clear_pending(work, pool->id); >spin_unlock_irq(>lock); >... >

[PATCHv2 2/7] EDAC, altera: Add panic flag check to A10 IRQ

From: Thor Thayer In preparation for additional memory module ECCs, the IRQ function will check a panic flag before doing a kernel panic on double bit errors. ECCs on buffers will not cause a kernel panic on DBERRs. Signed-off-by: Thor Thayer

[PATCHv2 2/7] EDAC, altera: Add panic flag check to A10 IRQ

From: Thor Thayer In preparation for additional memory module ECCs, the IRQ function will check a panic flag before doing a kernel panic on double bit errors. ECCs on buffers will not cause a kernel panic on DBERRs. Signed-off-by: Thor Thayer --- v2 New patch. Add panic flag to IRQ function.

[PATCHv2 0/7] Add EDAC peripheral init functions & Ethernet EDAC

From: Thor Thayer This patch set adds the memory initialization functions for Altera's Arria10 peripherals, the first of which is the Ethernet EDAC. The ECC memory init functions are common to all the peripheral memory buffers. Thor Thayer (7): EDAC, altera:

[PATCHv2 0/7] Add EDAC peripheral init functions & Ethernet EDAC

From: Thor Thayer This patch set adds the memory initialization functions for Altera's Arria10 peripherals, the first of which is the Ethernet EDAC. The ECC memory init functions are common to all the peripheral memory buffers. Thor Thayer (7): EDAC, altera: Check parent status for Arria10

<    4   5   6   7   8   9   10   11   12   13   >