Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

> > Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad > > toggle hotkey (Fn+F4) which is handled transparently to the operating > > system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is > > pressed, touchpad state is properly toggled without any explicit support

[tip:perf/core] perf/x86/intel: Fix MSR_LAST_BRANCH_FROM_x bug when no TSX

Commit-ID: 19fc9ddd61e059cc45464bdf6e8fa304bb94080f Gitweb: http://git.kernel.org/tip/19fc9ddd61e059cc45464bdf6e8fa304bb94080f Author: David Carrillo-Cisneros AuthorDate: Tue, 21 Jun 2016 11:31:11 -0700 Committer: Ingo Molnar CommitDate: Mon, 27 Jun 2016 11:34:19 +0200 perf/x86/intel:

[tip:perf/core] perf/x86/intel: Print LBR support statement after validation

Commit-ID: f09509b9398b23ca53360ca57106555698ec2e93 Gitweb: http://git.kernel.org/tip/f09509b9398b23ca53360ca57106555698ec2e93 Author: David Carrillo-Cisneros AuthorDate: Tue, 21 Jun 2016 11:31:10 -0700 Committer: Ingo Molnar CommitDate: Mon, 27

[tip:perf/core] perf/x86/intel: Print LBR support statement after validation

Commit-ID: f09509b9398b23ca53360ca57106555698ec2e93 Gitweb: http://git.kernel.org/tip/f09509b9398b23ca53360ca57106555698ec2e93 Author: David Carrillo-Cisneros AuthorDate: Tue, 21 Jun 2016 11:31:10 -0700 Committer: Ingo Molnar CommitDate: Mon, 27 Jun 2016 11:34:18 +0200 perf/x86/intel:

[PATCH] mmc: s3cmci: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

[PATCH] video: s3c2410fb: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

[PATCH] video: s3c2410fb: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

[PATCH] mmc: s3cmci: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

Re: BUG?: kernel does not (re)set irq smp_affinity to reboot_cpu

Hi Russell, On 27-06-16 13:31, Russell King - ARM Linux wrote: On Mon, Jun 27, 2016 at 12:55:26PM +0200, Hans de Goede wrote: Hi Russel, On 27-06-16 11:45, Russell King - ARM Linux wrote: On Mon, Jun 27, 2016 at 10:13:05AM +0100, Marc Zyngier wrote: I'm wondering if that's not an effect of

Re: BUG?: kernel does not (re)set irq smp_affinity to reboot_cpu

Hi Russell, On 27-06-16 13:31, Russell King - ARM Linux wrote: On Mon, Jun 27, 2016 at 12:55:26PM +0200, Hans de Goede wrote: Hi Russel, On 27-06-16 11:45, Russell King - ARM Linux wrote: On Mon, Jun 27, 2016 at 10:13:05AM +0100, Marc Zyngier wrote: I'm wondering if that's not an effect of

Re: [PATCH v5 0/9] Output raw touch data via V4L2

On 27/06/2016 13:22, Hans Verkuil wrote: > On 06/27/2016 01:57 PM, Nick Dyer wrote: > 2) Alternatively, if we want to keep using BUF_TYPE_VIDEO_CAPTURE, then: > > - we keep V4L2_CAP_TOUCH which is combined with CAP_VIDEO_CAPTURE (and perhaps > VIDEO_OUTPUT in the future). The CAP_TOUCH just

Re: [PATCH v5 0/9] Output raw touch data via V4L2

On 27/06/2016 13:22, Hans Verkuil wrote: > On 06/27/2016 01:57 PM, Nick Dyer wrote: > 2) Alternatively, if we want to keep using BUF_TYPE_VIDEO_CAPTURE, then: > > - we keep V4L2_CAP_TOUCH which is combined with CAP_VIDEO_CAPTURE (and perhaps > VIDEO_OUTPUT in the future). The CAP_TOUCH just

[PATCH] mtd: nand: s3c2410: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

[PATCH] mtd: nand: s3c2410: Register cpufreq notifier only on S3C24xx

The driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes (ratio between frequencies of ARM's parent clock (fclk) and clock for peripherals remains fixed). This is needed only on S3C24xx platform when cpufreq driver is enabled so limit the ifdef

Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

On Sun, Jun 26, 2016 at 09:41:35AM +0200, Micha?? K??pie?? wrote: > Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad > toggle hotkey (Fn+F4) which is handled transparently to the operating > system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is > pressed,

Re: [PATCH] fujitsu-laptop: Support touchpad toggle hotkey on Skylake-based models

On Sun, Jun 26, 2016 at 09:41:35AM +0200, Micha?? K??pie?? wrote: > Haswell-based Fujitsu laptops (Lifebook E734/E744/E754) have a touchpad > toggle hotkey (Fn+F4) which is handled transparently to the operating > system: while an ACPI notification is sent to FUJ02B1 when Fn+F4 is > pressed,

Re: [PATCH 1/5] sched,time: count actually elapsed irq & softirq time

On Mon, 2016-06-27 at 14:25 +0200, Frederic Weisbecker wrote: > On Wed, Jun 22, 2016 at 10:25:47PM -0400, r...@redhat.com wrote: > > > > From: Rik van Riel > > > > Currently, if there was any irq or softirq time during 'ticks' > > jiffies, the entire period will be accounted as

Re: [PATCH 1/5] sched,time: count actually elapsed irq & softirq time

On Mon, 2016-06-27 at 14:25 +0200, Frederic Weisbecker wrote: > On Wed, Jun 22, 2016 at 10:25:47PM -0400, r...@redhat.com wrote: > > > > From: Rik van Riel > > > > Currently, if there was any irq or softirq time during 'ticks' > > jiffies, the entire period will be accounted as irq or softirq >

Re: [PATCH v5 0/7] da8xx USB PHY (was da8xx USB clocks)

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote: > v5 changes: > > Functionally, nothing has really changed. Just some cleanups based on > feedback. > > * Renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate > * License header matches MODULE_LICENSE in new phy driver applied all

Re: [PATCH v5 0/7] da8xx USB PHY (was da8xx USB clocks)

On Tuesday 10 May 2016 05:09 AM, David Lechner wrote: > v5 changes: > > Functionally, nothing has really changed. Just some cleanups based on > feedback. > > * Renamed "usbphy" to "usb_phy" or "usb-phy" as appropriate > * License header matches MODULE_LICENSE in new phy driver applied all

Re: [PATCH v5 3/7] phy: Add set_mode callback

Hi, On Tuesday 10 May 2016 05:09 AM, David Lechner wrote: > The initial use for this is for PHYs that have a mode related to USB OTG. > There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting > in the USB PHY to override OTG VBUS and ID signals. > > Of course, the enum can be

Re: [PATCH v5 3/7] phy: Add set_mode callback

Hi, On Tuesday 10 May 2016 05:09 AM, David Lechner wrote: > The initial use for this is for PHYs that have a mode related to USB OTG. > There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting > in the USB PHY to override OTG VBUS and ID signals. > > Of course, the enum can be

Re: [PATCH 00/27] Move LRU page reclaim from zones to nodes v7

On 24/06/16 17:50, Mel Gorman wrote: > On Fri, Jun 24, 2016 at 04:35:45PM +1000, Balbir Singh wrote: >>> 1. The residency of a page partially depends on what zone the page was >>>allocated from. This is partially combatted by the fair zone allocation >>>policy but that is a partial

Re: [PATCH 00/27] Move LRU page reclaim from zones to nodes v7

On 24/06/16 17:50, Mel Gorman wrote: > On Fri, Jun 24, 2016 at 04:35:45PM +1000, Balbir Singh wrote: >>> 1. The residency of a page partially depends on what zone the page was >>>allocated from. This is partially combatted by the fair zone allocation >>>policy but that is a partial

Re: [RFC][PATCH 8/8] rtmutex: Fix PI chain order integrity

On Mon, 27 Jun 2016, Peter Zijlstra wrote: > On Wed, Jun 15, 2016 at 08:25:07AM +0100, Juri Lelli wrote: > > I guess it's not that likely, but yes it could potentially happen that a > > waiter is optimistically spinning, depletes its runtime, gets throttled > > and then replenished when still

Re: [RFC][PATCH 8/8] rtmutex: Fix PI chain order integrity

On Mon, 27 Jun 2016, Peter Zijlstra wrote: > On Wed, Jun 15, 2016 at 08:25:07AM +0100, Juri Lelli wrote: > > I guess it's not that likely, but yes it could potentially happen that a > > waiter is optimistically spinning, depletes its runtime, gets throttled > > and then replenished when still

Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands

Hi all, + Marcin, According to Marcin's series of patches "mtd: spi-nor: DUAL/QUAD I/O read modes implementation" and the Spansion/Cypress S25FS512S datasheet, new Cypress QSPI memories no longer supports Fast Read 1-1-2 or Fast Read 1-1-4 but only Fast Read x-2-2 and Fast Read x-4-4. Hence one

Re: [PATCH 7/9] mtd: m25p80: add support of dual and quad spi protocols to all commands

Hi all, + Marcin, According to Marcin's series of patches "mtd: spi-nor: DUAL/QUAD I/O read modes implementation" and the Spansion/Cypress S25FS512S datasheet, new Cypress QSPI memories no longer supports Fast Read 1-1-2 or Fast Read 1-1-4 but only Fast Read x-2-2 and Fast Read x-4-4. Hence one

Re: linux-next: lots of repeated patches in the tpmdd tree

On Mon, Jun 27, 2016 at 09:36:46AM +1000, Stephen Rothwell wrote: > Hi Jarkko, > > I noticed that a large number of the patches in the tpmdd tree appear > twice (and some three times). They appear to have been rebased on top > of the security tree before being remerged. Please clean this all

Re: linux-next: lots of repeated patches in the tpmdd tree

On Mon, Jun 27, 2016 at 09:36:46AM +1000, Stephen Rothwell wrote: > Hi Jarkko, > > I noticed that a large number of the patches in the tpmdd tree appear > twice (and some three times). They appear to have been rebased on top > of the security tree before being remerged. Please clean this all

Re: [PATCH 1/5] sched,time: count actually elapsed irq & softirq time

On Wed, Jun 22, 2016 at 10:25:47PM -0400, r...@redhat.com wrote: > From: Rik van Riel > > Currently, if there was any irq or softirq time during 'ticks' > jiffies, the entire period will be accounted as irq or softirq > time. > > This is inaccurate if only a subset of 'ticks'

Re: [PATCH 1/5] sched,time: count actually elapsed irq & softirq time

On Wed, Jun 22, 2016 at 10:25:47PM -0400, r...@redhat.com wrote: > From: Rik van Riel > > Currently, if there was any irq or softirq time during 'ticks' > jiffies, the entire period will be accounted as irq or softirq > time. > > This is inaccurate if only a subset of 'ticks' jiffies was >

[PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata

[PATCH] sparc64: sparc64_defconfig: convert to use libata PATA drivers

IDE subsystem has been deprecated since 2009 and the majority (if not all) of Linux distributions have switched to use libata for ATA support exclusively. However there are still some users (mostly old or/and embedded non-x86 systems) that have not converted from using IDE subsystem to libata

Re: [PATCH v5 0/9] Output raw touch data via V4L2

On 06/27/2016 01:57 PM, Nick Dyer wrote: > Hi Hans- > > Thanks for reviewing this again in such detail. > > On 27/06/2016 12:26, Hans Verkuil wrote: >> On 06/23/2016 12:08 AM, Nick Dyer wrote: >>> This is a series of patches to add output of raw touch diagnostic data via >>> V4L2 >>> to the

Re: [RFC][PATCH 8/8] rtmutex: Fix PI chain order integrity

On Wed, Jun 15, 2016 at 08:25:07AM +0100, Juri Lelli wrote: > I guess it's not that likely, but yes it could potentially happen that a > waiter is optimistically spinning, depletes its runtime, gets throttled > and then replenished when still spinning. Maybe it doesn't really make > sense

Re: [PATCH v5 0/9] Output raw touch data via V4L2

On 06/27/2016 01:57 PM, Nick Dyer wrote: > Hi Hans- > > Thanks for reviewing this again in such detail. > > On 27/06/2016 12:26, Hans Verkuil wrote: >> On 06/23/2016 12:08 AM, Nick Dyer wrote: >>> This is a series of patches to add output of raw touch diagnostic data via >>> V4L2 >>> to the

Re: [RFC][PATCH 8/8] rtmutex: Fix PI chain order integrity

On Wed, Jun 15, 2016 at 08:25:07AM +0100, Juri Lelli wrote: > I guess it's not that likely, but yes it could potentially happen that a > waiter is optimistically spinning, depletes its runtime, gets throttled > and then replenished when still spinning. Maybe it doesn't really make > sense

Re: [PATCH v2 3/8] mfd: tps65218: Use mfd_add_devices instead of of_platform_populate

On Mon, 27 Jun 2016, Keerthy wrote: > mfd_add_devices enables parsing device tree nodes without compatibles > for child nodes. Replace of_platform_populate with mfd_add_devices. > mfd_cell currently is populated with only regulators. > > Signed-off-by: Keerthy > --- > >

Re: [PATCH v2 3/8] mfd: tps65218: Use mfd_add_devices instead of of_platform_populate

On Mon, 27 Jun 2016, Keerthy wrote: > mfd_add_devices enables parsing device tree nodes without compatibles > for child nodes. Replace of_platform_populate with mfd_add_devices. > mfd_cell currently is populated with only regulators. > > Signed-off-by: Keerthy > --- > > Changes in v2: > > *

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

On Mon, 27 Jun 2016, Keerthy wrote: > Currently read directly calls the repmap read function. Hence > remove the redundant wrapper and use regmap read wherever > needed. > > Signed-off-by: Keerthy > --- > drivers/mfd/tps65218.c | 16 +--- >

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

On Mon, 27 Jun 2016, Keerthy wrote: > Currently read directly calls the repmap read function. Hence > remove the redundant wrapper and use regmap read wherever > needed. > > Signed-off-by: Keerthy > --- > drivers/mfd/tps65218.c | 16 +--- >

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc5 next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Keerthy/mfd-regulator-tps65218-Clean-ups/20160627

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc5 next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Keerthy/mfd-regulator-tps65218-Clean-ups/20160627

Re: [PATCH] devpts: fix null pointer dereference on failed memory allocation

On 26/06/16 19:29, Greg Kroah-Hartman wrote: > On Mon, Jun 20, 2016 at 03:40:27PM +0100, Colin King wrote: >> From: Colin Ian King >> >> An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null >> pointer dereference in devpts_kill_index because

Re: [PATCH] devpts: fix null pointer dereference on failed memory allocation

On 26/06/16 19:29, Greg Kroah-Hartman wrote: > On Mon, Jun 20, 2016 at 03:40:27PM +0100, Colin King wrote: >> From: Colin Ian King >> >> An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null >> pointer dereference in devpts_kill_index because tty->link->driver_data >> is NULL. The

[PATCH 0/2] TIF_MEMDIE usage fixlet

Hi, while I was looking to move TIF_MEMDIE out of the thread info for other purpose I have noticed these two usages which are not correct. I do not think any of them warrant a stable backport because it is highly unlikely they would ever hit but it is better to have them fixed. I would route

[PATCH 1/2] freezer, oom: check TIF_MEMDIE on the correct task

From: Michal Hocko freezing_slow_path is checking TIF_MEMDIE to skip OOM killed tasks. It is, however, checking the flag on the current task rather than the given one. This is really confusing because freezing() can be called also on !current tasks. It would end up working

[PATCH 0/2] TIF_MEMDIE usage fixlet

Hi, while I was looking to move TIF_MEMDIE out of the thread info for other purpose I have noticed these two usages which are not correct. I do not think any of them warrant a stable backport because it is highly unlikely they would ever hit but it is better to have them fixed. I would route

[PATCH 1/2] freezer, oom: check TIF_MEMDIE on the correct task

From: Michal Hocko freezing_slow_path is checking TIF_MEMDIE to skip OOM killed tasks. It is, however, checking the flag on the current task rather than the given one. This is really confusing because freezing() can be called also on !current tasks. It would end up working correctly for its main

[PATCH 2/2] cpuset, mm: fix TIF_MEMDIE check in cpuset_change_task_nodemask

From: Michal Hocko c0ff7453bb5c ("cpuset,mm: fix no node to alloc memory when changing cpuset's mems") has added TIF_MEMDIE and PF_EXITING check but it is checking the flag on the current task rather than the given one. This doesn't make much sense and it is actually wrong. If

[PATCH 2/2] cpuset, mm: fix TIF_MEMDIE check in cpuset_change_task_nodemask

From: Michal Hocko c0ff7453bb5c ("cpuset,mm: fix no node to alloc memory when changing cpuset's mems") has added TIF_MEMDIE and PF_EXITING check but it is checking the flag on the current task rather than the given one. This doesn't make much sense and it is actually wrong. If the current task

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 05:08 -0700, Joe Perches wrote: > On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: > > On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > > > > > > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > > > > > > > From: Daode Huang

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 05:08 -0700, Joe Perches wrote: > On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: > > On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > > > > > > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > > > > > > > From: Daode Huang > > > > > > > > There

Re: [PATCHv3 1/2] usb: USB Type-C connector class

Hi, On Mon, Jun 27, 2016 at 03:51:08PM +0530, Rajaram R wrote: > May be I am missing user or usage of the driver.. I see this driver is > providing limited information of the Type-C connectors or the port > partner Yes, this interface can't provide directly information received from PD commands

Re: [PATCHv3 1/2] usb: USB Type-C connector class

Hi, On Mon, Jun 27, 2016 at 03:51:08PM +0530, Rajaram R wrote: > May be I am missing user or usage of the driver.. I see this driver is > providing limited information of the Type-C connectors or the port > partner Yes, this interface can't provide directly information received from PD commands

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: > On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > > > > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > > > > > From: Daode Huang > > > > > > There are two approaches to assign data, one does

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 15:00 +0300, Andy Shevchenko wrote: > On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > > > > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > > > > > From: Daode Huang > > > > > > There are two approaches to assign data, one does 2 loops, another > > >

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > From: Daode Huang > > > > There are two approaches to assign data, one does 2 loops, another > > does 1 loop. This patch normalize the different methods to

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 04:49 -0700, Joe Perches wrote: > On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > > From: Daode Huang > > > > There are two approaches to assign data, one does 2 loops, another > > does 1 loop. This patch normalize the different methods to 1 loop. > [] > > diff

[PATCH] serial: samsung: Register cpufreq notifier only on S3C24xx

The Samsung serial driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes. This is needed only on S3C24xx platform so limit the ifdef to respective cpufreq driver. On S3C24xx the ratio ratio between frequencies of UART's parent clock (pclk) and

[PATCH] serial: samsung: Register cpufreq notifier only on S3C24xx

The Samsung serial driver registered for CPU frequency transitions to recalculate its clock when ARM clock frequency changes. This is needed only on S3C24xx platform so limit the ifdef to respective cpufreq driver. On S3C24xx the ratio ratio between frequencies of UART's parent clock (pclk) and

Re: [PATCH v5 0/9] Output raw touch data via V4L2

Hi Hans- Thanks for reviewing this again in such detail. On 27/06/2016 12:26, Hans Verkuil wrote: > On 06/23/2016 12:08 AM, Nick Dyer wrote: >> This is a series of patches to add output of raw touch diagnostic data via >> V4L2 >> to the Atmel maXTouch and Synaptics RMI4 drivers. >> >> It's a

Re: [PATCH v5 0/9] Output raw touch data via V4L2

Hi Hans- Thanks for reviewing this again in such detail. On 27/06/2016 12:26, Hans Verkuil wrote: > On 06/23/2016 12:08 AM, Nick Dyer wrote: >> This is a series of patches to add output of raw touch diagnostic data via >> V4L2 >> to the Atmel maXTouch and Synaptics RMI4 drivers. >> >> It's a

[PATCH] drm/i915: fix build errors when ACPI is not enabled

From: Randy Dunlap Fix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister'

[PATCH] drm/i915: fix build errors when ACPI is not enabled

From: Randy Dunlap Fix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister'

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc5 next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Keerthy/mfd-regulator-tps65218-Clean-ups/20160627

Re: [PATCH v2 1/8] mfd: tps65218: Remove redundant read wrapper

Hi, [auto build test ERROR on robh/for-next] [also build test ERROR on v4.7-rc5 next-20160624] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Keerthy/mfd-regulator-tps65218-Clean-ups/20160627

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > From: Daode Huang > > There are two approaches to assign data, one does 2 loops, another > does 1 loop. This patch normalize the different methods to 1 loop. [] > diff --git

Re: [PATCH net-next 6/9] net: hns: normalize two different loop

On Mon, 2016-06-27 at 17:54 +0800, Yisen Zhuang wrote: > From: Daode Huang > > There are two approaches to assign data, one does 2 loops, another > does 1 loop. This patch normalize the different methods to 1 loop. [] > diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c >

Re: BUG?: kernel does not (re)set irq smp_affinity to reboot_cpu

On Mon, Jun 27, 2016 at 12:31:43PM +0100, Russell King - ARM Linux wrote: > On Mon, Jun 27, 2016 at 12:55:26PM +0200, Hans de Goede wrote: > > Hi Russel, Btw, please take note of how my name is spelt. Thanks. > Only if we accept that pm_power_off() should be called with IRQs > enabled, which we

Re: BUG?: kernel does not (re)set irq smp_affinity to reboot_cpu

On Mon, Jun 27, 2016 at 12:31:43PM +0100, Russell King - ARM Linux wrote: > On Mon, Jun 27, 2016 at 12:55:26PM +0200, Hans de Goede wrote: > > Hi Russel, Btw, please take note of how my name is spelt. Thanks. > Only if we accept that pm_power_off() should be called with IRQs > enabled, which we

Re: [PATCH] mmc: core: add auto bkops support

Hi Ulf and Adrian, On 6/27/16, 12:08 PM, "Ulf Hansson" wrote: >[...] > If I am not wrong, in current implementation of runtime suspend, the driver stops BKOPS (send HPI) just before sending sleep command, see _mmc_suspend(), depends on

Re: [PATCH] mmc: core: add auto bkops support

Hi Ulf and Adrian, On 6/27/16, 12:08 PM, "Ulf Hansson" wrote: >[...] > If I am not wrong, in current implementation of runtime suspend, the driver stops BKOPS (send HPI) just before sending sleep command, see _mmc_suspend(), depends on “MMC_CAP_AGGRESSIVE_PM” flag. In this

[PATCH 1/1] regulator: max77620: check for valid regulator info

Check for valid regulator information data before configuring FPS source and FPS power up/down period to avoid NULL pointer exception if entries for PMIC regulators not provided through device tree. SD4 regulator is not supported by MAX77620 PMIC, removing SD4 entry from regulator information

[PATCH 1/1] regulator: max77620: check for valid regulator info

Check for valid regulator information data before configuring FPS source and FPS power up/down period to avoid NULL pointer exception if entries for PMIC regulators not provided through device tree. SD4 regulator is not supported by MAX77620 PMIC, removing SD4 entry from regulator information

[PATCH v2] sched/fair: avoid !CONFIG_SMP cpufreq update callbacks for !root cfs_rq

This is to avoid cpufreq update callbacks for for !root cgroups when !CONFIG_SMP Signed-off-by: Jisheng Zhang --- Since v1: -fix commit msg, now I really know what the check is for, thank Peter kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[PATCH v2] sched/fair: avoid !CONFIG_SMP cpufreq update callbacks for !root cfs_rq

This is to avoid cpufreq update callbacks for for !root cgroups when !CONFIG_SMP Signed-off-by: Jisheng Zhang --- Since v1: -fix commit msg, now I really know what the check is for, thank Peter kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH] memory:bugxfix panic on cat or write /dev/kmem

On Sat 25-06-16 09:20:06, Chenjie (K) wrote: > > > On 2016/6/23 20:42, Michal Hocko wrote: > > On Fri 24-06-16 01:30:10, chenj...@huawei.com wrote: > > > From: chenjie > > > > > > cat /dev/kmem and echo > /dev/kmem will lead panic > > > > Writing to /dev/kmem without

Re: [PATCH] memory:bugxfix panic on cat or write /dev/kmem

On Sat 25-06-16 09:20:06, Chenjie (K) wrote: > > > On 2016/6/23 20:42, Michal Hocko wrote: > > On Fri 24-06-16 01:30:10, chenj...@huawei.com wrote: > > > From: chenjie > > > > > > cat /dev/kmem and echo > /dev/kmem will lead panic > > > > Writing to /dev/kmem without being extremely careful

Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Mon, 27 Jun 2016, Pavel Machek wrote: > I believe you want "whenever source of function A influenced code in > function B, I want to be notified", and I believe it should be > documented as such. Well, exactly. IPA is a group of optimizations that are, by definition, intra-prodcedural. --

Re: [PATCH] Disable non-ABI-compliant optimisations for live patching

On Mon, 27 Jun 2016, Pavel Machek wrote: > I believe you want "whenever source of function A influenced code in > function B, I want to be notified", and I believe it should be > documented as such. Well, exactly. IPA is a group of optimizations that are, by definition, intra-prodcedural. --

Re: next build: 142 builds: 6 failed, 136 passed, 17 errors, 111 warnings (next-20160624)

On Friday, June 24, 2016 2:28:59 PM CEST kernelci. org bot wrote: > > Errors summary: > > 3 arch/arm/include/asm/jump_label.h:13:7: error: impossible constraint > in 'asm' > 66 arch/arm/include/asm/jump_label.h:13:7: warning: asm operand 0 > probably doesn't match constraints

[PATCH 3/3] extcon: Add resource-managed functions to register extcon notifier

This patch adds the resource-managed functions for register/unregister the extcon notifier with the id of each external connector. This function will make it easy to handle the extcon notifier. - int devm_extcon_register_notifier(struct device *dev, struct

Re: next build: 142 builds: 6 failed, 136 passed, 17 errors, 111 warnings (next-20160624)

On Friday, June 24, 2016 2:28:59 PM CEST kernelci. org bot wrote: > > Errors summary: > > 3 arch/arm/include/asm/jump_label.h:13:7: error: impossible constraint > in 'asm' > 66 arch/arm/include/asm/jump_label.h:13:7: warning: asm operand 0 > probably doesn't match constraints

[PATCH 3/3] extcon: Add resource-managed functions to register extcon notifier

This patch adds the resource-managed functions for register/unregister the extcon notifier with the id of each external connector. This function will make it easy to handle the extcon notifier. - int devm_extcon_register_notifier(struct device *dev, struct

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On 27/06/16 12:20, Michael Ellerman wrote: > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: >> On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: >>> On 26/06/16 05:19, Michael Ellerman wrote: On Fri, 2016-24-06 at 17:43:00 UTC, Colin King wrote: > trivial fix to spelling

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On 27/06/16 12:20, Michael Ellerman wrote: > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: >> On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: >>> On 26/06/16 05:19, Michael Ellerman wrote: On Fri, 2016-24-06 at 17:43:00 UTC, Colin King wrote: > trivial fix to spelling

[PATCH 0/3] extcon: Refactoring the core and add resource-managed functions for notifier

This patch-set are refactoring the extcon core without the modification of operation. The struct extcon_cabe moves from header file to extcon core and make the new devres.c driver which only handles the resource-managed functions. Lastly, this patch-set add resource-managed functions for extcon

[PATCH 1/3] extcon: Move struct extcon_cable from header file to core

This patch moves the struct extcon_cable because that should be only handled by extcon core. There are no reason to publish the internal structure. Signed-off-by: Chanwoo Choi --- drivers/extcon/extcon.c | 20 include/linux/extcon.h | 20

[PATCH 2/3] extcon: Split out the resource-managed functions from extcon core

This patch split out the resource-managed related functions from extcon core driver. Signed-off-by: Chanwoo Choi --- drivers/extcon/Makefile | 2 +- drivers/extcon/devres.c | 143 drivers/extcon/extcon.c | 117

[PATCH 1/3] extcon: Move struct extcon_cable from header file to core

This patch moves the struct extcon_cable because that should be only handled by extcon core. There are no reason to publish the internal structure. Signed-off-by: Chanwoo Choi --- drivers/extcon/extcon.c | 20 include/linux/extcon.h | 20 2 files

[PATCH 2/3] extcon: Split out the resource-managed functions from extcon core

This patch split out the resource-managed related functions from extcon core driver. Signed-off-by: Chanwoo Choi --- drivers/extcon/Makefile | 2 +- drivers/extcon/devres.c | 143 drivers/extcon/extcon.c | 117

[PATCH 0/3] extcon: Refactoring the core and add resource-managed functions for notifier

This patch-set are refactoring the extcon core without the modification of operation. The struct extcon_cabe moves from header file to extcon core and make the new devres.c driver which only handles the resource-managed functions. Lastly, this patch-set add resource-managed functions for extcon

Re: [PATCH 1/2] drm: Add drm driver for OpenCores VGA/LCD display controller

On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote: >> This driver supports the VGA/LCD core available from OpenCores: >> http://opencores.org/project,vga_lcd >> >> It's intended as a replacement for the "ocfb"

Re: [PATCH] ARM: s3c64xx: avoid warning about 'struct device_node'

On 06/27/2016 01:02 PM, Arnd Bergmann wrote: > The change to simplify of_platform_populate() had an unintended > side-effect of introducing a build warning on s3c64xx: > > In file included from arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:18:0: > arch/arm/mach-s3c64xx/common.h:27:30: error: 'struct

Re: [PATCH 1/2] drm: Add drm driver for OpenCores VGA/LCD display controller

On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote: >> This driver supports the VGA/LCD core available from OpenCores: >> http://opencores.org/project,vga_lcd >> >> It's intended as a replacement for the "ocfb" framebuffer driver

Re: [PATCH] ARM: s3c64xx: avoid warning about 'struct device_node'

On 06/27/2016 01:02 PM, Arnd Bergmann wrote: > The change to simplify of_platform_populate() had an unintended > side-effect of introducing a build warning on s3c64xx: > > In file included from arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c:18:0: > arch/arm/mach-s3c64xx/common.h:27:30: error: 'struct

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On Mon, 2016-06-27 at 21:20 +1000, Michael Ellerman wrote: > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: > > > > On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: > > > > > > On 26/06/16 05:19, Michael Ellerman wrote: > > > > > > > > On Fri, 2016-24-06 at 17:43:00 UTC, Colin

Re: powerpc/fadump: trivial fix of spelling mistake, clean up message

On Mon, 2016-06-27 at 21:20 +1000, Michael Ellerman wrote: > On Mon, 2016-06-27 at 03:51 -0700, Joe Perches wrote: > > > > On Mon, 2016-06-27 at 11:38 +0100, Colin Ian King wrote: > > > > > > On 26/06/16 05:19, Michael Ellerman wrote: > > > > > > > > On Fri, 2016-24-06 at 17:43:00 UTC, Colin

<    6   7   8   9   10   11   12   13   14   15   >