RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> On 01/11/17 15:12, Winkler, Tomas wrote: > > >>> On 01/11/17 10:24, Winkler, Tomas wrote: > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote: > >> On older platforms the command should be just ignored by the > >> firmware but some older platforms misbehave so

[PATCH v4 1/4] signals, sparc: Add signal codes for ADI violations

SPARC M7 processor introduces a new feature - Application Data Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. When a rogue access occurs, MMU blocks the access and raises an exception. In response to the exception, kernel sends the offending task a SIGSEGV with si_code that

RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> On 01/11/17 15:12, Winkler, Tomas wrote: > > >>> On 01/11/17 10:24, Winkler, Tomas wrote: > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote: > >> On older platforms the command should be just ignored by the > >> firmware but some older platforms misbehave so

[PATCH v4 1/4] signals, sparc: Add signal codes for ADI violations

SPARC M7 processor introduces a new feature - Application Data Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. When a rogue access occurs, MMU blocks the access and raises an exception. In response to the exception, kernel sends the offending task a SIGSEGV with si_code that

[PATCH v4 3/4] sparc64: Add support for ADI register fields, ASIs and traps

SPARC M7 processor adds new control register fields, ASIs and a new trap to support the ADI (Application Data Integrity) feature. This patch adds definitions for these register fields, ASIs and a handler for the new precise memory corruption detected trap. Signed-off-by: Khalid Aziz

[PATCH v4 3/4] sparc64: Add support for ADI register fields, ASIs and traps

SPARC M7 processor adds new control register fields, ASIs and a new trap to support the ADI (Application Data Integrity) feature. This patch adds definitions for these register fields, ASIs and a handler for the new precise memory corruption detected trap. Signed-off-by: Khalid Aziz Cc: Khalid

Re: [PATCH] mm: Ignore __GFP_NOWARN when reporting stalls

On Wed 11-01-17 19:55:20, Tetsuo Handa wrote: > Currently, warn_alloc() prints warning messages only if __GFP_NOWARN > is not specified. When warn_alloc() was proposed, I asserted that > warn_alloc() should print stall warning messages even if __GFP_NOWARN > is specified, but that assertion was

Re: [PATCH] mm: Ignore __GFP_NOWARN when reporting stalls

On Wed 11-01-17 19:55:20, Tetsuo Handa wrote: > Currently, warn_alloc() prints warning messages only if __GFP_NOWARN > is not specified. When warn_alloc() was proposed, I asserted that > warn_alloc() should print stall warning messages even if __GFP_NOWARN > is specified, but that assertion was

Re: [PATCH/RESEND v2 1/5] z3fold: make pages_nr atomic

On Wed, Jan 11, 2017 at 10:06 AM, Vitaly Wool wrote: > This patch converts pages_nr per-pool counter to atomic64_t. > > Signed-off-by: Vitaly Wool Acked-by: Dan Streetman > --- > mm/z3fold.c | 20 +--- > 1 file

Re: [PATCH v3 0/5] fbtft: make it work with DMA enabled SPI

Den 11.01.2017 15:43, skrev Andy Shevchenko: On Tue, 2017-01-03 at 20:29 +0200, Andy Shevchenko wrote: This series enables 64x48 OLED display and fixes the driver to work with DMA enabled SPI properly. Has been tested on Intel Edison board with Adafruit 2'8" and SSD1306 64x48 (Sparkfun for

Re: [PATCH/RESEND v2 1/5] z3fold: make pages_nr atomic

On Wed, Jan 11, 2017 at 10:06 AM, Vitaly Wool wrote: > This patch converts pages_nr per-pool counter to atomic64_t. > > Signed-off-by: Vitaly Wool Acked-by: Dan Streetman > --- > mm/z3fold.c | 20 +--- > 1 file changed, 9 insertions(+), 11 deletions(-) > > diff --git

Re: [PATCH v3 0/5] fbtft: make it work with DMA enabled SPI

Den 11.01.2017 15:43, skrev Andy Shevchenko: On Tue, 2017-01-03 at 20:29 +0200, Andy Shevchenko wrote: This series enables 64x48 OLED display and fixes the driver to work with DMA enabled SPI properly. Has been tested on Intel Edison board with Adafruit 2'8" and SSD1306 64x48 (Sparkfun for

