[PATCH v4 1/3] drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument

drm_framebuffer_init() uses const for the drm_framebuffer_funcs argument so use that on drm_fb_cma_alloc() and drm_fbdev_cma_create_with_funcs() as well. Cc: laurent.pinch...@ideasonboard.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_cma_helper.c | 4 ++--

[PATCH v4 1/3] drm/fb-cma-helper: Use const for drm_framebuffer_funcs argument

drm_framebuffer_init() uses const for the drm_framebuffer_funcs argument so use that on drm_fb_cma_alloc() and drm_fbdev_cma_create_with_funcs() as well. Cc: laurent.pinch...@ideasonboard.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_cma_helper.c | 4 ++--

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: > On 10.05.2016, at 21:58, Martin Sperl wrote: >> >> >> >>> On 10.05.2016, at 19:37, Eric Anholt wrote: >>> >>> Martin Sperl writes: >>> > On 10.05.2016 03:01, Eric Anholt

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: > On 10.05.2016, at 21:58, Martin Sperl wrote: >> >> >> >>> On 10.05.2016, at 19:37, Eric Anholt wrote: >>> >>> Martin Sperl writes: >>> > On 10.05.2016 03:01, Eric Anholt wrote: > With the new patch 2 inserted between my previous pair, I think this >

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: >> On 10.05.2016, at 19:37, Eric Anholt wrote: >> >> Martin Sperl writes: >>> and also hsm (probably hardware security module): >>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/regdump >>> ctl = 0x02d6

Re: [PATCH 0/3] clk: bcm2835: critical clocks and parent selection

Martin Sperl writes: >> On 10.05.2016, at 19:37, Eric Anholt wrote: >> >> Martin Sperl writes: >>> and also hsm (probably hardware security module): >>> root@raspcm:~# cat /sys/kernel/debug/clk/hsm/regdump >>> ctl = 0x02d6 >>> div = 0x30e0 >>> root@raspcm:~# cat

RE: [PATCH v7 10/14] usb: otg: add hcd companion support

On Thu, 12 May 2016, Yoshihiro Shimoda wrote: > > > Alan, does USB core even know which EHCI and OHCI are linked to the same > > > port > > > or the handoff is software transparent? > > > > The core knows. It doesn't use the information for a whole lot of > > things, but it does use it in a

Re: [PATCH v2] mmc: dw_mmc: rockchip: Set the drive phase properly

Hi, On Wed, May 11, 2016 at 2:40 PM, Douglas Anderson wrote: > Historically for Rockchip devices we've relied on the power-on > default (or perhaps the firmware setting) to get the correct drive > phase for dw_mmc devices. This worked OK for the most part, but: > > *

RE: [PATCH v7 10/14] usb: otg: add hcd companion support

On Thu, 12 May 2016, Yoshihiro Shimoda wrote: > > > Alan, does USB core even know which EHCI and OHCI are linked to the same > > > port > > > or the handoff is software transparent? > > > > The core knows. It doesn't use the information for a whole lot of > > things, but it does use it in a

Re: [PATCH v2] mmc: dw_mmc: rockchip: Set the drive phase properly

Hi, On Wed, May 11, 2016 at 2:40 PM, Douglas Anderson wrote: > Historically for Rockchip devices we've relied on the power-on > default (or perhaps the firmware setting) to get the correct drive > phase for dw_mmc devices. This worked OK for the most part, but: > > * Relying on the setting just

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

ker...@martin.sperl.org writes: > From: Martin Sperl > > As the sdram clock is a critical clock to the system > the minimal bcm2835-sdram driver claims (and enables) > this clock and also exposes the corresponding sdram > registers via debugfs. I don't think this is a

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

ker...@martin.sperl.org writes: > From: Martin Sperl > > As the sdram clock is a critical clock to the system > the minimal bcm2835-sdram driver claims (and enables) > this clock and also exposes the corresponding sdram > registers via debugfs. I don't think this is a good solution to the

RE: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

