[PATCH 2/2] Input: migor-ts: mark PM functions as __maybe_unused

The migor touchscreen driver is now available for COMPILE_TEST, so we run into a harmless randconfig warning on ARM when CONFIG_PM is disabled: drivers/input/touchscreen/migor_ts.c:216:12: error: 'migor_ts_resume' defined but not used [-Werror=unused-function]

[PATCH] ps3_gelic: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH 1/2] Input: atmel captouch depends on i2c

The newly added Atmal captouch driver fails to build when CONFIG_I2C is disabled: drivers/input/misc/atmel_captouch.c: In function 'atmel_read': drivers/input/misc/atmel_captouch.c:115:8: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration] This adds an

[PATCH 1/2] Input: atmel captouch depends on i2c

The newly added Atmal captouch driver fails to build when CONFIG_I2C is disabled: drivers/input/misc/atmel_captouch.c: In function 'atmel_read': drivers/input/misc/atmel_captouch.c:115:8: error: implicit declaration of function 'i2c_transfer' [-Werror=implicit-function-declaration] This adds an

Input: two merge window build fixes

Hi Dmitry, I ran into two new build regressions in the input subsystem with today's linux-next, maybe you can apply these fixes before sending off the pull request for v4.7. Arnd [PATCH 1/2] Input: atmel captouch depends on i2c [PATCH 2/2] Input: migor-ts: mark PM functions as

Input: two merge window build fixes

Hi Dmitry, I ran into two new build regressions in the input subsystem with today's linux-next, maybe you can apply these fixes before sending off the pull request for v4.7. Arnd [PATCH 1/2] Input: atmel captouch depends on i2c [PATCH 2/2] Input: migor-ts: mark PM functions as

[PATCH] net:liquidio: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/ethernet/cavium/liquidio/octeon_device.c | 4 +--- 1 file

[PATCH] net:liquidio: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/net/ethernet/cavium/liquidio/octeon_device.c | 4 +--- 1 file changed, 1 insertion(+),

Re: [PATCH 3.12 00/76] 3.12.60-stable review

On 05/19/2016 02:08 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.60 release. There are 76 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by

Re: [PATCH 3.12 00/76] 3.12.60-stable review

On 05/19/2016 02:08 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.60 release. There are 76 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by

[PATCH] mptbase: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/message/fusion/mptbase.c | 3 +-- 1 file changed, 1

[PATCH] mptbase: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/message/fusion/mptbase.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[PATCH] drivers/memstick/core/mspro_block: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/memstick/core/mspro_block.c | 3 +-- 1 file changed, 1

[PATCH] drivers/memstick/core/mspro_block: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/memstick/core/mspro_block.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 03:27 PM, Wanpeng Li wrote: > From: Wanpeng Li > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of dynamic halt-polling, lower-end of message passing workload > latency TCP_RR's poll time < 10us) we can treat it as a short halt,

