[PATCH] selftests/x86: Add a selftest for SYSRET to noncanonical addresses

SYSRET to a noncanonical address will blow up on Intel CPUs. Linux needs to prevent this from happening in two major cases, and the criteria will become more complicated when support for larger virtual address spaces is added. A fast-path SYSCALL will fallthrough to the following instruction

[PATCH] selftests/x86: Add a selftest for SYSRET to noncanonical addresses

SYSRET to a noncanonical address will blow up on Intel CPUs. Linux needs to prevent this from happening in two major cases, and the criteria will become more complicated when support for larger virtual address spaces is added. A fast-path SYSCALL will fallthrough to the following instruction

Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote: > This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel > driver. This panel has 1440x2560 resolution in 5.7-inch physical > panel in the TM2 device. > > Signed-off-by: Donghwa Lee > Signed-off-by:

Re: [PATCH 1/2] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

On Wed, Dec 14, 2016 at 03:04:04PM +0900, Hoegeun Kwon wrote: > This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel > driver. This panel has 1440x2560 resolution in 5.7-inch physical > panel in the TM2 device. > > Signed-off-by: Donghwa Lee > Signed-off-by: Hyungwon Hwang >

Re: [PATCH] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

On Mon, 19 Dec 2016, Juergen Gross wrote: > On 19/12/16 03:56, Jiandi An wrote: > > Ensure all reserved fields of xatp are zero before making hypervisor > > call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in > > XEN fails the mapping request if extra.res reserved field in xatp

Re: [PATCH] Xen: ARM: Zero reserved fields of xatp before making hypervisor call

On Mon, 19 Dec 2016, Juergen Gross wrote: > On 19/12/16 03:56, Jiandi An wrote: > > Ensure all reserved fields of xatp are zero before making hypervisor > > call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in > > XEN fails the mapping request if extra.res reserved field in xatp

