Re: [PATCHv6] support for AD5820 camera auto-focus coil

On Thu, Nov 03, 2016 at 11:27:27AM +0100, Pavel Machek wrote: > Hi! > > > > > > > Yeah. I just compiled it but haven't tested it. I presume it'll > > > > > > work. :-) > > > > > > > > > > I'm testing it on n900. I guess simpler hardware with ad5820 would be > > > > > better for the > > > > >

Re: [PATCHv6] support for AD5820 camera auto-focus coil

On Thu, Nov 03, 2016 at 11:27:27AM +0100, Pavel Machek wrote: > Hi! > > > > > > > Yeah. I just compiled it but haven't tested it. I presume it'll > > > > > > work. :-) > > > > > > > > > > I'm testing it on n900. I guess simpler hardware with ad5820 would be > > > > > better for the > > > > >

[RFC 2/8] iommu/iova: fix __alloc_and_insert_iova_range

Fix the size check within start_pfn and limit_pfn. Signed-off-by: Eric Auger --- the issue was observed when playing with 1 page iova domain with higher iova reserved. --- drivers/iommu/iova.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[RFC 2/8] iommu/iova: fix __alloc_and_insert_iova_range

Fix the size check within start_pfn and limit_pfn. Signed-off-by: Eric Auger --- the issue was observed when playing with 1 page iova domain with higher iova reserved. --- drivers/iommu/iova.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/iova.c

[RFC 5/8] vfio/type1: Introduce RESV_IOVA_RANGE capability

This patch allows the user-space to retrieve the reserved IOVA range(s), if any. The implementation is based on capability chains, now also added to VFIO_IOMMU_GET_INFO. Signed-off-by: Eric Auger --- --- drivers/vfio/vfio_iommu_type1.c | 63

[RFC 7/8] iommu/vt-d: Implement add_reserved_regions callback

Implement the add_reserved_regions callback by registering the [FEE0_h - FEF0_000h] 1MB range as a reserved region (MSI address space). Signed-off-by: Eric Auger --- drivers/iommu/intel-iommu.c | 48 + 1 file changed, 35

[RFC 8/8] iommu/arm-smmu: implement add_reserved_regions callback

The function populates the list of reserved regions with the PCI host bridge windows and the MSI IOVA range. At the moment an arbitray MSI IOVA window is set at 0x800 of size 1MB. Signed-off-by: Eric Auger --- drivers/iommu/arm-smmu.c | 63

[RFC 5/8] vfio/type1: Introduce RESV_IOVA_RANGE capability

This patch allows the user-space to retrieve the reserved IOVA range(s), if any. The implementation is based on capability chains, now also added to VFIO_IOMMU_GET_INFO. Signed-off-by: Eric Auger --- --- drivers/vfio/vfio_iommu_type1.c | 63 -

[RFC 7/8] iommu/vt-d: Implement add_reserved_regions callback

Implement the add_reserved_regions callback by registering the [FEE0_h - FEF0_000h] 1MB range as a reserved region (MSI address space). Signed-off-by: Eric Auger --- drivers/iommu/intel-iommu.c | 48 + 1 file changed, 35 insertions(+), 13

[RFC 8/8] iommu/arm-smmu: implement add_reserved_regions callback

The function populates the list of reserved regions with the PCI host bridge windows and the MSI IOVA range. At the moment an arbitray MSI IOVA window is set at 0x800 of size 1MB. Signed-off-by: Eric Auger --- drivers/iommu/arm-smmu.c | 63

[RFC 6/8] iommu: Handle the list of reserved regions

A new callback is introduced, add_reserved_regions. This function aims at populating the iommu domain reserved region list with regions associated with the device. The function is called on device attachment. The list is freed on iommu_domain_free(). Signed-off-by: Eric Auger

[PATCH] proc: Report no_new_privs state

Similar to being able to examine if a process has been correctly confined with seccomp, the state of no_new_privs is equally interesting, so this adds it to /proc/$pid/status. Signed-off-by: Kees Cook --- Documentation/filesystems/proc.txt | 2 ++ fs/proc/array.c

