Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Interestingly, the *only* other user of ti->task for a full allmodconfig build of

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Interestingly, the *only* other user of ti->task for a full allmodconfig build of x86-64 seems to be

Re: [PATCH] usb: xhci: handle uPD720201 and uPD720202 w/o ROM

Hello, On Tuesday, June 21, 2016 05:56:58 AM Yoshihiro Shimoda wrote: > > From: Christian Lamparter > > Sent: Tuesday, June 21, 2016 12:32 AM > > > > On Wednesday, June 08, 2016 12:14:57 AM Christian Lamparter wrote: > > > This patch adds a firmware check for the uPD720201K8-711-BAC-A > > > and

Re: [PATCH] usb: xhci: handle uPD720201 and uPD720202 w/o ROM

Hello, On Tuesday, June 21, 2016 05:56:58 AM Yoshihiro Shimoda wrote: > > From: Christian Lamparter > > Sent: Tuesday, June 21, 2016 12:32 AM > > > > On Wednesday, June 08, 2016 12:14:57 AM Christian Lamparter wrote: > > > This patch adds a firmware check for the uPD720201K8-711-BAC-A > > > and

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Thu, Jun 23, 2016 at 08:33:18PM +0200, Peter Zijlstra wrote: > On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote: > > > > What kind of config and userspace setup? Do you run this cruft in a > > > cgroup of sorts? > > > > No, we don't do any special setup except to control the

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Thu, Jun 23, 2016 at 08:33:18PM +0200, Peter Zijlstra wrote: > On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote: > > > > What kind of config and userspace setup? Do you run this cruft in a > > > cgroup of sorts? > > > > No, we don't do any special setup except to control the

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On 06/23/2016 08:28 PM, Darren Hart wrote: On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote: On Thu, 23 Jun 2016, Darren Hart wrote: On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: In my opinion, we should treat the timeout value as relative for FUTEX_WAIT

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On 06/23/2016 08:28 PM, Darren Hart wrote: On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote: On Thu, 23 Jun 2016, Darren Hart wrote: On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: In my opinion, we should treat the timeout value as relative for FUTEX_WAIT

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

Hi Darren, On 06/23/2016 06:16 PM, Darren Hart wrote: On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote: On 06/23/2016 09:18 AM, Thomas Gleixner wrote: Once upon a time, you told me the following: On 15 May 2014 at 16:14,

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

Hi Darren, On 06/23/2016 06:16 PM, Darren Hart wrote: On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: On Thu, 23 Jun 2016, Michael Kerrisk (man-pages) wrote: On 06/23/2016 09:18 AM, Thomas Gleixner wrote: Once upon a time, you told me the following: On 15 May 2014 at 16:14,

Re: [PATCH V8 4/9] vfio: platform: add support for ACPI probe

On Mon, 20 Jun 2016 11:51:14 -0400 Sinan Kaya wrote: > The code is using the compatible DT string to associate a reset driver > with the actual device itself. The compatible string does not exist on > ACPI based systems. HID is the unique identifier for a device driver >

Re: [PATCH V8 4/9] vfio: platform: add support for ACPI probe

On Mon, 20 Jun 2016 11:51:14 -0400 Sinan Kaya wrote: > The code is using the compatible DT string to associate a reset driver > with the actual device itself. The compatible string does not exist on > ACPI based systems. HID is the unique identifier for a device driver > instead. > >

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote: > > What kind of config and userspace setup? Do you run this cruft in a > > cgroup of sorts? > > No, we don't do any special setup except to control the number of threads. OK, so I'm fairly certain you _do_ run in a cgroup, because

Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and SPECjvm2008 benchmarks against 4.6 kernel

On Fri, Jun 17, 2016 at 01:04:23AM +0200, Jirka Hladky wrote: > > What kind of config and userspace setup? Do you run this cruft in a > > cgroup of sorts? > > No, we don't do any special setup except to control the number of threads. OK, so I'm fairly certain you _do_ run in a cgroup, because

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, Jun 23, 2016 at 09:35:29AM -0700, Andy Lutomirski wrote: > > So which is the least-bad option? To summarize: > > > > 1) task flag(s) for preemption and page faults > > > > 2) turn pt_regs into a stack frame > > > > 3) annotate all calls from entry code in a table > > > > 4) encode

Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking

