[RFCv3 16/17] media: vim2m: add media device

Request API requires a media node. Add one to the vim2m driver so we can use requests with it. Signed-off-by: Alexandre Courbot --- drivers/media/platform/vim2m.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/media/platform/vim2m.c

[RFCv3 07/17] v4l2-ctrls: prepare internal structs for request API

From: Hans Verkuil Add a refcount and is_request bool to struct v4l2_ctrl_handler: this is used to refcount a handler that represents a request. Add a p_req field to struct v4l2_ctrl_ref that will store the request value. Signed-off-by: Hans Verkuil

[RFCv3 16/17] media: vim2m: add media device

Request API requires a media node. Add one to the vim2m driver so we can use requests with it. Signed-off-by: Alexandre Courbot --- drivers/media/platform/vim2m.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/media/platform/vim2m.c

[RFCv3 17/17] media: vim2m: add request support

Set the necessary ops for supporting requests in vim2m. Signed-off-by: Alexandre Courbot --- drivers/media/platform/vim2m.c | 55 ++ 1 file changed, 55 insertions(+) diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c index

[RFCv3 15/17] v4l2: document the request API interface

Document how the request API can be used along with the existing V4L2 interface. Signed-off-by: Alexandre Courbot --- Documentation/media/uapi/v4l/buffer.rst| 10 +- Documentation/media/uapi/v4l/common.rst| 1 + Documentation/media/uapi/v4l/request-api.rst | 236

[RFCv3 07/17] v4l2-ctrls: prepare internal structs for request API

From: Hans Verkuil Add a refcount and is_request bool to struct v4l2_ctrl_handler: this is used to refcount a handler that represents a request. Add a p_req field to struct v4l2_ctrl_ref that will store the request value. Signed-off-by: Hans Verkuil Signed-off-by: Alexandre Courbot ---

[RFCv3 09/17] v4l2-ctrls: use ref in helper instead of ctrl

From: Hans Verkuil The next patch needs the reference to a control instead of the control itself, so change struct v4l2_ctrl_helper accordingly. Signed-off-by: Hans Verkuil Signed-off-by: Alexandre Courbot ---

[RFCv3 13/17] videodev2.h: add request_fd field to v4l2_ext_controls

Allow to specify a request to be used with the S_EXT_CTRLS and G_EXT_CTRLS operations. Signed-off-by: Alexandre Courbot --- include/uapi/linux/videodev2.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/videodev2.h

[RFCv3 09/17] v4l2-ctrls: use ref in helper instead of ctrl

From: Hans Verkuil The next patch needs the reference to a control instead of the control itself, so change struct v4l2_ctrl_helper accordingly. Signed-off-by: Hans Verkuil Signed-off-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ctrls.c | 18 +- 1 file changed, 9

[RFCv3 13/17] videodev2.h: add request_fd field to v4l2_ext_controls

Allow to specify a request to be used with the S_EXT_CTRLS and G_EXT_CTRLS operations. Signed-off-by: Alexandre Courbot --- include/uapi/linux/videodev2.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index

[RFCv3 11/17] v4l2-ctrls: add v4l2_ctrl_request_setup

From: Hans Verkuil Add a helper function that can set controls from a request. Signed-off-by: Hans Verkuil Signed-off-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ctrls.c | 71

[RFCv3 04/17] media: vb2: add support for requests in QBUF ioctl

Support the request argument of the QBUF ioctl. Signed-off-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ioctl.c | 83 +++- 1 file changed, 82 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c

[RFCv3 01/17] media: add request API core and UAPI

The request API provides a way to group buffers and device parameters into units of work to be queued and executed. This patch introduces the UAPI and core framework. This patch is based on the previous work by Laurent Pinchart. The core has changed considerably, but the UAPI is mostly untouched.

[RFCv3 11/17] v4l2-ctrls: add v4l2_ctrl_request_setup