Re: [PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote: > The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. > > Signed-off-by: Caesar Wang > --- > > Changes in v3: None > Changes in v2: None > > .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt

Re: [PATCH v3 1/2] dt-bindings: display: Add BOE nv101wxmn51 panel binding

On Wed, Dec 14, 2016 at 11:19:55AM +0800, Caesar Wang wrote: > The BOE 10.1" NV101WXMN51 panel is an WXGA TFT LCD panel. > > Signed-off-by: Caesar Wang > --- > > Changes in v3: None > Changes in v2: None > > .../devicetree/bindings/display/panel/boe,nv101wxmn51.txt | 7 > +++ >

Re: [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string

On Wed, Dec 14, 2016 at 11:10:46AM +0900, Masahiro Yamada wrote: > Add a Socionext SoC specific compatible (suggested by Rob Herring). > > No SoC specific data are associated with the compatible strings for > now, but other SoC vendors may use this IP and want to differentiate > IP variants in

Re: [PATCH v2] mmc: sdhci-cadence: add Socionext UniPhier specific compatible string

On Wed, Dec 14, 2016 at 11:10:46AM +0900, Masahiro Yamada wrote: > Add a Socionext SoC specific compatible (suggested by Rob Herring). > > No SoC specific data are associated with the compatible strings for > now, but other SoC vendors may use this IP and want to differentiate > IP variants in

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: > IIUIC find_microcode_in_initrd() is called with paging on only on Intel > (which is where I observed it). Ah, that was an important fact. Yes, I can repro it now. Thanks. -- Regards/Gruss, Boris. Good mailing practices for

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On Mon, Dec 19, 2016 at 01:12:25PM -0500, Boris Ostrovsky wrote: > IIUIC find_microcode_in_initrd() is called with paging on only on Intel > (which is where I observed it). Ah, that was an important fact. Yes, I can repro it now. Thanks. -- Regards/Gruss, Boris. Good mailing practices for

Re: [PATCH] staging: comedi: cb_pcidas64: Fixed coding issue about multiple line dereferencing

Hi devendra, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/devendra-sharma/staging-comedi

Re: [PATCH] staging: comedi: cb_pcidas64: Fixed coding issue about multiple line dereferencing

Hi devendra, [auto build test WARNING on staging/staging-testing] [also build test WARNING on v4.9 next-20161219] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/devendra-sharma/staging-comedi

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani wrote: > On 2016-12-13 12:04, Rob Herring wrote: >> >> On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote: >>> >>> UFS device and link can be put in multiple different low power modes >>> hence >>> UFS driver

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

On Tue, Dec 13, 2016 at 2:16 PM, Subhash Jadavani wrote: > On 2016-12-13 12:04, Rob Herring wrote: >> >> On Mon, Dec 12, 2016 at 04:54:20PM -0800, Subhash Jadavani wrote: >>> >>> UFS device and link can be put in multiple different low power modes >>> hence >>> UFS driver supports multiple

Re: [PATCH] perf diff: bug fix, donot overwrite valid build id

Em Mon, Dec 19, 2016 at 02:53:30PM +, Liang, Kan escreveu: > Hi Arnaldo, > > Ping > > Are you OK with the fix? Yeah, looks ok, will merge it. - Arnaldo > Thanks, > Kan > > > > > From: Kan Liang > > > > Fixes a perf diff regression issue which was introduced by

Re: [PATCH] perf diff: bug fix, donot overwrite valid build id

Em Mon, Dec 19, 2016 at 02:53:30PM +, Liang, Kan escreveu: > Hi Arnaldo, > > Ping > > Are you OK with the fix? Yeah, looks ok, will merge it. - Arnaldo > Thanks, > Kan > > > > > From: Kan Liang > > > > Fixes a perf diff regression issue which was introduced by commit > > 5baecbcd9c9a

Re: *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated

Em Mon, Dec 19, 2016 at 06:28:42PM +0100, Markus Trippelsdorf escreveu: > On 2016.12.19 at 17:52 +0100, Markus Trippelsdorf wrote: > > On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote: > > > Running the latest kernel git tree, I get buffer overflow warnings when > > > I try to run "perf

Re: *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated

Em Mon, Dec 19, 2016 at 06:28:42PM +0100, Markus Trippelsdorf escreveu: > On 2016.12.19 at 17:52 +0100, Markus Trippelsdorf wrote: > > On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote: > > > Running the latest kernel git tree, I get buffer overflow warnings when > > > I try to run "perf

Re: [PATCH v4 0/4] Introduce the initify gcc plugin

On 12/16/2016 02:06 PM, Kees Cook wrote: > Hi, > > This is a continuation of Emese Revfy's initify plugin upstreaming. This > is based on her v3, but updated with various fixes from her github tree. > Additionally, I split off the printf attribute fixes and sent those > separately. > > This is

Re: [PATCH v4 0/4] Introduce the initify gcc plugin

On 12/16/2016 02:06 PM, Kees Cook wrote: > Hi, > > This is a continuation of Emese Revfy's initify plugin upstreaming. This > is based on her v3, but updated with various fixes from her github tree. > Additionally, I split off the printf attribute fixes and sent those > separately. > > This is

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, 19 Dec 2016, Josh Poimboeuf wrote: > On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > index 215612c..b4a6663 100644 > > > --- a/arch/x86/Kconfig > > > +++

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, 19 Dec 2016, Josh Poimboeuf wrote: > On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > index 215612c..b4a6663 100644 > > > --- a/arch/x86/Kconfig > > > +++

[PULL 0/5] Xtensa improvements for 4.10

://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20161219 for you to fetch changes up to 30b507051dd1f79bbedce79cb37dc0ef31f5fb6c: xtensa: update DMA-related Documentation/features entries (2016-12-15 10:41:51 -0800) Xtensa

[PULL 0/5] Xtensa improvements for 4.10

://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20161219 for you to fetch changes up to 30b507051dd1f79bbedce79cb37dc0ef31f5fb6c: xtensa: update DMA-related Documentation/features entries (2016-12-15 10:41:51 -0800) Xtensa

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe ha scritto: > > On 12/19/2016 04:32 AM, Paolo Valente wrote: >> >>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: >>> >>> This is version 4 of this patchset, version 3 was posted here: >>> >>>

Re: [PATCHSET v4] blk-mq-scheduling framework

> Il giorno 19 dic 2016, alle ore 16:20, Jens Axboe ha scritto: > > On 12/19/2016 04:32 AM, Paolo Valente wrote: >> >>> Il giorno 17 dic 2016, alle ore 01:12, Jens Axboe ha scritto: >>> >>> This is version 4 of this patchset, version 3 was posted here: >>> >>>

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

Em Sat, Dec 17, 2016 at 07:27:54AM +1100, Anton Blanchard escreveu: > Hi Ravi, > > > > perf report (with TUI) exits with error when it finds a sample of > > > zero length symbol(i.e. addr == sym->start == sym->end). Actually > > > these are valid samples. Don't exit TUI and show report with such

Re: [PATCH] perf TUI: Don't throw error for zero length symbols

Em Sat, Dec 17, 2016 at 07:27:54AM +1100, Anton Blanchard escreveu: > Hi Ravi, > > > > perf report (with TUI) exits with error when it finds a sample of > > > zero length symbol(i.e. addr == sym->start == sym->end). Actually > > > these are valid samples. Don't exit TUI and show report with such

Re: [PATCH] fbdev: remove current maintainer

On Mon, 19 Dec 2016 14:34:12 +0100 Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: > > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen > > wrote: > > > > > Remove Tomi Valkeinen

Re: [PATCH] fbdev: remove current maintainer

On Mon, 19 Dec 2016 14:34:12 +0100 Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, December 15, 2016 12:12:52 PM Andrew Morton wrote: > > On Thu, 8 Dec 2016 10:34:12 +0200 Tomi Valkeinen > > wrote: > > > > > Remove Tomi Valkeinen from fbdev maintainer and mark fbdev as orphan. >

Re: [PATCH] staging: comedi: cb_pcidas64: Fixed coding issue about multiple line dereferencing

On 19/12/2016 15:14, devendra sharma wrote: Fixed coding issue about multiple line dereferencing Signed-off-by: Devendra Sharma --- drivers/staging/comedi/drivers/cb_pcidas64.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) I guess this

Re: [PATCH] staging: comedi: cb_pcidas64: Fixed coding issue about multiple line dereferencing

On 19/12/2016 15:14, devendra sharma wrote: Fixed coding issue about multiple line dereferencing Signed-off-by: Devendra Sharma --- drivers/staging/comedi/drivers/cb_pcidas64.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) I guess this is version 3 of the patch?

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 01:07 PM, Borislav Petkov wrote: > On Mon, Dec 19, 2016 at 05:40:27PM +0100, Borislav Petkov wrote: >> On Mon, Dec 19, 2016 at 11:10:29AM -0500, Boris Ostrovsky wrote: >>> config attached. I'll see how I can get you the initrd. >> Wait a bit, lemme see if I can repro with my initrd

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On 12/19/2016 01:07 PM, Borislav Petkov wrote: > On Mon, Dec 19, 2016 at 05:40:27PM +0100, Borislav Petkov wrote: >> On Mon, Dec 19, 2016 at 11:10:29AM -0500, Boris Ostrovsky wrote: >>> config attached. I'll see how I can get you the initrd. >> Wait a bit, lemme see if I can repro with my initrd

RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF

David Laight wrote: > From: George Spelvin ... >> uint32_t >> hsiphash24(char const *in, size_t len, uint32_t const key[2]) >> { >> uint32_t c = key[0]; >> uint32_t d = key[1]; >> uint32_t a = 0x6c796765 ^ 0x736f6d65; >> uint32_t b = d ^ 0x74656462 ^ 0x646f7261; > I've not

RE: [PATCH v5 1/4] siphash: add cryptographically secure PRF

David Laight wrote: > From: George Spelvin ... >> uint32_t >> hsiphash24(char const *in, size_t len, uint32_t const key[2]) >> { >> uint32_t c = key[0]; >> uint32_t d = key[1]; >> uint32_t a = 0x6c796765 ^ 0x736f6d65; >> uint32_t b = d ^ 0x74656462 ^ 0x646f7261; > I've not

Debug hints for fpu state NULL pointer dereference on context switch during core dump in 3.0.101

I am trying to debug a problem that has been happening occationally for years on some of our systems running 3.0.101 kernel (yes I know it is old, we are moving to 4.9 at the moment but I would like older releases to be fixed too, assuming 4.9 makes this problem disappear). What is happening is

Debug hints for fpu state NULL pointer dereference on context switch during core dump in 3.0.101

I am trying to debug a problem that has been happening occationally for years on some of our systems running 3.0.101 kernel (yes I know it is old, we are moving to 4.9 at the moment but I would like older releases to be fixed too, assuming 4.9 makes this problem disappear). What is happening is

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On Mon, Dec 19, 2016 at 05:40:27PM +0100, Borislav Petkov wrote: > On Mon, Dec 19, 2016 at 11:10:29AM -0500, Boris Ostrovsky wrote: > > config attached. I'll see how I can get you the initrd. > > Wait a bit, lemme see if I can repro with my initrd here. Hmm, it boots here (btw, this is with the

Re: [PATCH] x86/microcode: Adjust ramdisk address when accessing by virtual address

On Mon, Dec 19, 2016 at 05:40:27PM +0100, Borislav Petkov wrote: > On Mon, Dec 19, 2016 at 11:10:29AM -0500, Boris Ostrovsky wrote: > > config attached. I'll see how I can get you the initrd. > > Wait a bit, lemme see if I can repro with my initrd here. Hmm, it boots here (btw, this is with the

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

Hi, On Mon, Dec 19, 2016 at 9:33 AM, Andy Shevchenko wrote: > On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: >> Hi, >> >> On Mon, Dec 19, 2016 at 4:59 AM, Andy Shevchenko >> wrote: >> > On Sun, 2016-12-18 at 17:14

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

Hi, On Mon, Dec 19, 2016 at 9:33 AM, Andy Shevchenko wrote: > On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: >> Hi, >> >> On Mon, Dec 19, 2016 at 4:59 AM, Andy Shevchenko >> wrote: >> > On Sun, 2016-12-18 at 17:14 -0800, Douglas Anderson wrote: >> > > On a Rockchip rk3399-based board

Re: [PATCH 2/5] dmaengine: Add support for custom data mapping

On Mon, Dec 19, 2016 at 09:19:23PM +0530, Vinod Koul wrote: > On Sun, Dec 18, 2016 at 11:06:42PM -0600, Andy Gross wrote: > > On Sun, Dec 18, 2016 at 09:56:02PM +0530, Vinod Koul wrote: > > > On Thu, Dec 15, 2016 at 03:25:52PM +0530, Abhishek Sahu wrote: > > > > The current DMA APIs only support

Re: [PATCH 2/5] dmaengine: Add support for custom data mapping

On Mon, Dec 19, 2016 at 09:19:23PM +0530, Vinod Koul wrote: > On Sun, Dec 18, 2016 at 11:06:42PM -0600, Andy Gross wrote: > > On Sun, Dec 18, 2016 at 09:56:02PM +0530, Vinod Koul wrote: > > > On Thu, Dec 15, 2016 at 03:25:52PM +0530, Abhishek Sahu wrote: > > > > The current DMA APIs only support

Re: [PATCH] staging: comedi: dyna_pci10xx: fixed check patch warnings about memory barrier comments

On 19/12/2016 14:36, devendra sharma wrote: Added comments before memory barrier Signed-off-by: Devendra Sharma --- drivers/staging/comedi/drivers/dyna_pci10xx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH] staging: comedi: dyna_pci10xx: fixed check patch warnings about memory barrier comments

On 19/12/2016 14:36, devendra sharma wrote: Added comments before memory barrier Signed-off-by: Devendra Sharma --- drivers/staging/comedi/drivers/dyna_pci10xx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/comedi/drivers/dyna_pci10xx.c

Re: [PATCH v6 1/2] Add OV5647 device tree documentation

On Tue, Dec 13, 2016 at 02:32:36PM +, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/i2c/ov5647.txt | 35 > ++ > 1 file changed, 35 insertions(+) >

Re: [PATCH v6 1/2] Add OV5647 device tree documentation

On Tue, Dec 13, 2016 at 02:32:36PM +, Ramiro Oliveira wrote: > Create device tree bindings documentation. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/i2c/ov5647.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode 100644

[PATCH] clocksource: arm_arch_timer: print timer value at init time

This is useful to get an indication of how much time we spent in firmware. It's not guaranteed that the timer started at 0 on reset, so it's just an approximation, and might very well be invalid on some systems. But it's still a useful metric to have access to. Signed-off-by: Olof Johansson

[PATCH] clocksource: arm_arch_timer: print timer value at init time

This is useful to get an indication of how much time we spent in firmware. It's not guaranteed that the timer started at 0 on reset, so it's just an approximation, and might very well be invalid on some systems. But it's still a useful metric to have access to. Signed-off-by: Olof Johansson ---

Re: [RFC] arch/x86/Kconfig.cpu: Update with new gcc disponible 64bits CPU uarchs.

hehehe Thanks, Petkov! Instead distros, I was thinking in HPC vendors, (SGI, etc), where those can ship an optmized kernel compiled to the target CPU inside the HPC equipment, resulting in a better product. Well, I've reading a HPC equipment vendor documentation explaining that warrant will be

Re: [RFC] arch/x86/Kconfig.cpu: Update with new gcc disponible 64bits CPU uarchs.

hehehe Thanks, Petkov! Instead distros, I was thinking in HPC vendors, (SGI, etc), where those can ship an optmized kernel compiled to the target CPU inside the HPC equipment, resulting in a better product. Well, I've reading a HPC equipment vendor documentation explaining that warrant will be

Re: [PATCH] drivers: staging: fbtft: fix checkpatch error and udelay

19.12.2016, 08:35, "Greg KH" : > On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote: >>  These changes where identified by checkpatch.pl as needed changes to >>  align the code with the linux development coding style. The several >>  lines of text where

Re: [PATCH] drivers: staging: fbtft: fix checkpatch error and udelay

19.12.2016, 08:35, "Greg KH" : > On Sun, Dec 18, 2016 at 11:47:30AM -0600, Scott Matheina wrote: >>  These changes where identified by checkpatch.pl as needed changes to >>  align the code with the linux development coding style. The several >>  lines of text where aligned with the precending

Re: [PATCH] staging: comedi: ni_670x: using the BIT(x) macro

On 16/12/2016 20:20, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer using the BIT macro replacing bit shifting on 1 with the BIT(x) macro. Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/ni_670x.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH] staging: comedi: ni_670x: using the BIT(x) macro