On Thu, Jun 23, 2016 at 09:35:29AM -0700, Andy Lutomirski wrote: > > So which is the least-bad option? To summarize: > > > > 1) task flag(s) for preemption and page faults > > > > 2) turn pt_regs into a stack frame > > > > 3) annotate all calls from entry code in a table > > > > 4) encode

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote: > On Thu, 23 Jun 2016, Darren Hart wrote: > > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: > > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT > > regardless of the CLOCK used. > >

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Thu, Jun 23, 2016 at 07:26:52PM +0200, Thomas Gleixner wrote: > On Thu, 23 Jun 2016, Darren Hart wrote: > > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: > > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT > > regardless of the CLOCK used. > >

Re: [PATCH v2 1/3] irqchip: exynos_combiner: fixup reg access on be

Matt, Ben, Both of you submitted similar patches for the same driver, same purpose. Since Ben's hit my inbox first, I'll take his. thx, Jason. On Wed, Jun 22, 2016 at 05:57:01PM +0100, Matthew Leach wrote: > Use the byte-order aware big endian accessors, allowing for kernels > running under

Re: [PATCH v2 1/3] irqchip: exynos_combiner: fixup reg access on be

Matt, Ben, Both of you submitted similar patches for the same driver, same purpose. Since Ben's hit my inbox first, I'll take his. thx, Jason. On Wed, Jun 22, 2016 at 05:57:01PM +0100, Matthew Leach wrote: > Use the byte-order aware big endian accessors, allowing for kernels > running under

[PATCH] btrfs: Fix slab accounting flags

BTRFS is using a variety of slab caches to satisfy internal needs. Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT, meaning allocations from the caches are going to be accounted as SReclaimable. At the same time btrfs is not registering any shrinkers whatsoever, thus

[PATCH] btrfs: Fix slab accounting flags

BTRFS is using a variety of slab caches to satisfy internal needs. Those slab caches are always allocated with the SLAB_RECLAIM_ACCOUNT, meaning allocations from the caches are going to be accounted as SReclaimable. At the same time btrfs is not registering any shrinkers whatsoever, thus

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Heh ;) I am looking at it too. > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On 06/23, Linus Torvalds wrote: > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. Heh ;) I am looking at it too. > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact,

Re: [PATCH] irqchip/mips-gic: Fix IRQs in gic_dev_domain

Qais, On Tue, May 24, 2016 at 11:43:07AM +0100, Qais Yousef wrote: > Hmm I certainly did test this on real hardware with GIC. Are you using the > new dev domain? The idea is that GIC is logically divided and shouldn't be > used directly. Sorry I'm travelling and can't check the code. Any update

Re: [PATCH] irqchip/mips-gic: Fix IRQs in gic_dev_domain

Qais, On Tue, May 24, 2016 at 11:43:07AM +0100, Qais Yousef wrote: > Hmm I certainly did test this on real hardware with GIC. Are you using the > new dev domain? The idea is that GIC is logically divided and shouldn't be > used directly. Sorry I'm travelling and can't check the code. Any update

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, Jun 23, 2016 at 11:05 AM, Yigal Korman wrote: > On Thu, Jun 23, 2016 at 8:36 PM, Kani, Toshimitsu wrote: >> On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: >>> On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: >>> >

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, Jun 23, 2016 at 11:05 AM, Yigal Korman wrote: > On Thu, Jun 23, 2016 at 8:36 PM, Kani, Toshimitsu wrote: >> On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: >>> On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: >>> > >>> > >>> > Currently, presence of direct_access() in

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

Hi Greg, > Greg Kroah-Hartman hat am 1. Juni 2016 um 19:55 > geschrieben: > > > On Wed, Jun 01, 2016 at 10:27:49AM +0200, Stefan Wahren wrote: > > Hi Greg, > > > > Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: > > > Hi Greg, > > > > > > This is v3 patchset