From: Hans Verkuil Add a helper function that can set controls from a request. Signed-off-by: Hans Verkuil Signed-off-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ctrls.c | 71 include/media/v4l2-ctrls.h | 2 + 2 files changed, 73

[RFCv3 04/17] media: vb2: add support for requests in QBUF ioctl

Support the request argument of the QBUF ioctl. Signed-off-by: Alexandre Courbot --- drivers/media/v4l2-core/v4l2-ioctl.c | 83 +++- 1 file changed, 82 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c

[RFCv3 01/17] media: add request API core and UAPI

The request API provides a way to group buffers and device parameters into units of work to be queued and executed. This patch introduces the UAPI and core framework. This patch is based on the previous work by Laurent Pinchart. The core has changed considerably, but the UAPI is mostly untouched.

[RFCv3 00/17] Request API, take three

As discussed yesterday, here is a rebase on the media master branch. A few minor fixes for typos have also slept in, but otherwise this is equivalent to v2. I expect to have the buffer queueing behavior fixed in the next version. Alexandre Courbot (9): media: add request API core and UAPI

[RFCv3 00/17] Request API, take three

As discussed yesterday, here is a rebase on the media master branch. A few minor fixes for typos have also slept in, but otherwise this is equivalent to v2. I expect to have the buffer queueing behavior fixed in the next version. Alexandre Courbot (9): media: add request API core and UAPI

[PATCH v13 0/4] fw_cfg: add DMA operations & etc/vmcoreinfo support

Hi, This series adds DMA operations support to the qemu fw_cfg kernel module and populates "etc/vmcoreinfo" with vmcoreinfo location details (entry added since qemu 2.11 with -device vmcoreinfo). v13: - reorder patch series, introduce DMA write before DMA read - do some measurements of DMA read

[PATCH v13 0/4] fw_cfg: add DMA operations & etc/vmcoreinfo support

Hi, This series adds DMA operations support to the qemu fw_cfg kernel module and populates "etc/vmcoreinfo" with vmcoreinfo location details (entry added since qemu 2.11 with -device vmcoreinfo). v13: - reorder patch series, introduce DMA write before DMA read - do some measurements of DMA read

[PATCH v5 1/4] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c

[PATCH v5 1/4] cpu_pm: add syscore_suspend error handling

If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This will put the CPU in the correct state to resume from the failure. Signed-off-by: Derek Basehore --- kernel/cpu_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c index

[PATCH v13 3/4] fw_cfg: write vmcoreinfo details

If the "etc/vmcoreinfo" fw_cfg file is present and we are not running the kdump kernel, write the addr/size of the vmcoreinfo ELF note. The DMA operation is expected to run synchronously with today qemu, but the specification states that it may become async, so we run "control" field check in a

[PATCH v13 3/4] fw_cfg: write vmcoreinfo details

If the "etc/vmcoreinfo" fw_cfg file is present and we are not running the kdump kernel, write the addr/size of the vmcoreinfo ELF note. The DMA operation is expected to run synchronously with today qemu, but the specification states that it may become async, so we run "control" field check in a

[PATCH v13 4/4] RFC: fw_cfg: do DMA read operation

Modify fw_cfg_read_blob() to use DMA if the device supports it. Return errors, because the operation may fail. So far, only one call in fw_cfg_register_dir_entries() is using kmalloc'ed buf and is thus clearly eligible to DMA read. Initially, I didn't implement DMA read to speed up boot time,

[PATCH v13 4/4] RFC: fw_cfg: do DMA read operation

Modify fw_cfg_read_blob() to use DMA if the device supports it. Return errors, because the operation may fail. So far, only one call in fw_cfg_register_dir_entries() is using kmalloc'ed buf and is thus clearly eligible to DMA read. Initially, I didn't implement DMA read to speed up boot time,

[PATCH v5 0/5] GICv3 Save and Restore

A lot of changes in v2. The distributor and redistributor saving and restoring is left to the PSCI/firmware implementation after discussions with ARM. This reduces the line changes by a lot and removes now unneeded patches. Patches are verified on an RK3399 platform with pending patches in the