On 16/12/2016 20:20, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer using the BIT macro replacing bit shifting on 1 with the BIT(x) macro. Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/ni_670x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] staging: comedi: ni_at_ao: using the BIT(x) macro

On 16/12/2016 20:06, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer using the BIT macro replacing bit shifting on 1 with the BIT(x) macro. Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/ni_at_ao.c | 62 +++ 1

Re: [PATCH] staging: comedi: ni_at_ao: using the BIT(x) macro

On 16/12/2016 20:06, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer using the BIT macro replacing bit shifting on 1 with the BIT(x) macro. Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/ni_at_ao.c | 62 +++ 1 file changed, 31

Re: [PATCH 3/3] staging: comedi: cb_pcidas64: use preferred kernel type u32

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u32' over 'uint32_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 38 ++-- 1 file changed, 19 insertions(+), 19

Re: [PATCH 3/3] staging: comedi: cb_pcidas64: use preferred kernel type u32

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u32' over 'uint32_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 38 ++-- 1 file changed, 19 insertions(+), 19 deletions(-)

Re: [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

On Mon, Dec 12, 2016 at 03:00:35PM +, Ramiro Oliveira wrote: > Create device tree bindings documentation for Media and Video Device, as well > as the DW MIPI CSI-2 Host. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/snps,dw-mipi-csi.txt |

Re: [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

On Mon, Dec 12, 2016 at 03:00:35PM +, Ramiro Oliveira wrote: > Create device tree bindings documentation for Media and Video Device, as well > as the DW MIPI CSI-2 Host. > > Signed-off-by: Ramiro Oliveira > --- > .../devicetree/bindings/media/snps,dw-mipi-csi.txt | 37 >

Re: [PATCH 2/3] staging: comedi: cb_pcidas64: use preferred kernel type u16

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u16' over 'uint16_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 58 ++-- 1 file changed, 29 insertions(+), 29

Re: [PATCH 2/3] staging: comedi: cb_pcidas64: use preferred kernel type u16

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u16' over 'uint16_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 58 ++-- 1 file changed, 29 insertions(+), 29 deletions(-)

Re: [PATCH] sched: fix group_entity's share update

On 16 December 2016 at 09:55, Vincent Guittot wrote: > On 15 December 2016 at 22:42, Peter Zijlstra wrote: >> >> On Thu, Dec 01, 2016 at 05:38:53PM +0100, Vincent Guittot wrote: >> > The update of the share of a cfs_rq is done when its load_avg

Re: [PATCH] sched: fix group_entity's share update

On 16 December 2016 at 09:55, Vincent Guittot wrote: > On 15 December 2016 at 22:42, Peter Zijlstra wrote: >> >> On Thu, Dec 01, 2016 at 05:38:53PM +0100, Vincent Guittot wrote: >> > The update of the share of a cfs_rq is done when its load_avg is updated >> > but before the group_entity's

Re: [PATCH 1/3] staging: comedi: cb_pcidas64: use preferred kernel type u8

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u8' over 'uint8_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 46 ++-- 1 file changed, 23 insertions(+), 23

Re: [PATCH 1/3] staging: comedi: cb_pcidas64: use preferred kernel type u8

On 16/12/2016 19:15, Saber Rezvani wrote: Fix the checkpatch.pl issue: CHECK: Prefer kernel type 'u8' over 'uint8_t' Signed-off-by: Saber Rezvani --- drivers/staging/comedi/drivers/cb_pcidas64.c | 46 ++-- 1 file changed, 23 insertions(+), 23 deletions(-) Thanks!

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

On Mon, 2016-12-19 at 19:33 +0200, Andy Shevchenko wrote: > On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: > What I think is that the root cause of this is still unknown and > either > above looks like a hack. One more link: http://www.spinics.net/lists/linux-serial/msg22316.html --

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

On Mon, 2016-12-19 at 19:33 +0200, Andy Shevchenko wrote: > On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: > What I think is that the root cause of this is still unknown and > either > above looks like a hack. One more link: http://www.spinics.net/lists/linux-serial/msg22316.html --

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: > Hi, > > On Mon, Dec 19, 2016 at 4:59 AM, Andy Shevchenko > wrote: > > On Sun, 2016-12-18 at 17:14 -0800, Douglas Anderson wrote: > > > On a Rockchip rk3399-based board during suspend/resume testing, we >

Re: [PATCH] serial: 8250: Avoid "too much work" from bogus rx timeout interrupt

On Mon, 2016-12-19 at 09:12 -0800, Doug Anderson wrote: > Hi, > > On Mon, Dec 19, 2016 at 4:59 AM, Andy Shevchenko > wrote: > > On Sun, 2016-12-18 at 17:14 -0800, Douglas Anderson wrote: > > > On a Rockchip rk3399-based board during suspend/resume testing, we > > > found that we could get the

HalfSipHash Acceptable Usage

Hi JP, With the threads getting confusing, I've been urged to try and keep the topics and threads more closely constrained. Here's where we're at, and here's the current pressing security concern. It'd be helpful to have a definitive statement on what you think is best, so we can just build on

HalfSipHash Acceptable Usage

Hi JP, With the threads getting confusing, I've been urged to try and keep the topics and threads more closely constrained. Here's where we're at, and here's the current pressing security concern. It'd be helpful to have a definitive statement on what you think is best, so we can just build on

Re: [RFC] arch/x86/Kconfig.cpu: Update with new gcc disponible 64bits CPU uarchs.

On Mon, Dec 19, 2016 at 03:09:50PM -0200, Gustavo da Silva wrote: > Good afternon! > > Are there reasons to 'Kconfig.cpu' and 'Makefile' not contains the > 'gcc -mtune=???' > recent options? This keeps popping up every couple of months. I was wondering when it is going to appear again and there

Re: [RFC] arch/x86/Kconfig.cpu: Update with new gcc disponible 64bits CPU uarchs.

On Mon, Dec 19, 2016 at 03:09:50PM -0200, Gustavo da Silva wrote: > Good afternon! > > Are there reasons to 'Kconfig.cpu' and 'Makefile' not contains the > 'gcc -mtune=???' > recent options? This keeps popping up every couple of months. I was wondering when it is going to appear again and there

[PATCH] gpio: Move freeing of GPIO hogs before numbing of the device

When removing a gpiochip that uses GPIO hogging (e.g. by unloading the chip's DT overlay), a warning is printed: gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED This happens because gpiochip_free_hogs() is called after the gdev->chip pointer is reset to NULL. Hence

[PATCH] gpio: Move freeing of GPIO hogs before numbing of the device

When removing a gpiochip that uses GPIO hogging (e.g. by unloading the chip's DT overlay), a warning is printed: gpio gpiochip8: REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED This happens because gpiochip_free_hogs() is called after the gdev->chip pointer is reset to NULL. Hence

Re: *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated

On 2016.12.19 at 17:52 +0100, Markus Trippelsdorf wrote: > On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote: > > Running the latest kernel git tree, I get buffer overflow warnings when > > I try to run "perf top": > > > > *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf

Re: *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf terminated

On 2016.12.19 at 17:52 +0100, Markus Trippelsdorf wrote: > On 2016.12.19 at 17:18 +0100, Markus Trippelsdorf wrote: > > Running the latest kernel git tree, I get buffer overflow warnings when > > I try to run "perf top": > > > > *** buffer overflow detected ***: /usr/src/linux/tools/perf/perf

Re: [RFC 0/1] New PCI Switch Management Driver

On 19/12/16 10:29 AM, Keith Busch wrote: > Since the in-kernel driver binds to the device, won't this driver > conflict with the initialization the in-kernel one already does? Bus > master, MSI setup, etc? No. The management interface is on a completely separate PCI endpoint. So from the

Re: [RFC 0/1] New PCI Switch Management Driver

On 19/12/16 10:29 AM, Keith Busch wrote: > Since the in-kernel driver binds to the device, won't this driver > conflict with the initialization the in-kernel one already does? Bus > master, MSI setup, etc? No. The management interface is on a completely separate PCI endpoint. So from the

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 215612c..b4a6663 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -155,6 +155,7 @@ config X86 > >

Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces

On Mon, Dec 19, 2016 at 05:25:19PM +0100, Miroslav Benes wrote: > On Thu, 8 Dec 2016, Josh Poimboeuf wrote: > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 215612c..b4a6663 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -155,6 +155,7 @@ config X86 > >

Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote: > > 2) When using the NETLINK inface, the command TASKSTATS_CMD_GET > consequently returns -EINVAL. > > The code that is used by the atopacctd daemon is based on the demo code > 'getdelays.c' that can be found in the kernel

Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote: > > 2) When using the NETLINK inface, the command TASKSTATS_CMD_GET > consequently returns -EINVAL. > > The code that is used by the atopacctd daemon is based on the demo code > 'getdelays.c' that can be found in the kernel

Re: [PATCH] stmmac: fix memory barriers

Às 5:19 PM de 12/19/2016, Niklas Cassel escreveu: > On 12/19/2016 06:10 PM, Joao Pinto wrote: >> Hi, >> >> I am trying to built net-next git tree and it is failing: >> >> CC drivers/pnp/card.o >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function >> ‘stmmac_hw_fix_mac_speed’:

Re: [PATCH] stmmac: fix memory barriers

Às 5:19 PM de 12/19/2016, Niklas Cassel escreveu: > On 12/19/2016 06:10 PM, Joao Pinto wrote: >> Hi, >> >> I am trying to built net-next git tree and it is failing: >> >> CC drivers/pnp/card.o >> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function >> ‘stmmac_hw_fix_mac_speed’:

Re: [RFC PATCH] usb: USB Type-C connector class

On 12/19/2016 06:45 AM, Heikki Krogerus wrote: The purpose of USB Type-C connector class is to provide unified interface for the user space to get the status and basic information about USB Type-C connectors on a system, control over data role swapping, and when the port supports USB Power

Re: [RFC PATCH] usb: USB Type-C connector class

On 12/19/2016 06:45 AM, Heikki Krogerus wrote: The purpose of USB Type-C connector class is to provide unified interface for the user space to get the status and basic information about USB Type-C connectors on a system, control over data role swapping, and when the port supports USB Power

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Ted, On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o wrote: > On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: >> >> - Ted, Andy Lutorminski and I will try to figure out a construction of >> >> get_random_long() that we all like. > > We don't have to find the

RE: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)

Dell - Internal Use - Confidential > > There is small problem, though. On non-Apple systems the host controller only > appears when something is connected to thunderbolt ports. So the char device > would not be there all the time. However, I think we can still notify the > userspace by sending

RE: [PATCH v8 3/8] thunderbolt: Communication with the ICM (firmware)

Dell - Internal Use - Confidential > > There is small problem, though. On non-Apple systems the host controller only > appears when something is connected to thunderbolt ports. So the char device > would not be there all the time. However, I think we can still notify the > userspace by sending

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

Hi Ted, On Sat, Dec 17, 2016 at 4:41 PM, Theodore Ts'o wrote: > On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: >> >> - Ted, Andy Lutorminski and I will try to figure out a construction of >> >> get_random_long() that we all like. > > We don't have to find the most optimal

[PATCH] pvrusb2: Clean up file handle in open() error path.

Fix to avoid possible exit file handle in error paths. Signed-off-by: Santosh Kumar Singh --- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c

[PATCH] pvrusb2: Clean up file handle in open() error path.

Fix to avoid possible exit file handle in error paths. Signed-off-by: Santosh Kumar Singh --- drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c index

Re: [RFC 0/1] New PCI Switch Management Driver

On Mon, Dec 19, 2016 at 10:06:56AM -0700, Logan Gunthorpe wrote: > As I noted, the hardware is compliant and works perfectly fine with the > in-kernel driver. However, the hardware has many additional custom > features that are not covered by the PCI specs. For example, it has an > interface to

Re: [RFC 0/1] New PCI Switch Management Driver

On Mon, Dec 19, 2016 at 10:06:56AM -0700, Logan Gunthorpe wrote: > As I noted, the hardware is compliant and works perfectly fine with the > in-kernel driver. However, the hardware has many additional custom > features that are not covered by the PCI specs. For example, it has an > interface to

<    1   2   3   4   5   6   7   8   9   10   >