Re: [PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

On 05/19/2016 03:27 PM, Wanpeng Li wrote: > From: Wanpeng Li > > If an emulated lapic timer will fire soon(in the scope of 10us the > base of dynamic halt-polling, lower-end of message passing workload > latency TCP_RR's poll time < 10us) we can treat it as a short halt, > and poll to wait it

[PATCH] drm/vmwgfx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 7 +++ 1 file changed, 3

[PATCH] drm/vmwgfx: use kmemdup

Use kmemdup when some other buffer is immediately copied into allocated region. It replaces call to allocation followed by memcpy, by a single call to kmemdup. Signed-off-by: Muhammad Falak R Wani --- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 7 +++ 1 file changed, 3 insertions(+), 4

Re: [PATCH v3] xen: add steal_clock support on x86

On 05/19/2016 09:26 AM, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor

Re: [PATCH v3] xen: add steal_clock support on x86

On 05/19/2016 09:26 AM, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Thu, May 19, 2016 at 11:00:13AM +0200, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 10:26:06AM -0700, Paul E. McKenney wrote: > > On Wed, May 18, 2016 at 01:05:55PM +0200, Peter Zijlstra wrote: > > > > Alternatively, could we try and talk to our GCC friends to make sure GCC > > > doesn't

Re: [PATCH v2] locking/rwsem: Add reader-owned state to the owner field

On Thu, May 19, 2016 at 11:00:13AM +0200, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 10:26:06AM -0700, Paul E. McKenney wrote: > > On Wed, May 18, 2016 at 01:05:55PM +0200, Peter Zijlstra wrote: > > > > Alternatively, could we try and talk to our GCC friends to make sure GCC > > > doesn't

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

Re: [PATCH] PM / sleep: fix unbalanced pm runtime disable in __device_suspend_late()

On Fri, May 13, 2016 at 8:03 PM, Grygorii Strashko wrote: > The PM runtime will be left disabled for the device if its .suspend_late() > callback fails and async suspend is not allowed for this device. In > this case device will not be added in dpm_late_early_list and >

Re: [PATCH] PM / sleep: fix unbalanced pm runtime disable in __device_suspend_late()

On Fri, May 13, 2016 at 8:03 PM, Grygorii Strashko wrote: > The PM runtime will be left disabled for the device if its .suspend_late() > callback fails and async suspend is not allowed for this device. In > this case device will not be added in dpm_late_early_list and > dpm_resume_early() will

Re: [Patch]cpuidle: Save current cpu as local variable instead of calling smp_processor_id() in loop

Hi Peterz Thanks a lot for the overwhelming response :) I will look into the change history to have a pervasive understanding of the framework. On Wed, May 18, 2016 at 02:40:52PM +0200, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 02:30:44PM +0200, Peter Zijlstra wrote: > > void cpu_idle

Re: [Patch]cpuidle: Save current cpu as local variable instead of calling smp_processor_id() in loop

Hi Peterz Thanks a lot for the overwhelming response :) I will look into the change history to have a pervasive understanding of the framework. On Wed, May 18, 2016 at 02:40:52PM +0200, Peter Zijlstra wrote: > On Wed, May 18, 2016 at 02:30:44PM +0200, Peter Zijlstra wrote: > > void cpu_idle

Re: [PATCH v5 0/2] Introducing Exynos ChipId driver

Hi Krzysztof, On 16 May 2016 at 18:52, Krzysztof Kozlowski wrote: > > On Thu, Dec 11, 2014 at 9:07 AM, Pankaj Dubey > wrote: > > This patch series introduces Exynos Chipid platform driver. > > Each Exynos SoC has ChipID block which can give

Re: [PATCH v5 0/2] Introducing Exynos ChipId driver

Hi Krzysztof, On 16 May 2016 at 18:52, Krzysztof Kozlowski wrote: > > On Thu, Dec 11, 2014 at 9:07 AM, Pankaj Dubey > wrote: > > This patch series introduces Exynos Chipid platform driver. > > Each Exynos SoC has ChipID block which can give information about SoC's > > product Id and revision

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

On Monday 25 April 2016 22:06:11 Gabriele Mazzotta wrote: > 2016-04-18 14:35 GMT+02:00 Pali Rohár : > > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: > >> On Monday, March 28, 2016 10:33:09 AM Darren Hart wrote: > >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100,

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

On Monday 25 April 2016 22:06:11 Gabriele Mazzotta wrote: > 2016-04-18 14:35 GMT+02:00 Pali Rohár : > > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: > >> On Monday, March 28, 2016 10:33:09 AM Darren Hart wrote: > >> > On Thu, Mar 24, 2016 at 12:24:56PM +0100, Gabriele Mazzotta wrote:

Re: [PATCH] arm: tegra: initial support for apalis tk1

On Mon, 2016-05-16 at 10:55 -0500, Rob Herring wrote: > On Thu, May 12, 2016 at 02:27:12PM +0200, Marcel Ziswiler wrote: > > > > This patch adds the device tree to support Toradex Apalis TK1 a > > computer on module which can be used on different carrier boards. > > > > The module consists of a