[PATCH v13 1/4] crash: export paddr_vmcoreinfo_note()

The following patch is going to use the symbol from the fw_cfg module, to call the function and write the note location details in the vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. CC: Andrew Morton CC: Baoquan He CC: Dave

[PATCH v13 1/4] crash: export paddr_vmcoreinfo_note()

The following patch is going to use the symbol from the fw_cfg module, to call the function and write the note location details in the vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note. CC: Andrew Morton CC: Baoquan He CC: Dave Young CC: Dave Young CC: Hari Bathini CC:

[PATCH v5 0/5] GICv3 Save and Restore

A lot of changes in v2. The distributor and redistributor saving and restoring is left to the PSCI/firmware implementation after discussions with ARM. This reduces the line changes by a lot and removes now unneeded patches. Patches are verified on an RK3399 platform with pending patches in the

[PATCH] x86/nospec: Fixup array_index_nospec_mask() asm constraint

Allow the compiler to handle @size as an immediate value rather than allocating a register. Reported-by: Linus Torvalds Cc: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Thomas Gleixner

[PATCH] x86/nospec: Fixup array_index_nospec_mask() asm constraint

Allow the compiler to handle @size as an immediate value rather than allocating a register. Reported-by: Linus Torvalds Cc: Ingo Molnar Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Thomas Gleixner Signed-off-by: Dan Williams --- arch/x86/include/asm/barrier.h |2 +- 1 file changed, 1

[PATCH v5 2/4] irqchip/gic-v3-its: add ability to save/restore ITS state

Some platforms power off GIC logic in suspend, so we need to save/restore state. The distributor and redistributor registers need to be handled in platform code due to access permissions on those registers, but the ITS registers can be restored in the kernel. Signed-off-by: Derek Basehore

[PATCH v5 2/4] irqchip/gic-v3-its: add ability to save/restore ITS state

Some platforms power off GIC logic in suspend, so we need to save/restore state. The distributor and redistributor registers need to be handled in platform code due to access permissions on those registers, but the ITS registers can be restored in the kernel. Signed-off-by: Derek Basehore ---

[PATCH v5 3/4] DT/arm,gic-v3-its: add reset-on-suspend property

This adds documentation for the new reset-on-suspend property. This property enables saving and restoring the ITS for when it loses state in system suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++ 1

[PATCH v13 2/4] fw_cfg: add DMA register

Add an optional kernel module (or command line) parameter using the following syntax: [qemu_fw_cfg.]ioport=@[::[:]] or [qemu_fw_cfg.]mmio=@[::[:]] and initializes the register address using given or default offset. Signed-off-by: Marc-André Lureau

[PATCH v5 3/4] DT/arm,gic-v3-its: add reset-on-suspend property

This adds documentation for the new reset-on-suspend property. This property enables saving and restoring the ITS for when it loses state in system suspend. Signed-off-by: Derek Basehore --- Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt | 3 +++ 1 file changed, 3

[PATCH v13 2/4] fw_cfg: add DMA register

Add an optional kernel module (or command line) parameter using the following syntax: [qemu_fw_cfg.]ioport=@[::[:]] or [qemu_fw_cfg.]mmio=@[::[:]] and initializes the register address using given or default offset. Signed-off-by: Marc-André Lureau Reviewed-by: Gabriel Somlo ---

[PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume

This adds functionality to resend the MAPC command to an ITS node on resume. If the ITS is powered down during suspend and the collections are not backed by memory, the ITS will lose that state. This just sets up the known state for the collections after the ITS is restored. This is enabled via

[PATCH v5 4/4] irqchip/gic-v3-its: add ability to resend MAPC on resume

This adds functionality to resend the MAPC command to an ITS node on resume. If the ITS is powered down during suspend and the collections are not backed by memory, the ITS will lose that state. This just sets up the known state for the collections after the ITS is restored. This is enabled via

Re: [PATCH]nvme-pci: Fixes EEH failure on ppc

On Tue, Feb 06, 2018 at 02:01:05PM -0600, wenxiong wrote: > On 2018-02-06 10:33, Keith Busch wrote: > > On Mon, Feb 05, 2018 at 03:49:40PM -0600, wenxi...@vmlinux.vnet.ibm.com > > wrote: > > > @@ -1189,6 +1183,12 @@ static enum blk_eh_timer_return > > > nvme_timeout(struct request *req, bool

Re: [PATCH]nvme-pci: Fixes EEH failure on ppc

On Tue, Feb 06, 2018 at 02:01:05PM -0600, wenxiong wrote: > On 2018-02-06 10:33, Keith Busch wrote: > > On Mon, Feb 05, 2018 at 03:49:40PM -0600, wenxi...@vmlinux.vnet.ibm.com > > wrote: > > > @@ -1189,6 +1183,12 @@ static enum blk_eh_timer_return > > > nvme_timeout(struct request *req, bool

Re: [PATCH] scsi: qedf: remove redundant initialization of 'fcport'

Colin, > Pointer fcport is initialized with a value that is never read, it is > re-assigned a new value later on, hence the initialization is redundant > and can be removed. Applied to 4.17/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: qedf: remove redundant initialization of 'fcport'

Colin, > Pointer fcport is initialized with a value that is never read, it is > re-assigned a new value later on, hence the initialization is redundant > and can be removed. Applied to 4.17/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH tip-pti 2/2] x86/entry: interleave XOR register clearing with PUSH/MOV instructions

On Tue, Feb 6, 2018 at 3:54 PM, Andi Kleen wrote: > > But for push, on older CPUs (older AMD, most Atoms, really old Intel big core) > sub+mov is a lot faster than push because push has additional dependencies > causing pipeline bubbles. So you would make these cases slower

Re: [PATCH tip-pti 2/2] x86/entry: interleave XOR register clearing with PUSH/MOV instructions

On Tue, Feb 6, 2018 at 3:54 PM, Andi Kleen wrote: > > But for push, on older CPUs (older AMD, most Atoms, really old Intel big core) > sub+mov is a lot faster than push because push has additional dependencies > causing pipeline bubbles. So you would make these cases slower if you > use PUSH. I

Re: [PATCH 5/6] scsi: qedi: fix building with LTO

Arnd, > When link-time optimizations are enabled, qedi fails to build because > of mismatched prototypes: Applied to 4.17/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 5/6] scsi: qedi: fix building with LTO

Arnd, > When link-time optimizations are enabled, qedi fails to build because > of mismatched prototypes: Applied to 4.17/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

linux-next: manual merge of the kvm tree with the arm64 tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: arch/arm64/include/asm/pgtable-prot.h between commit: 41acec624087 ("arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0()") from the arm64 tree and commit: d0e22b4ac3ba ("KVM: arm/arm64: Limit

linux-next: manual merge of the kvm tree with the arm64 tree

Hi all, Today's linux-next merge of the kvm tree got a conflict in: arch/arm64/include/asm/pgtable-prot.h between commit: 41acec624087 ("arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0()") from the arm64 tree and commit: d0e22b4ac3ba ("KVM: arm/arm64: Limit

Re: [PATCH] scsi: libfc: remove redundant initialization of 'disc'

Colin, > Pointer disc is being intializated a value that is never read and then > re-assigned the same value later on, hence the initialization is redundant > and can be removed. Applied to 4.17/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: libfc: remove redundant initialization of 'disc'

Colin, > Pointer disc is being intializated a value that is never read and then > re-assigned the same value later on, hence the initialization is redundant > and can be removed. Applied to 4.17/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v4 07/10] x86: narrow out of bounds syscalls to sys_read under speculation

On Tue, Feb 6, 2018 at 4:33 PM, Dan Williams wrote: > > Should we go with array_element_nospec() in the meantime? So we're not > depending on jump labels? With the constraint fix and killing that > superfluous AND the assembly is now: > > e26: 48 81 fd 4d 01

Re: [PATCH v4 07/10] x86: narrow out of bounds syscalls to sys_read under speculation

On Tue, Feb 6, 2018 at 4:33 PM, Dan Williams wrote: > > Should we go with array_element_nospec() in the meantime? So we're not > depending on jump labels? With the constraint fix and killing that > superfluous AND the assembly is now: > > e26: 48 81 fd 4d 01 00 00cmp$0x14d,%rbp

Re: [PATCH v8 1/7] v4l2-dv-timings: add v4l2_hdmi_colorimetry()

On 02/06/2018 12:27 PM, Tim Harvey wrote: > From: Hans Verkuil > > Add the v4l2_hdmi_colorimetry() function so we have a single function > that determines the colorspace, YCbCr encoding, quantization range and > transfer function from the InfoFrame data. > > Signed-off-by:

Re: [PATCH v8 1/7] v4l2-dv-timings: add v4l2_hdmi_colorimetry()

On 02/06/2018 12:27 PM, Tim Harvey wrote: > From: Hans Verkuil > > Add the v4l2_hdmi_colorimetry() function so we have a single function > that determines the colorspace, YCbCr encoding, quantization range and > transfer function from the InfoFrame data. > > Signed-off-by: Hans Verkuil >

Re: [PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

Kishon, Can you help merge this in your  or next tree?  I'm hoping that we can land this somewhere.:-) Thanks, -Caesar 在 2018年01月11日 10:40, Caesar Wang 写道: Hi Kishon, Since the Shawn isn't available, I take over this series patches for now. As the original bug had tracked on

Re: [PATCH v3 0/2] phy: rockchip-emmc: fixes emmc-phy power on failed with rk3399 SoCs

Kishon, Can you help merge this in your  or next tree?  I'm hoping that we can land this somewhere.:-) Thanks, -Caesar 在 2018年01月11日 10:40, Caesar Wang 写道: Hi Kishon, Since the Shawn isn't available, I take over this series patches for now. As the original bug had tracked on

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote: > > Creation of shareable buffer by guest > > - > > > > 1. Client requests virtio driver to create a buffer suitable for sharing > > with host (DRM_VIRTGPU_RESOURCE_CREATE) > > client

Re: [PATCH v3 1/2] drm/virtio: Add window server support

On Tue, Feb 06, 2018 at 03:23:02PM +0100, Gerd Hoffmann wrote: > > Creation of shareable buffer by guest > > - > > > > 1. Client requests virtio driver to create a buffer suitable for sharing > > with host (DRM_VIRTGPU_RESOURCE_CREATE) > > client

Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage

Hi Punit, On Mon, Feb 05, 2018 at 03:05:43PM +, Punit Agrawal wrote: > Naoya Horiguchi writes: > > > Recently the following BUG was reported: > > > > Injecting memory failure for pfn 0x3c at process virtual address > > 0x7fe3 > > Memory

[PATCH] net: ethernet: ti: cpsw: fix net watchdog timeout

It was discovered that simple program which indefinitely sends 200b UDP packets and runs on TI AM574x SoC (SMP) under RT Kernel triggers network watchdog timeout in TI CPSW driver (<6 hours run). The network watchdog timeout is triggered due to race between cpsw_ndo_start_xmit() and

Re: [PATCH v2] mm: hwpoison: disable memory error handling on 1GB hugepage

Hi Punit, On Mon, Feb 05, 2018 at 03:05:43PM +, Punit Agrawal wrote: > Naoya Horiguchi writes: > > > Recently the following BUG was reported: > > > > Injecting memory failure for pfn 0x3c at process virtual address > > 0x7fe3 > > Memory failure: 0x3c: recovery

[PATCH] net: ethernet: ti: cpsw: fix net watchdog timeout

It was discovered that simple program which indefinitely sends 200b UDP packets and runs on TI AM574x SoC (SMP) under RT Kernel triggers network watchdog timeout in TI CPSW driver (<6 hours run). The network watchdog timeout is triggered due to race between cpsw_ndo_start_xmit() and

Re: [PATCH] char: rtc: remove unused rtc_control() API

On 07/02/2018 at 00:24:11 +0100, Arnd Bergmann wrote: > On Tue, Feb 6, 2018 at 11:12 PM, Alexandre Belloni > wrote: > > Since commit 34ce71a96dcb ("ALSA: timer: remove legacy rtctimer"), the > > rtc_register/rtc_control/rtc_unregister API is unused. As it is highly

Re: [PATCH] char: rtc: remove unused rtc_control() API

On 07/02/2018 at 00:24:11 +0100, Arnd Bergmann wrote: > On Tue, Feb 6, 2018 at 11:12 PM, Alexandre Belloni > wrote: > > Since commit 34ce71a96dcb ("ALSA: timer: remove legacy rtctimer"), the > > rtc_register/rtc_control/rtc_unregister API is unused. As it is highly > > unlikely to be needed

Re: [PATCH 1/2] staging: android: ion: Remove dead code in ion_page_pool_free

Hi Laura, On 2018/2/7 7:11, Laura Abbott wrote: > On 02/06/2018 03:10 PM, Laura Abbott wrote: >> On 02/04/2018 07:26 PM, Yisheng Xie wrote: >>> ion_page_pool_add will always return 0, however ion_page_pool_free will >>> call ion_page_pool_free_pages when ion_page_pool_add's return value is >>>

Re: [PATCH 1/2] staging: android: ion: Remove dead code in ion_page_pool_free

Hi Laura, On 2018/2/7 7:11, Laura Abbott wrote: > On 02/06/2018 03:10 PM, Laura Abbott wrote: >> On 02/04/2018 07:26 PM, Yisheng Xie wrote: >>> ion_page_pool_add will always return 0, however ion_page_pool_free will >>> call ion_page_pool_free_pages when ion_page_pool_add's return value is >>>

[PATCH] ARM: multi_v7_defconfig: Enable serial console on RPi 3

The Raspberry Pi 3 uses the 8250-based auxilary UART of the BCM2837 SoC as the primary serial console of the board, so enable it in the multiplatform defconfig. Signed-off-by: Tuomas Tynkkynen --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+)

[PATCH] ARM: multi_v7_defconfig: Enable serial console on RPi 3

The Raspberry Pi 3 uses the 8250-based auxilary UART of the BCM2837 SoC as the primary serial console of the board, so enable it in the multiplatform defconfig. Signed-off-by: Tuomas Tynkkynen --- arch/arm/configs/multi_v7_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH] staging: android: ion: minor cleanup for ion_page_pool