Re: [PATCH v3 0/2] nvmem: remove regmap dependency

Hi Greg, > Greg Kroah-Hartman hat am 1. Juni 2016 um 19:55 > geschrieben: > > > On Wed, Jun 01, 2016 at 10:27:49AM +0200, Stefan Wahren wrote: > > Hi Greg, > > > > Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla: > > > Hi Greg, > > > > > > This is v3 patchset for the leftover 2 patches

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, Jun 23, 2016 at 8:36 PM, Kani, Toshimitsu wrote: > On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: >> On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: >> > >> > >> > Currently, presence of direct_access() in block_device_operations >> >

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, Jun 23, 2016 at 8:36 PM, Kani, Toshimitsu wrote: > On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: >> On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: >> > >> > >> > Currently, presence of direct_access() in block_device_operations >> > indicates support of DAX on its block

Re: Documenting ptrace access mode checking

On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote: > Hi Jann, Stephen, et al. > > Jann, since you recently committed a patch in this area, and Stephen, > since you committed 006ebb40d3d much further back in time, I wonder if > you might help me by reviewing the text below that I propose

Re: Documenting ptrace access mode checking

On 06/21/2016 05:41 AM, Michael Kerrisk (man-pages) wrote: > Hi Jann, Stephen, et al. > > Jann, since you recently committed a patch in this area, and Stephen, > since you committed 006ebb40d3d much further back in time, I wonder if > you might help me by reviewing the text below that I propose

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > wrote: >> >> The thread_info->tsk pointer, that was one of the most critical issues >> and the main raison d'être of the

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > wrote: >> >> The thread_info->tsk pointer, that was one of the most critical issues >> and the main raison d'être of the thread_info, has been replaced on >> x86 by just using the per-cpu

[PATCH] staging: wilc1000: arrays can't be NULL

hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs which have the following element: u8 bssid[6]; pstrNetworkInfo, of type network_info, also contains an u8 array named bssid. request->ssids is an array of cfg80211_ssid structs. Making ssid: u8 ssid[IEEE80211_MAX_SSID_LEN];

[PATCH] staging: wilc1000: arrays can't be NULL

hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs which have the following element: u8 bssid[6]; pstrNetworkInfo, of type network_info, also contains an u8 array named bssid. request->ssids is an array of cfg80211_ssid structs. Making ssid: u8 ssid[IEEE80211_MAX_SSID_LEN];

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds wrote: > > The thread_info->tsk pointer, that was one of the most critical issues > and the main raison d'être of the thread_info, has been replaced on > x86 by just using the per-cpu "current_task". Yes,.there are

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds wrote: > > The thread_info->tsk pointer, that was one of the most critical issues > and the main raison d'être of the thread_info, has been replaced on > x86 by just using the per-cpu "current_task". Yes,.there are probably > more than a few

Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes

On Wednesday 22 June 2016 21:22:16 Ivaylo Dimitrov wrote: > ir-rx51 is a driver for Nokia N900 IR transmitter. The current series > fixes the remaining problems in the driver: > > - replace GP timer 9 with PWM framework usage > - replace pulse width timer dmtimer usage with hrtimer > - add DT

Re: [RESEND PATCH v2 0/5] ir-rx51 driver fixes

On Wednesday 22 June 2016 21:22:16 Ivaylo Dimitrov wrote: > ir-rx51 is a driver for Nokia N900 IR transmitter. The current series > fixes the remaining problems in the driver: > > - replace GP timer 9 with PWM framework usage > - replace pulse width timer dmtimer usage with hrtimer > - add DT

Re: [RESEND PATCH v2 1/5] ir-rx51: Fix build after multiarch changes broke it

On Wednesday 22 June 2016 21:22:17 Ivaylo Dimitrov wrote: > The ir-rx51 driver for n900 has been disabled since the multiarch > changes as plat include directory no longer is SoC specific. > > Let's fix it with minimal changes to pass the dmtimer calls in > pdata. Then the following changes can

Re: [RESEND PATCH v2 1/5] ir-rx51: Fix build after multiarch changes broke it

