Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Hi Robert, Michal's and Nick's patch is already added to 4.9-rc6, however Adam's patch is still missing for x86: https://patchwork.kernel.org/patch/9408985/raw/ You can check on how I patch it on Manjaro here (line 75):

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Hi Robert, Michal's and Nick's patch is already added to 4.9-rc6, however Adam's patch is still missing for x86: https://patchwork.kernel.org/patch/9408985/raw/ You can check on how I patch it on Manjaro here (line 75):

[PATCH] KVM: x86: check for pic and ioapic presence before use

Split irqchip allows pic and ioapic routes to be used without them being created, which results in NULL access. Check for NULL and avoid it. (The setup is too racy for a nicer solutions.) Found by syzkaller: general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace

[PATCH] KVM: x86: check for pic and ioapic presence before use

Split irqchip allows pic and ioapic routes to be used without them being created, which results in NULL access. Check for NULL and avoid it. (The setup is too racy for a nicer solutions.) Found by syzkaller: general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace

Re: [PATCH] clk: bcm: Fix unmet Kconfig dependencies for CLK_BCM_63XX

On 11/23/2016 12:18 PM, Stephen Boyd wrote: > On 11/22, Florian Fainelli wrote: >> With commit f4e871509959 ("clk: iproc: Make clocks visible options"), >> COMMON_CLK_IPROC gained a dependency on ARCH_BCM_IPROC, yet CLK_BCM_63XX >> also selects that option, this causes the following Kconfig

Re: [PATCH] clk: bcm: Fix unmet Kconfig dependencies for CLK_BCM_63XX

On 11/23/2016 12:18 PM, Stephen Boyd wrote: > On 11/22, Florian Fainelli wrote: >> With commit f4e871509959 ("clk: iproc: Make clocks visible options"), >> COMMON_CLK_IPROC gained a dependency on ARCH_BCM_IPROC, yet CLK_BCM_63XX >> also selects that option, this causes the following Kconfig

Re: [PATCH 13/14] perf tools: warn on high overhead

kan.li...@intel.com writes: > From: Kan Liang > > The rough overhead rate can be caculated by the sum of all kinds of > overhead / elapsed time. > If the overhead rate is higher than 10%, warning the user. Thinking about this more: this is comparing the cost of a single CPU

Re: [PATCH 13/14] perf tools: warn on high overhead

kan.li...@intel.com writes: > From: Kan Liang > > The rough overhead rate can be caculated by the sum of all kinds of > overhead / elapsed time. > If the overhead rate is higher than 10%, warning the user. Thinking about this more: this is comparing the cost of a single CPU to the total wall

Re: [PATCH v3 4/9] media: venus: vdec: add video decoder files

Le lundi 21 novembre 2016 à 18:09 +0200, Stanimir Varbanov a écrit : > >> Meanwhile I have found bigger obstacle - I cannot run multiple > instances > >> simultaneously. By m2m design it can execute only one job (m2m > context) > >> at a time per m2m device. Can you confirm that my observation is

Re: [PATCH v3 4/9] media: venus: vdec: add video decoder files

Le lundi 21 novembre 2016 à 18:09 +0200, Stanimir Varbanov a écrit : > >> Meanwhile I have found bigger obstacle - I cannot run multiple > instances > >> simultaneously. By m2m design it can execute only one job (m2m > context) > >> at a time per m2m device. Can you confirm that my observation is

Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI

On Thu, Oct 27, 2016 at 10:36:00PM +0200, Thomas Gleixner wrote: > > + new_owner = rt_mutex_next_owner(_state->pi_mutex); > > + if (!new_owner) { > > + /* > > +* This is the case where futex_lock_pi() has not yet or failed > > +* to acquire the lock but still

Re: [RFC][PATCH 4/4] futex: Rewrite FUTEX_UNLOCK_PI

On Thu, Oct 27, 2016 at 10:36:00PM +0200, Thomas Gleixner wrote: > > + new_owner = rt_mutex_next_owner(_state->pi_mutex); > > + if (!new_owner) { > > + /* > > +* This is the case where futex_lock_pi() has not yet or failed > > +* to acquire the lock but still

Re: [PATCH] clk: bcm: Fix unmet Kconfig dependencies for CLK_BCM_63XX

On 11/22, Florian Fainelli wrote: > With commit f4e871509959 ("clk: iproc: Make clocks visible options"), > COMMON_CLK_IPROC gained a dependency on ARCH_BCM_IPROC, yet CLK_BCM_63XX > also selects that option, this causes the following Kconfig warning: > > warning: (CLK_BCM_63XX) selects

Re: [PATCH] clk: bcm: Fix unmet Kconfig dependencies for CLK_BCM_63XX

On 11/22, Florian Fainelli wrote: > With commit f4e871509959 ("clk: iproc: Make clocks visible options"), > COMMON_CLK_IPROC gained a dependency on ARCH_BCM_IPROC, yet CLK_BCM_63XX > also selects that option, this causes the following Kconfig warning: > > warning: (CLK_BCM_63XX) selects

[PATCH v3 2/3] cpuidle: allow setting deepest idle

When idle injection is used to cap power, we need to override governor's choice of idle states. This patch allows caller to select the deepest idle state on a CPU therefore achieve the maximum potential power saving. Signed-off-by: Jacob Pan ---

[PATCH v3 2/3] cpuidle: allow setting deepest idle

When idle injection is used to cap power, we need to override governor's choice of idle states. This patch allows caller to select the deepest idle state on a CPU therefore achieve the maximum potential power saving. Signed-off-by: Jacob Pan --- drivers/cpuidle/cpuidle.c | 11 +++

[PATCH] KVM: x86: drop error recovery in em_jmp_far and em_ret_far

em_jmp_far and em_ret_far assumed that setting IP can only fail in 64 bit mode, but syzkaller proved otherwise (and SDM agrees). Code segment was restored upon failure, but it was left uninitialized outside of long mode, which could lead to a leak of host kernel stack. We could have fixed that by

[PATCH v3 1/3] idle: add support for tasks that inject idle

From: Peter Zijlstra Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use realtime tasks to take control of CPU then inject idle. There are two issues with this approach: 1. Low efficiency: injected idle task is treated as busy so sched ticks do not

[PATCH v3 0/3] Stop sched tick in idle injection task

Changelog: v3: - rearrange idle.c change based on Rafael's suggestion. v2: - moved duration timer from powerclamp driver to play_idle() - unexport cpuidle_use_deepest_state - indentation fix Idle injection drivers today use RT threads to run idle loop. There are

[PATCH] KVM: x86: drop error recovery in em_jmp_far and em_ret_far

em_jmp_far and em_ret_far assumed that setting IP can only fail in 64 bit mode, but syzkaller proved otherwise (and SDM agrees). Code segment was restored upon failure, but it was left uninitialized outside of long mode, which could lead to a leak of host kernel stack. We could have fixed that by

[PATCH v3 1/3] idle: add support for tasks that inject idle

From: Peter Zijlstra Idle injection drivers such as Intel powerclamp and ACPI PAD drivers use realtime tasks to take control of CPU then inject idle. There are two issues with this approach: 1. Low efficiency: injected idle task is treated as busy so sched ticks do not stop during injected

[PATCH v3 0/3] Stop sched tick in idle injection task

Changelog: v3: - rearrange idle.c change based on Rafael's suggestion. v2: - moved duration timer from powerclamp driver to play_idle() - unexport cpuidle_use_deepest_state - indentation fix Idle injection drivers today use RT threads to run idle loop. There are

[PATCH] KVM: x86: fix out-of-bounds accesses of rtc_eoi map

KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be bigger that the maximal number of VCPUs, resulting in out-of-bounds access. Found by syzkaller: BUG: KASAN: slab-out-of-bounds in __apic_accept_irq+0xb33/0xb50 at addr [...] Write of size 1 by task a.out/27101 CPU: 1

[PATCH] KVM: x86: fix out-of-bounds accesses of rtc_eoi map

KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be bigger that the maximal number of VCPUs, resulting in out-of-bounds access. Found by syzkaller: BUG: KASAN: slab-out-of-bounds in __apic_accept_irq+0xb33/0xb50 at addr [...] Write of size 1 by task a.out/27101 CPU: 1

[PATCH v3 3/3] thermal/powerclamp: stop sched tick in forced idle

With the introduction of play_idle(), idle injection kthread can go through the normal idle task processing to get correct accounting and turn off scheduler tick when possible. Hrtimer is used to wake up since timeout is most likely to occur during idle injection. Signed-off-by: Jacob Pan

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Phil, I don't have those files. I'll patch and test. Thanks, Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Wed, Nov 23, 2016 at 1:08 PM, Philip Müller wrote: > Hi Robert, > > you have to apply following patch also: > >

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Phil, I don't have those files. I'll patch and test. Thanks, Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 On Wed, Nov 23, 2016 at 1:08 PM, Philip Müller wrote: > Hi Robert, > > you have to apply following patch also: > >

[PATCH v3 3/3] thermal/powerclamp: stop sched tick in forced idle

With the introduction of play_idle(), idle injection kthread can go through the normal idle task processing to get correct accounting and turn off scheduler tick when possible. Hrtimer is used to wake up since timeout is most likely to occur during idle injection. Signed-off-by: Jacob Pan ---

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Wed, Nov 23, 2016 at 04:44:39AM -0500, kan.li...@intel.com wrote: > +/* > + * single overhead record layout: > + * > + *cpu: The cpu which overhead occues This is duplicate information, its already present in sample_id when PERF_SAMPLE_CPU, and without that we don't care. > + * nr:

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Wed, Nov 23, 2016 at 04:44:39AM -0500, kan.li...@intel.com wrote: > +/* > + * single overhead record layout: > + * > + *cpu: The cpu which overhead occues This is duplicate information, its already present in sample_id when PERF_SAMPLE_CPU, and without that we don't care. > + * nr:

Re: [RFC PATCH 3/3] staging: remove fbtft

On Wed, Nov 23, 2016 at 2:03 AM, Tomi Valkeinen wrote: > Since the fbdev framework is in maintenance mode and all new display > drivers should be made with the DRM framework, remove fbtft from > staging. > > Signed-off-by: Tomi Valkeinen I'd request

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/21/2016 12:13 AM, Jon Masters wrote: On 11/07/2016 07:45 PM, Will Deacon wrote: I figured this was a reasonable post to piggy-back on for the LPC minutes relating to guest MSIs on arm64. Thanks for this Will. I'm still digging out post-LPC and SC16, but the summary was much

Re: Summary of LPC guest MSI discussion in Santa Fe

On 11/21/2016 12:13 AM, Jon Masters wrote: On 11/07/2016 07:45 PM, Will Deacon wrote: I figured this was a reasonable post to piggy-back on for the LPC minutes relating to guest MSIs on arm64. Thanks for this Will. I'm still digging out post-LPC and SC16, but the summary was much

Re: [RFC PATCH 3/3] staging: remove fbtft

On Wed, Nov 23, 2016 at 2:03 AM, Tomi Valkeinen wrote: > Since the fbdev framework is in maintenance mode and all new display > drivers should be made with the DRM framework, remove fbtft from > staging. > > Signed-off-by: Tomi Valkeinen I'd request that fbtft please be kept in staging until a

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Wed, Nov 23, 2016 at 04:44:39AM -0500, kan.li...@intel.com wrote: > +struct perf_overhead_entry { > + __u32 cpu; > + __u64 nr; > + __u64 time; > +}; > +void perf_log_overhead(struct perf_event *event, u32 type, > +struct perf_overhead_entry *entry) > +{ >

Re: [PATCH 01/14] perf/x86: Introduce PERF_RECORD_OVERHEAD

On Wed, Nov 23, 2016 at 04:44:39AM -0500, kan.li...@intel.com wrote: > +struct perf_overhead_entry { > + __u32 cpu; > + __u64 nr; > + __u64 time; > +}; > +void perf_log_overhead(struct perf_event *event, u32 type, > +struct perf_overhead_entry *entry) > +{ >

RE: [PATCH 03/14] perf/x86: output multiplexing overhead

> > On Wed, Nov 23, 2016 at 04:44:41AM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Multiplexing overhead is one of the key overhead when the number of > > events is more than available counters. > > > > Signed-off-by: Kan Liang > >

RE: [PATCH 03/14] perf/x86: output multiplexing overhead

> > On Wed, Nov 23, 2016 at 04:44:41AM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > Multiplexing overhead is one of the key overhead when the number of > > events is more than available counters. > > > > Signed-off-by: Kan Liang > > --- > > include/linux/perf_event.h |

Re: [PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux

On 11/22, Eric Anholt wrote: > From: Boris Brezillon > > There is no fixed divider on pllh_aux. > > Signed-off-by: Boris Brezillon > Signed-off-by: Eric Anholt > Reviewed-by: Eric Anholt

Re: [PATCH] clk: bcm2835: Fix ->fixed_divider of pllh_aux

On 11/22, Eric Anholt wrote: > From: Boris Brezillon > > There is no fixed divider on pllh_aux. > > Signed-off-by: Boris Brezillon > Signed-off-by: Eric Anholt > Reviewed-by: Eric Anholt > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a

mmotm 2016-11-23-12-08 uploaded

The mm-of-the-moment snapshot 2016-11-23-12-08 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-11-23-12-08 uploaded

The mm-of-the-moment snapshot 2016-11-23-12-08 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Hi Robert, you have to apply following patch also: provide-asm-prototypes.h-for-x86.patch: https://patchwork.kernel.org/patch/9408985/raw/ @Adam, Nick: Was this patch not yet sent to Linus? greez, Phil Am 01.11.2016 um 14:46 schrieb Nicholas Piggin: > On Tue, 1 Nov 2016 13:48:59 +0100 >

Re: [PATCH 1/4] serial: core: Add LED trigger support

Hi Sascha, [auto build test WARNING on tty/tty-testing] [also build test WARNING on v4.9-rc6 next-20161123] [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/Sascha-Hauer/serial-core-Add-LED

Re: BUG: 4.9-rc6 Still "no symbol version" on boot

Hi Robert, you have to apply following patch also: provide-asm-prototypes.h-for-x86.patch: https://patchwork.kernel.org/patch/9408985/raw/ @Adam, Nick: Was this patch not yet sent to Linus? greez, Phil Am 01.11.2016 um 14:46 schrieb Nicholas Piggin: > On Tue, 1 Nov 2016 13:48:59 +0100 >

Re: [PATCH 1/4] serial: core: Add LED trigger support

Hi Sascha, [auto build test WARNING on tty/tty-testing] [also build test WARNING on v4.9-rc6 next-20161123] [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/Sascha-Hauer/serial-core-Add-LED

Re: [PATCH 04/14] perf/x86: output side-band events overhead

On Wed, Nov 23, 2016 at 04:44:42AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Iterating all events which need to receive side-band events also bring > some overhead. > Save the overhead information in task context or CPU context, whichever > context is

Re: [PATCH 03/14] perf/x86: output multiplexing overhead

On Wed, Nov 23, 2016 at 04:44:41AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Multiplexing overhead is one of the key overhead when the number of > events is more than available counters. > > Signed-off-by: Kan Liang > --- >

Re: [PATCH 04/14] perf/x86: output side-band events overhead

On Wed, Nov 23, 2016 at 04:44:42AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Iterating all events which need to receive side-band events also bring > some overhead. > Save the overhead information in task context or CPU context, whichever > context is available. > > Signed-off-by:

Re: [PATCH 03/14] perf/x86: output multiplexing overhead

On Wed, Nov 23, 2016 at 04:44:41AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > Multiplexing overhead is one of the key overhead when the number of > events is more than available counters. > > Signed-off-by: Kan Liang > --- > include/linux/perf_event.h | 2 ++ >

Re: [PATCH 02/14] perf/x86: output NMI overhead

On Wed, Nov 23, 2016 at 04:44:40AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > NMI handler is one of the most important part which brings overhead. > > There are lots of NMI during sampling. It's very expensive to log each > NMI. So the accumulated time and NMI#

Re: [PATCH 02/14] perf/x86: output NMI overhead

On Wed, Nov 23, 2016 at 04:44:40AM -0500, kan.li...@intel.com wrote: > From: Kan Liang > > NMI handler is one of the most important part which brings overhead. > > There are lots of NMI during sampling. It's very expensive to log each > NMI. So the accumulated time and NMI# will be output when

Re: [PATCH v2 1/2] clk: qcom: clk-smd-rpm: Fix clk_hw references

On 11/23, Georgi Djakov wrote: > Fix the clk_hw references to the actual clocks and add a xlate function > to return the hw pointers from the already existing static array. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > ---

Re: [PATCH v2 2/2] clk: qcom: clk-rpm: Fix clk_hw references

On 11/23, Georgi Djakov wrote: > Fix the clk_hw references to the actual clocks and add a xlate function > to return the hw pointers from the already existing static array. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > ---

Re: [PATCH v2 1/2] clk: qcom: clk-smd-rpm: Fix clk_hw references

On 11/23, Georgi Djakov wrote: > Fix the clk_hw references to the actual clocks and add a xlate function > to return the hw pointers from the already existing static array. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > --- Applied to clk-next -- Qualcomm Innovation Center,

Re: [PATCH v2 2/2] clk: qcom: clk-rpm: Fix clk_hw references

On 11/23, Georgi Djakov wrote: > Fix the clk_hw references to the actual clocks and add a xlate function > to return the hw pointers from the already existing static array. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > --- Applied to clk-next -- Qualcomm Innovation Center,

Re: Regression: Failed boots bisected to 4cd13c21b207 "softirq: Let ksoftirqd do its job"

On Wed, Nov 23, 2016 at 10:21 AM, Brian Starkey wrote: > This patch didn't help. > > I did get some new traces though - I've attached the diff for the > trace_printks I added. > > Before 4cd13c21b207: > https://drive.google.com/open?id=0B8siaK6ZjvEwcEtOeFQzTmY0Nnc > After

Re: Regression: Failed boots bisected to 4cd13c21b207 "softirq: Let ksoftirqd do its job"

On Wed, Nov 23, 2016 at 10:21 AM, Brian Starkey wrote: > This patch didn't help. > > I did get some new traces though - I've attached the diff for the > trace_printks I added. > > Before 4cd13c21b207: > https://drive.google.com/open?id=0B8siaK6ZjvEwcEtOeFQzTmY0Nnc > After 4cd13c21b207: >

Re: [PATCH v5 1/3] tpm: move event log init functions to tpm_eventlog_init.c

On Wed, Nov 23, 2016 at 12:27:35PM -0500, Nayna Jain wrote: > The device driver code for the event log has the init functions and > TPM 1.2 parsing logic both defined in same file(tpm_eventlog.c). > > Since the initialization functions are common with the TPM 2.0 event > log support, this patch

Re: [PATCH v5 1/3] tpm: move event log init functions to tpm_eventlog_init.c

On Wed, Nov 23, 2016 at 12:27:35PM -0500, Nayna Jain wrote: > The device driver code for the event log has the init functions and > TPM 1.2 parsing logic both defined in same file(tpm_eventlog.c). > > Since the initialization functions are common with the TPM 2.0 event > log support, this patch

Re: bio linked list corruption.

On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote: > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4 > trace from just before this happened. Does this shed any light ? > > https://codemonkey.org.uk/junk/trace.txt crap, I just noticed the timestamps in the

Re: bio linked list corruption.

On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote: > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4 > trace from just before this happened. Does this shed any light ? > > https://codemonkey.org.uk/junk/trace.txt crap, I just noticed the timestamps in the

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On Wed, Nov 23, 2016 at 02:25:51PM +0100, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 6:30 PM, Thierry Reding > wrote: > > > So I don't really know how to go about merging both. I'll reply to this > > email later with a copy of the patch that I wrote, maybe we can

Re: [PATCH] gpio: tegra186: Add support for T186 GPIO

On Wed, Nov 23, 2016 at 02:25:51PM +0100, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 6:30 PM, Thierry Reding > wrote: > > > So I don't really know how to go about merging both. I'll reply to this > > email later with a copy of the patch that I wrote, maybe we can take it > > from there. > >

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-23 02:12 PM, Jason Gunthorpe wrote: On Wed, Nov 23, 2016 at 10:40:47AM -0800, Dan Williams wrote: I don't think that was designed for the case where the backing memory is a special/static physical address range rather than anonymous "System RAM", right? The hardware doesn't care

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-23 02:12 PM, Jason Gunthorpe wrote: On Wed, Nov 23, 2016 at 10:40:47AM -0800, Dan Williams wrote: I don't think that was designed for the case where the backing memory is a special/static physical address range rather than anonymous "System RAM", right? The hardware doesn't care

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

On Wed, Nov 23, 2016 at 11:31:52AM -0600, Bjorn Helgaas wrote: > On Mon, Nov 21, 2016 at 10:53:52AM -0600, Bjorn Helgaas wrote: > > On Wed, Nov 16, 2016 at 12:11:58PM -0600, Bjorn Helgaas wrote: > > > Hi Johannes, > > > > > > On Wed, Nov 02, 2016 at 04:35:52PM -0600, Johannes Thumshirn wrote: > >

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

On Wed, Nov 23, 2016 at 11:31:52AM -0600, Bjorn Helgaas wrote: > On Mon, Nov 21, 2016 at 10:53:52AM -0600, Bjorn Helgaas wrote: > > On Wed, Nov 16, 2016 at 12:11:58PM -0600, Bjorn Helgaas wrote: > > > Hi Johannes, > > > > > > On Wed, Nov 02, 2016 at 04:35:52PM -0600, Johannes Thumshirn wrote: > >

[PATCH] x86/coredump: always use user_regs_struct for compat_elf_gregset_t

>From commit 90954e7b9407 ("x86/coredump: Use pr_reg size, rather that TIF_IA32 flag") elf coredump file is constructed according to register set size - and that's good: if binary crashes with 32-bit code selector, generate 32-bit ELF core, otherwise - 64-bit core. That was made for restoring

[PATCH] x86/coredump: always use user_regs_struct for compat_elf_gregset_t

>From commit 90954e7b9407 ("x86/coredump: Use pr_reg size, rather that TIF_IA32 flag") elf coredump file is constructed according to register set size - and that's good: if binary crashes with 32-bit code selector, generate 32-bit ELF core, otherwise - 64-bit core. That was made for restoring

Re: [PATCH 3/6] arc: Use full path in KBUILD_IMAGE definition

Hi Michal, On Tue, 2016-11-22 at 22:34 +0100, Michal Marek wrote: > The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which > expect it to point to the image file in the build directory. The > builddeb script has a workaround for architectures which only provide > the basename,

[PATCH V3 for-next 00/11] Code improvements & fixes for HNS RoCE driver

This patchset introduces some code improvements and fixes for the identified problems in the HNS RoCE driver. Lijun Ou (4): IB/hns: Add the interface for querying QP1 IB/hns: add self loopback for CM IB/hns: Modify the condition of notifying hardware loopback IB/hns: Fix the bug for qp

[PATCH V3 for-next 01/11] IB/hns: Add the interface for querying QP1

From: Lijun Ou In old code, It only added the interface for querying non-specific QP. This patch mainly adds an interface for querying QP1. Signed-off-by: Lijun Ou Reviewed-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta

[PATCH V3 for-next 00/11] Code improvements & fixes for HNS RoCE driver

This patchset introduces some code improvements and fixes for the identified problems in the HNS RoCE driver. Lijun Ou (4): IB/hns: Add the interface for querying QP1 IB/hns: add self loopback for CM IB/hns: Modify the condition of notifying hardware loopback IB/hns: Fix the bug for qp

[PATCH V3 for-next 01/11] IB/hns: Add the interface for querying QP1

From: Lijun Ou In old code, It only added the interface for querying non-specific QP. This patch mainly adds an interface for querying QP1. Signed-off-by: Lijun Ou Reviewed-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta --- Change Log Patch V2: Addressed the comment provided by Anurup M

Re: [PATCH 3/6] arc: Use full path in KBUILD_IMAGE definition

Hi Michal, On Tue, 2016-11-22 at 22:34 +0100, Michal Marek wrote: > The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which > expect it to point to the image file in the build directory. The > builddeb script has a workaround for architectures which only provide > the basename,

[PATCH V3 for-next 04/11] IB/hns: add self loopback for CM

From: Lijun Ou This patch mainly adds self loopback support for CM. Signed-off-by: Lijun Ou Signed-off-by: Peter Chen Reviewed-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta ---

[PATCH V3 for-next 04/11] IB/hns: add self loopback for CM

From: Lijun Ou This patch mainly adds self loopback support for CM. Signed-off-by: Lijun Ou Signed-off-by: Peter Chen Reviewed-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 11 +++ drivers/infiniband/hw/hns/hns_roce_hw_v1.h |

[PATCH V3 for-next 06/11] IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()

From: Lijun Ou In old code, the value of qp state from qpc was assigned for attr->qp_state. The value may be an error while attr_mask & IB_QP_STATE is zero. Signed-off-by: Lijun Ou Reviewed-by: Wei Hu (Xavier) Signed-off-by:

[PATCH V3 for-next 07/11] IB/hns: Modify the macro for the timeout when cmd process

From: "Wei Hu (Xavier)" This patch modified the macro for the timeout when cmd is processing as follows: Before modification: enum { HNS_ROCE_CMD_TIME_CLASS_A = 1, HNS_ROCE_CMD_TIME_CLASS_B = 1, HNS_ROCE_CMD_TIME_CLASS_C

[PATCH V3 for-next 09/11] IB/hns: Change qpn allocation to round-robin mode.

From: "Wei Hu (Xavier)" When using CM to establish connections, qp number that was freed just now will be rejected by ib core. To fix these problem, We change qpn allocation to round-robin mode. We added the round-robin mode for allocating resources using bitmap. We use

Re: [PATCH] gpio: Add Tegra186 support

On Wed, Nov 23, 2016 at 02:30:45PM +0100, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 6:55 PM, Thierry Reding > wrote: > > > From: Thierry Reding > > > > Tegra186 has two GPIO controllers that are largely register compatible > > between one

[PATCH V3 for-next 06/11] IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()

From: Lijun Ou In old code, the value of qp state from qpc was assigned for attr->qp_state. The value may be an error while attr_mask & IB_QP_STATE is zero. Signed-off-by: Lijun Ou Reviewed-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_hw_v1.c |2

[PATCH V3 for-next 07/11] IB/hns: Modify the macro for the timeout when cmd process

From: "Wei Hu (Xavier)" This patch modified the macro for the timeout when cmd is processing as follows: Before modification: enum { HNS_ROCE_CMD_TIME_CLASS_A = 1, HNS_ROCE_CMD_TIME_CLASS_B = 1, HNS_ROCE_CMD_TIME_CLASS_C = 1, }; After

Re: [PATCH] gpio: Add Tegra186 support

On Wed, Nov 23, 2016 at 02:30:45PM +0100, Linus Walleij wrote: > On Tue, Nov 22, 2016 at 6:55 PM, Thierry Reding > wrote: > > > From: Thierry Reding > > > > Tegra186 has two GPIO controllers that are largely register compatible > > between one another but are completely different from the

[PATCH V3 for-next 09/11] IB/hns: Change qpn allocation to round-robin mode.

From: "Wei Hu (Xavier)" When using CM to establish connections, qp number that was freed just now will be rejected by ib core. To fix these problem, We change qpn allocation to round-robin mode. We added the round-robin mode for allocating resources using bitmap. We use round-robin mode for qp

[PATCH V3 for-next 11/11] IB/hns: Fix for Checkpatch.pl comment style errors

This patch correct the comment style errors caught by checkpatch.pl script Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_cmd.c|8 ++-- drivers/infiniband/hw/hns/hns_roce_device.h | 28 ++--- drivers/infiniband/hw/hns/hns_roce_eq.c

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-23 03:51 AM, Christian König wrote: Am 23.11.2016 um 08:49 schrieb Daniel Vetter: On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote: On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote: On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch

[PATCH V3 for-next 08/11] IB/hns: Modify query info named port_num when querying RC QP

From: "Wei Hu (Xavier)" This patch modified the output query info qp_attr->port_num to fix bug in hip06. Signed-off-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_hw_v1.c |4

[PATCH V3 for-next 08/11] IB/hns: Modify query info named port_num when querying RC QP

From: "Wei Hu (Xavier)" This patch modified the output query info qp_attr->port_num to fix bug in hip06. Signed-off-by: Wei Hu (Xavier) Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_hw_v1.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

[PATCH V3 for-next 11/11] IB/hns: Fix for Checkpatch.pl comment style errors

This patch correct the comment style errors caught by checkpatch.pl script Signed-off-by: Salil Mehta --- drivers/infiniband/hw/hns/hns_roce_cmd.c|8 ++-- drivers/infiniband/hw/hns/hns_roce_device.h | 28 ++--- drivers/infiniband/hw/hns/hns_roce_eq.c |6 +--

Re: Enabling peer to peer device transactions for PCIe devices

On 2016-11-23 03:51 AM, Christian König wrote: Am 23.11.2016 um 08:49 schrieb Daniel Vetter: On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote: On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote: On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch wrote: On 2016-11-22 03:10

[PATCH V3 for-next 10/11] IB/hns: Implement the add_gid/del_gid and optimize the GIDs management

From: Shaobo Xu IB core has implemented the calculation of GIDs and the management of GID tables, and it is now responsible to supply query function for GIDs. So the calculation of GIDs and the management of GID tables in the RoCE driver is redundant. The patch is to

[PATCH V3 for-next 05/11] IB/hns: Modify the condition of notifying hardware loopback

From: Lijun Ou This patch modified the condition of notifying hardware loopback. In hip06, RoCE Engine has several ports, one QP is related to one port. hardware only support loopback in the same port, not in the different ports. So, If QP related to port N, the dmac in the

[PATCH V3 for-next 10/11] IB/hns: Implement the add_gid/del_gid and optimize the GIDs management

From: Shaobo Xu IB core has implemented the calculation of GIDs and the management of GID tables, and it is now responsible to supply query function for GIDs. So the calculation of GIDs and the management of GID tables in the RoCE driver is redundant. The patch is to implement the

[PATCH V3 for-next 05/11] IB/hns: Modify the condition of notifying hardware loopback

From: Lijun Ou This patch modified the condition of notifying hardware loopback. In hip06, RoCE Engine has several ports, one QP is related to one port. hardware only support loopback in the same port, not in the different ports. So, If QP related to port N, the dmac in the QP context equals

Re: [PATCH 2/4] serial: 8250: Add LED trigger support

Hi Sascha, [auto build test ERROR on tty/tty-testing] [also build test ERROR on v4.9-rc6 next-20161123] [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/Sascha-Hauer/serial-core-Add-LED-trigger

Re: [PATCH 2/4] serial: 8250: Add LED trigger support

Hi Sascha, [auto build test ERROR on tty/tty-testing] [also build test ERROR on v4.9-rc6 next-20161123] [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/Sascha-Hauer/serial-core-Add-LED-trigger

[PATCH V3 for-next 02/11] IB/hns: Add code for refreshing CQ CI using TPTR

From: "Wei Hu (Xavier)" This patch added the code for refreshing CQ CI using TPTR in hip06 SoC. We will send a doorbell to hardware for refreshing CQ CI when user succeed to poll a cqe. But it will be failed if the doorbell has been blocked. So hardware will read a

[PATCH V3 for-next 02/11] IB/hns: Add code for refreshing CQ CI using TPTR

From: "Wei Hu (Xavier)" This patch added the code for refreshing CQ CI using TPTR in hip06 SoC. We will send a doorbell to hardware for refreshing CQ CI when user succeed to poll a cqe. But it will be failed if the doorbell has been blocked. So hardware will read a special buffer called TPTR to

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