Hi Laura, On 2018/2/7 6:51, Laura Abbott wrote: > On 01/31/2018 01:50 AM, Yisheng Xie wrote: >> ion_page_pool.c now is used to apply pool APIs for system heap, which do >> not need do any initial at device_initcall. >> >> Meanwhile, this patch also remove some useless include files. >> > >

Re: [PATCH] staging: android: ion: minor cleanup for ion_page_pool

Hi Laura, On 2018/2/7 6:51, Laura Abbott wrote: > On 01/31/2018 01:50 AM, Yisheng Xie wrote: >> ion_page_pool.c now is used to apply pool APIs for system heap, which do >> not need do any initial at device_initcall. >> >> Meanwhile, this patch also remove some useless include files. >> > >

mmotm 2018-02-06-16-41 uploaded

The mm-of-the-moment snapshot 2018-02-06-16-41 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2018-02-06-16-41 uploaded

The mm-of-the-moment snapshot 2018-02-06-16-41 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [PATCH 1/1] scsi: storvsc: Increase cmd_per_lun for higher speed devices

Michael, > Increase cmd_per_lun to allow more I/Os in progress per device, > particularly for NVMe's. The Hyper-V host side can handle the higher > count with no issues. Applied to 4.16/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/1] scsi: storvsc: Increase cmd_per_lun for higher speed devices

