Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote: > "Luis R. Rodriguez" writes: > > > > +int request_firmware_nowait(struct module *module, bool uevent, > > > + const char *name, struct device *device, gfp_t gfp, > > > + void

Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

On Thu, 2017-08-03 at 08:23 +0300, Kalle Valo wrote: > "Luis R. Rodriguez" writes: > > > > +int request_firmware_nowait(struct module *module, bool uevent, > > > + const char *name, struct device *device, gfp_t gfp, > > > + void *context, > > > +

[PATCH] mm: fix list corruptions on shmem shrinklist

We saw many list corruption warnings on shmem shrinklist: [45480.300911] [ cut here ] [45480.305558] WARNING: CPU: 18 PID: 177 at lib/list_debug.c:59 __list_del_entry+0x9e/0xc0 [45480.313622] list_del corruption. prev->next should be 9ae5694b82d8, but was

[PATCH] mm: fix list corruptions on shmem shrinklist

We saw many list corruption warnings on shmem shrinklist: [45480.300911] [ cut here ] [45480.305558] WARNING: CPU: 18 PID: 177 at lib/list_debug.c:59 __list_del_entry+0x9e/0xc0 [45480.313622] list_del corruption. prev->next should be 9ae5694b82d8, but was

Re: [RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

On Mon, Jul 17, 2017 at 11:27:36AM +0300, Cosar Dindar wrote: > This patch adds CRC (CRC32 Crypto) support for STM32F4 series. > > As an hardware limitation polynomial and key setting are not supported. > They are fixed as 0x4C11DB7 (poly) and 0x (key). > CRC32C Castagnoli algorithm is

Re: [RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

On Mon, Jul 17, 2017 at 11:27:36AM +0300, Cosar Dindar wrote: > This patch adds CRC (CRC32 Crypto) support for STM32F4 series. > > As an hardware limitation polynomial and key setting are not supported. > They are fixed as 0x4C11DB7 (poly) and 0x (key). > CRC32C Castagnoli algorithm is

Re: [PATCH 0/3] constify char attribute_group structures

Hi Mark, On Wednesday 02 August 2017 11:26 PM, Gross, Mark wrote: Why stop at these 3 users of attribute_group? I am doing for all. This changes is only for char user. Few patch are under review and few are merged. Rest all I will send. ~arvind --mark -Original Message- From:

Re: [PATCH 0/3] constify char attribute_group structures

Hi Mark, On Wednesday 02 August 2017 11:26 PM, Gross, Mark wrote: Why stop at these 3 users of attribute_group? I am doing for all. This changes is only for char user. Few patch are under review and few are merged. Rest all I will send. ~arvind --mark -Original Message- From:

Re: [PATCH] iommu/arm-smmu: Defer TLB flush in case of unmap op

Hi Robin, On 08/02/2017 05:47 PM, Robin Murphy wrote: On 02/08/17 10:53, Vivek Gautam wrote: We don't want to touch the TLB when smmu is suspended. Defer it until resume. Signed-off-by: Vivek Gautam --- Hi all, Here's the small patch in response of suggestion

Re: [PATCH] iommu/arm-smmu: Defer TLB flush in case of unmap op

Hi Robin, On 08/02/2017 05:47 PM, Robin Murphy wrote: On 02/08/17 10:53, Vivek Gautam wrote: We don't want to touch the TLB when smmu is suspended. Defer it until resume. Signed-off-by: Vivek Gautam --- Hi all, Here's the small patch in response of suggestion to defer tlb operations when

Re: [PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

On Wednesday 02 August 2017 10:33 PM, Lokesh Vutla wrote: > On 8/1/2017 6:20 PM, Peter Ujfalusi wrote: >> On 2017-08-01 07:41, Lokesh Vutla wrote: >>> -Example: >>> +Examples: >> >> Do we really need to expand the examples to have identical set, but with >> power-domains? > > IIRC, there was a

Re: [PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

On Wednesday 02 August 2017 10:33 PM, Lokesh Vutla wrote: > On 8/1/2017 6:20 PM, Peter Ujfalusi wrote: >> On 2017-08-01 07:41, Lokesh Vutla wrote: >>> -Example: >>> +Examples: >> >> Do we really need to expand the examples to have identical set, but with >> power-domains? > > IIRC, there was a

Re: [PATCH] KVM: svm: support single stepping over emulated instructions

> We already have b742c1e6e79d ("KVM: SVM: handle singlestep exception > when skipping emulated instructions"), so the only applicable part of > this patch is Doh. :) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 0e846f0cb83b..931ba449456e 100644 > > ---

Re: [PATCH] KVM: svm: support single stepping over emulated instructions

> We already have b742c1e6e79d ("KVM: SVM: handle singlestep exception > when skipping emulated instructions"), so the only applicable part of > this patch is Doh. :) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 0e846f0cb83b..931ba449456e 100644 > > ---

Re: [PATCH V7 5/7] crypto: AES CBC multi-buffer glue code

On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote: > > +/* notify the caller of progress ; request still stays in queue */ > + > +static void notify_callback(struct mcryptd_skcipher_request_ctx *rctx, > + struct mcryptd_alg_cstate *cstate, > +

Re: [PATCH V7 5/7] crypto: AES CBC multi-buffer glue code

On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote: > > +/* notify the caller of progress ; request still stays in queue */ > + > +static void notify_callback(struct mcryptd_skcipher_request_ctx *rctx, > + struct mcryptd_alg_cstate *cstate, > +

[PATCH v7] rockchip/rga: v4l2 m2m support

Rockchip RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D graphics operations, such as point/line drawing, image scaling, rotation, BitBLT, alpha blending and image blur/sharpness The drvier is mostly based on s5p-g2d v4l2 m2m driver And supports various operations from

[PATCH v7] rockchip/rga: v4l2 m2m support

Rockchip RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D graphics operations, such as point/line drawing, image scaling, rotation, BitBLT, alpha blending and image blur/sharpness The drvier is mostly based on s5p-g2d v4l2 m2m driver And supports various operations from

Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

"Luis R. Rodriguez" writes: >> +int request_firmware_nowait(struct module *module, bool uevent, >> +const char *name, struct device *device, gfp_t gfp, >> +void *context, >> +void (*cont)(const struct

Re: [PATCH V5 1/2] firmware: add more flexible request_firmware_async function

"Luis R. Rodriguez" writes: >> +int request_firmware_nowait(struct module *module, bool uevent, >> +const char *name, struct device *device, gfp_t gfp, >> +void *context, >> +void (*cont)(const struct firmware *fw, void >>

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

On 2017-08-03 00:50, Stephen Warren wrote: > On 08/02/2017 03:25 PM, Peter Rosin wrote: >> (and muxc->max_adapters == num_names) > > Well, unless muxc->deselect is true... No, deselect does not affect neither max_adapters nor num_names. They are always equal. Cheers, Peter

Re: [PATCH 2/2] i2c: mux: pinctrl: drop the idle_state member

On 2017-08-03 00:50, Stephen Warren wrote: > On 08/02/2017 03:25 PM, Peter Rosin wrote: >> (and muxc->max_adapters == num_names) > > Well, unless muxc->deselect is true... No, deselect does not affect neither max_adapters nor num_names. They are always equal. Cheers, Peter

Re: [PATCH] watchdog: moxart_wdt: Replace decimal permissions with 4 digit octal

On 07/29/2017 02:15 AM, SZ Lin wrote: ERROR: Use 4 digit octal (0777) not decimal permissions This error was detected by checkpatch.pl Signed-off-by: SZ Lin I think checkpatch is overdoing it a bit here. There are more than 2,000 of those. Plus, I really don't see the

Re: [PATCH] watchdog: moxart_wdt: Replace decimal permissions with 4 digit octal

On 07/29/2017 02:15 AM, SZ Lin wrote: ERROR: Use 4 digit octal (0777) not decimal permissions This error was detected by checkpatch.pl Signed-off-by: SZ Lin I think checkpatch is overdoing it a bit here. There are more than 2,000 of those. Plus, I really don't see the value in this change.

Re: [v4 09/15] sparc64: optimized struct page zeroing

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3 next-20170802] [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/Pavel-Tatashin/complete-deferred-page

Re: [v4 09/15] sparc64: optimized struct page zeroing

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3 next-20170802] [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/Pavel-Tatashin/complete-deferred-page

RE: [PATCH] PCI: rcar-pcie: Fix memory leak when no PCIe card is inserted

Hi > -Original Message- > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > Sent: Wednesday, August 2, 2017 6:03 PM > To: HARUNOBU KUROKAWA > Cc: ho...@verge.net.au; bhelg...@google.com; linux-...@vger.kernel.org; >

RE: [PATCH] PCI: rcar-pcie: Fix memory leak when no PCIe card is inserted

Hi > -Original Message- > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > Sent: Wednesday, August 2, 2017 6:03 PM > To: HARUNOBU KUROKAWA > Cc: ho...@verge.net.au; bhelg...@google.com; linux-...@vger.kernel.org; > linux-renesas-...@vger.kernel.org; >

Re: [PATCH 0/2] PCI: dwc: convert remaining dbi read/writes to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

+cc kishon for dra7xx On Friday 14 July 2017 05:37 PM, Niklas Cassel wrote: > Since the introduction of the dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros, > most dw_pcie_read(pci->dbi_base, ..)/dw_pcie_write(pci->dbi_base, ..) calls > have been converted to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

Re: [PATCH 0/2] PCI: dwc: convert remaining dbi read/writes to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

+cc kishon for dra7xx On Friday 14 July 2017 05:37 PM, Niklas Cassel wrote: > Since the introduction of the dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros, > most dw_pcie_read(pci->dbi_base, ..)/dw_pcie_write(pci->dbi_base, ..) calls > have been converted to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

[PATCHv5 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig | 6 ++ 1 file changed, 6

[PATCHv5 0/3] Intel FPGA VIP Frame Buffer II drm driver

From: Ong Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to

[PATCHv5 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCHv5 0/3] Intel FPGA VIP Frame Buffer II drm driver

From: Ong Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA

[PATCHv5 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Signed-off-by: Ong Hean Loong --- V5: *Fix Comments V4: *Fix Comments V3: *Changes to fixing drm_simple_pipe *Used drm_fb_cma_get_gem_addr V2: *Adding drm_simple_display_pipe_init --- drivers/gpu/drm/Kconfig

[PATCHv5 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Signed-off-by: Ong Hean Loong --- V5: *Fix Comments V4: *Fix Comments V3: *Changes to fixing drm_simple_pipe *Used drm_fb_cma_get_gem_addr V2: *Adding drm_simple_display_pipe_init --- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile

[PATCHv5 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Device tree binding for Intel FPGA Video and Image Processing Suite. The binding involved would be generated from the Altera (Intel) Qsys system. The bindings would set the max width, max height, buts per pixel and memory port width. The device tree

[PATCHv5 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite

From: Ong Hean Loong Device tree binding for Intel FPGA Video and Image Processing Suite. The binding involved would be generated from the Altera (Intel) Qsys system. The bindings would set the max width, max height, buts per pixel and memory port width. The device tree binding only supports the

Re: [v4 13/15] mm: stop zeroing memory during allocation in vmemmap

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3] [cannot apply to next-20170802] [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/Pavel-Tatashin/complete

Re: [v4 13/15] mm: stop zeroing memory during allocation in vmemmap

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3] [cannot apply to next-20170802] [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/Pavel-Tatashin/complete

[PATCH v2 1/4] arm64: dts: qcom: Add RPM glink nodes to msm8996

Signed-off-by: Bjorn Andersson --- Changes since v1: - None arch/arm64/boot/dts/qcom/msm8996.dtsi | 78 +++ 1 file changed, 78 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi

[PATCH v2 4/4] arm64: dts: qcom: msm8996: Specify smd-edge for ADSP

Add the smd-edge node for the adsp, to allow SMD communication with the ADSP. Signed-off-by: Bjorn Andersson --- Changes since v1: - Spelled out GIC_SPI arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git

[PATCH] drivers: spi: Pick spi bus number from Linux idr or spi alias

Patch was compile tested and built(ARCH=arm) on next-20170802. - Patch was hardware tested on AM335x (McSPI controller) with memory chips as slaves. - Added spi aliases in aliases node, device tree and tested. - No build/run-time issues reported. ---

[PATCH v2 1/4] arm64: dts: qcom: Add RPM glink nodes to msm8996

Signed-off-by: Bjorn Andersson --- Changes since v1: - None arch/arm64/boot/dts/qcom/msm8996.dtsi | 78 +++ 1 file changed, 78 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi index

[PATCH v2 4/4] arm64: dts: qcom: msm8996: Specify smd-edge for ADSP

Add the smd-edge node for the adsp, to allow SMD communication with the ADSP. Signed-off-by: Bjorn Andersson --- Changes since v1: - Spelled out GIC_SPI arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi

[PATCH] drivers: spi: Pick spi bus number from Linux idr or spi alias

have an alias, pick the bus number from alias ID (c) Convert to linux idr interface Signed-off-by: Suniel Mahesh Signed-off-by: Karthik Tummala Tested-by: Karthik Tummala --- Note: - Patch was compile tested and built(ARCH=arm) on next-20170802. - Patch was hardware tested on AM335x (McSPI

[PATCH v2 3/4] arm64: dts: msm8996: Add modem smp2p nodes

Signed-off-by: Bjorn Andersson --- Changes since v1: - Spelled out GIC_SPI arch/arm64/boot/dts/qcom/msm8996.dtsi | 24 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi

[PATCH v2 3/4] arm64: dts: msm8996: Add modem smp2p nodes

Signed-off-by: Bjorn Andersson --- Changes since v1: - Spelled out GIC_SPI arch/arm64/boot/dts/qcom/msm8996.dtsi | 24 1 file changed, 24 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi index

[PATCH v2 2/4] arm64: dts: qcom: db820c: Add pm8994 regulator node

From: Rajendra Nayak Add PM8994 RPM regulators with their min/max voltages to DB820c. Signed-off-by: Rajendra Nayak Signed-off-by: Bjorn Andersson --- Changes since v1: - None

[PATCH v2 0/4] DB820c DTS dump

A dump of DTS patches for MSM8996 and DB820c, found in the Linaro landing team tree. Changes since v1: - Dropped the QFPROM patch, as it was only partial Bjorn Andersson (3): arm64: dts: qcom: Add RPM glink nodes to msm8996 arm64: dts: msm8996: Add modem smp2p nodes arm64: dts: qcom:

[PATCH v2 2/4] arm64: dts: qcom: db820c: Add pm8994 regulator node

From: Rajendra Nayak Add PM8994 RPM regulators with their min/max voltages to DB820c. Signed-off-by: Rajendra Nayak Signed-off-by: Bjorn Andersson --- Changes since v1: - None arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 148 +++ 1 file changed, 148 insertions(+)

[PATCH v2 0/4] DB820c DTS dump

A dump of DTS patches for MSM8996 and DB820c, found in the Linaro landing team tree. Changes since v1: - Dropped the QFPROM patch, as it was only partial Bjorn Andersson (3): arm64: dts: qcom: Add RPM glink nodes to msm8996 arm64: dts: msm8996: Add modem smp2p nodes arm64: dts: qcom:

Re: [PATCH] This patch adds support for Sinovoip BPI-M3 A83T based board.

On Thu, Aug 3, 2017 at 7:25 AM, Philipp Rossak wrote: > From: Philipp Rossak > > It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI, > mic, AP6212 Wifi, etc on it. > It is paired with AXP813 PMIC which is almost same as AXP818. > >

Re: [PATCH] This patch adds support for Sinovoip BPI-M3 A83T based board.

On Thu, Aug 3, 2017 at 7:25 AM, Philipp Rossak wrote: > From: Philipp Rossak > > It has 2G LPDDR3, UART, ethernet, USB, HDMI, USB Sata, MIPI DSI, > mic, AP6212 Wifi, etc on it. > It is paired with AXP813 PMIC which is almost same as AXP818. > > Signed-off-by: Vishnu Patekar > > This Patch got

Re: [v4 04/15] mm: discard memblock data later

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3 next-20170802] [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/Pavel-Tatashin/complete-deferred-page

Re: [v4 04/15] mm: discard memblock data later

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3 next-20170802] [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/Pavel-Tatashin/complete-deferred-page

Re: [v4 14/15] mm: optimize early system hash allocations

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3] [cannot apply to next-20170802] [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/Pavel-Tatashin/complete

Re: [v4 14/15] mm: optimize early system hash allocations

Hi Pavel, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13-rc3] [cannot apply to next-20170802] [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/Pavel-Tatashin/complete

[PATCH v9 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang --- drivers/irqchip/irq-qeic.c | 90

[PATCH v9 3/4] irqchip/qeic: merge qeic_of_init into qe_ic_init

qeic_of_init just get device_node of qeic from dtb and call qe_ic_init, pass the device_node to qe_ic_init. So merge qeic_of_init into qe_ic_init to get the qeic node in qe_ic_init. Signed-off-by: Zhao Qiang --- drivers/irqchip/irq-qeic.c | 90 --

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Peter, On Wednesday 02 August 2017 01:44 PM, Peter Zijlstra wrote: On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: Hi, I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64 platform. It looks like that stalled cpu was

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Peter, On Wednesday 02 August 2017 01:44 PM, Peter Zijlstra wrote: On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: Hi, I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64 platform. It looks like that stalled cpu was

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Marc, On Wednesday 02 August 2017 02:14 PM, Marc Zyngier wrote: On 02/08/17 09:08, Will Deacon wrote: Hi Pratyush, On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Marc, On Wednesday 02 August 2017 02:14 PM, Marc Zyngier wrote: On 02/08/17 09:08, Will Deacon wrote: Hi Pratyush, On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Will, On Wednesday 02 August 2017 01:38 PM, Will Deacon wrote: Hi Pratyush, On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64 platform. It looks like that stalled cpu

Re: rcu_sched stall while waiting in csd_lock_wait()

Hi Will, On Wednesday 02 August 2017 01:38 PM, Will Deacon wrote: Hi Pratyush, On Wed, Aug 02, 2017 at 09:01:19AM +0530, Pratyush Anand wrote: I am observing following rcu_sched stall while executing `perf record -a -- sleep 1` with one of the arm64 platform. It looks like that stalled cpu

[PATCH v9 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0,

[PATCH v9 2/4] irqchip/qeic: merge qeic init code from platforms to a common function

The codes of qe_ic init from a variety of platforms are redundant, merge them to a common function and put it to irqchip/irq-qeic.c For non-p1021_mds mpc85xx_mds boards, use "qe_ic_init(np, 0, qe_ic_cascade_low_mpic, qe_ic_cascade_high_mpic);" instead of "qe_ic_init(np, 0,

[PATCH v9 0/4] this patchset is to remove PPCisms for QEIC

QEIC is supported more than just powerpc boards, so remove PPCisms. changelog: Changes for v8: - use IRQCHIP_DECLARE() instead of subsys_initcall in qeic driver - remove include/soc/fsl/qe/qe_ic.h Changes for v9: - rebase - fix the compile issue

[PATCH v9 4/4] irqchip/qeic: remove PPCisms for QEIC

QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang --- arch/powerpc/platforms/83xx/km83xx.c | 1 - arch/powerpc/platforms/83xx/misc.c| 1 -

[PATCH v9 0/4] this patchset is to remove PPCisms for QEIC

QEIC is supported more than just powerpc boards, so remove PPCisms. changelog: Changes for v8: - use IRQCHIP_DECLARE() instead of subsys_initcall in qeic driver - remove include/soc/fsl/qe/qe_ic.h Changes for v9: - rebase - fix the compile issue

[PATCH v9 4/4] irqchip/qeic: remove PPCisms for QEIC

QEIC was supported on PowerPC, and dependent on PPC, Now it is supported on other platforms, so remove PPCisms. Signed-off-by: Zhao Qiang --- arch/powerpc/platforms/83xx/km83xx.c | 1 - arch/powerpc/platforms/83xx/misc.c| 1 - arch/powerpc/platforms/83xx/mpc832x_mds.c

[PATCH v9 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang --- MAINTAINERS| 6 ++ drivers/irqchip/Makefile | 1 +

[PATCH v9 1/4] irqchip/qeic: move qeic driver from drivers/soc/fsl/qe

move the driver from drivers/soc/fsl/qe to drivers/irqchip, merge qe_ic.h and qe_ic.c into irq-qeic.c. Signed-off-by: Zhao Qiang --- MAINTAINERS| 6 ++ drivers/irqchip/Makefile | 1 + drivers/{soc/fsl/qe/qe_ic.c =>

Re: [PATCH 2/2] qlcnic: add const to bin_attribute structure

-Original Message- From: Bhumika Goyal Date: Wednesday, August 2, 2017 at 11:27 PM To: "julia.law...@lip6.fr" , "kv...@codeaurora.org" , "linux-wirel...@vger.kernel.org" ,

Re: [PATCH 2/2] qlcnic: add const to bin_attribute structure

-Original Message- From: Bhumika Goyal Date: Wednesday, August 2, 2017 at 11:27 PM To: "julia.law...@lip6.fr" , "kv...@codeaurora.org" , "linux-wirel...@vger.kernel.org" , "net...@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Harish Patil , "Chopra, Manish" , Dept-GE Linux NIC Dev

[PATCH] ARM: dts: rockchip: convert rk3288 device tree files to 64 bits

In order to be able to use more than 4GB of RAM when the LPAE is activated, the dts must be converted in 64 bits. Signed-off-by: Tao Huang --- Another way to support 64-bit memory is create a soc subnode, and move all peripherals to this subnode. But it will break

[PATCH] ARM: dts: rockchip: convert rk3288 device tree files to 64 bits

In order to be able to use more than 4GB of RAM when the LPAE is activated, the dts must be converted in 64 bits. Signed-off-by: Tao Huang --- Another way to support 64-bit memory is create a soc subnode, and move all peripherals to this subnode. But it will break userspace compatibility. For

[PATCH 2/4] seccomp: Add SECCOMP_FILTER_FLAG_KILL_PROCESS

Right now, SECCOMP_RET_KILL kills the current thread. There have been a few requests for RET_KILL to kill the entire process (the thread group), but since seccomp's u32 return values are ABI, and ordered by lowest value, with RET_KILL as 0, there isn't a trivial way to provide an even smaller

[PATCH 2/4] seccomp: Add SECCOMP_FILTER_FLAG_KILL_PROCESS

Right now, SECCOMP_RET_KILL kills the current thread. There have been a few requests for RET_KILL to kill the entire process (the thread group), but since seccomp's u32 return values are ABI, and ordered by lowest value, with RET_KILL as 0, there isn't a trivial way to provide an even smaller

[PATCH 1/4] seccomp: Provide matching filter for introspection

Both the upcoming logging improvements and changes to RET_KILL will need to know which filter a given seccomp return value originated from. In order to delay logic processing of result until after the seccomp loop, this adds a single pointer assignment on matches. This will allow both log and

[PATCH 1/4] seccomp: Provide matching filter for introspection

Both the upcoming logging improvements and changes to RET_KILL will need to know which filter a given seccomp return value originated from. In order to delay logic processing of result until after the seccomp loop, this adds a single pointer assignment on matches. This will allow both log and

[PATCH 3/4] selftests/seccomp: Refactor RET_ERRNO tests

This refactors the errno tests (since they all use the same pattern for their filter) and adds a RET_DATA field ordering test. Signed-off-by: Kees Cook --- tools/testing/selftests/seccomp/seccomp_bpf.c | 95 --- 1 file changed, 58 insertions(+), 37

[PATCH 3/4] selftests/seccomp: Refactor RET_ERRNO tests

This refactors the errno tests (since they all use the same pattern for their filter) and adds a RET_DATA field ordering test. Signed-off-by: Kees Cook --- tools/testing/selftests/seccomp/seccomp_bpf.c | 95 --- 1 file changed, 58 insertions(+), 37 deletions(-) diff

[PATCH 4/4] selftests/seccomp: Test thread vs process killing

SECCOMP_RET_KILL is supposed to kill the current thread (and userspace depends on this), so test for this, distinct from killing the entire process. This also tests killing the entire process with the new SECCOMP_FILTER_FLAG_KILL_PROCESS flag. (This also moves a bunch of defines up earlier in the

[PATCH 4/4] selftests/seccomp: Test thread vs process killing

SECCOMP_RET_KILL is supposed to kill the current thread (and userspace depends on this), so test for this, distinct from killing the entire process. This also tests killing the entire process with the new SECCOMP_FILTER_FLAG_KILL_PROCESS flag. (This also moves a bunch of defines up earlier in the

[PATCH 0/4] seccomp: Add SECCOMP_FILTER_FLAG_KILL_PROCESS

This series is the result of Fabricio and I going around a few times on possible solutions for finding a way to enhance RET_KILL to kill the process group. There's a lot of ways this could be done, but I wanted something that felt cleanest. As it happens, Tyler's recent patch series for logging

[PATCH 0/4] seccomp: Add SECCOMP_FILTER_FLAG_KILL_PROCESS

This series is the result of Fabricio and I going around a few times on possible solutions for finding a way to enhance RET_KILL to kill the process group. There's a lot of ways this could be done, but I wanted something that felt cleanest. As it happens, Tyler's recent patch series for logging

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote: > > Take CAAM's engine HWRNG: it can work both as a TRNG and as a > TRNG-seeded DRBG (that's how it's currently configured). > IIUC, both setups are fit as source for the entropy pool. So which is it? If it's a DRBG then it should not

Re: [PATCH v1] crypto: caam - set hwrng quality level

On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote: > > Take CAAM's engine HWRNG: it can work both as a TRNG and as a > TRNG-seeded DRBG (that's how it's currently configured). > IIUC, both setups are fit as source for the entropy pool. So which is it? If it's a DRBG then it should not

linux-next: build warning after merge of the drm-msm tree

Hi all, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from drivers/gpu/drm/msm/msm_drv.h:37:0, from drivers/gpu/drm/msm/msm_gpu.h:24, from drivers/gpu/drm/msm/msm_gpu.c:18:

linux-next: build warning after merge of the drm-msm tree

Hi all, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from drivers/gpu/drm/msm/msm_drv.h:37:0, from drivers/gpu/drm/msm/msm_gpu.h:24, from drivers/gpu/drm/msm/msm_gpu.c:18:

linux-next: build warning after merge of the drm-msm tree

Hi all, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'a5xx_zap_shader_init': drivers/gpu/drm/msm/adreno/a5xx_gpu.c:493:19: warning: unused variable 'a5xx_gpu' [-Wunused-variable]

linux-next: build warning after merge of the drm-msm tree

Hi all, After merging the drm-msm tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/gpu/drm/msm/adreno/a5xx_gpu.c: In function 'a5xx_zap_shader_init': drivers/gpu/drm/msm/adreno/a5xx_gpu.c:493:19: warning: unused variable 'a5xx_gpu' [-Wunused-variable]

RE: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

> -Original Message- > From: sathyanarayanan kuppuswamy > [mailto:sathyanarayanan.kuppusw...@linux.intel.com] > Sent: Thursday, August 3, 2017 3:29 AM > To: Chakravarty, Souvik K ; > x...@kernel.org; mi...@redhat.com; Zha, Qipeng > ;

RE: [RFC v1 3/6] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

> -Original Message- > From: sathyanarayanan kuppuswamy > [mailto:sathyanarayanan.kuppusw...@linux.intel.com] > Sent: Thursday, August 3, 2017 3:29 AM > To: Chakravarty, Souvik K ; > x...@kernel.org; mi...@redhat.com; Zha, Qipeng > ; h...@zytor.com; dvh...@infradead.org; >

linux-next: manual merge of the drm-msm tree with the drm tree

Hi all, Today's linux-next merge of the drm-msm tree got a conflict in: drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c between commits: 0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper function") 64581714b58b ("drm: Convert atomic drivers from CRTC .disable() to

linux-next: manual merge of the drm-msm tree with the drm tree

Hi all, Today's linux-next merge of the drm-msm tree got a conflict in: drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c between commits: 0b20a0f8c3cb ("drm: Add old state pointer to CRTC .enable() helper function") 64581714b58b ("drm: Convert atomic drivers from CRTC .disable() to

[PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

In some cases drivers referencing a reserved-memory region might want to remap the entire region, but when defining the reserved-memory by "size" the client driver has no means to know the associated base address of the reserved memory region. This patch adds an accessor for such drivers to

[PATCH v2 0/5] Qualcomm remote filesystem shared memory driver

Some remote processors (in particular the modem) found in Qualcomm platforms stores configuration parameters and other data in a file system. As the remotes does not have direct storage access it needs to relay block accesses through a service running on the application CPU. The memory is

  1   2   3   4   5   6   7   8   9   10   >