On Wednesday 22 June 2016 21:22:17 Ivaylo Dimitrov wrote: > The ir-rx51 driver for n900 has been disabled since the multiarch > changes as plat include directory no longer is SoC specific. > > Let's fix it with minimal changes to pass the dmtimer calls in > pdata. Then the following changes can

[PATCH] char: xillybus: fix spelling mistake: "upgarde" -> "upgrade"

From: Colin Ian King trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/char/xillybus/xillybus_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] char: xillybus: fix spelling mistake: "upgarde" -> "upgrade"

From: Colin Ian King trivial fix to spelling mistake in dev_err message Signed-off-by: Colin Ian King --- drivers/char/xillybus/xillybus_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/xillybus/xillybus_core.c b/drivers/char/xillybus/xillybus_core.c

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

Hi Brian, On Wed, Jun 22, 2016 at 11:01 PM, Brian Norris wrote: > On Wed, Jun 22, 2016 at 07:29:46AM -0400, Yendapally Reddy Dhananjaya Reddy > wrote: >> Add support for the PWM controller present in Broadcom's iProc >> family of SoCs. This driver is derived from

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

Hi Brian, On Wed, Jun 22, 2016 at 11:01 PM, Brian Norris wrote: > On Wed, Jun 22, 2016 at 07:29:46AM -0400, Yendapally Reddy Dhananjaya Reddy > wrote: >> Add support for the PWM controller present in Broadcom's iProc >> family of SoCs. This driver is derived from the pwm-bcm-kona >> driver,

Re: [PATCH] Input: elantech - add more IC body types to the list

On Tue, Jun 21, 2016 at 04:15:35PM -0700, Dmitry Torokhov wrote: > The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and > according to Elan both 11 and 12 are valid IC types and should be > identified as hw_version 4. > > Reported-by: Patrick Lessard

Re: [PATCH] Input: elantech - add more IC body types to the list

On Tue, Jun 21, 2016 at 04:15:35PM -0700, Dmitry Torokhov wrote: > The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and > according to Elan both 11 and 12 are valid IC types and should be > identified as hw_version 4. > > Reported-by: Patrick Lessard > Signed-off-by: Dmitry

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > Let me quote my previous email ;) > > And we can't free/nullify it when the parent/debuger reaps a zombie, > say, mark_oom_victim() expects that get_task_struct() protects > thread_info as well. >

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

On 6/22/2016 10:23 AM, Sebastian Reichel wrote: > * PGP Signed by an unknown key > > Hi Rhyland, > > On Tue, Jun 21, 2016 at 02:06:55PM -0400, Rhyland Klein wrote: >> Sebastian, might this be accepted soon? We can't enable the bq27xxx >> driver for Tegra210 Smaug without running into the crash

Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Thu, Jun 23, 2016 at 10:03 AM, Oleg Nesterov wrote: > > Let me quote my previous email ;) > > And we can't free/nullify it when the parent/debuger reaps a zombie, > say, mark_oom_victim() expects that get_task_struct() protects > thread_info as well. > > probably we can

Re: [PATCH v4] power_supply: power_supply_read_temp only if use_cnt > 0

On 6/22/2016 10:23 AM, Sebastian Reichel wrote: > * PGP Signed by an unknown key > > Hi Rhyland, > > On Tue, Jun 21, 2016 at 02:06:55PM -0400, Rhyland Klein wrote: >> Sebastian, might this be accepted soon? We can't enable the bq27xxx >> driver for Tegra210 Smaug without running into the crash

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

Hi Boris, On Thu, Jun 23, 2016 at 11:09 PM, Boris Brezillon wrote: > On Wed, 22 Jun 2016 07:29:46 -0400 > Yendapally Reddy Dhananjaya Reddy wrote: > >> Add support for the PWM controller present in Broadcom's iProc >> family of

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

Hi Boris, On Thu, Jun 23, 2016 at 11:09 PM, Boris Brezillon wrote: > On Wed, 22 Jun 2016 07:29:46 -0400 > Yendapally Reddy Dhananjaya Reddy wrote: > >> Add support for the PWM controller present in Broadcom's iProc >> family of SoCs. This driver is derived from the pwm-bcm-kona >> driver, with