Michael, > Increase cmd_per_lun to allow more I/Os in progress per device, > particularly for NVMe's. The Hyper-V host side can handle the higher > count with no issues. Applied to 4.16/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests

Michael, > Update the algorithm in storvsc_do_io to look for a channel starting > with the current CPU + 1 and wrap around (within the current NUMA > node). This spreads VMbus interrupts more evenly across CPUs. Previous > code always started with first CPU in the current NUMA node, skewing >

Re: [PATCH 1/1] scsi: storvsc: Spread interrupts when picking a channel for I/O requests

Michael, > Update the algorithm in storvsc_do_io to look for a channel starting > with the current CPU + 1 and wrap around (within the current NUMA > node). This spreads VMbus interrupts more evenly across CPUs. Previous > code always started with first CPU in the current NUMA node, skewing >

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

On 02/06/2018 01:12 AM, Peter Zijlstra wrote: On Mon, Feb 05, 2018 at 02:09:11PM -0800, Subhra Mazumdar wrote: The pseudo random is also used for choosing a random core to compare with, how will transposing achieve that? Not entirely sure what your point is. Current code doesn't compare to

Re: [RESEND RFC PATCH V3] sched: Improve scalability of select_idle_sibling using SMT balance

On 02/06/2018 01:12 AM, Peter Zijlstra wrote: On Mon, Feb 05, 2018 at 02:09:11PM -0800, Subhra Mazumdar wrote: The pseudo random is also used for choosing a random core to compare with, how will transposing achieve that? Not entirely sure what your point is. Current code doesn't compare to