Re: [PATCH 04/15] video: fbdev: use permission-specific DEVICE_ATTR variants

Hi, On Saturday, October 29, 2016 09:36:58 PM Julia Lawall wrote: > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > > The semantic patch that makes this change is as follows: >

Re: [PATCH 04/15] video: fbdev: use permission-specific DEVICE_ATTR variants

Hi, On Saturday, October 29, 2016 09:36:58 PM Julia Lawall wrote: > Use DEVICE_ATTR_RW for read-write attributes. This simplifies the > source code, improves readbility, and reduces the chance of > inconsistencies. > > The semantic patch that makes this change is as follows: >

Re: [PATCH 2/2] btrfs: drop gfp mask tweaking in try_release_extent_state

On Mon, Jan 09, 2017 at 03:39:03PM +0100, Michal Hocko wrote: > From: Michal Hocko > > try_release_extent_state reduces the gfp mask to GFP_NOFS if it is > compatible. This is true for GFP_KERNEL as well. There is no real > reason to do that though. There is no new lock taken

Re: Perf hotplug lockup in v4.9-rc8

On Wed, Jan 11, 2017 at 02:59:20PM +, Mark Rutland wrote: > Hi Peter, > > Sorry for the delay; this fell into my backlog over the holiday. > > On Fri, Dec 09, 2016 at 02:59:00PM +0100, Peter Zijlstra wrote: > > So while I went back and forth trying to make that less ugly, I figured > > there

Re: [PATCH 2/2] btrfs: drop gfp mask tweaking in try_release_extent_state

On Mon, Jan 09, 2017 at 03:39:03PM +0100, Michal Hocko wrote: > From: Michal Hocko > > try_release_extent_state reduces the gfp mask to GFP_NOFS if it is > compatible. This is true for GFP_KERNEL as well. There is no real > reason to do that though. There is no new lock taken down the > the only

Re: Perf hotplug lockup in v4.9-rc8

On Wed, Jan 11, 2017 at 02:59:20PM +, Mark Rutland wrote: > Hi Peter, > > Sorry for the delay; this fell into my backlog over the holiday. > > On Fri, Dec 09, 2016 at 02:59:00PM +0100, Peter Zijlstra wrote: > > So while I went back and forth trying to make that less ugly, I figured > > there

Re: [PATCH] tools: gpio add .gitignore for generated files

On 01/11/2017 08:19 AM, Linus Walleij wrote: > On Tue, Jan 10, 2017 at 3:07 PM, Shuah Khan wrote: >> On 01/10/2017 02:29 AM, Linus Walleij wrote: >>> On Thu, Jan 5, 2017 at 10:32 PM, Shuah Khan wrote: >>> Add .gitignore for generated files.

[PATCH 2/3] perf/x86/amd/uncore: Dynamically allocate uncore counters

This patch updates the AMD uncore driver to support AMD Family17h processors. In Family17h, there are two extra last level cache counters. The counters are, therefore, allocated dynamically based on the family. The cpu hotplug up callback function is refactored to better manage failure

[PATCH 3/3] perf/x86/amd/uncore: Update sysfs attributes for Family17h processors

This patch updates the sysfs attributes for AMD Family17h processors. In Family17h, the event bit position is changed for both the NorthBridge and Last level cache counters. The sysfs attributes are assigned based on the family and the type of the counter. Signed-off-by: Janakarajan Natarajan

Re: [PATCH] tools: gpio add .gitignore for generated files

On 01/11/2017 08:19 AM, Linus Walleij wrote: > On Tue, Jan 10, 2017 at 3:07 PM, Shuah Khan wrote: >> On 01/10/2017 02:29 AM, Linus Walleij wrote: >>> On Thu, Jan 5, 2017 at 10:32 PM, Shuah Khan wrote: >>> Add .gitignore for generated files. Signed-off-by: Shuah Khan ---

[PATCH 2/3] perf/x86/amd/uncore: Dynamically allocate uncore counters