Re: [PATCH v2 2/2] netfilter/nflog: nflog-range does not truncate packets (userspace)

On Tue, Jun 21, 2016 at 03:02:16PM -0400, Vishwanath Pai wrote: > netfilter/nflog: nflog-range does not truncate packets > > The option --nflog-range has never worked, but we cannot just fix this > because users might be using this feature option and their behavior would > change. Instead add a

Re: [PATCH v2 2/2] netfilter/nflog: nflog-range does not truncate packets (userspace)

On Tue, Jun 21, 2016 at 03:02:16PM -0400, Vishwanath Pai wrote: > netfilter/nflog: nflog-range does not truncate packets > > The option --nflog-range has never worked, but we cannot just fix this > because users might be using this feature option and their behavior would > change. Instead add a

Re: [RESEND PATCH] thermal: helpers: Check return value of get_temp

On 6/6/2016 12:53 PM, Rhyland Klein wrote: > Check the return value of get_temp, which can fail. If it does, then > unlock and return the error code. > > Signed-off-by: Rhyland Klein > --- > drivers/thermal/thermal_helpers.c | 4 > 1 file changed, 4 insertions(+) > >

Re: [RESEND PATCH] thermal: helpers: Check return value of get_temp

On 6/6/2016 12:53 PM, Rhyland Klein wrote: > Check the return value of get_temp, which can fail. If it does, then > unlock and return the error code. > > Signed-off-by: Rhyland Klein > --- > drivers/thermal/thermal_helpers.c | 4 > 1 file changed, 4 insertions(+) > > diff --git

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

On Wed, 22 Jun 2016 07:29:46 -0400 Yendapally Reddy Dhananjaya Reddy wrote: > Add support for the PWM controller present in Broadcom's iProc > family of SoCs. This driver is derived from the pwm-bcm-kona > driver, with changes to the register offsets and bit