[RFC 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain

Introduce a new iommu_reserved_region struct. This embodies an IOVA reserved region that cannot be used along with the IOMMU API. The list is protected by a dedicated mutex. An iommu domain now owns a list of those. Signed-off-by: Eric Auger --- ---

[RFC 6/8] iommu: Handle the list of reserved regions

A new callback is introduced, add_reserved_regions. This function aims at populating the iommu domain reserved region list with regions associated with the device. The function is called on device attachment. The list is freed on iommu_domain_free(). Signed-off-by: Eric Auger ---

[PATCH] proc: Report no_new_privs state

Similar to being able to examine if a process has been correctly confined with seccomp, the state of no_new_privs is equally interesting, so this adds it to /proc/$pid/status. Signed-off-by: Kees Cook --- Documentation/filesystems/proc.txt | 2 ++ fs/proc/array.c| 5 +++-- 2

[RFC 4/8] iommu: Add a list of iommu_reserved_region in iommu_domain

Introduce a new iommu_reserved_region struct. This embodies an IOVA reserved region that cannot be used along with the IOMMU API. The list is protected by a dedicated mutex. An iommu domain now owns a list of those. Signed-off-by: Eric Auger --- --- drivers/iommu/iommu.c | 2 ++

[RFC 1/8] vfio: fix vfio_info_cap_add/shift

Capability header next field is an offset relative to the start of the INFO buffer. tmp->next is assigned the proper value but iterations implemented in vfio_info_cap_add and vfio_info_cap_shift use next as an offset between the headers. When coping with multiple capabilities this leads to an

[RFC 3/8] iommu/dma: Allow MSI-only cookies

From: Robin Murphy IOMMU domain users such as VFIO face a similar problem to DMA API ops with regard to mapping MSI messages in systems where the MSI write is subject to IOMMU translation. With the relevant infrastructure now in place for managed DMA domains, it's actually

[RFC 1/8] vfio: fix vfio_info_cap_add/shift

Capability header next field is an offset relative to the start of the INFO buffer. tmp->next is assigned the proper value but iterations implemented in vfio_info_cap_add and vfio_info_cap_shift use next as an offset between the headers. When coping with multiple capabilities this leads to an

[RFC 3/8] iommu/dma: Allow MSI-only cookies

From: Robin Murphy IOMMU domain users such as VFIO face a similar problem to DMA API ops with regard to mapping MSI messages in systems where the MSI write is subject to IOMMU translation. With the relevant infrastructure now in place for managed DMA domains, it's actually really simple for

[RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II)

Following Will & Robin's suggestions, this series attempts to propose an alternative to [1] where the host would arbitrarily decide the location of the IOVA MSI window and would be able to report to the userspace the list of reserved IOVA regions that cannot be used along with VFIO_IOMMU_MAP_DMA.

[RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II)

Following Will & Robin's suggestions, this series attempts to propose an alternative to [1] where the host would arbitrarily decide the location of the IOVA MSI window and would be able to report to the userspace the list of reserved IOVA regions that cannot be used along with VFIO_IOMMU_MAP_DMA.

Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver

On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote: > slim core is used as a basis for many IPs in the STi > chipsets such as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other

Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver

On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote: > slim core is used as a basis for many IPs in the STi > chipsets such as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other

Re: [PATH] z3fold: extend compaction function

On Thu, Nov 3, 2016 at 10:16 PM, Andrew Morton wrote: > On Thu, 3 Nov 2016 22:04:28 +0100 Vitaly Wool wrote: > >> z3fold_compact_page() currently only handles the situation when >> there's a single middle chunk within the z3fold page. However it

Re: [PATH] z3fold: extend compaction function

On Thu, Nov 3, 2016 at 10:16 PM, Andrew Morton wrote: > On Thu, 3 Nov 2016 22:04:28 +0100 Vitaly Wool wrote: > >> z3fold_compact_page() currently only handles the situation when >> there's a single middle chunk within the z3fold page. However it >> may be worth it to move middle chunk closer to

[PATCH v2 01/10] ARC: timer: rtc: implement read loop in "C" vs. inline asm

The current code doesn't even compile CC: sta...@vger.kernel.org Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/arc/kernel/time.c b/arch/arc/kernel/time.c index

[PATCH v2 01/10] ARC: timer: rtc: implement read loop in "C" vs. inline asm

The current code doesn't even compile CC: sta...@vger.kernel.org Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/arc/kernel/time.c b/arch/arc/kernel/time.c index f927b8dc6edd..1a117b999c0c

[PATCH v2 02/10] ARC: timer: gfrc, rtc: deuglify big endian code

A standard "C" shift will be handled appropriately by the compiler dependin gon the endian used fo rbuild. So we don't need the explicit distinction in code Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 30 -- 1 file changed, 8

[PATCH v2 09/10] ARC: breakout timer include code into separate header ...

... which allows for use in drivers/clocksource later Signed-off-by: Vineet Gupta --- arch/arc/include/asm/arcregs.h | 9 + arch/arc/kernel/time.c | 18 +++--- include/soc/arc/timers.h | 38 ++ 3 files

[PATCH v2 02/10] ARC: timer: gfrc, rtc: deuglify big endian code

A standard "C" shift will be handled appropriately by the compiler dependin gon the endian used fo rbuild. So we don't need the explicit distinction in code Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 30 -- 1 file changed, 8 insertions(+), 22

[PATCH v2 09/10] ARC: breakout timer include code into separate header ...

... which allows for use in drivers/clocksource later Signed-off-by: Vineet Gupta --- arch/arc/include/asm/arcregs.h | 9 + arch/arc/kernel/time.c | 18 +++--- include/soc/arc/timers.h | 38 ++ 3 files changed, 42

[PATCH v2 10/10] clocksource: import ARC timer driver

This adds support for - CONFIG_ARC_TIMERS : legacy 32-bit TIMER0 and TIMER1 which count UP from @CNT to @LIMIT, before optionally triggering an interrupt. These are programmed using ARC auxiliary register interface. These are present in all ARC cores (ARC700 and ARC HS38) TIMER0

[PATCH v2 10/10] clocksource: import ARC timer driver

This adds support for - CONFIG_ARC_TIMERS : legacy 32-bit TIMER0 and TIMER1 which count UP from @CNT to @LIMIT, before optionally triggering an interrupt. These are programmed using ARC auxiliary register interface. These are present in all ARC cores (ARC700 and ARC HS38) TIMER0

[PATCH v2 05/10] ARC: time: move time_init() out of the driver

to allow future git mv of the driver into drivers/clocksource Acked-by: Daniel Lezcano Signed-off-by: Vineet Gupta --- arch/arc/kernel/setup.c | 11 +++ arch/arc/kernel/time.c | 9 - 2 files changed, 11 insertions(+), 9

[PATCH v2 05/10] ARC: time: move time_init() out of the driver

to allow future git mv of the driver into drivers/clocksource Acked-by: Daniel Lezcano Signed-off-by: Vineet Gupta --- arch/arc/kernel/setup.c | 11 +++ arch/arc/kernel/time.c | 9 - 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/arch/arc/kernel/setup.c

[PATCH v2 08/10] ARC: move mcip.h into include/soc and adjust the includes

Also remove the dependency on ARCv2, to increase compile coverage for !ARCV2 builds Acked-by: Daniel Lezcano Signed-off-by: Vineet Gupta --- arch/arc/kernel/mcip.c | 2 +- arch/arc/kernel/time.c

[PATCH v2 03/10] ARC: timer: gfrc, rtc: Read BCR to detect whether hardware exists ...

... don't rely on cpuinfo populated in arc boot code. This paves way for moving this code in drivers/clocksource/ And while at it, convert the WARN() to pr_warn() as sugested by Daniel Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 18 +- 1 file

[PATCH v2 06/10] ARC: timer: Build gfrc, rtc under same option (64-bit timers)

The original distinction was done as they were deveoped at different times and primarily becuse they are specific to UP (RTC) and SMP (GFRC). But given that driver now handles that at runtime, (i.e. not allowing RTC as clocksource in SMP), we can simplify things a bit. Signed-off-by: Vineet

[PATCH v2 04/10] ARC: timer: gfrc: boot print alongside other timers

Signed-off-by: Vineet Gupta --- arch/arc/kernel/setup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 0385df77a697..595d06900061 100644 --- a/arch/arc/kernel/setup.c +++

[PATCH v2 08/10] ARC: move mcip.h into include/soc and adjust the includes

Also remove the dependency on ARCv2, to increase compile coverage for !ARCV2 builds Acked-by: Daniel Lezcano Signed-off-by: Vineet Gupta --- arch/arc/kernel/mcip.c | 2 +- arch/arc/kernel/time.c | 2 +- arch/arc/plat-axs10x/axs10x.c

[PATCH v2 03/10] ARC: timer: gfrc, rtc: Read BCR to detect whether hardware exists ...

... don't rely on cpuinfo populated in arc boot code. This paves way for moving this code in drivers/clocksource/ And while at it, convert the WARN() to pr_warn() as sugested by Daniel Signed-off-by: Vineet Gupta --- arch/arc/kernel/time.c | 18 +- 1 file changed, 13

[PATCH v2 06/10] ARC: timer: Build gfrc, rtc under same option (64-bit timers)

The original distinction was done as they were deveoped at different times and primarily becuse they are specific to UP (RTC) and SMP (GFRC). But given that driver now handles that at runtime, (i.e. not allowing RTC as clocksource in SMP), we can simplify things a bit. Signed-off-by: Vineet

[PATCH v2 04/10] ARC: timer: gfrc: boot print alongside other timers

Signed-off-by: Vineet Gupta --- arch/arc/kernel/setup.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 0385df77a697..595d06900061 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -234,11

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

[PATCH v2 07/10] ARC: breakout aux handling into a separate header

ARC timers use aux registers for programming and this paves way for moving ARC timer drivers into drivers/clocksource Signed-off-by: Vineet Gupta --- arch/arc/include/asm/arcregs.h | 85 +- arch/arc/include/asm/mcip.h| 2 +-

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

[PATCH v2 07/10] ARC: breakout aux handling into a separate header

ARC timers use aux registers for programming and this paves way for moving ARC timer drivers into drivers/clocksource Signed-off-by: Vineet Gupta --- arch/arc/include/asm/arcregs.h | 85 +- arch/arc/include/asm/mcip.h| 2 +- include/soc/arc/aux.h

Re: [PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

On 11/03/2016 02:21 PM, Vineet Gupta wrote: > Hi, > > This series addresses the long pending move of ARC timer code into > drivers/clocksource/. > > Thx, > -Vineet Sorry patch sending got aborted, git send-email SNAFU - tripping on '#' below CC: stable #4.2+ ---> likes [4.2+]

Re: [PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

On 11/03/2016 02:21 PM, Vineet Gupta wrote: > Hi, > > This series addresses the long pending move of ARC timer code into > drivers/clocksource/. > > Thx, > -Vineet Sorry patch sending got aborted, git send-email SNAFU - tripping on '#' below CC: stable #4.2+ ---> likes [4.2+]

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

[RFC] fpga mgr: Introduce FPGA capabilities

Add FPGA capabilities as a way to express the capabilities of a given FPGA manager. Removes code duplication by comparing the low-level driver's capabilities at the framework level rather than having each driver check for supported operations in the write_init() callback. This allows for

[RFC] fpga mgr: Introduce FPGA capabilities

Add FPGA capabilities as a way to express the capabilities of a given FPGA manager. Removes code duplication by comparing the low-level driver's capabilities at the framework level rather than having each driver check for supported operations in the write_init() callback. This allows for

Re: [PATCH] x86/boot: Remove always empty $(USERINCLUDE)

On Thu, 03 Nov, at 10:51:38AM, Paul Bolle wrote: > Apparently Matt left Intel. Let's forward this to a recently used > address. > > On Thu, 2016-11-03 at 10:47 +0100, Paul Bolle wrote: > > Commmit b6eea87fc685 ("x86, boot: Explicitly include autoconf.h for > > hostprogs") correctly noted > >

Re: [PATCH] x86/boot: Remove always empty $(USERINCLUDE)

On Thu, 03 Nov, at 10:51:38AM, Paul Bolle wrote: > Apparently Matt left Intel. Let's forward this to a recently used > address. > > On Thu, 2016-11-03 at 10:47 +0100, Paul Bolle wrote: > > Commmit b6eea87fc685 ("x86, boot: Explicitly include autoconf.h for > > hostprogs") correctly noted > >

Re: [PATCH v10 03/11] remoteproc: Update Kconfig setup to 'depends on REMOTEPROC'

On Sat 08 Oct 05:52 PDT 2016, Peter Griffin wrote: > Make REMOTEPROC core a selectable kconfig option, and update > remoteproc client drivers to 'depends on' the core. This avoids > some nasty Kconfig recursive dependency issues. Also when using > menuconfig client drivers will be hidden until

Re: [PATCH v10 03/11] remoteproc: Update Kconfig setup to 'depends on REMOTEPROC'

On Sat 08 Oct 05:52 PDT 2016, Peter Griffin wrote: > Make REMOTEPROC core a selectable kconfig option, and update > remoteproc client drivers to 'depends on' the core. This avoids > some nasty Kconfig recursive dependency issues. Also when using > menuconfig client drivers will be hidden until

Re: [PATCH] z3fold: make pages_nr atomic

On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton wrote: > On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool wrote: > >> This patch converts pages_nr per-pool counter to atomic64_t. > > Which is slower. > > Presumably there is a reason for making this

Re: [PATCH] z3fold: make pages_nr atomic

On Thu, Nov 3, 2016 at 10:14 PM, Andrew Morton wrote: > On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool wrote: > >> This patch converts pages_nr per-pool counter to atomic64_t. > > Which is slower. > > Presumably there is a reason for making this change. This reason > should be described in the

Re: [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags

On Fri, Sep 16, 2016 at 09:42:41PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Marek (internally), Geert and Alban reported errors like: > genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68) > The patchset fixes this issue. > > Tested on: > 1. Exynos4412: Odroid U3, >

Re: [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags

On Fri, Sep 16, 2016 at 09:42:41PM +0200, Krzysztof Kozlowski wrote: > Hi, > > Marek (internally), Geert and Alban reported errors like: > genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68) > The patchset fixes this issue. > > Tested on: > 1. Exynos4412: Odroid U3, >

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

[PATCH v2 00/10] Move ARC timer code into drivers/clocksource/

Hi, This series addresses the long pending move of ARC timer code into drivers/clocksource/. Thx, -Vineet v1 -> v2 - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier stable backport - Folded the

Re: [PATCH v3] console: use first console if stdout-path device doesn't appear

Hi Sergey, On Friday, 4 November 2016 02:40:40 GMT Sergey Senozhatsky wrote: > On (11/03/16 12:57), Paul Burton wrote: > > If a device tree specified a preferred device for kernel console output > > via the stdout-path or linux,stdout-path chosen node properties there's > > no guarantee that it

Re: [PATCH v3] console: use first console if stdout-path device doesn't appear

Hi Sergey, On Friday, 4 November 2016 02:40:40 GMT Sergey Senozhatsky wrote: > On (11/03/16 12:57), Paul Burton wrote: > > If a device tree specified a preferred device for kernel console output > > via the stdout-path or linux,stdout-path chosen node properties there's > > no guarantee that it

Re: [PATCH v9 00/16] re-enable DAX PMD support

On Thu, Nov 03, 2016 at 11:51:02AM -0600, Ross Zwisler wrote: > On Thu, Nov 03, 2016 at 12:58:26PM +1100, Dave Chinner wrote: > > On Tue, Nov 01, 2016 at 01:54:02PM -0600, Ross Zwisler wrote: > > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > > locking. This

Re: [PATCH v9 00/16] re-enable DAX PMD support

On Thu, Nov 03, 2016 at 11:51:02AM -0600, Ross Zwisler wrote: > On Thu, Nov 03, 2016 at 12:58:26PM +1100, Dave Chinner wrote: > > On Tue, Nov 01, 2016 at 01:54:02PM -0600, Ross Zwisler wrote: > > > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > > > locking. This

[PATCH V5] pinctrl: qcom: Add msm8994 pinctrl driver

Initial pinctrl driver for QCOM msm8994 platforms. In order to continue the initial board support for QCOM msm8994/msm8992 presented in patches from Jeremy McNicoll , let's put a proper pinctrl driver in place. Currently, the DT for these platforms uses the msm8x74 pinctrl

[PATCH V5] pinctrl: qcom: Add msm8994 pinctrl driver

Initial pinctrl driver for QCOM msm8994 platforms. In order to continue the initial board support for QCOM msm8994/msm8992 presented in patches from Jeremy McNicoll , let's put a proper pinctrl driver in place. Currently, the DT for these platforms uses the msm8x74 pinctrl driver to enable basic

Re: [PATH] z3fold: extend compaction function

On Thu, 3 Nov 2016 22:04:28 +0100 Vitaly Wool wrote: > z3fold_compact_page() currently only handles the situation when > there's a single middle chunk within the z3fold page. However it > may be worth it to move middle chunk closer to either first or > last chunk, whichever

Re: [PATH] z3fold: extend compaction function

On Thu, 3 Nov 2016 22:04:28 +0100 Vitaly Wool wrote: > z3fold_compact_page() currently only handles the situation when > there's a single middle chunk within the z3fold page. However it > may be worth it to move middle chunk closer to either first or > last chunk, whichever is there, if the gap

Re: [PATCH] z3fold: make pages_nr atomic

On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool wrote: > This patch converts pages_nr per-pool counter to atomic64_t. Which is slower. Presumably there is a reason for making this change. This reason should be described in the changelog.

Re: [PATCH] z3fold: make pages_nr atomic

On Thu, 3 Nov 2016 22:00:58 +0100 Vitaly Wool wrote: > This patch converts pages_nr per-pool counter to atomic64_t. Which is slower. Presumably there is a reason for making this change. This reason should be described in the changelog.

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based

Re: vmalloced stacks and scatterwalk_map_and_copy()

On Thu, Nov 03, 2016 at 01:30:49PM -0700, Andy Lutomirski wrote: > > Also, Herbert, it seems like the considerable majority of the crypto > code is acting on kernel virtual memory addresses and does software > processing. Would it perhaps make sense to add a kvec-based or > iov_iter-based

Re: [PATCH 0/5] drm/sun4i: Handle TV overscan

On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard wrote: > Hi Russell, > > On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote: >> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote: >> > The first one is that this overscanning should

Re: [PATCH 0/5] drm/sun4i: Handle TV overscan

On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard wrote: > Hi Russell, > > On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote: >> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote: >> > The first one is that this overscanning should be reported by the >> > connector

[PATCH 2/2] intel_rdt: export min_cbm_bits

min_cbm_bits could be 1 or 2 for L3 cache. Kenrel does check the bits when writting mask. Unfortunately it's not exported to userspace. This patch fixes the gap. Signed-off-by: Shaohua Li --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 16 1 file changed, 16

[PATCH 2/2] intel_rdt: export min_cbm_bits

min_cbm_bits could be 1 or 2 for L3 cache. Kenrel does check the bits when writting mask. Unfortunately it's not exported to userspace. This patch fixes the gap. Signed-off-by: Shaohua Li --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 16 1 file changed, 16 insertions(+) diff

[PATCH 1/2] intel_rdt: fix a build warnning

gcc complains: "warning: ‘dentry’ may be used uninitialized in this function" Signed-off-by: Shaohua Li --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c

[PATCH 1/2] intel_rdt: fix a build warnning

gcc complains: "warning: ‘dentry’ may be used uninitialized in this function" Signed-off-by: Shaohua Li --- arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c

Re: [PATCH 17/34] [media] DaVinci-VPFE-Capture: Improve another size determination in vpfe_enum_input()

>> @@ -1091,7 +1091,7 @@ static int vpfe_enum_input(struct file *file, void >> *priv, >> return -EINVAL; >> } >> sdinfo = _dev->cfg->sub_devs[subdev]; >> -memcpy(inp, >inputs[index], sizeof(struct v4l2_input)); >> +memcpy(inp, >inputs[index], sizeof(*inp)); > > If I am

Re: [PATCH 17/34] [media] DaVinci-VPFE-Capture: Improve another size determination in vpfe_enum_input()

>> @@ -1091,7 +1091,7 @@ static int vpfe_enum_input(struct file *file, void >> *priv, >> return -EINVAL; >> } >> sdinfo = _dev->cfg->sub_devs[subdev]; >> -memcpy(inp, >inputs[index], sizeof(struct v4l2_input)); >> +memcpy(inp, >inputs[index], sizeof(*inp)); > > If I am

[PATH] z3fold: extend compaction function

z3fold_compact_page() currently only handles the situation when there's a single middle chunk within the z3fold page. However it may be worth it to move middle chunk closer to either first or last chunk, whichever is there, if the gap between them is big enough. This patch adds the relevant code,

[PATH] z3fold: extend compaction function

z3fold_compact_page() currently only handles the situation when there's a single middle chunk within the z3fold page. However it may be worth it to move middle chunk closer to either first or last chunk, whichever is there, if the gap between them is big enough. This patch adds the relevant code,

[PATCH] z3fold: make pages_nr atomic

This patch converts pages_nr per-pool counter to atomic64_t. Signed-off-by: Vitaly Wool --- mm/z3fold.c | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 8f9e89c..4d02280 100644 ---

[PATCH] z3fold: make pages_nr atomic

This patch converts pages_nr per-pool counter to atomic64_t. Signed-off-by: Vitaly Wool --- mm/z3fold.c | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/mm/z3fold.c b/mm/z3fold.c index 8f9e89c..4d02280 100644 --- a/mm/z3fold.c +++ b/mm/z3fold.c @@

Re: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted

[Re: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted] On 03/11/2016 (Thu 12:17) Andrew Morton wrote: > On Sat, 29 Oct 2016 14:08:31 +0800 zhongjiang wrote: > > > From: zhong jiang > > > > Since 'commit 3e89e1c5ea84 ("hugetlb: make mm

Re: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted

[Re: [RFC PATCH] hugetlbfs: fix the hugetlbfs can not be mounted] On 03/11/2016 (Thu 12:17) Andrew Morton wrote: > On Sat, 29 Oct 2016 14:08:31 +0800 zhongjiang wrote: > > > From: zhong jiang > > > > Since 'commit 3e89e1c5ea84 ("hugetlb: make mm and fs code explicitly > > non-modular")' > >

Re: [PATCH 10/34] [media] DaVinci-VPBE: Check return value of a setup_if_config() call in vpbe_set_output()

>> From: Markus Elfring >> Date: Wed, 12 Oct 2016 09:56:56 +0200 >> >> * A function was called over the pointer "setup_if_config" in the data >> structure "venc_platform_data". But the return value was not used so far. >> Thus assign it to the local variable

Re: [PATCH 10/34] [media] DaVinci-VPBE: Check return value of a setup_if_config() call in vpbe_set_output()

>> From: Markus Elfring >> Date: Wed, 12 Oct 2016 09:56:56 +0200 >> >> * A function was called over the pointer "setup_if_config" in the data >> structure "venc_platform_data". But the return value was not used so far. >> Thus assign it to the local variable "ret" which will be checked with

Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read()

On Wed 02-11-16 11:32:04, Kirill A. Shutemov wrote: > On Tue, Nov 01, 2016 at 05:39:40PM +0100, Jan Kara wrote: > > On Mon 31-10-16 21:10:35, Kirill A. Shutemov wrote: > > > > If I understand the motivation right, it is mostly about being able to > > > > mmap > > > > PMD-sized chunks to

Re: [PATCHv3 15/41] filemap: handle huge pages in do_generic_file_read()

On Wed 02-11-16 11:32:04, Kirill A. Shutemov wrote: > On Tue, Nov 01, 2016 at 05:39:40PM +0100, Jan Kara wrote: > > On Mon 31-10-16 21:10:35, Kirill A. Shutemov wrote: > > > > If I understand the motivation right, it is mostly about being able to > > > > mmap > > > > PMD-sized chunks to

Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args

* kbuild test robot [161103 13:29]: >In file included from drivers/pinctrl/core.c:36:0: > >> drivers/pinctrl/devicetree.h:29:14: warning: 'struct of_phandle_args' > >> declared inside parameter list will not be visible outside of this > >> definition or declaratio Hmm maybe

Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args

* kbuild test robot [161103 13:29]: >In file included from drivers/pinctrl/core.c:36:0: > >> drivers/pinctrl/devicetree.h:29:14: warning: 'struct of_phandle_args' > >> declared inside parameter list will not be visible outside of this > >> definition or declaratio Hmm maybe we should just

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

On Wed, Nov 02, 2016 at 11:47:55PM +, Jakub Kicinski wrote: > I realized that kmemleak is not scanning the __ro_after_init section... > Following patch solves the false positives but I wonder if it's the > right/acceptable solution. Thanks for putting this together. I actually hit a similar

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

On Wed, Nov 02, 2016 at 11:47:55PM +, Jakub Kicinski wrote: > I realized that kmemleak is not scanning the __ro_after_init section... > Following patch solves the false positives but I wonder if it's the > right/acceptable solution. Thanks for putting this together. I actually hit a similar

[PATCH] cpufreq: stats: clear statistics

From: Markus Mayer Allow cpufreq statistics to be cleared by writing anything to /sys/.../cpufreq/stats/reset. Reading this new sysfs entry returns nothing. Resetting the statistics can be useful in a test environment (test governor, retrieve stats, reset stats, test other

[PATCH] cpufreq: stats: clear statistics

From: Markus Mayer Allow cpufreq statistics to be cleared by writing anything to /sys/.../cpufreq/stats/reset. Reading this new sysfs entry returns nothing. Resetting the statistics can be useful in a test environment (test governor, retrieve stats, reset stats, test other governor, etc.). This

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