Re: [PATCH v4 07/10] x86: narrow out of bounds syscalls to sys_read under speculation

On Tue, Feb 6, 2018 at 2:52 PM, Linus Torvalds wrote: > On Tue, Feb 6, 2018 at 1:37 PM, Dan Williams wrote: >> >> At that point we're basically just back to the array_ptr() version >> that returned a sanitized pointer to an array element.

Re: [PATCH v4 07/10] x86: narrow out of bounds syscalls to sys_read under speculation

On Tue, Feb 6, 2018 at 2:52 PM, Linus Torvalds wrote: > On Tue, Feb 6, 2018 at 1:37 PM, Dan Williams wrote: >> >> At that point we're basically just back to the array_ptr() version >> that returned a sanitized pointer to an array element. > > .. that one does an extra unnecessary 'andq' instead

Re: [PATCH] kbuild: clang: disable unused variable warnings only when constant

2018-02-07 8:46 GMT+09:00 Prasad Sodagudi : > Currently, GCC disables -Wunused-const-variable, but not > -Wunused-variable, so warns unused variables if they are > non-constant. > > While, Clang does not warn unused variables at all regardless of > the const qualifier

Re: [PATCH] kbuild: clang: disable unused variable warnings only when constant

2018-02-07 8:46 GMT+09:00 Prasad Sodagudi : > Currently, GCC disables -Wunused-const-variable, but not > -Wunused-variable, so warns unused variables if they are > non-constant. > > While, Clang does not warn unused variables at all regardless of > the const qualifier because

[RFC PATCH] vfio/pci: Add ioeventfd support

The ioeventfd here is actually irqfd handling of an ioeventfd such as supported in KVM. A user is able to pre-program a device write to occur when the eventfd triggers. This is yet another instance of eventfd-irqfd triggering between KVM and vfio. The impetus for this is high frequency writes

[RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 +

[RFC PATCH] vfio/pci: Add ioeventfd support

The ioeventfd here is actually irqfd handling of an ioeventfd such as supported in KVM. A user is able to pre-program a device write to occur when the eventfd triggers. This is yet another instance of eventfd-irqfd triggering between KVM and vfio. The impetus for this is high frequency writes

[RFC PATCH 3/4] x86/speculation: Use IBRS if available before calling into firmware

Retpoline means the kernel is safe because it has no indirect branches. But firmware isn't, so use IBRS for firmware calls if it's available. Signed-off-by: David Woodhouse --- arch/x86/include/asm/apm.h | 6 ++ arch/x86/include/asm/cpufeatures.h | 1 +

[RFC PATCH 0/4] Retpoline / IBRS_ALL

Using retpoline ensures the kernel is safe because it doesn't contain any indirect branches, but firmware still can — and we make calls into firmware at runtime. Where the IBRS microcode support is available, use that before calling into firmware. While doing that, I noticed that we were calling

[RFC PATCH 0/4] Retpoline / IBRS_ALL

Using retpoline ensures the kernel is safe because it doesn't contain any indirect branches, but firmware still can — and we make calls into firmware at runtime. Where the IBRS microcode support is available, use that before calling into firmware. While doing that, I noticed that we were calling

[PATCH] video: fbdev: vermilion: use 64-bit arithmetic instead of 32-bit

Cast _pitch_ to u64 in order to give the compiler complete information about the proper arithmetic to use. Notice that this variable is being used in a context that expects an expression of type u64 (64 bits, unsigned). The expression pitch * var->yres_virtual is currently being evaluated using

[PATCH] video: fbdev: vermilion: use 64-bit arithmetic instead of 32-bit

Cast _pitch_ to u64 in order to give the compiler complete information about the proper arithmetic to use. Notice that this variable is being used in a context that expects an expression of type u64 (64 bits, unsigned). The expression pitch * var->yres_virtual is currently being evaluated using

[RFC PATCH 4/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

The original IBRS hack in microcode is horribly slow. For the next generation of CPUs, as a stopgap until we get a proper fix, Intel promise an "Enhanced IBRS" which will be fast. The assumption is that predictions in the BTB/RSB will be tagged with the VMX mode and ring that they were learned

[RFC PATCH 4/4] x86/speculation: Support "Enhanced IBRS" on future CPUs

The original IBRS hack in microcode is horribly slow. For the next generation of CPUs, as a stopgap until we get a proper fix, Intel promise an "Enhanced IBRS" which will be fast. The assumption is that predictions in the BTB/RSB will be tagged with the VMX mode and ring that they were learned

[RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

With retpoline, tight loops of "call this function for every XXX" are very much pessimised by taking a prediction miss *every* time. This one showed up very high in our early testing. By marking the iterator slot_handle_…() functions always_inline, we can ensure that the indirect function call

[RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

With retpoline, tight loops of "call this function for every XXX" are very much pessimised by taking a prediction miss *every* time. This one showed up very high in our early testing. By marking the iterator slot_handle_…() functions always_inline, we can ensure that the indirect function call

[RFC PATCH 1/4] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

This reverts commit 64e16720ea0879f8ab4547e3b9758936d483909b. We cannot call C functions like that, without marking all the call-clobbered registers as, well, clobbered. We might have got away with it for now because the __ibp_barrier() function was *fairly* unlikely to actually use any other

[RFC PATCH 1/4] Revert "x86/speculation: Simplify indirect_branch_prediction_barrier()"

This reverts commit 64e16720ea0879f8ab4547e3b9758936d483909b. We cannot call C functions like that, without marking all the call-clobbered registers as, well, clobbered. We might have got away with it for now because the __ibp_barrier() function was *fairly* unlikely to actually use any other

[PATCH] ACPI / CPPC: Use 64-bit arithmetic instead of 32-bit

Add suffix ULL to constant 500 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression NUM_RETRIES * cppc_ss->latency at line 578, which at

[PATCH] ACPI / CPPC: Use 64-bit arithmetic instead of 32-bit

Add suffix ULL to constant 500 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression NUM_RETRIES * cppc_ss->latency at line 578, which at

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