This patch updates the AMD uncore driver to support AMD Family17h processors. In Family17h, there are two extra last level cache counters. The counters are, therefore, allocated dynamically based on the family. The cpu hotplug up callback function is refactored to better manage failure

[PATCH 3/3] perf/x86/amd/uncore: Update sysfs attributes for Family17h processors

This patch updates the sysfs attributes for AMD Family17h processors. In Family17h, the event bit position is changed for both the NorthBridge and Last level cache counters. The sysfs attributes are assigned based on the family and the type of the counter. Signed-off-by: Janakarajan Natarajan

[PATCH 1/3] perf/x86/amd/uncore: Update AMD uncore to rename L2 to LLC

This patch renames L2 counters to LLC counters. In AMD Family17h processors, L3 cache counter is supported. Since older families have at most L2 counters, last level cache (LLC) indicates L2/L3 based on the family. Signed-off-by: Janakarajan Natarajan ---

[PATCH 0/3] perf/x86/amd/uncore: Update AMD uncore driver

This patchset updates the AMD uncore driver to support AMD Family17h processors. First, the current L2 counters are renamed to Last level cache (LLC) counter to reflect either L2 or L3 counters depending on the family. Then, it also dynamically allocates the counters since they vary between

[PATCH 1/3] perf/x86/amd/uncore: Update AMD uncore to rename L2 to LLC

This patch renames L2 counters to LLC counters. In AMD Family17h processors, L3 cache counter is supported. Since older families have at most L2 counters, last level cache (LLC) indicates L2/L3 based on the family. Signed-off-by: Janakarajan Natarajan --- arch/x86/events/amd/uncore.c | 98

[PATCH 0/3] perf/x86/amd/uncore: Update AMD uncore driver

This patchset updates the AMD uncore driver to support AMD Family17h processors. First, the current L2 counters are renamed to Last level cache (LLC) counter to reflect either L2 or L3 counters depending on the family. Then, it also dynamically allocates the counters since they vary between

[RESEND PATCH v5] arm64: dts: qcom: Add msm8916 CoreSight components

From: "Ivan T. Ivanov" Add initial set of CoreSight components found on Qualcomm msm8916 and apq8016 based platforms, including the DragonBoard 410c board. Signed-off-by: Ivan T. Ivanov Acked-by: Mathieu Poirier

[RESEND PATCH v5] arm64: dts: qcom: Add msm8916 CoreSight components

From: "Ivan T. Ivanov" Add initial set of CoreSight components found on Qualcomm msm8916 and apq8016 based platforms, including the DragonBoard 410c board. Signed-off-by: Ivan T. Ivanov Acked-by: Mathieu Poirier Signed-off-by: Georgi Djakov --- Changes since v4:

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 01/11/2017, 04:56 PM, Bronek Kozicki wrote: > On 11/01/2017 15:50, Jiri Slaby wrote: >> On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: >>> Hello, >>> >>> any particular reason why this fix >>>

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 01/11/2017, 04:56 PM, Bronek Kozicki wrote: > On 11/01/2017 15:50, Jiri Slaby wrote: >> On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: >>> Hello, >>> >>> any particular reason why this fix >>>

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 11/01/2017 15:50, Jiri Slaby wrote: On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: Hello, any particular reason why this fix https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 was missed from stable 4.8 line? Apparently the

Re: [PATCH] afs: correctly use 64-bit time for UUID