> On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: > > + case HFI1_IOCTL_EP_INFO: > > + case HFI1_IOCTL_EP_ERASE_CHIP: > > + case HFI1_IOCTL_EP_ERASE_RANGE: > > + case HFI1_IOCTL_EP_READ_RANGE: > > + case HFI1_IOCTL_EP_WRITE_RANGE: > > + if

RE: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

> On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: > > + case HFI1_IOCTL_EP_INFO: > > + case HFI1_IOCTL_EP_ERASE_CHIP: > > + case HFI1_IOCTL_EP_ERASE_RANGE: > > + case HFI1_IOCTL_EP_READ_RANGE: > > + case HFI1_IOCTL_EP_WRITE_RANGE: > > + if

Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

On Thu, 12 May 2016, Wenyou Yang wrote: > In order to get lower consumption, as a workaround, suspend > the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt > Configuration Register while OHCI USB suspending. What does this mean? What does suspending a port do? Is it the same as

Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

On Thu, 12 May 2016, Wenyou Yang wrote: > In order to get lower consumption, as a workaround, suspend > the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt > Configuration Register while OHCI USB suspending. What does this mean? What does suspending a port do? Is it the same as

Re: [PATCH v2] arm64: fix current_thread_info()->addr_limit setup

On Thu, May 12, 2016 at 06:22:03PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote: > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > > index 24ed037..fda75ce 100644 > > --- a/arch/arm64/include/asm/elf.h > > +++

Re: [PATCH v2] arm64: fix current_thread_info()->addr_limit setup

On Thu, May 12, 2016 at 06:22:03PM +0100, Catalin Marinas wrote: > On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote: > > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > > index 24ed037..fda75ce 100644 > > --- a/arch/arm64/include/asm/elf.h > > +++

Re: [PATCH] mfd: max77620: Fix FPS switch statements

On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: When configuring FPS during probe, assuming a DT node is present for FPS, the code can run into a problem with the switch statements in max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, in the case of chip->chip_id ==

[PATCH 1/2] Revert "clk: rockchip: reset init state before mmc card initialization"

This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization"). Though not totally obvious from the commit message nor from the source code, that commit appears to be trying to reset the "_drv" MMC clocks to 90 degrees (note that the "_sample" MMC clocks have

Re: [PATCH] mfd: max77620: Fix FPS switch statements

On Thursday 12 May 2016 11:15 PM, Rhyland Klein wrote: When configuring FPS during probe, assuming a DT node is present for FPS, the code can run into a problem with the switch statements in max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, in the case of chip->chip_id ==

[PATCH 1/2] Revert "clk: rockchip: reset init state before mmc card initialization"

This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization"). Though not totally obvious from the commit message nor from the source code, that commit appears to be trying to reset the "_drv" MMC clocks to 90 degrees (note that the "_sample" MMC clocks have

[PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

Just like every other Rockhip device, the MMC "_sample" clocks should have a shift of 0, not a shift of 1. The rk3399 TRM agrees. Presumably these values were set to 0 because of a typo. Things _sorta_ would have worked with the incorrect sample phase shift because of the register layout but

[PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

Just like every other Rockhip device, the MMC "_sample" clocks should have a shift of 0, not a shift of 1. The rk3399 TRM agrees. Presumably these values were set to 0 because of a typo. Things _sorta_ would have worked with the incorrect sample phase shift because of the register layout but

Re: [BUG]Writeback Cgroup/Dirty Throttle: very small buffered write thoughput caused by writeback cgroup and dirty thottle

Hello, On Thu, May 12, 2016 at 09:11:33AM +0800, Miao Xie wrote: > >My box has 48 cores and 188GB memory, but I set > >vm.dirty_background_bytes = 268435456 > >vm.dirty_bytes = 536870912 > > > >if I set vm.dirty_background_bytes and vm.dirty_bytes to be a large >

Re: [BUG]Writeback Cgroup/Dirty Throttle: very small buffered write thoughput caused by writeback cgroup and dirty thottle

Hello, On Thu, May 12, 2016 at 09:11:33AM +0800, Miao Xie wrote: > >My box has 48 cores and 188GB memory, but I set > >vm.dirty_background_bytes = 268435456 > >vm.dirty_bytes = 536870912 > > > >if I set vm.dirty_background_bytes and vm.dirty_bytes to be a large >

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Thu, May 12, 2016 at 11:48:43AM +0530, Abhishek Sahu wrote: > On Thu, May 12, 2016 at 12:13:47AM -0500, Andy Gross wrote: > > On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > > > > > > > > > In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the > > > >end,

Re: [PATCH 1/2] i2c: qup: Cleared the error bits in ISR

On Thu, May 12, 2016 at 11:48:43AM +0530, Abhishek Sahu wrote: > On Thu, May 12, 2016 at 12:13:47AM -0500, Andy Gross wrote: > > On Wed, May 11, 2016 at 11:04:17PM +0530, Abhishek Sahu wrote: > > > > > > > > > > In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the > > > >end,

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Thanks for the clarification. Below some comments. > On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: >> >> El 21/04/16 a las 00:12, Kees Cook escribió: >>> On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert >> v.es> wrote: > On Wed, Apr 6, 2016 at 12:07 PM,

Re: [PATCH] Honor mmap_min_addr with the actual minimum

Thanks for the clarification. Below some comments. > On Wed, 2016-05-11 at 14:54 +0200, Hector Marco-Gisbert wrote: >> >> El 21/04/16 a las 00:12, Kees Cook escribió: >>> On Tue, Apr 19, 2016 at 11:55 AM, Hector Marco-Gisbert >> v.es> wrote: > On Wed, Apr 6, 2016 at 12:07 PM, Hector

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Thu, 12 May 2016 04:53:19 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, May 12, 2016 10:21 AM > > > > On Thu, 12 May 2016 01:19:44 + > > "Tian, Kevin" wrote: > > > > > > From:

Re: [PATCH 5/5] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

On Thu, 12 May 2016 04:53:19 + "Tian, Kevin" wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Thursday, May 12, 2016 10:21 AM > > > > On Thu, 12 May 2016 01:19:44 + > > "Tian, Kevin" wrote: > > > > > > From: Alex Williamson

[PATCH] mfd: max77620: Fix FPS switch statements

When configuring FPS during probe, assuming a DT node is present for FPS, the code can run into a problem with the switch statements in max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, in the case of chip->chip_id == MAX77620, it will set fps_[mix|max]_period but then fall

[PATCH] mfd: max77620: Fix FPS switch statements

When configuring FPS during probe, assuming a DT node is present for FPS, the code can run into a problem with the switch statements in max77620_config_fps() and max77620_get_fps_period_reg_value(). Namely, in the case of chip->chip_id == MAX77620, it will set fps_[mix|max]_period but then fall

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: > + case HFI1_IOCTL_EP_INFO: > + case HFI1_IOCTL_EP_ERASE_CHIP: > + case HFI1_IOCTL_EP_ERASE_RANGE: > + case HFI1_IOCTL_EP_READ_RANGE: > + case HFI1_IOCTL_EP_WRITE_RANGE: > + if

Re: [PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

On Thu, May 12, 2016 at 10:18:47AM -0700, Dennis Dalessandro wrote: > + case HFI1_IOCTL_EP_INFO: > + case HFI1_IOCTL_EP_ERASE_CHIP: > + case HFI1_IOCTL_EP_ERASE_RANGE: > + case HFI1_IOCTL_EP_READ_RANGE: > + case HFI1_IOCTL_EP_WRITE_RANGE: > + if

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote: > There is also a driver software version being exported via a sysfs > file. This is needed so that user space applications (psm) can > determine if it needs to do ioctl() or write(). Why? Don't do this, just call ioctl() and if

Re: [PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

On Thu, May 12, 2016 at 10:18:27AM -0700, Dennis Dalessandro wrote: > There is also a driver software version being exported via a sysfs > file. This is needed so that user space applications (psm) can > determine if it needs to do ioctl() or write(). Why? Don't do this, just call ioctl() and if

[PATCH] x86/rwsem: Save and restore all callee-clobbered regs in 32-bit ____down_write()

Anyway, here's an actual patch with a commit message. Guenter, can you give it a run please? It does fix the issue here with your .config but I'd appreciate a confirmation. Thanks. --- From: Borislav Petkov down_write() calls a function to handle the slow path when the lock

[PATCH] x86/rwsem: Save and restore all callee-clobbered regs in 32-bit ____down_write()

Anyway, here's an actual patch with a commit message. Guenter, can you give it a run please? It does fix the issue here with your .config but I'd appreciate a confirmation. Thanks. --- From: Borislav Petkov down_write() calls a function to handle the slow path when the lock is contended.

Re: [PATCH v2] arm64: fix current_thread_info()->addr_limit setup

On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote: > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > index 24ed037..fda75ce 100644 > --- a/arch/arm64/include/asm/elf.h > +++ b/arch/arm64/include/asm/elf.h > @@ -138,7 +138,10 @@ typedef struct user_fpsimd_state

Re: [PATCH v2] arm64: fix current_thread_info()->addr_limit setup

On Thu, May 12, 2016 at 07:06:03PM +0300, Yury Norov wrote: > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h > index 24ed037..fda75ce 100644 > --- a/arch/arm64/include/asm/elf.h > +++ b/arch/arm64/include/asm/elf.h > @@ -138,7 +138,10 @@ typedef struct user_fpsimd_state

[PATCH v2 4/5] IB/hfi1: Remove write(), use ioctl() for user cmds

Remove the write() handler for user space commands now that ioctl handling is available. User apps will need to change to use ioctl from this point forward. Reviewed-by: Mitko Haralanov Signed-off-by: Dennis Dalessandro ---

[PATCH v2 4/5] IB/hfi1: Remove write(), use ioctl() for user cmds

Remove the write() handler for user space commands now that ioctl handling is available. User apps will need to change to use ioctl from this point forward. Reviewed-by: Mitko Haralanov Signed-off-by: Dennis Dalessandro --- drivers/staging/rdma/hfi1/file_ops.c | 249

[PATCH v2 2/5] IB/hfi1: Remove unused user command

The HFI1_CMD_SDMA_STATUS_UPD command was never implemented it has no reason to live in the driver. Remove it. Reviewed-by: Christoph Hellwig Reviewed-by: Mitko Haralanov Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro

[PATCH v2 5/5] IB/hfi1: Add trace message in user IOCTL handling

Add a trace message to HFI1s user IOCTL handling. This allows debugging of which IOCTLs are being handled by the driver. Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro --- drivers/staging/rdma/hfi1/file_ops.c |2 ++

[PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

IOCTL is more suited to what user space commands need to do than the write() interface. Add IOCTL definitions for all existing write commands and the handling for those. The write() interface will be removed in a follow on patch. Reviewed-by: Mitko Haralanov

[PATCH v2 2/5] IB/hfi1: Remove unused user command

The HFI1_CMD_SDMA_STATUS_UPD command was never implemented it has no reason to live in the driver. Remove it. Reviewed-by: Christoph Hellwig Reviewed-by: Mitko Haralanov Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro --- drivers/staging/rdma/hfi1/file_ops.c |3 ---

[PATCH v2 5/5] IB/hfi1: Add trace message in user IOCTL handling

Add a trace message to HFI1s user IOCTL handling. This allows debugging of which IOCTLs are being handled by the driver. Reviewed-by: Ira Weiny Signed-off-by: Dennis Dalessandro --- drivers/staging/rdma/hfi1/file_ops.c |2 ++ drivers/staging/rdma/hfi1/trace.c|1 +

[PATCH v2 3/5] IB/hfi1: Add ioctl() interface for user commands

IOCTL is more suited to what user space commands need to do than the write() interface. Add IOCTL definitions for all existing write commands and the handling for those. The write() interface will be removed in a follow on patch. Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn

[PATCH v2 1/5] IB/hfi1: Export drivers user sw version via sysfs

User space consumers of hfi1 will need to know what version of the driver they are dealing with. This becomes particularly important when the write() interface is removed. User's will need to be able to query the driver information but without asking the driver directly. Add the driver's software

[PATCH v2 1/5] IB/hfi1: Export drivers user sw version via sysfs

User space consumers of hfi1 will need to know what version of the driver they are dealing with. This becomes particularly important when the write() interface is removed. User's will need to be able to query the driver information but without asking the driver directly. Add the driver's software

[PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

This patch series removes the write() interface for user access in favor of an ioctl() based approach. This is in response to the complaint that we had different handlers for write() and writev() doing different things and expecting different types of data. See:

[PATCH v2 0/5] IB/hfi1: Remove write() and use ioctl() for user access

This patch series removes the write() interface for user access in favor of an ioctl() based approach. This is in response to the complaint that we had different handlers for write() and writev() doing different things and expecting different types of data. See:

Re: UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47

On Thu, May 12, 2016 at 07:38:00PM +0300, Meelis Roos wrote: > I am seeing it on multiple different PC-s. > > [7.837957] > > [7.837959] UBSAN: Undefined behaviour in > drivers/usb/host/ehci-hub.c:877:47

Re: UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47

On Thu, May 12, 2016 at 07:38:00PM +0300, Meelis Roos wrote: > I am seeing it on multiple different PC-s. > > [7.837957] > > [7.837959] UBSAN: Undefined behaviour in > drivers/usb/host/ehci-hub.c:877:47

Re: [PATCH 5/8] ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles

Hi, * Keerthy [160510 22:56]: > With the device tree parsing using the regulator framework > there is a no longer a need for separate compatibles for > individual regulator nodes. Hence removing them all. Please resend the dts related clean-up patches separately once the rest

Re: [PATCH 5/8] ARM: dts: AM437X-GP-EVM: Remove redundant regulator compatibles

Hi, * Keerthy [160510 22:56]: > With the device tree parsing using the regulator framework > there is a no longer a need for separate compatibles for > individual regulator nodes. Hence removing them all. Please resend the dts related clean-up patches separately once the rest of the

Re: [PATCH] arm64: Implement optimised IP checksum helpers

Hi Luke, On 12/05/16 16:34, Luke Starrett wrote: Hi Robin, I pulled this in to a userspace test app expecting that the __uint128_t type might cause GCC to emit 'ldp'. Seems like that was that your intent based on your commit note. Instead I see two 64b loads (ldr Xn), and a single 32b load

Re: [PATCH] arm64: Implement optimised IP checksum helpers

Hi Luke, On 12/05/16 16:34, Luke Starrett wrote: Hi Robin, I pulled this in to a userspace test app expecting that the __uint128_t type might cause GCC to emit 'ldp'. Seems like that was that your intent based on your commit note. Instead I see two 64b loads (ldr Xn), and a single 32b load

Re: [PATCH v7 4/6] dax: export a low-level __dax_zero_page_range helper

On Thu, 2016-05-12 at 10:41 +0200, Jan Kara wrote: > On Wed 11-05-16 15:08:50, Vishal Verma wrote: > > > > From: Christoph Hellwig > > > > This allows XFS to perform zeroing using the iomap infrastructure > > and > > avoid buffer heads. > > > > [vishal: fix conflicts with

Re: [PATCH v7 4/6] dax: export a low-level __dax_zero_page_range helper

On Thu, 2016-05-12 at 10:41 +0200, Jan Kara wrote: > On Wed 11-05-16 15:08:50, Vishal Verma wrote: > > > > From: Christoph Hellwig > > > > This allows XFS to perform zeroing using the iomap infrastructure > > and > > avoid buffer heads. > > > > [vishal: fix conflicts with dax-error-handling] >

[PATCH] qxl: catch qxlfb_create_pinned_object failures

Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_fb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index 7136e52..17c1ef0 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c

[PATCH] qxl: catch qxlfb_create_pinned_object failures

Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_fb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c index 7136e52..17c1ef0 100644 --- a/drivers/gpu/drm/qxl/qxl_fb.c +++ b/drivers/gpu/drm/qxl/qxl_fb.c @@ -360,6 +360,9 @@

Re: [PATCH 0/19] get rid of superfluous __GFP_REPEAT

Andrew, do you think this should go in in the next merge window or should I repost after rc1 is out? I do not mind one way or the other. I would obviously would like to get them in sooner rather than later but I can certainly live with these wait a bit longer. Thanks! -- Michal Hocko SUSE Labs

Re: [PATCH 0/19] get rid of superfluous __GFP_REPEAT

Andrew, do you think this should go in in the next merge window or should I repost after rc1 is out? I do not mind one way or the other. I would obviously would like to get them in sooner rather than later but I can certainly live with these wait a bit longer. Thanks! -- Michal Hocko SUSE Labs

Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

On Thu, 12 May 2016, David Howells wrote: Mat Martineau wrote: + len = crypto_akcipher_maxsize(tfm); + info->key_size = len * 8; + info->max_data_size = len; + info->max_sig_size = len; + info->max_enc_size = len; +

Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

On Thu, 12 May 2016, David Howells wrote: Mat Martineau wrote: + len = crypto_akcipher_maxsize(tfm); + info->key_size = len * 8; + info->max_data_size = len; + info->max_sig_size = len; + info->max_enc_size = len; + info->max_dec_size = len; If len >

Re: [PATCH] locking, rwsem: Fix down_write_killable()

On Thu 12-05-16 13:57:45, Peter Zijlstra wrote: [...] > Subject: locking, rwsem: Fix down_write_killable() > From: Peter Zijlstra > Date: Wed, 11 May 2016 11:41:28 +0200 > > The new signal_pending exit path in __rwsem_down_write_failed_common() > was fingered as breaking

Re: [PATCH] locking, rwsem: Fix down_write_killable()

On Thu 12-05-16 13:57:45, Peter Zijlstra wrote: [...] > Subject: locking, rwsem: Fix down_write_killable() > From: Peter Zijlstra > Date: Wed, 11 May 2016 11:41:28 +0200 > > The new signal_pending exit path in __rwsem_down_write_failed_common() > was fingered as breaking his kernel by Tetsuo

Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator

* Eduard Gavin [160509 07:43]: > Dear Nishanth, > In igepV5 the LDO7 is connected to: > VDDA_DSIPORTA - ball AA33 > VDDA_DSIPORTC - ball AE33 > VDDA_HDMI - ball AN25 > LDO4 is connected to: > VPP1 - ball AD9 Thanks for the info, here's an updated patch

Re: [PATCH] ARM: dts: omap5-igep0050: Correct hdmi regulator

* Eduard Gavin [160509 07:43]: > Dear Nishanth, > In igepV5 the LDO7 is connected to: > VDDA_DSIPORTA - ball AA33 > VDDA_DSIPORTC - ball AE33 > VDDA_HDMI - ball AN25 > LDO4 is connected to: > VPP1 - ball AD9 Thanks for the info, here's an updated patch with comments and now

Re: [PATCH v4 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Sorry about that. I will fix and send a new iteration this afternoon. Thomas On Thu, May 12, 2016 at 9:27 AM, kbuild test robot <l...@intel.com> wrote: > Hi, > > [auto build test ERROR on next-20160512] > [cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7

Re: [PATCH v4 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Sorry about that. I will fix and send a new iteration this afternoon. Thomas On Thu, May 12, 2016 at 9:27 AM, kbuild test robot wrote: > Hi, > > [auto build test ERROR on next-20160512] > [cannot apply to tip/x86/core v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6-rc7] > [if your patch is appli

Re: [PATCH] MAINTAINERS: add entry for the Sync File Framework

Hi Gustavo, On 11 May 2016 at 14:45, Gustavo Padovan wrote: > From: Gustavo Padovan > > Add Gustavo as maintainer for the Sync File Framework. Sumit is > co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's > tree as base. >

Re: [PATCH] MAINTAINERS: add entry for the Sync File Framework

Hi Gustavo, On 11 May 2016 at 14:45, Gustavo Padovan wrote: > From: Gustavo Padovan > > Add Gustavo as maintainer for the Sync File Framework. Sumit is > co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's > tree as base. > > Cc: Sumit Semwal > Signed-off-by: Gustavo Padovan

Re: [PATCH 1/2] arm64: dts: NS2: Add all of the UARTs

Hi Kefeng, On 5/12/2016 7:46 AM, Jon Mason wrote: On Thu, May 12, 2016 at 2:16 AM, Kefeng Wang > wrote: On 2016/5/12 6:56, Jon Mason wrote: > Add all of the UARTs present on NS2 and enable them in the SVK device >

Re: [PATCH 1/2] arm64: dts: NS2: Add all of the UARTs

Hi Kefeng, On 5/12/2016 7:46 AM, Jon Mason wrote: On Thu, May 12, 2016 at 2:16 AM, Kefeng Wang mailto:wangkefeng.w...@huawei.com>> wrote: On 2016/5/12 6:56, Jon Mason wrote: > Add all of the UARTs present on NS2 and enable them in the SVK device > tree file. Also, do some

UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47

I am seeing it on multiple different PC-s. [7.837957] [7.837959] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [7.837961] index -1 is out of range for type 'u32 [1]' [7.837964]

UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47

I am seeing it on multiple different PC-s. [7.837957] [7.837959] UBSAN: Undefined behaviour in drivers/usb/host/ehci-hub.c:877:47 [7.837961] index -1 is out of range for type 'u32 [1]' [7.837964]

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

Le 05/12/2016 à 03:52 PM, Jerome Glisse a écrit : > On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote: >> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit : >>> On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote: [...] With

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

Le 05/12/2016 à 03:52 PM, Jerome Glisse a écrit : > On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote: >> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit : >>> On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote: [...] With

Re: [PATCH v3 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

* Peter Ujfalusi [160511 01:46]: > Tony, Paul, > > On 04/29/16 13:53, Peter Ujfalusi wrote: > > Hi, > > > > Based on the ongoing discussion on v2 (ARM: OMAP3: Fix McBSP2/3 hwmod setup > > for > > sidetone) I have dropped the removal of the sidetone hwmod and only > >

Re: [PATCH v3 0/7] ARM/ASoC: OMAP3: Fix McBSP2/3 sidetone support

* Peter Ujfalusi [160511 01:46]: > Tony, Paul, > > On 04/29/16 13:53, Peter Ujfalusi wrote: > > Hi, > > > > Based on the ongoing discussion on v2 (ARM: OMAP3: Fix McBSP2/3 hwmod setup > > for > > sidetone) I have dropped the removal of the sidetone hwmod and only > > corrected > > it. The

[PATCH 2/4] x86/fpu/xstate: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size

From: Fenghua Yu User space uses standard format xsave area. fpstate in signal frame should have standard format size. To explicitly distinguish between xstate size in kernel space and the one in user space, we rename xstate_size to fpu_kernel_xstate_size. This patch is

[PATCH 2/4] x86/fpu/xstate: Rename xstate_size to fpu_kernel_xstate_size to distinguish from fpu_user_xstate_size

From: Fenghua Yu User space uses standard format xsave area. fpstate in signal frame should have standard format size. To explicitly distinguish between xstate size in kernel space and the one in user space, we rename xstate_size to fpu_kernel_xstate_size. This patch is not fixing a bug. It

[PATCH 1/4] x86/fpu/xstate: Define and use fpu_user_xstate_size

From: Fenghua Yu The kernel xstate area can be in standard or compacted format; it is always in standard format for user mode. When XSAVES is enabled, the kernel uses the compacted format and it is necessary to use a separate fpu_user_xstate_size for signal/ptrace frames.

[PATCH 1/4] x86/fpu/xstate: Define and use fpu_user_xstate_size

From: Fenghua Yu The kernel xstate area can be in standard or compacted format; it is always in standard format for user mode. When XSAVES is enabled, the kernel uses the compacted format and it is necessary to use a separate fpu_user_xstate_size for signal/ptrace frames. Signed-off-by: Fenghua

[PATCH 0/4] x86/fpu/state: Fix XSAVES issues - Part 1

This is Part 1 of previous 13 XSAVES patches. Break it down to smaller series. There are no code changes; only minor fixes in the titles. Fenghua Yu (3): x86/fpu/xstate: Define and use fpu_user_xstate_size x86/fpu/xstate: Rename xstate_size to fpu_kernel_xstate_size to distinguish from

[PATCH 3/4] x86/fpu/xstate: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization

From: Fenghua Yu Keep init_fpstate.xsave.header.xfeatures as zero for init optimization. This is important for init optimization that is implemented in processor. If a bit corresponding to an xstate in xstate_bv is 0, it means the xstate is in init status and will not be

[PATCH 4/4] x86/fpu/xstate: Copy xstate registers directly to signal frame when compacted format is in use

XSAVES is a kernel instruction and uses a compacted format. When working with user space, the kernel should provide standard-format, non-supervisor state data. We cannot do __copy_to_user() from a compacted-format kernel xstate area to a signal frame. Dave Hansen proposes this method to simplify

[PATCH 0/4] x86/fpu/state: Fix XSAVES issues - Part 1

This is Part 1 of previous 13 XSAVES patches. Break it down to smaller series. There are no code changes; only minor fixes in the titles. Fenghua Yu (3): x86/fpu/xstate: Define and use fpu_user_xstate_size x86/fpu/xstate: Rename xstate_size to fpu_kernel_xstate_size to distinguish from

[PATCH 3/4] x86/fpu/xstate: Keep init_fpstate.xsave.header.xfeatures as zero for init optimization

From: Fenghua Yu Keep init_fpstate.xsave.header.xfeatures as zero for init optimization. This is important for init optimization that is implemented in processor. If a bit corresponding to an xstate in xstate_bv is 0, it means the xstate is in init status and will not be read from memory to the

[PATCH 4/4] x86/fpu/xstate: Copy xstate registers directly to signal frame when compacted format is in use

XSAVES is a kernel instruction and uses a compacted format. When working with user space, the kernel should provide standard-format, non-supervisor state data. We cannot do __copy_to_user() from a compacted-format kernel xstate area to a signal frame. Dave Hansen proposes this method to simplify

Re: [RFC PATCH 1/3] asm-generic: io: Add exec versions of ioremap

On Mon, May 09, 2016 at 04:41:49PM -0500, Dave Gerlach wrote: > diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c > index 66a978d05958..c6eef3c98074 100644 > --- a/arch/arm/mm/ioremap.c > +++ b/arch/arm/mm/ioremap.c > @@ -400,6 +400,20 @@ EXPORT_SYMBOL(ioremap_wc); > * clocks that would

Re: [RFC PATCH 1/3] asm-generic: io: Add exec versions of ioremap

On Mon, May 09, 2016 at 04:41:49PM -0500, Dave Gerlach wrote: > diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c > index 66a978d05958..c6eef3c98074 100644 > --- a/arch/arm/mm/ioremap.c > +++ b/arch/arm/mm/ioremap.c > @@ -400,6 +400,20 @@ EXPORT_SYMBOL(ioremap_wc); > * clocks that would

Re: [PATCH v5] mm: Add memory allocation watchdog kernel thread.

On Fri 13-05-16 00:09:07, Tetsuo Handa wrote: [...] > Michal, this version eliminated overhead of walking the process list > when nothing is wrong. You are aware of the possibility of > debug_show_all_locks() failing to report the culprit, aren't you? > So, what are unacceptable major problems for

Re: [PATCH v5] mm: Add memory allocation watchdog kernel thread.

On Fri 13-05-16 00:09:07, Tetsuo Handa wrote: [...] > Michal, this version eliminated overhead of walking the process list > when nothing is wrong. You are aware of the possibility of > debug_show_all_locks() failing to report the culprit, aren't you? > So, what are unacceptable major problems for

[PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is

[PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is

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