Re: [PATCH v5 2/6] drivers:hv: Call vmbus_mmio_free() to reverse vmbus_mmio_allocate()

On Tue, Apr 05, 2016 at 06:18:18PM -0700, Jake Oshins wrote: > Existing code just called release_mem_region(). Adding a > wrapper around it allows the more complex range tracking > that is introduced later in this patch series. > > Signed-off-by: Jake Oshins With typo fix

Re: [PATCH v5 2/6] drivers:hv: Call vmbus_mmio_free() to reverse vmbus_mmio_allocate()

On Tue, Apr 05, 2016 at 06:18:18PM -0700, Jake Oshins wrote: > Existing code just called release_mem_region(). Adding a > wrapper around it allows the more complex range tracking > that is introduced later in this patch series. > > Signed-off-by: Jake Oshins With typo fix below, Acked-by:

Re: [PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

On 04/21/2016 09:43 AM, Tomi Valkeinen wrote: >> Signed-off-by: Lodes, Jim > > Thanks, looks good. Can you fix the email here too, and resend? Yes, I'll fix the sign off and make sure we have it correct going forward.

Re: [PATCH] OMAPDSS: HDMI5: Fix AVI infoframe

On 04/21/2016 09:43 AM, Tomi Valkeinen wrote: >> Signed-off-by: Lodes, Jim > > Thanks, looks good. Can you fix the email here too, and resend? Yes, I'll fix the sign off and make sure we have it correct going forward.

Re: [PATCH 1/5] regulator: core: Resolve supply earlier

On 20/04/16 16:21, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Apr 19, 2016 at 05:09:59PM +0100, Jon Hunter wrote: >> On 19/04/16 16:40, Mark Brown wrote: > >>> This is *really* weird. Why would we need the list lock to do a >>> device_register()? > >> So I did not think

Re: [PATCH 1/5] regulator: core: Resolve supply earlier

On 20/04/16 16:21, Mark Brown wrote: > * PGP Signed by an unknown key > > On Tue, Apr 19, 2016 at 05:09:59PM +0100, Jon Hunter wrote: >> On 19/04/16 16:40, Mark Brown wrote: > >>> This is *really* weird. Why would we need the list lock to do a >>> device_register()? > >> So I did not think

Re: [PATCH v2 1/4] dt-bindings: Add jdi panel vendor

On Wed, Apr 20, 2016 at 03:02:30PM +0530, Vinay Simha BN wrote: > Japan Display Inc. > > Signed-off-by: Vinay Simha BN > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH v2 1/4] dt-bindings: Add jdi panel vendor

On Wed, Apr 20, 2016 at 03:02:30PM +0530, Vinay Simha BN wrote: > Japan Display Inc. > > Signed-off-by: Vinay Simha BN > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

[PATCH v1 4/5] perf: Introduce address range filtering

Many instruction trace pmus out there support address range-based filtering, which would, for example, generate trace data only for a given range of instruction addresses, which is useful for tracing individual functions, modules or libraries. Other pmus may also utilize this functionality to

[PATCH v1 3/5] perf: Extend perf_event_aux_ctx() to optionally iterate through more events

Trace filtering code needs an iterator that can go through all events in a context, including inactive and filtered, to be able to update their filters' address ranges based on mmap or exec events. This patch changes perf_event_aux_ctx() to optionally do this. Signed-off-by: Alexander Shishkin

[PATCH v1 4/5] perf: Introduce address range filtering

Many instruction trace pmus out there support address range-based filtering, which would, for example, generate trace data only for a given range of instruction addresses, which is useful for tracing individual functions, modules or libraries. Other pmus may also utilize this functionality to

[PATCH v1 3/5] perf: Extend perf_event_aux_ctx() to optionally iterate through more events

Trace filtering code needs an iterator that can go through all events in a context, including inactive and filtered, to be able to update their filters' address ranges based on mmap or exec events. This patch changes perf_event_aux_ctx() to optionally do this. Signed-off-by: Alexander Shishkin

[PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

New versions of Intel PT support address range-based filtering. These are the registers, bit definitions and relevant CPUID bits. Signed-off-by: Alexander Shishkin --- arch/x86/events/intel/pt.c | 2 ++ arch/x86/events/intel/pt.h | 2 ++

[PATCH v1 2/5] perf/x86/intel/pt: IP filtering register/cpuid bits

New versions of Intel PT support address range-based filtering. These are the registers, bit definitions and relevant CPUID bits. Signed-off-by: Alexander Shishkin --- arch/x86/events/intel/pt.c | 2 ++ arch/x86/events/intel/pt.h | 2 ++ arch/x86/include/asm/msr-index.h | 18

Re: [PATCH] Fix bindings documentation for Palmas.

On Tue, Apr 19, 2016 at 05:42:51PM +0200, H. Nikolaus Schaller wrote: > > > H. Nikolaus Schaller (1): > Documentation: bindings: fix palmas-rtc documentation > > Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Don't send a

[PATCH v1 1/5] perf: Move set_filter() from behind EVENT_TRACING

For instruction trace filtering, namely, for communicating filter definitions from userspace, I'd like to re-use the SET_FILTER code that the tracepoints are using currently. To that end, this patch moves the relevant code from behind EVENT_TRACING macro. Signed-off-by: Alexander Shishkin

[PATCH v1 1/5] perf: Move set_filter() from behind EVENT_TRACING

For instruction trace filtering, namely, for communicating filter definitions from userspace, I'd like to re-use the SET_FILTER code that the tracepoints are using currently. To that end, this patch moves the relevant code from behind EVENT_TRACING macro. Signed-off-by: Alexander Shishkin ---

Re: [PATCH] Fix bindings documentation for Palmas.

On Tue, Apr 19, 2016 at 05:42:51PM +0200, H. Nikolaus Schaller wrote: > > > H. Nikolaus Schaller (1): > Documentation: bindings: fix palmas-rtc documentation > > Documentation/devicetree/bindings/rtc/rtc-palmas.txt | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Don't send a

[PATCH v1 5/5] perf/x86/intel/pt: Add support for address range filtering in PT

Newer versions of Intel PT support address ranges, which can be used to define IP address range-based filters or TraceSTOP regions. Number of ranges in enumerated via cpuid. This patch implements pmu callbacks and related low-level code to allow filter validation, configuration and programming

[PATCH v1 0/5] perf: Introduce address range filtering

Hi Peter, This is the second round of my filtering patchset. I've changed quite many things since the previous one [1], notably * split the pmu callback in two as we discussed, * split the filter itself into 'core' and 'hw' parts, * made only parent events eligible for configuring filters

[PATCH v1 0/5] perf: Introduce address range filtering

Hi Peter, This is the second round of my filtering patchset. I've changed quite many things since the previous one [1], notably * split the pmu callback in two as we discussed, * split the filter itself into 'core' and 'hw' parts, * made only parent events eligible for configuring filters

[PATCH v1 5/5] perf/x86/intel/pt: Add support for address range filtering in PT

Newer versions of Intel PT support address ranges, which can be used to define IP address range-based filters or TraceSTOP regions. Number of ranges in enumerated via cpuid. This patch implements pmu callbacks and related low-level code to allow filter validation, configuration and programming

Re: [PATCH] Documentation: bindings: fix palmas-rtc documentation

On Tue, Apr 19, 2016 at 05:42:52PM +0200, H. Nikolaus Schaller wrote: > Signed-off-by: H. Nikolaus Schaller A more specific subject and commit message would be nice. It is a lot of change to figure out it is just s/100mA/100uA/. Acked-by: Rob Herring >

Re: [PATCH] Documentation: bindings: fix palmas-rtc documentation

On Tue, Apr 19, 2016 at 05:42:52PM +0200, H. Nikolaus Schaller wrote: > Signed-off-by: H. Nikolaus Schaller A more specific subject and commit message would be nice. It is a lot of change to figure out it is just s/100mA/100uA/. Acked-by: Rob Herring > --- >

[PATCH V3] audit: add tty field to LOGIN event

The tty field was missing from AUDIT_LOGIN events. Refactor code to create a new function audit_get_tty(), using it to replace the call in audit_log_task_info() and to add it to audit_log_set_loginuid(). Lock and bump the kref to protect it, adding audit_put_tty() alias to decrement it.

[PATCH V3] audit: add tty field to LOGIN event

The tty field was missing from AUDIT_LOGIN events. Refactor code to create a new function audit_get_tty(), using it to replace the call in audit_log_task_info() and to add it to audit_log_set_loginuid(). Lock and bump the kref to protect it, adding audit_put_tty() alias to decrement it.

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 13:29+0200, Greg Kurz: > On Wed, 20 Apr 2016 20:29:09 +0200 > Radim Krčmář wrote: >> 2016-04-20 17:44+0200, Greg Kurz: >> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") >> > introduced a check to prevent potential kernel memory

Re: [PATCH v3] KVM: remove buggy vcpu id check on vcpu creation

2016-04-21 13:29+0200, Greg Kurz: > On Wed, 20 Apr 2016 20:29:09 +0200 > Radim Krčmář wrote: >> 2016-04-20 17:44+0200, Greg Kurz: >> > Commit 338c7dbadd26 ("KVM: Improve create VCPU parameter (CVE-2013-4587)") >> > introduced a check to prevent potential kernel memory corruption in case >> > the

Re: [PATCH v5 1/4] dmaengine: dw: platform: check nr_masters to be non-zero

Hi, [auto build test WARNING on next-20160421] [also build test WARNING on v4.6-rc4] [cannot apply to robh/for-next asoc/for-next v4.6-rc4 v4.6-rc3 v4.6-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci

Re: [PATCH v5 1/4] dmaengine: dw: platform: check nr_masters to be non-zero

Hi, [auto build test WARNING on next-20160421] [also build test WARNING on v4.6-rc4] [cannot apply to robh/for-next asoc/for-next v4.6-rc4 v4.6-rc3 v4.6-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci

Re: [PATCH] regulator: arizona-ldo1: Mark as always-on if no LDOENA

On Thu, Apr 21, 2016 at 01:02:02PM +0100, Richard Fitzgerald wrote: > If we don't have a GPIO for LDOENA it's impossible to turn > the LDO1 regulator off so mark it as always-on. If there is no enable control method for the regulator this should be redundant. If that's not the case you should

Re: [PATCH] regulator: arizona-ldo1: Mark as always-on if no LDOENA

On Thu, Apr 21, 2016 at 01:02:02PM +0100, Richard Fitzgerald wrote: > If we don't have a GPIO for LDOENA it's impossible to turn > the LDO1 regulator off so mark it as always-on. If there is no enable control method for the regulator this should be redundant. If that's not the case you should

Re: [PATCH v2] x86/vdso: Use RDPID in preference to LSL when available

On Thu, Apr 21, 2016 at 5:16 AM, Borislav Petkov wrote: > On Wed, Apr 20, 2016 at 06:16:01PM -0700, Andy Lutomirski wrote: >> Also, it's time for someone to do UMIP. I'll see if I can convince >> someone in KVM land to emulate it to make it easier to test. > > That'll be fun - we

Re: [PATCH v2] x86/vdso: Use RDPID in preference to LSL when available

On Thu, Apr 21, 2016 at 5:16 AM, Borislav Petkov wrote: > On Wed, Apr 20, 2016 at 06:16:01PM -0700, Andy Lutomirski wrote: >> Also, it's time for someone to do UMIP. I'll see if I can convince >> someone in KVM land to emulate it to make it easier to test. > > That'll be fun - we can simply set

Re: [PATCH 2/2] crypto: s5p-sss - Remove useless hash interrupt handler

On Tue, Apr 19, 2016 at 03:44:12PM +0200, Krzysztof Kozlowski wrote: > Beside regular feed control interrupt, the driver requires also hash > interrupt for older SoCs (samsung,s5pv210-secss). However after > requesting it, the interrupt handler isn't doing anything with it, not > even clearing the

Re: [PATCH 2/2] crypto: s5p-sss - Remove useless hash interrupt handler

On Tue, Apr 19, 2016 at 03:44:12PM +0200, Krzysztof Kozlowski wrote: > Beside regular feed control interrupt, the driver requires also hash > interrupt for older SoCs (samsung,s5pv210-secss). However after > requesting it, the interrupt handler isn't doing anything with it, not > even clearing the

[PATCH v5 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303.html) contains a number of mostly minor fixes and cleanups for the DW DMA driver. A couple of them affect the DT binding so these may need to be updated to maintain compatibility (old format is still supported though). The rest

[PATCH v5 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303.html) contains a number of mostly minor fixes and cleanups for the DW DMA driver. A couple of them affect the DT binding so these may need to be updated to maintain compatibility (old format is still supported though). The rest

[[PATCH v2] 1/8] ARM: dts: STi: STiH407: Provide generic (safe) DVFS configuration

You'll notice that the voltage cell is populated with 0's. Voltage information is very platform specific, even depends on 'cut' and 'substrate' versions. Thus it is left blank for a generic (safe) implementation. If other nodes/properties are provided by the bootloader, the ST CPUFreq driver

[[PATCH v2] 1/8] ARM: dts: STi: STiH407: Provide generic (safe) DVFS configuration

You'll notice that the voltage cell is populated with 0's. Voltage information is very platform specific, even depends on 'cut' and 'substrate' versions. Thus it is left blank for a generic (safe) implementation. If other nodes/properties are provided by the bootloader, the ST CPUFreq driver

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

Em Thu, Apr 21, 2016 at 12:48:58PM +0200, Peter Zijlstra escreveu: > On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: > > The default remains 127, which is good for most cases, and not even hit > > most of the time, but then for some cases, as reported by Brendan, 1024+ >

Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth via sysctl

Em Thu, Apr 21, 2016 at 12:48:58PM +0200, Peter Zijlstra escreveu: > On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote: > > The default remains 127, which is good for most cases, and not even hit > > most of the time, but then for some cases, as reported by Brendan, 1024+ >

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > > [quote from pdf] > > > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > > This is commonly achieved even before user space is initiated. > > Unfortunately one of the issues of the /dev/urandom

Re: [RFC][PATCH 0/6] /dev/random - a new approach

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > > [quote from pdf] > > > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > > This is commonly achieved even before user space is initiated. > > Unfortunately one of the issues of the /dev/urandom

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote: > ( Good Lord, I hate doing string manipulation in C ) (yep) > > On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote: > > > > So, "len" does not include the room for the terminating NUL-byte here. > > When "len" is passed to

Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8

On Thu, Apr 21, 2016 at 01:18:27PM +0100, Matt Fleming wrote: > ( Good Lord, I hate doing string manipulation in C ) (yep) > > On Wed, 20 Apr, at 03:25:32PM, Laszlo Ersek wrote: > > > > So, "len" does not include the room for the terminating NUL-byte here. > > When "len" is passed to

[PATCH v5 2/4] dmaengine: dw: revisit data_width property

There are several changes are done here: - Convert the property to be in bytes Besides this is common practice for such property the use of a value in bytes much more convenient than handling the encoded value. - Rename data_width to data-width in the device tree bindings - While here, replace

[PATCH v5 2/4] dmaengine: dw: revisit data_width property

There are several changes are done here: - Convert the property to be in bytes Besides this is common practice for such property the use of a value in bytes much more convenient than handling the encoded value. - Rename data_width to data-width in the device tree bindings - While here, replace

[PATCH v5 3/4] dmaengine: dw: keep entire platform data in struct dw_dma

Keep the entire platform data in the struct dw_dma. It makes the driver a bit cleaner. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/core.c| 30 +++--- drivers/dma/dw/platform.c| 4 ++--

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Thu, Apr 21, 2016 at 03:56:53PM +0100, Stefan Hajnoczi wrote: > On Thu, Apr 21, 2016 at 04:43:45PM +0300, Michael S. Tsirkin wrote: > > This adds a flag to enable/disable bypassing the IOMMU by > > virtio devices. > > > > This is on top of patch > >

[PATCH v5 3/4] dmaengine: dw: keep entire platform data in struct dw_dma

Keep the entire platform data in the struct dw_dma. It makes the driver a bit cleaner. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/core.c| 30 +++--- drivers/dma/dw/platform.c| 4 ++-- drivers/dma/dw/regs.h| 5 ++---

Re: [PATCH V2 RFC] fixup! virtio: convert to use DMA api

On Thu, Apr 21, 2016 at 03:56:53PM +0100, Stefan Hajnoczi wrote: > On Thu, Apr 21, 2016 at 04:43:45PM +0300, Michael S. Tsirkin wrote: > > This adds a flag to enable/disable bypassing the IOMMU by > > virtio devices. > > > > This is on top of patch > >

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

On Thu, Apr 21, 2016 at 6:30 AM, Boris Ostrovsky wrote: > > > On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> >> +void __init kernel_randomize_memory(void) >> +{ >> + size_t i; >> + unsigned long addr = memory_rand_start; >> + unsigned long padding,

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

On Thu, Apr 21, 2016 at 6:30 AM, Boris Ostrovsky wrote: > > > On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> >> +void __init kernel_randomize_memory(void) >> +{ >> + size_t i; >> + unsigned long addr = memory_rand_start; >> + unsigned long padding, rand, mem_tb; >> +

[PATCH v5 1/4] dmaengine: dw: platform: check nr_masters to be non-zero

The nr_masters value equal to 0 is invalid since this DMA controller has to have at least one master. Check this before we proceed with the rest of properties. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/platform.c | 21 +++-- 1 file

[PATCH v5 1/4] dmaengine: dw: platform: check nr_masters to be non-zero

The nr_masters value equal to 0 is invalid since this DMA controller has to have at least one master. Check this before we proceed with the rest of properties. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/platform.c | 21 +++-- 1 file changed, 11 insertions(+), 10

[PATCH v5 4/4] dmaengine: dw: pass platform data via struct dw_dma_chip

We pass struct dw_dma_chip to the dw_dma_probe() anyway, thus we may use it to pass platform data as well. While here, constify the source of platform data. Signed-off-by: Andy Shevchenko --- drivers/ata/sata_dwc_460ex.c | 2 +- drivers/dma/dw/core.c

Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

Hi Ulf, On Thursday 21 Apr 2016 15:52:06 Ulf Hansson wrote: > On 21 April 2016 at 14:41, Laurent Pinchart wrote: > > On Thursday 21 Apr 2016 11:10:19 Ulf Hansson wrote: > >> On 21 April 2016 at 01:30, Laurent Pinchart wrote: > >>> On Monday 07 Mar 2016 11:10:08 Ulf Hansson wrote: > [...] >

[PATCH v5 4/4] dmaengine: dw: pass platform data via struct dw_dma_chip

We pass struct dw_dma_chip to the dw_dma_probe() anyway, thus we may use it to pass platform data as well. While here, constify the source of platform data. Signed-off-by: Andy Shevchenko --- drivers/ata/sata_dwc_460ex.c | 2 +- drivers/dma/dw/core.c | 9 +

Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

Hi Ulf, On Thursday 21 Apr 2016 15:52:06 Ulf Hansson wrote: > On 21 April 2016 at 14:41, Laurent Pinchart wrote: > > On Thursday 21 Apr 2016 11:10:19 Ulf Hansson wrote: > >> On 21 April 2016 at 01:30, Laurent Pinchart wrote: > >>> On Monday 07 Mar 2016 11:10:08 Ulf Hansson wrote: > [...] >

[[PATCH v2] 4/8] ARM: dts: STi: STiH407: Provide CPU with a means to look-up Major number

This is used for CPU Frequency Scaling. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi

[[PATCH v2] 4/8] ARM: dts: STi: STiH407: Provide CPU with a means to look-up Major number

This is used for CPU Frequency Scaling. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi index d0e639cd..eb2601f

Re: [PATCH 1/3] documentation: nvmem: imx-ocotp: Add i.MX6UL support

On Tue, Apr 19, 2016 at 04:59:12PM +0800, Peng Fan wrote: > Add i.MX6UL support in documentation. > > Signed-off-by: Peng Fan > Cc: Srinivas Kandagatla > Cc: Maxime Ripard > Cc: Rob Herring

[[PATCH v2] 2/8] ARM: dts: STi: STiH407: Provide CPU with clocking information

Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi index

Re: [PATCH 1/3] documentation: nvmem: imx-ocotp: Add i.MX6UL support

On Tue, Apr 19, 2016 at 04:59:12PM +0800, Peng Fan wrote: > Add i.MX6UL support in documentation. > > Signed-off-by: Peng Fan > Cc: Srinivas Kandagatla > Cc: Maxime Ripard > Cc: Rob Herring > --- > Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +++-- > 1 file changed, 3

[[PATCH v2] 2/8] ARM: dts: STi: STiH407: Provide CPU with clocking information

Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi index 9fa1e58..af9233b 100644 ---

[[PATCH v2] 8/8] ARM: dts: STi: STih407: Switch LPC mode from RTC to Clocksource

This aligns with the internal configuration. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/stih407-family.dtsi

[[PATCH v2] 8/8] ARM: dts: STi: STih407: Switch LPC mode from RTC to Clocksource

This aligns with the internal configuration. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi

[[PATCH v2] 5/8] ARM: dts: STi: stih407-family: Add nodes for Mailbox

This patch supplies the Mailbox Controller nodes. In order to request channels, these nodes will be referenced by Mailbox Client nodes. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 33

[[PATCH v2] 5/8] ARM: dts: STi: stih407-family: Add nodes for Mailbox

This patch supplies the Mailbox Controller nodes. In order to request channels, these nodes will be referenced by Mailbox Client nodes. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 33 + 1 file changed, 33

[[PATCH v2] 7/8] ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

Doing so saves quite a bit of code in the driver. For more information on the 'reserved-memory' bindings see: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Suggested-by: Suman Anna Signed-off-by: Lee Jones Signed-off-by: Maxime

[[PATCH v2] 7/8] ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory

Doing so saves quite a bit of code in the driver. For more information on the 'reserved-memory' bindings see: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt Suggested-by: Suman Anna Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin ---

[[PATCH v2] 6/8] ARM: dts: STiH407: Add nodes for RemoteProc

Signed-off-by: Ludovic Barre Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 40 +++ 1 file changed, 40 insertions(+) diff --git

[[PATCH v2] 6/8] ARM: dts: STiH407: Add nodes for RemoteProc

Signed-off-by: Ludovic Barre Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 40 +++ 1 file changed, 40 insertions(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi

Re: [PATCH 5/6] leds: pca963x: Inform the output that it is inverted

On Tue, Apr 19, 2016 at 09:40:49AM +0200, Olliver Schinagl wrote: > When leds are connected in a totem-pole configuration, they can be > connected either in a active-high, or active-low manor. The driver > currently always assumes active-high. This patch adds the > 'nxp,inverted-out' boolean

[[PATCH v2] 3/8] ARM: dts: STi: STiH407: Link CPU with its voltage supply

Used for Voltage Scaling using CPUFreq. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi

[[PATCH v2] 3/8] ARM: dts: STi: STiH407: Link CPU with its voltage supply

Used for Voltage Scaling using CPUFreq. Signed-off-by: Lee Jones Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-family.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi index af9233b..d0e639cd

Re: [PATCH 5/6] leds: pca963x: Inform the output that it is inverted

On Tue, Apr 19, 2016 at 09:40:49AM +0200, Olliver Schinagl wrote: > When leds are connected in a totem-pole configuration, they can be > connected either in a active-high, or active-low manor. The driver > currently always assumes active-high. This patch adds the > 'nxp,inverted-out' boolean

Re: [PATCH v2] regulator: core: Add debugfs to show constraint flags

On Thu, Apr 21, 2016 at 01:36:14PM +0100, Richard Fitzgerald wrote: > + ret = snprintf(buf, PAGE_SIZE, > + "always_on: %u\nboot_on: %u\napply_uV: %u\nramp_disable: %u\n" > + "soft_start: %u\npull_down: %u\nover_current_protection: %u\n", > + !!c->always_on,

Re: [PATCH v2] regulator: core: Add debugfs to show constraint flags

On Thu, Apr 21, 2016 at 01:36:14PM +0100, Richard Fitzgerald wrote: > + ret = snprintf(buf, PAGE_SIZE, > + "always_on: %u\nboot_on: %u\napply_uV: %u\nramp_disable: %u\n" > + "soft_start: %u\npull_down: %u\nover_current_protection: %u\n", > + !!c->always_on,

[PATCH v3 3/5] irqchip/gic: Restore CPU interface checking

From: Marc Zyngier When introducing the whole CPU feature detection framework, we lost the capability to detect a mismatched GIC configuration (using the GICv2 MMIO interface, but having the system register interface enabled). In order to solve this, use the new

[PATCH v3 3/5] irqchip/gic: Restore CPU interface checking

From: Marc Zyngier When introducing the whole CPU feature detection framework, we lost the capability to detect a mismatched GIC configuration (using the GICv2 MMIO interface, but having the system register interface enabled). In order to solve this, use the new this_cpu_has_cap() helper. Also

Re: [PATCH v4 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

On Thu, 2016-04-21 at 18:03 +0300, Andy Shevchenko wrote: > This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303. > html) > contains a number of mostly minor fixes and cleanups for the DW DMA > driver. A > couple of them affect the DT binding so these may need to be updated > to >

Re: [PATCH v4 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

On Thu, 2016-04-21 at 18:03 +0300, Andy Shevchenko wrote: > This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303. > html) > contains a number of mostly minor fixes and cleanups for the DW DMA > driver. A > couple of them affect the DT binding so these may need to be updated > to >

[PATCH v4 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303.html) contains a number of mostly minor fixes and cleanups for the DW DMA driver. A couple of them affect the DT binding so these may need to be updated to maintain compatibility (old format is still supported though). The rest

[PATCH v4 0/4] Fixes / cleanups in dw_dmac (affects on few subsystems)

This patch series (v3: http://www.spinics.net/lists/kernel/msg2215303.html) contains a number of mostly minor fixes and cleanups for the DW DMA driver. A couple of them affect the DT binding so these may need to be updated to maintain compatibility (old format is still supported though). The rest

[PATCH v4 4/4] dmaengine: dw: override LLP support if asked in platform data

There is at least one known device, i.e. UART on Intel Galileo, that works unreliably in case of use of multi block transfer support in DMA mode. Override autodetection by user provided data. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/core.c

[PATCH v4 4/4] dmaengine: dw: override LLP support if asked in platform data

There is at least one known device, i.e. UART on Intel Galileo, that works unreliably in case of use of multi block transfer support in DMA mode. Override autodetection by user provided data. Signed-off-by: Andy Shevchenko --- drivers/dma/dw/core.c| 10 +++---

[PATCH v4 3/4] dmaengine: dw: set polarity of handshake interface

Intel Quark UART uses DesignWare DMA IP. Though the DMA IP is connected in such way that handshake interface uses inverted polarity. We have to provide a possibility to set this in the DMA driver when configuring a channel. Introduce a new member of custom slave configuration called 'polarity'

[PATCH v4 1/4] dmaengine: dw: keep copy of custom slave config in dwc

It seems we need to extend custom slave configuration by one more member to support Intel Quart UART. It becomes a burden to manage all members of struct dw_dma_slave one-by-one. Replace set of fields by embedding struct dw_dma_slave into struct dw_dma_chan. Signed-off-by: Andy Shevchenko

[PATCH v4 3/4] dmaengine: dw: set polarity of handshake interface

Intel Quark UART uses DesignWare DMA IP. Though the DMA IP is connected in such way that handshake interface uses inverted polarity. We have to provide a possibility to set this in the DMA driver when configuring a channel. Introduce a new member of custom slave configuration called 'polarity'

[PATCH v4 1/4] dmaengine: dw: keep copy of custom slave config in dwc

It seems we need to extend custom slave configuration by one more member to support Intel Quart UART. It becomes a burden to manage all members of struct dw_dma_slave one-by-one. Replace set of fields by embedding struct dw_dma_slave into struct dw_dma_chan. Signed-off-by: Andy Shevchenko ---

[PATCH v4 2/4] dmaengine: dw: provide probe(), remove() stubs for users

Some users consider DMA optional, thus when driver is not compiled we shouldn't prevent compilation of the users. Add stubs for dw_dma_probe() and dw_dma_remove(). Signed-off-by: Andy Shevchenko --- include/linux/dma/dw.h | 5 + 1 file changed, 5

[PATCH v4 2/4] dmaengine: dw: provide probe(), remove() stubs for users

Some users consider DMA optional, thus when driver is not compiled we shouldn't prevent compilation of the users. Add stubs for dw_dma_probe() and dw_dma_remove(). Signed-off-by: Andy Shevchenko --- include/linux/dma/dw.h | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v3 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

CPU Errata work arounds are detected and applied to the kernel code at boot time and the data is then freed up. If a new hotplugged CPU requires a work around which was not applied at boot time, there is nothing we can do but simply fail the booting. Cc: Will Deacon Cc: Mark

[PATCH v3 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

CPU Errata work arounds are detected and applied to the kernel code at boot time and the data is then freed up. If a new hotplugged CPU requires a work around which was not applied at boot time, there is nothing we can do but simply fail the booting. Cc: Will Deacon Cc: Mark Rutland Cc: Andre

[RESEND PATCH v3] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

Pan Xinhui was asking for a lock holder cpu argument in pv_wait() to help the porting of pvqspinlock to PPC. The new argument will can help hypervisor expediate the execution of the critical section by the lock holder, if its vCPU isn't running, so that it can release the lock sooner. The

[RESEND PATCH v3] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

Pan Xinhui was asking for a lock holder cpu argument in pv_wait() to help the porting of pvqspinlock to PPC. The new argument will can help hypervisor expediate the execution of the critical section by the lock holder, if its vCPU isn't running, so that it can release the lock sooner. The

Re: [PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

On Mon, Apr 18, 2016 at 08:43:16PM +0200, H. Nikolaus Schaller wrote: > This is a driver for the Integrated Silicon Solution Inc. LED driver > chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 > LEDs. > > Each LED is individually controllable in brightness (through pwm) > in 256 steps

Re: [PATCH] drivers: led: is31fl319x: 6/9-channel light effect led driver

On Mon, Apr 18, 2016 at 08:43:16PM +0200, H. Nikolaus Schaller wrote: > This is a driver for the Integrated Silicon Solution Inc. LED driver > chips IS31FL3196 and IS31FL3199. They can drive up to 6 or 9 > LEDs. > > Each LED is individually controllable in brightness (through pwm) > in 256 steps

<    3   4   5   6   7   8   9   10   11   12   >