Re: [PATCH v4 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

On Wed, 22 Jun 2016 07:29:46 -0400 Yendapally Reddy Dhananjaya Reddy wrote: > Add support for the PWM controller present in Broadcom's iProc > family of SoCs. This driver is derived from the pwm-bcm-kona > driver, with changes to the register offsets and bit positions. I haven't looked at the 2

Re: [PATCH v10 07/10] perf record: Read from overwritable ring buffer

On 23 June 2016 at 09:31, pi3orama wrote: > > > 发自我的 iPhone > >> 在 2016年6月23日，下午10:27，Nilay Vaish 写道： >> >>> On 23 June 2016 at 00:27, Wang Nan wrote: >>> @@ -542,6 +568,79 @@ static struct perf_event_header finished_round_event =

Re: [PATCH v10 07/10] perf record: Read from overwritable ring buffer

On 23 June 2016 at 09:31, pi3orama wrote: > > > 发自我的 iPhone > >> 在 2016年6月23日，下午10:27，Nilay Vaish 写道： >> >>> On 23 June 2016 at 00:27, Wang Nan wrote: >>> @@ -542,6 +568,79 @@ static struct perf_event_header finished_round_event = >>> { >>>.type = PERF_RECORD_FINISHED_ROUND, >>> }; >>>

[PATCH] ASoC: Samsung: s3c-i2s-v2: fix spelling mistake: "unknwon" -> "unknown"

From: Colin Ian King trivial fix to spelling mistake in pr_err message Signed-off-by: Colin Ian King --- sound/soc/samsung/s3c-i2s-v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/s3c-i2s-v2.c

[PATCH] ASoC: Samsung: s3c-i2s-v2: fix spelling mistake: "unknwon" -> "unknown"

From: Colin Ian King trivial fix to spelling mistake in pr_err message Signed-off-by: Colin Ian King --- sound/soc/samsung/s3c-i2s-v2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/s3c-i2s-v2.c b/sound/soc/samsung/s3c-i2s-v2.c index b6ab3fc..bf8ae79

Re: [PATCH] bridge: netfilter: spanning tree: Add masked_ether_addr_equal and neatening

On Wed, Jun 15, 2016 at 01:58:45PM -0700, Joe Perches wrote: > There is code duplication of a masked ethernet address comparison here > so make it a separate function instead. > > Miscellanea: > > o Neaten alignment of FWINV macro uses to make it clearer for the reader Applied, thanks. >

Re: [PATCH] bridge: netfilter: spanning tree: Add masked_ether_addr_equal and neatening

On Wed, Jun 15, 2016 at 01:58:45PM -0700, Joe Perches wrote: > There is code duplication of a masked ethernet address comparison here > so make it a separate function instead. > > Miscellanea: > > o Neaten alignment of FWINV macro uses to make it clearer for the reader Applied, thanks. >

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: > On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: > > > > > > Currently, presence of direct_access() in block_device_operations > > indicates support of DAX on its block device.  Because > > block_device_operations is

Re: [PATCH v2 1/3] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support

On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote: > On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote: > > > > > > Currently, presence of direct_access() in block_device_operations > > indicates support of DAX on its block device.  Because > > block_device_operations is instantiated with

Re: [PATCH] fbdev: atyfb: fix array overflow

On Thu, Jun 23, 2016 at 11:22:20AM +0200, Arnd Bergmann wrote: > On Thursday, June 23, 2016 10:50:04 AM CEST Geert Uytterhoeven wrote: > > Hi Arnd, > > > > On Wed, Jun 22, 2016 at 2:37 PM, Arnd Bergmann wrote: > > > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this >

Re: [PATCH] fbdev: atyfb: fix array overflow

On Thu, Jun 23, 2016 at 11:22:20AM +0200, Arnd Bergmann wrote: > On Thursday, June 23, 2016 10:50:04 AM CEST Geert Uytterhoeven wrote: > > Hi Arnd, > > > > On Wed, Jun 22, 2016 at 2:37 PM, Arnd Bergmann wrote: > > > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this > > > gcc

Re: [PATCH V4 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Thu, Jun 23, 2016 at 01:11:41PM +0800, wrote: > From: Rui Wang > > On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote: > > [...] > > > @@ -1779,8 +1780,12 @@ void __init > > > pci_assign_unassigned_resources(void) > > > { > > > struct pci_bus *root_bus; > > > > > > -

Re: [PATCH V4 1/3] x86/ioapic: Support hot-removal of IOAPICs present during boot

On Thu, Jun 23, 2016 at 01:11:41PM +0800, wrote: > From: Rui Wang > > On Wed, June 22, 2016 11:15 PM Bjorn Helgaas wrote: > > [...] > > > @@ -1779,8 +1780,12 @@ void __init > > > pci_assign_unassigned_resources(void) > > > { > > > struct pci_bus *root_bus; > > > > > > -

Re: [PATCH v2 1/2] netfilter/nflog: nflog-range does not truncate packets

On Tue, Jun 21, 2016 at 02:58:46PM -0400, Vishwanath Pai wrote: > netfilter/nflog: nflog-range does not truncate packets > > li->u.ulog.copy_len is currently ignored by the kernel, we should truncate > the packet to either li->u.ulog.copy_len (if set) or copy_range before > sending it to

Re: [PATCH v2 1/2] netfilter/nflog: nflog-range does not truncate packets

On Tue, Jun 21, 2016 at 02:58:46PM -0400, Vishwanath Pai wrote: > netfilter/nflog: nflog-range does not truncate packets > > li->u.ulog.copy_len is currently ignored by the kernel, we should truncate > the packet to either li->u.ulog.copy_len (if set) or copy_range before > sending it to

RE: [RFC v3 42/45] nfs: Add richacl support

> First, let me say thanks for all the work! We (Primary Data) have been using > samba with the vfs_richacl module reexporting an nfsv4.2 mount and things > are working pretty well. You can count on us for testing, bug fixing and code > review. > > Now for my question: It looks like this call to

RE: [RFC v3 42/45] nfs: Add richacl support

> First, let me say thanks for all the work! We (Primary Data) have been using > samba with the vfs_richacl module reexporting an nfsv4.2 mount and things > are working pretty well. You can count on us for testing, bug fixing and code > review. > > Now for my question: It looks like this call to

Re: [PATCH] pci: Add support for unbinding the generic PCI host controller

On 2016-06-22 08:06, Will Deacon wrote: > Hi Jan, > > On Tue, Jun 21, 2016 at 08:07:50PM +0200, Jan Kiszka wrote: >> Particularly useful when working in virtual environments where the >> controller may come and go, but possibly not only there. >> >> Signed-off-by: Jan Kiszka

Re: [PATCH] pci: Add support for unbinding the generic PCI host controller

On 2016-06-22 08:06, Will Deacon wrote: > Hi Jan, > > On Tue, Jun 21, 2016 at 08:07:50PM +0200, Jan Kiszka wrote: >> Particularly useful when working in virtual environments where the >> controller may come and go, but possibly not only there. >> >> Signed-off-by: Jan Kiszka >> --- >>

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

Hi Chris, [ ... ] > + ret = extcon_register_notifier(tcphy->pd_extcon, EXTCON_USB, > + >event_nb); > + if (ret) { > + dev_err(dev, "regitster EXTCON_USB notifer failed\n"); > + return ret; > + } > + > + ret

Re: [v3 PATCH 3/5] phy: Add USB Type-C PHY driver for rk3399

Hi Chris, [ ... ] > + ret = extcon_register_notifier(tcphy->pd_extcon, EXTCON_USB, > + >event_nb); > + if (ret) { > + dev_err(dev, "regitster EXTCON_USB notifer failed\n"); > + return ret; > + } > + > + ret

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Thu, 23 Jun 2016, Darren Hart wrote: > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT > regardless of the CLOCK used. Which requires even more changes as you have to select which clock you are using

Re: futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op

On Thu, 23 Jun 2016, Darren Hart wrote: > On Thu, Jun 23, 2016 at 03:40:36PM +0200, Thomas Gleixner wrote: > In my opinion, we should treat the timeout value as relative for FUTEX_WAIT > regardless of the CLOCK used. Which requires even more changes as you have to select which clock you are using

Re: [PATCH] fbdev: atyfb: fix array overflow

On Thu, Jun 23, 2016 at 11:06:11AM +0200, Arnd Bergmann wrote: > On Thursday, June 23, 2016 3:28:25 AM CEST Ville Syrjälä wrote: > > On Wed, Jun 22, 2016 at 02:37:11PM +0200, Arnd Bergmann wrote: > > > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this > > > gcc warning for atyfb: > >

Re: [PATCH] fbdev: atyfb: fix array overflow

On Thu, Jun 23, 2016 at 11:06:11AM +0200, Arnd Bergmann wrote: > On Thursday, June 23, 2016 3:28:25 AM CEST Ville Syrjälä wrote: > > On Wed, Jun 22, 2016 at 02:37:11PM +0200, Arnd Bergmann wrote: > > > When building with CONFIG_UBSAN_SANITIZE_ALL on ARM, I get this > > > gcc warning for atyfb: > >

Re: [PATCH] tcm_qla2xxx: fix spelling mistake: "seperator" -> "separator"

- Original Message - > From: "Colin King" > To: "James E . J . Bottomley" , "Martin K . > Petersen" , > linux-s...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Sent: Thursday, June 23, 2016 1:12:25

Re: [PATCH] tcm_qla2xxx: fix spelling mistake: "seperator" -> "separator"

- Original Message - > From: "Colin King" > To: "James E . J . Bottomley" , "Martin K . > Petersen" , > linux-s...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Sent: Thursday, June 23, 2016 1:12:25 PM > Subject: [PATCH] tcm_qla2xxx: fix spelling mistake: "seperator" ->

Re: [PATCH v2 3/4] input: touchscreen: mxs-lradc: Add support for touchscreen

On Wed, Jun 15, 2016 at 11:26:18PM +0200, Stefan Wahren wrote: > Hi, > > unfortunately i still don't have a touchscreen to test this patch. > > > Ksenija Stanojevic hat am 8. Juni 2016 um > > 16:48 > > geschrieben: > > > > > > Add 4-wire/5-wire touchscreen

Re: [PATCH v2 3/4] input: touchscreen: mxs-lradc: Add support for touchscreen

On Wed, Jun 15, 2016 at 11:26:18PM +0200, Stefan Wahren wrote: > Hi, > > unfortunately i still don't have a touchscreen to test this patch. > > > Ksenija Stanojevic hat am 8. Juni 2016 um > > 16:48 > > geschrieben: > > > > > > Add 4-wire/5-wire touchscreen controller. > > > > Signed-off-by:

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

Hi Martin, On Tue, Jun 14, 2016 at 01:20:15PM +0200, Martin Kepplinger wrote: > static int pegasus_reset_resume(struct usb_interface *intf) > { > + struct pegasus *pegasus = usb_get_intfdata(intf); > + > + if (pegasus->dev->users) > + pegasus_set_mode(pegasus, PEN_MODE_XY,

Re: [PATCH v2] input: tablet: pegasus_notetaker: USB PM fixes

Hi Martin, On Tue, Jun 14, 2016 at 01:20:15PM +0200, Martin Kepplinger wrote: > static int pegasus_reset_resume(struct usb_interface *intf) > { > + struct pegasus *pegasus = usb_get_intfdata(intf); > + > + if (pegasus->dev->users) > + pegasus_set_mode(pegasus, PEN_MODE_XY,

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

Reza Arbab writes: > These functions are making direct calls to the hash table APIs, > leading to a BUG() on systems using radix. > > Switch them to the vmemmap_{create,remove}_mapping() wrappers, and > move to the __meminit section. They are really not the same. They

Re: [PATCH 1/6] arm64: alternatives: drop enable parameter from _else and _endif macro

On Mon, May 09, 2016 at 05:49:45PM +0100, Andre Przywara wrote: > Commit 77ee306c0aea9 ("arm64: alternatives: add enable parameter to > conditional asm macros") extended the alternative assembly macros. > Unfortunately this does not really work as one would expect, as the > enable parameter in

Re: [PATCH] powerpc/mm: update arch_{add,remove}_memory() for radix

Reza Arbab writes: > These functions are making direct calls to the hash table APIs, > leading to a BUG() on systems using radix. > > Switch them to the vmemmap_{create,remove}_mapping() wrappers, and > move to the __meminit section. They are really not the same. They can possibly end up using

Re: [PATCH 1/6] arm64: alternatives: drop enable parameter from _else and _endif macro

On Mon, May 09, 2016 at 05:49:45PM +0100, Andre Przywara wrote: > Commit 77ee306c0aea9 ("arm64: alternatives: add enable parameter to > conditional asm macros") extended the alternative assembly macros. > Unfortunately this does not really work as one would expect, as the > enable parameter in

Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

On Thu, Jun 23, 2016 at 04:35:54PM +0100, Dietmar Eggemann wrote: > > The things we ran into with these patches were that: > > > > 1) You need to update the cfs_rq _before_ any entity attach/detach > > (and might need to update_tg_load_avg when update_cfs_rq_load_avg() > > returns true).

Re: [PATCH 4/4] sched,fair: Fix PELT integrity for new tasks

On Thu, Jun 23, 2016 at 04:35:54PM +0100, Dietmar Eggemann wrote: > > The things we ran into with these patches were that: > > > > 1) You need to update the cfs_rq _before_ any entity attach/detach > > (and might need to update_tg_load_avg when update_cfs_rq_load_avg() > > returns true).

Re: [PATCH] kvm: x86: use getboottime64

On 17/06/2016 17:48, Arnd Bergmann wrote: > KVM reads the current boottime value as a struct timespec in order to > calculate the guest wallclock time, resulting in an overflow in 2038 > on 32-bit systems. > > The data then gets passed as an unsigned 32-bit number to the guest, > and that in

Re: [PATCH] kvm: x86: use getboottime64

On 17/06/2016 17:48, Arnd Bergmann wrote: > KVM reads the current boottime value as a struct timespec in order to > calculate the guest wallclock time, resulting in an overflow in 2038 > on 32-bit systems. > > The data then gets passed as an unsigned 32-bit number to the guest, > and that in

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