Re: [PATCH] arm: tegra: initial support for apalis tk1

On Mon, 2016-05-16 at 10:55 -0500, Rob Herring wrote: > On Thu, May 12, 2016 at 02:27:12PM +0200, Marcel Ziswiler wrote: > > > > This patch adds the device tree to support Toradex Apalis TK1 a > > computer on module which can be used on different carrier boards. > > > > The module consists of a

Re: [PATCH] ARM: lpc32xx: fix NR_IRQS confict

On Thursday 19 May 2016 08:09:29 Sylvain Lemieux wrote: > Hi Arnd, > > On Thu, 2016-05-19 at 13:04 +0300, Vladimir Zapolskiy wrote: > > Hi Arnd, > > > > On 19.05.2016 11:35, Arnd Bergmann wrote: > > > With the change to sparse IRQs, the lpc32xx platform gets a warning about > > > conflicting

Re: [PATCH] ARM: lpc32xx: fix NR_IRQS confict

On Thursday 19 May 2016 08:09:29 Sylvain Lemieux wrote: > Hi Arnd, > > On Thu, 2016-05-19 at 13:04 +0300, Vladimir Zapolskiy wrote: > > Hi Arnd, > > > > On 19.05.2016 11:35, Arnd Bergmann wrote: > > > With the change to sparse IRQs, the lpc32xx platform gets a warning about > > > conflicting

[PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

From: Wanpeng Li If an emulated lapic timer will fire soon(in the scope of 10us the base of dynamic halt-polling, lower-end of message passing workload latency TCP_RR's poll time < 10us) we can treat it as a short halt, and poll to wait it fire, the fire callback

[PATCH v2] KVM: halt-polling: poll if emulated lapic timer will fire soon

From: Wanpeng Li If an emulated lapic timer will fire soon(in the scope of 10us the base of dynamic halt-polling, lower-end of message passing workload latency TCP_RR's poll time < 10us) we can treat it as a short halt, and poll to wait it fire, the fire callback apic_timer_fn() will set

[PATCH v3] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 uses its own mechanism to account for the "stolen" time a thread wasn't able to run due to hypervisor scheduling. Add support in Xen arch independent time handling

Re: [PATCH v2 2/2] ASoC: da7219: Convert driver to use generic device/fwnode functions

On Tue, 2016-05-17 at 11:28 +0100, Adam Thomson wrote: > This change converts the driver from using the of_* functions to using > the device_* and fwnode_* functions for accssing FW related data. > > Signed-off-by: Adam Thomson > Tested-by: Sathyanarayana

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On 18/05/16 20:13, Prakash, Prashanth wrote: On 5/18/2016 11:37 AM, Sudeep Holla wrote: On 17/05/16 18:46, Prakash, Prashanth wrote: Hi Sudeep, On 5/11/2016 9:37 AM, Sudeep Holla wrote: + +static int acpi_processor_get_lpi_info(struct acpi_processor *pr) +{ +int ret, i; +struct

[PATCH v3] xen: add steal_clock support on x86

The pv_time_ops structure contains a function pointer for the "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 uses its own mechanism to account for the "stolen" time a thread wasn't able to run due to hypervisor scheduling. Add support in Xen arch independent time handling

Re: [PATCH v2 2/2] ASoC: da7219: Convert driver to use generic device/fwnode functions

On Tue, 2016-05-17 at 11:28 +0100, Adam Thomson wrote: > This change converts the driver from using the of_* functions to using > the device_* and fwnode_* functions for accssing FW related data. > > Signed-off-by: Adam Thomson > Tested-by: Sathyanarayana Nujella @@ -538,97 +538,96 @@ static

Re: [PATCH v5 2/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

On 18/05/16 20:13, Prakash, Prashanth wrote: On 5/18/2016 11:37 AM, Sudeep Holla wrote: On 17/05/16 18:46, Prakash, Prashanth wrote: Hi Sudeep, On 5/11/2016 9:37 AM, Sudeep Holla wrote: + +static int acpi_processor_get_lpi_info(struct acpi_processor *pr) +{ +int ret, i; +struct

Re: [PATCH v2] xen: add steal_clock support on x86

On 19/05/16 07:43, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. >

Re: [PATCH v2] xen: add steal_clock support on x86

On 19/05/16 07:43, Juergen Gross wrote: > The pv_time_ops structure contains a function pointer for the > "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86 > uses its own mechanism to account for the "stolen" time a thread wasn't > able to run due to hypervisor scheduling. >

Re: [PATCH 2/5] genirq: Allow the affinity of a percpu interrupt to be set/retrieved

Hi Marc, On Thu, May 19, 2016 at 3:13 PM, Marc Zyngier wrote: > On 19/05/16 12:08, Geert Uytterhoeven wrote: >> On Mon, Apr 11, 2016 at 10:57 AM, Marc Zyngier wrote: >>> In order to prepare the genirq layer for the concept of partitionned >>> percpu

Re: [PATCH 2/5] genirq: Allow the affinity of a percpu interrupt to be set/retrieved

Hi Marc, On Thu, May 19, 2016 at 3:13 PM, Marc Zyngier wrote: > On 19/05/16 12:08, Geert Uytterhoeven wrote: >> On Mon, Apr 11, 2016 at 10:57 AM, Marc Zyngier wrote: >>> In order to prepare the genirq layer for the concept of partitionned >>> percpu interrupts, let's allow an affinity to be

Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv wrote: > Hi, > >> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of >> Rafael J. Wysocki >> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after >> boot/resume [cut] >> > That's because of systemd

Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

On Thu, May 19, 2016 at 3:50 AM, Zheng, Lv wrote: > Hi, > >> From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of >> Rafael J. Wysocki >> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after >> boot/resume [cut] >> > That's because of systemd implementation. >> >

Re: [PATCH 1/2] dma-buf/fence: add fence_collection fences

Hi Christian, 2016-05-19 Christian König : > Am 19.05.2016 um 00:57 schrieb Chris Wilson: > > On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote: > > > +static void collection_check_cb_func(struct fence *fence, struct > > > fence_cb *cb) > > > +{ > > > +

Re: [PATCH 1/2] dma-buf/fence: add fence_collection fences

Hi Christian, 2016-05-19 Christian König : > Am 19.05.2016 um 00:57 schrieb Chris Wilson: > > On Wed, May 18, 2016 at 05:59:52PM -0300, Gustavo Padovan wrote: > > > +static void collection_check_cb_func(struct fence *fence, struct > > > fence_cb *cb) > > > +{ > > > + struct fence_collection_cb

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

On Thu, May 19, 2016 at 01:50:40PM +0100, Catalin Marinas wrote: > On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote: > > > > > > 在 2016/5/19 18:49, Catalin Marinas 写道: > > >On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote: > > >>we find that some apps will read cpuinfo when

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

On Thu, May 19, 2016 at 01:50:40PM +0100, Catalin Marinas wrote: > On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote: > > > > > > 在 2016/5/19 18:49, Catalin Marinas 写道: > > >On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote: > > >>we find that some apps will read cpuinfo when

Re: next build: 37 warnings 2 failures (next/next-20160519)

On Thursday 19 May 2016 15:03:34 Kishon Vijay Abraham I wrote: > > > >> 1 drivers/phy/phy-exynos-mipi-video.c:238:13: warning: 'val' may be > >> used uninitialized in this function [-Wmaybe-uninitialized] > > > > I sent a patch on May 11, it was reviewed by Krzysztof Kozlowski, but not >

Re: next build: 37 warnings 2 failures (next/next-20160519)

On Thursday 19 May 2016 15:03:34 Kishon Vijay Abraham I wrote: > > > >> 1 drivers/phy/phy-exynos-mipi-video.c:238:13: warning: 'val' may be > >> used uninitialized in this function [-Wmaybe-uninitialized] > > > > I sent a patch on May 11, it was reviewed by Krzysztof Kozlowski, but not >

Re: next build: 37 warnings 2 failures (next/next-20160519)

On Thursday 19 May 2016 11:20:44 Michal Hocko wrote: > On Thu 19-05-16 11:07:09, Arnd Bergmann wrote: > [...] > > > 6 mm/page_alloc.c:3651:6: warning: 'compact_result' may be used > > > uninitialized in this function [-Wmaybe-uninitialized] > > > > I'm surprised this one is still there, I

Re: next build: 37 warnings 2 failures (next/next-20160519)

On Thursday 19 May 2016 11:20:44 Michal Hocko wrote: > On Thu 19-05-16 11:07:09, Arnd Bergmann wrote: > [...] > > > 6 mm/page_alloc.c:3651:6: warning: 'compact_result' may be used > > > uninitialized in this function [-Wmaybe-uninitialized] > > > > I'm surprised this one is still there, I

Re: [PATCH 2/5] genirq: Allow the affinity of a percpu interrupt to be set/retrieved

Hi Geert, On 19/05/16 12:08, Geert Uytterhoeven wrote: > Hi Marc, > > On Mon, Apr 11, 2016 at 10:57 AM, Marc Zyngier wrote: >> In order to prepare the genirq layer for the concept of partitionned >> percpu interrupts, let's allow an affinity to be associated with >> such

Re: [PATCH 2/5] genirq: Allow the affinity of a percpu interrupt to be set/retrieved

Hi Geert, On 19/05/16 12:08, Geert Uytterhoeven wrote: > Hi Marc, > > On Mon, Apr 11, 2016 at 10:57 AM, Marc Zyngier wrote: >> In order to prepare the genirq layer for the concept of partitionned >> percpu interrupts, let's allow an affinity to be associated with >> such an interrupt. We

Re: [PATCH v3] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Thu, May 19, 2016 at 1:41 AM, Al Stone wrote: > When CPPC is being used by ACPI on arm64, user space tools such as > cpupower report CPU frequency values from sysfs that are incorrect. > > What the driver was doing was reporting the values given by ACPI tables > in whatever

Re: [PATCH v3] Force cppc_cpufreq to report values in KHz to fix user space reporting

On Thu, May 19, 2016 at 1:41 AM, Al Stone wrote: > When CPPC is being used by ACPI on arm64, user space tools such as > cpupower report CPU frequency values from sysfs that are incorrect. > > What the driver was doing was reporting the values given by ACPI tables > in whatever scale was used to

[PATCH] ARM: at91: Documentation: update the sama5d2 entry

Update the Atmel SoC entry for SAMA5D2 with all the product variants. Add the datasheet web link, now that it's available, for instant access to full product documentation. Signed-off-by: Nicolas Ferre --- Documentation/arm/Atmel/README | 10 -- 1 file changed,

Re: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 08:53:17 + "N, Soumya P" wrote: > Hi Steve, > > Could you please explain what this error means? > Is it related to length of subject? > I have run checkpatch.pl on patch and didn't show any error. > > Thanks, > Soumya. > > -Original Message-

[PATCH] ARM: at91: Documentation: update the sama5d2 entry

Update the Atmel SoC entry for SAMA5D2 with all the product variants. Add the datasheet web link, now that it's available, for instant access to full product documentation. Signed-off-by: Nicolas Ferre --- Documentation/arm/Atmel/README | 10 -- 1 file changed, 8 insertions(+), 2

Re: [PATCH] ftrace: As disabling interrupts is costly and write_lock variant of tasklist_lock is not held from interrupt context it is not necessary to disable interrupts.

On Thu, 19 May 2016 08:53:17 + "N, Soumya P" wrote: > Hi Steve, > > Could you please explain what this error means? > Is it related to length of subject? > I have run checkpatch.pl on patch and didn't show any error. > > Thanks, > Soumya. > > -Original Message- > From: Steven

Re: [RESEND PATCH v4] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi, Sorry for the delay but I'm waiting for 4.7-rc1 before taking new NAND patches, and decided to use this time to work on other stuff. On Wed, 18 May 2016 17:10:01 -0500 Kyle Roeschley wrote: > If erasing or writing the BBT fails, we should mark the current BBT > block

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

On 05/19/2016 08:31 PM, Shawn Lin wrote: > Hi, > > On 2016/5/19 1:37, Doug Anderson wrote: >> Hi, >> >> On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: >>> Hi >>> >>> >>> On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17, 2016 at 6:59 PM,

Re: [RESEND PATCH v4] mtd: nand_bbt: scan for next free bbt block if writing bbt fails

Hi, Sorry for the delay but I'm waiting for 4.7-rc1 before taking new NAND patches, and decided to use this time to work on other stuff. On Wed, 18 May 2016 17:10:01 -0500 Kyle Roeschley wrote: > If erasing or writing the BBT fails, we should mark the current BBT > block as bad and use the BBT

Re: [PATCH] mmc: dw_mmc: Consider HLE errors to be data and command errors

On 05/19/2016 08:31 PM, Shawn Lin wrote: > Hi, > > On 2016/5/19 1:37, Doug Anderson wrote: >> Hi, >> >> On Wed, May 18, 2016 at 2:14 AM, Shawn Lin wrote: >>> Hi >>> >>> >>> On 2016-5-18 12:12, Doug Anderson wrote: Hi, On Tue, May 17, 2016 at 6:59 PM, Shawn Lin wrote:

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Thu, May 19, 2016 at 12:41 PM, Zhu Guihua wrote: > Hi Rafael, Hi, > This patch set was reported a kernel panic from Intel LKP team. > I do some investigation for this. I found that this panic was caused > because of Intel test machine. On their machine, the acpi

Re: [PATCH v7 0/5] Make cpuid <-> nodeid mapping persistent

On Thu, May 19, 2016 at 12:41 PM, Zhu Guihua wrote: > Hi Rafael, Hi, > This patch set was reported a kernel panic from Intel LKP team. > I do some investigation for this. I found that this panic was caused > because of Intel test machine. On their machine, the acpi tables has > something wrong.

get_maintainer.pl and MAINTAINERS file

(Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 driver") Robin van der Gracht writes: >> And 4th, what is with the insane number of people on cc:? Use >> get_maintainer.pl correctly please, and don't just hit everyone you >> can possibly think of

get_maintainer.pl and MAINTAINERS file

(Changed the subject from "Re: [PATCH v6 0/3] auxdisplay: Introduce ht16k33 driver") Robin van der Gracht writes: >> And 4th, what is with the insane number of people on cc:? Use >> get_maintainer.pl correctly please, and don't just hit everyone you >> can possibly think of with a cc: for no

Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

Hi Finn, On Thu, May 19, 2016 at 2:02 PM, Finn Thain wrote: > On Thu, 19 May 2016, Geert Uytterhoeven wrote: >> In file included from drivers/scsi/mac_scsi.c:335: >> drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline >> after being called >>

Re: [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation

Hi Finn, On Thu, May 19, 2016 at 2:02 PM, Finn Thain wrote: > On Thu, 19 May 2016, Geert Uytterhoeven wrote: >> In file included from drivers/scsi/mac_scsi.c:335: >> drivers/scsi/NCR5380.h:295: warning: `NCR5380_poll_politely' declared inline >> after being called >> drivers/scsi/NCR5380.h:295:

[PATCH] ARM: dts: at91: add at91sam9260ek board DT

Add Device Tree source file for at91sam9260ek board. This official Atmel Evaluation Kit is designed around a SoC based on a ARM 926 core the at91sam9260. The board is also added to the dts Makefile. Signed-off-by: Nicolas Ferre --- Hi, This DTS file was sitting in my

[PATCH] ARM: dts: at91: add at91sam9260ek board DT

Add Device Tree source file for at91sam9260ek board. This official Atmel Evaluation Kit is designed around a SoC based on a ARM 926 core the at91sam9260. The board is also added to the dts Makefile. Signed-off-by: Nicolas Ferre --- Hi, This DTS file was sitting in my kernel tree for a long

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote: > > > 在 2016/5/19 18:49, Catalin Marinas 写道: > >On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote: > >>we find that some apps will read cpuinfo when start up, > >>they need the string as follows: > >>"Processor : AArch64

Re: [PATCH] arm64: cpuinfo: add AArch64 & elf platform for app compatibility

On Thu, May 19, 2016 at 07:06:40PM +0800, Xiaqing (A) wrote: > > > 在 2016/5/19 18:49, Catalin Marinas 写道: > >On Thu, May 19, 2016 at 10:44:33AM +0800, x00195127 wrote: > >>we find that some apps will read cpuinfo when start up, > >>they need the string as follows: > >>"Processor : AArch64

Re: [PATCH] ARM: at91: Add DT support for Olimex SAM9-L9260 board.

On Thu, May 19, 2016 at 7:28 AM, Nicolas Ferre wrote: > Le 19/05/2016 01:29, Rob Herring a écrit : >> On Wed, May 18, 2016 at 06:02:46PM +0530, Raashid Muhammed wrote: >>> From: Raashid Muhammed >>> >>> sam9-l9260 is a low cost board designed

Re: [PATCH] ARM: at91: Add DT support for Olimex SAM9-L9260 board.

On Thu, May 19, 2016 at 7:28 AM, Nicolas Ferre wrote: > Le 19/05/2016 01:29, Rob Herring a écrit : >> On Wed, May 18, 2016 at 06:02:46PM +0530, Raashid Muhammed wrote: >>> From: Raashid Muhammed >>> >>> sam9-l9260 is a low cost board designed by Olimex. >>> >>> More infomation is available at:

Re: [PATCH v2] skb_array: array based FIFO for skbs

On Thu, 2016-05-19 at 15:15 +0300, Michael S. Tsirkin wrote: > A simple array based FIFO of pointers. Intended for net stack so uses > skbs for type safety, but we can replace with with void * if others find > it useful outside of net stack. > > Signed-off-by: Michael S. Tsirkin

Re: [PATCH v2] skb_array: array based FIFO for skbs

On Thu, 2016-05-19 at 15:15 +0300, Michael S. Tsirkin wrote: > A simple array based FIFO of pointers. Intended for net stack so uses > skbs for type safety, but we can replace with with void * if others find > it useful outside of net stack. > > Signed-off-by: Michael S. Tsirkin > --- > >

Re: drivers/of: crash on boot

On Thu, May 19, 2016 at 6:19 AM, Gavin Shan wrote: > On Wed, May 18, 2016 at 08:51:59PM -0500, Rob Herring wrote: >>On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: >>> On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote:

Re: drivers/of: crash on boot

On Thu, May 19, 2016 at 6:19 AM, Gavin Shan wrote: > On Wed, May 18, 2016 at 08:51:59PM -0500, Rob Herring wrote: >>On Wed, May 18, 2016 at 7:23 PM, Rob Herring wrote: >>> On Wed, May 18, 2016 at 4:26 PM, Rhyland Klein wrote: On 5/18/2016 3:58 PM, Rhyland Klein wrote: > On 5/18/2016

pull-request: wireless-drivers-next 2016-05-13 (take two)

Hi Dave, this the second version of the last pull request to net-next for 4.7, which got postponed due to the recent iwlwifi merge conflict. Now that Linus fixed the merge problem in his tree I actually didn't have to fix anything in my tree anymore. So that's why I still use the same tag as in

pull-request: wireless-drivers-next 2016-05-13 (take two)

Hi Dave, this the second version of the last pull request to net-next for 4.7, which got postponed due to the recent iwlwifi merge conflict. Now that Linus fixed the merge problem in his tree I actually didn't have to fix anything in my tree anymore. So that's why I still use the same tag as in

[RFC PATCHv2] usb: USB Type-C Connector Class

The purpose of this class is to provide unified interface for user space to get the status and basic information about USB Type-C Connectors in the system, control data role swapping, and when USB PD is available, also power role swapping and Alternate Modes. Signed-off-by: Heikki Krogerus

[RFC PATCHv2] usb: USB Type-C Connector Class

The purpose of this class is to provide unified interface for user space to get the status and basic information about USB Type-C Connectors in the system, control data role swapping, and when USB PD is available, also power role swapping and Alternate Modes. Signed-off-by: Heikki Krogerus ---

Re: x86_64, Haswell, unhandled vga irqs before i915 loaded

Ping? Nobody interested? Maybe there is some more appropriate (specialized) place to ask? Any hints appreciated, Thank you. Please CC me, I'm not subscribed. Regards, Nikolai 14.05.2016 11:21, I wrote: Hello all, Some of my motherboards exhibit the [in]famous bug of throwing unwanted (and

Re: x86_64, Haswell, unhandled vga irqs before i915 loaded

Ping? Nobody interested? Maybe there is some more appropriate (specialized) place to ask? Any hints appreciated, Thank you. Please CC me, I'm not subscribed. Regards, Nikolai 14.05.2016 11:21, I wrote: Hello all, Some of my motherboards exhibit the [in]famous bug of throwing unwanted (and

Re: [PATCH 2/2] lightnvm: hold nvm_lock until finish the target creation

On 05/19/2016 08:38 AM, Wenwei Tao wrote: From: Wenwei Tao When create a target, we check whether the target is already exist first. If the answer is no, we release the lock and continue the creation. This cannot prevent concurrent creation of the same target, so hold the

Re: [PATCH 2/2] lightnvm: hold nvm_lock until finish the target creation

On 05/19/2016 08:38 AM, Wenwei Tao wrote: From: Wenwei Tao When create a target, we check whether the target is already exist first. If the answer is no, we release the lock and continue the creation. This cannot prevent concurrent creation of the same target, so hold the lock until finish the

Re: [PATCH] iwlegacy: avoid warning about missing braces

On Thu, May 19, 2016 at 09:58:49AM +0200, Arnd Bergmann wrote: > gcc-6 warns about code in il3945_hw_txq_ctx_free() being > somewhat ambiguous: > > drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit > braces to avoid ambiguous 'else' [-Wparentheses] > > This adds a set

Re: [PATCH] iwlegacy: avoid warning about missing braces

On Thu, May 19, 2016 at 09:58:49AM +0200, Arnd Bergmann wrote: > gcc-6 warns about code in il3945_hw_txq_ctx_free() being > somewhat ambiguous: > > drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit > braces to avoid ambiguous 'else' [-Wparentheses] > > This adds a set

Re: [PATCH 1/2] lightnvm: break the loop when rqd is not null

On 05/19/2016 08:38 AM, Wenwei Tao wrote: From: Wenwei Tao Break the loop when rqd is not null to reduce unnecessary schedule. Signed-off-by: Wenwei Tao --- drivers/lightnvm/rrpc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH 1/2] lightnvm: break the loop when rqd is not null

On 05/19/2016 08:38 AM, Wenwei Tao wrote: From: Wenwei Tao Break the loop when rqd is not null to reduce unnecessary schedule. Signed-off-by: Wenwei Tao --- drivers/lightnvm/rrpc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c

Re: [PATCH 0/3] External Interrupt Controller (EIC) fixes

On Thu, May 19, 2016 at 11:21:22AM +0200, Thomas Gleixner wrote: > On Tue, 17 May 2016, Paul Burton wrote: > > > This series fixes a few small issues with support for External Interrupt > > Controllers (cpu_has_veic), ensuring that it is configured to service > > all interrupts by default & that

Re: [PATCH 0/3] External Interrupt Controller (EIC) fixes

On Thu, May 19, 2016 at 11:21:22AM +0200, Thomas Gleixner wrote: > On Tue, 17 May 2016, Paul Burton wrote: > > > This series fixes a few small issues with support for External Interrupt > > Controllers (cpu_has_veic), ensuring that it is configured to service > > all interrupts by default & that

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