On Wednesday, January 11, 2017 2:47:20 PM CET David Howells wrote: > Arnd Bergmann wrote: > > > > Is it worth abstracting out in-kernel UUID generation? > > > > Do you mean moving it out of AFS into lib/*.c? I think the 'afs_uuid' > > structure is quite different from other UUID

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 11/01/2017 15:50, Jiri Slaby wrote: On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: Hello, any particular reason why this fix https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 was missed from stable 4.8 line? Apparently the

Re: [PATCH] afs: correctly use 64-bit time for UUID

On Wednesday, January 11, 2017 2:47:20 PM CET David Howells wrote: > Arnd Bergmann wrote: > > > > Is it worth abstracting out in-kernel UUID generation? > > > > Do you mean moving it out of AFS into lib/*.c? I think the 'afs_uuid' > > structure is quite different from other UUID definitions, so

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

Grygorii, On 10/01/17 22:00, Grygorii Strashko wrote: > Hi > > On 01/10/2017 06:18 AM, Roger Quadros wrote: >> Hi Linus, >> >> I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. >> >> reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to >> fix it. >> >>

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

Grygorii, On 10/01/17 22:00, Grygorii Strashko wrote: > Hi > > On 01/10/2017 06:18 AM, Roger Quadros wrote: >> Hi Linus, >> >> I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. >> >> reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to >> fix it. >> >>

Re: [PATCH v2] net: netcp: correct netcp_get_stats function signature

From: Keerthy Date: Wed, 11 Jan 2017 09:03:29 +0530 > Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function > and > Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits. > > The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old >

Re: [PATCH v2] net: netcp: correct netcp_get_stats function signature

From: Keerthy Date: Wed, 11 Jan 2017 09:03:29 +0530 > Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function > and > Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits. > > The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old > signature which causes

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

On 11/01/17 17:38, Linus Walleij wrote: > On Tue, Jan 10, 2017 at 1:18 PM, Roger Quadros wrote: > >> Hi Linus, >> >> I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. >> >> reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to >> fix it. >

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

On 11/01/17 17:38, Linus Walleij wrote: > On Tue, Jan 10, 2017 at 1:18 PM, Roger Quadros wrote: > >> Hi Linus, >> >> I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. >> >> reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to >> fix it. > > I sent out a

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

On Wed 11-01-17 08:52:50, Minchan Kim wrote: [...] > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct > > if (!file && !total_swap_pages) > > return false; > > > > - inactive = lruvec_lru_size(lruvec, file * LRU_FILE); > > - active = lruvec_lru_size(lruvec,

Re: + mm-vmscan-add-mm_vmscan_inactive_list_is_low-tracepoint.patch added to -mm tree

On Wed 11-01-17 08:52:50, Minchan Kim wrote: [...] > > @@ -2055,8 +2055,8 @@ static bool inactive_list_is_low(struct > > if (!file && !total_swap_pages) > > return false; > > > > - inactive = lruvec_lru_size(lruvec, file * LRU_FILE); > > - active = lruvec_lru_size(lruvec,

Re: [PATCH 2/2] gpio: davinci: Remove gpio2regs function to accommodate multi instances

On Wed, Jan 11, 2017 at 1:40 PM, Keerthy wrote: > On Wednesday 11 January 2017 04:34 PM, Linus Walleij wrote: >> On Wed, Jan 4, 2017 at 9:26 AM, Keerthy wrote: >> >>> gpio2regs is written making an assumption that driver supports only >>> one instance of gpio

Re: [PATCH 2/2] gpio: davinci: Remove gpio2regs function to accommodate multi instances

On Wed, Jan 11, 2017 at 1:40 PM, Keerthy wrote: > On Wednesday 11 January 2017 04:34 PM, Linus Walleij wrote: >> On Wed, Jan 4, 2017 at 9:26 AM, Keerthy wrote: >> >>> gpio2regs is written making an assumption that driver supports only >>> one instance of gpio controller. Removing this and adding

Re: [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions

From: Arnd Bergmann Date: Wed, 11 Jan 2017 15:36:09 +0100 > There are lots of #ifdefs in this file, and a recent patch got one > of them wrong, leading to a harmless warning in some randconfig > builds: > > ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics'

Re: [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions

From: Arnd Bergmann Date: Wed, 11 Jan 2017 15:36:09 +0100 > There are lots of #ifdefs in this file, and a recent patch got one > of them wrong, leading to a harmless warning in some randconfig > builds: > > ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics' > defined but

[PATCHv2 1/2] iio: Documentation: Add proximity unit

To follow iio guidelines Where possible we stick to the raw SI unit, so specify meters for proximity. Signed-off-by: Enric Balletbo i Serra --- Documentation/ABI/testing/sysfs-bus-iio | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCHv2 1/2] iio: Documentation: Add proximity unit

To follow iio guidelines Where possible we stick to the raw SI unit, so specify meters for proximity. Signed-off-by: Enric Balletbo i Serra --- Documentation/ABI/testing/sysfs-bus-iio | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/ABI/testing/sysfs-bus-iio

[PATCHv2 2/2] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

From: Gwendal Grignou Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. Creates an IIO device for each functions. Signed-off-by: Gwendal Grignou Signed-off-by: Guenter Roeck Signed-off-by: Enric

Re: [PATCH v6] drm: add fourcc codes for 16bit R and RG

On 17-01-11 17:05:04, Ville Syrjälä wrote: On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote: Am 05.01.2017 um 12:37 schrieb Ville Syrjälä: > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote: >> From: Rainer Hochecker >> >> This adds fourcc

[PATCHv2 2/2] iio: cros_ec_light_prox: add ChromeOS EC Light and Proximity Sensors

From: Gwendal Grignou Handle Light and Proximity sensors presented by the ChromeOS EC Sensor hub. Creates an IIO device for each functions. Signed-off-by: Gwendal Grignou Signed-off-by: Guenter Roeck Signed-off-by: Enric Balletbo i Serra --- drivers/iio/common/cros_ec_sensors/Kconfig

Re: [PATCH v6] drm: add fourcc codes for 16bit R and RG

On 17-01-11 17:05:04, Ville Syrjälä wrote: On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote: Am 05.01.2017 um 12:37 schrieb Ville Syrjälä: > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote: >> From: Rainer Hochecker >> >> This adds fourcc codes for 16bit planes

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: > Hello, > > any particular reason why this fix > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 > was missed from stable 4.8 line? Apparently the bug being fixed has its > own

Re: patch 4.8 "net: handle no dst on skb in icmp6_send"

On 01/08/2017, 03:28 PM, Bronek Kozicki wrote: > Hello, > > any particular reason why this fix > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79dc7e3f1cd323be4c81aa1a94faa1b3ed987fb2 > was missed from stable 4.8 line? Apparently the bug being fixed has its > own

[PATCH v3] ARM: dts: qcom: Add apq8064 CoreSight components

From: "Ivan T. Ivanov" Add initial set of CoreSight components found on Qualcomm apq8064 based platforms, including the IFC6410 board. Signed-off-by: Ivan T. Ivanov Acked-by: Mathieu Poirier Signed-off-by: Georgi

[PATCH v3] ARM: dts: qcom: Add apq8064 CoreSight components

From: "Ivan T. Ivanov" Add initial set of CoreSight components found on Qualcomm apq8064 based platforms, including the IFC6410 board. Signed-off-by: Ivan T. Ivanov Acked-by: Mathieu Poirier Signed-off-by: Georgi Djakov --- Changes since v2 (https://lkml.org/lkml/2016/11/21/522) * Rebase to

Re: [PATCH v2 4/5] firmware: add SmPL report for custom fallback mechanism

On Wed, Jan 11, 2017 at 03:02:22PM +0100, Luis R. Rodriguez wrote: > On Wed, Jan 11, 2017 at 09:32:26AM +0100, Greg KH wrote: > > On Fri, Dec 16, 2016 at 03:10:37AM -0800, Luis R. Rodriguez wrote: > > > Even though most distributions today disable the fallback mechanism > > > by default we've

Re: [PATCH v2 4/5] firmware: add SmPL report for custom fallback mechanism

On Wed, Jan 11, 2017 at 03:02:22PM +0100, Luis R. Rodriguez wrote: > On Wed, Jan 11, 2017 at 09:32:26AM +0100, Greg KH wrote: > > On Fri, Dec 16, 2016 at 03:10:37AM -0800, Luis R. Rodriguez wrote: > > > Even though most distributions today disable the fallback mechanism > > > by default we've

Re: [PATCH 10/62] watchdog: coh901327_wdt: Convert to use device managed functions

On Wed, Jan 11, 2017 at 12:34 AM, Guenter Roeck wrote: > Use device managed functions to simplify error handling, reduce > source code size, improve readability, and reduce the likelyhood of bugs. > > The conversion was done automatically with coccinelle using the > following

Re: [PATCH 10/62] watchdog: coh901327_wdt: Convert to use device managed functions

On Wed, Jan 11, 2017 at 12:34 AM, Guenter Roeck wrote: > Use device managed functions to simplify error handling, reduce > source code size, improve readability, and reduce the likelyhood of bugs. > > The conversion was done automatically with coccinelle using the > following semantic patches.

[tip:perf/urgent] perf/x86/intel: Use ULL constant to prevent undefined shift behaviour

Commit-ID: ad5013d5699d30ded0cdbbc68b93b2aa28222c6e Gitweb: http://git.kernel.org/tip/ad5013d5699d30ded0cdbbc68b93b2aa28222c6e Author: Colin King AuthorDate: Wed, 11 Jan 2017 11:43:10 + Committer: Thomas Gleixner CommitDate: Wed, 11 Jan

[tip:perf/urgent] perf/x86/intel: Use ULL constant to prevent undefined shift behaviour

Commit-ID: ad5013d5699d30ded0cdbbc68b93b2aa28222c6e Gitweb: http://git.kernel.org/tip/ad5013d5699d30ded0cdbbc68b93b2aa28222c6e Author: Colin King AuthorDate: Wed, 11 Jan 2017 11:43:10 + Committer: Thomas Gleixner CommitDate: Wed, 11 Jan 2017 16:43:30 +0100 perf/x86/intel: Use ULL

Re: [PATCH 3/3] iio: pc104: Mask PC/104 drivers via the PC104 Kconfig option

On Tue, Jan 10, 2017 at 10:45 PM, William Breathitt Gray wrote: > On Tue, Jan 10, 2017 at 09:13:02PM +, Jonathan Cameron wrote: >>On 10/01/17 18:51, William Breathitt Gray wrote: >>> PC/104 drivers should be hidden on machines which do not support PC/104 >>> devices.

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 07:24:45AM -0800, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: > > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: > >> On 01/10/2017 02:31 AM, Daniel Vetter wrote: > >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e > >>> Author: Daniel

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 07:24:45AM -0800, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: > > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: > >> On 01/10/2017 02:31 AM, Daniel Vetter wrote: > >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e > >>> Author: Daniel

Re: [PATCH 3/3] iio: pc104: Mask PC/104 drivers via the PC104 Kconfig option

On Tue, Jan 10, 2017 at 10:45 PM, William Breathitt Gray wrote: > On Tue, Jan 10, 2017 at 09:13:02PM +, Jonathan Cameron wrote: >>On 10/01/17 18:51, William Breathitt Gray wrote: >>> PC/104 drivers should be hidden on machines which do not support PC/104 >>> devices. This patch adds the PC104

[PATCH] PCI: Enumerate switches below PCI-to-PCIe bridges

PCI: Enumerate switches below PCI-to-PCIe bridges A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary interface and a PCI Express secondary interface. The PCIe interface is a Downstream Port that originates a Link. See the "PCI Express to PCI/PCI-X Bridge Specification", rev

[PATCH] PCI: Enumerate switches below PCI-to-PCIe bridges

PCI: Enumerate switches below PCI-to-PCIe bridges A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary interface and a PCI Express secondary interface. The PCIe interface is a Downstream Port that originates a Link. See the "PCI Express to PCI/PCI-X Bridge Specification", rev

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote: > Hi Uwe, > > 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König : > > Hello Cedric, > > > > On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote: > >> +/* > >> + * In standard

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

On Wed, Jan 11, 2017 at 02:58:44PM +0100, M'boumba Cedric Madianga wrote: > Hi Uwe, > > 2017-01-11 9:22 GMT+01:00 Uwe Kleine-König : > > Hello Cedric, > > > > On Thu, Jan 05, 2017 at 10:07:23AM +0100, M'boumba Cedric Madianga wrote: > >> +/* > >> + * In standard mode: > >> + * SCL period = SCL

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 4:24 PM, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: >> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: >>> On 01/10/2017 02:31 AM, Daniel Vetter wrote: commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e

Re: [Intel-gfx] 4.10-rc2 oops in DRM connector code

On Wed, Jan 11, 2017 at 4:24 PM, Dave Hansen wrote: > On 01/10/2017 11:43 PM, Daniel Vetter wrote: >> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote: >>> On 01/10/2017 02:31 AM, Daniel Vetter wrote: commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e Author: Daniel Vetter

Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

On Tuesday, January 10, 2017 4:39:43 PM CET Andrew Duggan wrote: > On 01/10/2017 04:16 AM, Arnd Bergmann wrote: > > If CONFIG_INPUT=m, we get a build error for the rmi4-f03 driver, > > added in linux-4.10: > > > > drivers/input/built-in.o: In function `rmi_f03_attention': > >

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Wed, 2017-01-11 at 13:34 +0200, Jarkko Sakkinen wrote: > On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote: > > > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein > > > wrote: > > > > The kernel needs

Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol

On Tuesday, January 10, 2017 4:39:43 PM CET Andrew Duggan wrote: > On 01/10/2017 04:16 AM, Arnd Bergmann wrote: > > If CONFIG_INPUT=m, we get a build error for the rmi4-f03 driver, > > added in linux-4.10: > > > > drivers/input/built-in.o: In function `rmi_f03_attention': > >

Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager

On Wed, 2017-01-11 at 13:34 +0200, Jarkko Sakkinen wrote: > On Tue, Jan 10, 2017 at 01:05:58PM -0700, Jason Gunthorpe wrote: > > On Tue, Jan 10, 2017 at 01:16:35AM +0200, Jarkko Sakkinen wrote: > > > On Wed, Jan 04, 2017 at 10:12:41AM -0600, Dr. Greg Wettstein > > > wrote: > > > > The kernel needs

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

Hello Cedric, On Wed, Jan 11, 2017 at 03:20:41PM +0100, M'boumba Cedric Madianga wrote: > > > >> + */ > >> + reg = i2c_dev->base + STM32F4_I2C_CR1; > >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK); > >> + stm32f4_i2c_set_bits(reg,

Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver

Hello Cedric, On Wed, Jan 11, 2017 at 03:20:41PM +0100, M'boumba Cedric Madianga wrote: > > > >> + */ > >> + reg = i2c_dev->base + STM32F4_I2C_CR1; > >> + stm32f4_i2c_clr_bits(reg, STM32F4_I2C_CR1_ACK); > >> + stm32f4_i2c_set_bits(reg,

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

On Tue, Jan 10, 2017 at 1:18 PM, Roger Quadros wrote: > Hi Linus, > > I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. > > reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to > fix it. I sent out a patch today: "gpio: provide lockdep

Re: gpio: pcf857x: lockdep warning on v4.10-rc3

On Tue, Jan 10, 2017 at 1:18 PM, Roger Quadros wrote: > Hi Linus, > > I see the following lockdep warning on v4.10-rc3 on TI's dra7-evm. > > reverting (d245b3f9bd3 "gpio: simplify adding threaded interrupts") seems to > fix it. I sent out a patch today: "gpio: provide lockdep keys for

[PATCH v5 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. The CPU must be offlined from Linux first. A sysfs interface is created which allows firmware to be loaded and changed at runtime. A full description is available at [1]. An

Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs

On Tue, Jan 10, 2017 at 8:19 PM, Tony Lindgren wrote: > Below is an experimental fix to intorduce pinctrl_start() that I've > tested with pinctrl-single. Then we should probably make all pin controller > drivers call pinctrl_start() to properly fix the issue of struct

[PATCH v5 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. If that VPE is brought back under Linux, it is necessary to ensure that all GIC interrupts are routed and masked as Linux expects them, as the firmware can have done anything it

[PATCH v5 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a more standard mechanism for using one or more VPs as coprocessors running separate firmware. Here we deprecate this mechanism before it is removed. Signed-off-by: Matt Redfearn --- Changes in v5:

[PATCH] regulator: twl6030: fix range comparison, allowing vsel = 59

From: Colin Ian King The range min_uV > 135 && min_uV <= 15 is never reachable because of a typo in the previous range check and hence vsel = 59 is never reached. Fix the previous range check to enable the vsel = 59 setting. Fixes CoverityScan CID#728454

Re: [PATCH v2] gpio: pca953x: Add optional reset gpio control

On Tue, Jan 10, 2017 at 8:29 PM, Steve Longerbeam wrote: > Add optional reset-gpios pin control. If present, de-assert the > specified reset gpio pin to bring the chip out of reset. > > Signed-off-by: Steve Longerbeam > Cc: Linus Walleij

[PATCH v5 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt VP(E) stealing provides a mechanism for removing an offline Virtual Processor from the Linux kernel such that it is available to run bare metal code. Once the CPU has been offlined from Linux, the CPU can be given a task to run via

[PATCH v5 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a remote processor. Firmware may be loaded via the sysfs interface and changed at runtime, allowing the processor to handle real-time tasks or perform coprocessing while remaining processors are available to Linux. Coprocessor

[PATCH] regulator: twl6030: fix range comparison, allowing vsel = 59

From: Colin Ian King The range min_uV > 135 && min_uV <= 15 is never reachable because of a typo in the previous range check and hence vsel = 59 is never reached. Fix the previous range check to enable the vsel = 59 setting. Fixes CoverityScan CID#728454 ("Logially dead code")

Re: [PATCH v2] gpio: pca953x: Add optional reset gpio control

On Tue, Jan 10, 2017 at 8:29 PM, Steve Longerbeam wrote: > Add optional reset-gpios pin control. If present, de-assert the > specified reset gpio pin to bring the chip out of reset. > > Signed-off-by: Steve Longerbeam > Cc: Linus Walleij > Cc: Alexandre Courbot > Cc:

[PATCH v5 0/4] MIPS: Remote processor driver

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. The CPU must be offlined from Linux first. A sysfs interface is created which allows firmware to be loaded and changed at runtime. A full description is available at [1]. An

Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs

On Tue, Jan 10, 2017 at 8:19 PM, Tony Lindgren wrote: > Below is an experimental fix to intorduce pinctrl_start() that I've > tested with pinctrl-single. Then we should probably make all pin controller > drivers call pinctrl_start() to properly fix the issue of struct pinctrl_dev > handle not

[PATCH v5 1/4] irqchip: mips-gic: Add context saving for MIPS_REMOTEPROC

The MIPS remote processor driver allows non-Linux firmware to take control of and execute on one of the systems VPEs. If that VPE is brought back under Linux, it is necessary to ensure that all GIC interrupts are routed and masked as Linux expects them, as the firmware can have done anything it

[PATCH v5 4/4] MIPS: Deprecate VPE Loader

The MIPS remote processor driver (CONFIG_MIPS_REMOTEPROC) provides a more standard mechanism for using one or more VPs as coprocessors running separate firmware. Here we deprecate this mechanism before it is removed. Signed-off-by: Matt Redfearn --- Changes in v5: None Changes in v4: None

[PATCH v5 2/4] MIPS: CPS: Add VP(E) stealing

From: Lisa Parratt VP(E) stealing provides a mechanism for removing an offline Virtual Processor from the Linux kernel such that it is available to run bare metal code. Once the CPU has been offlined from Linux, the CPU can be given a task to run via mips_cps_steal_cpu_and_execute(). The CPU is

[PATCH v5 3/4] remoteproc/MIPS: Add a remoteproc driver for MIPS

This driver allows a MIPS processor offlined from Linux to be used as a remote processor. Firmware may be loaded via the sysfs interface and changed at runtime, allowing the processor to handle real-time tasks or perform coprocessing while remaining processors are available to Linux. Coprocessor

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: > > (1) The file we want to unlink have many hard links, but only one dcache > entry in memory. > (2) open this file, but it's inode->i_nlink read from disk was 1 (too low). > (3) some one call rename and drop it's i_nlink to zero. >

Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy

On Wed, Jan 11, 2017 at 05:07:29PM +0800, zhangyi (F) wrote: > > (1) The file we want to unlink have many hard links, but only one dcache > entry in memory. > (2) open this file, but it's inode->i_nlink read from disk was 1 (too low). > (3) some one call rename and drop it's i_nlink to zero. >

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