[PATCH v2 9/9] arm: tegra: set hot trips for Tegra124

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm/boot/dts/tegra124.dtsi | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-)

[PATCH v2 3/9] arm64: tegra: set critical trips for Tegra132

Set general "critical" trip temperatures for cpu, gpu, mem and pllx thermal zones on Tegra132, these trips can trigger shut down or reset. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 60 1 file changed, 60 insertions(+) diff --git

[PATCH v2 8/9] arm64: tegra: set hot trips for Tegra132

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 41 +--- 1 file changed, 32 insertions(+),

[PATCH v2 4/9] of: Add bindings of hw throttle for soctherm

Add HW throttle configuration sub-node for soctherm, which is used to describe the throttle event, and worked as a cooling device. The "hot" type trip in thermal zone can be bound to this cooling device, and trigger the throttle function. Signed-off-by: Wei Ni ---

[PATCH v2 8/9] arm64: tegra: set hot trips for Tegra132

Enable throttle function for SOC_THERM. Set "hot" trips for cpu and gpu thermal zones, which can trigger the SOC_THERM hardware throttle. Signed-off-by: Wei Ni --- arch/arm64/boot/dts/nvidia/tegra132.dtsi | 41 +--- 1 file changed, 32 insertions(+), 9 deletions(-)

[PATCH v2 4/9] of: Add bindings of hw throttle for soctherm

Add HW throttle configuration sub-node for soctherm, which is used to describe the throttle event, and worked as a cooling device. The "hot" type trip in thermal zone can be bound to this cooling device, and trigger the throttle function. Signed-off-by: Wei Ni ---

[PATCH V2 6/7] cpufreq: dt: Kill platform-data

There are no more users of platform-data for cpufreq-dt driver, get rid of it. Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd --- drivers/cpufreq/cpufreq-dt.c | 6 +- include/linux/cpufreq-dt.h | 24 2 files

[PATCH V2 6/7] cpufreq: dt: Kill platform-data

There are no more users of platform-data for cpufreq-dt driver, get rid of it. Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd --- drivers/cpufreq/cpufreq-dt.c | 6 +- include/linux/cpufreq-dt.h | 24 2 files changed, 1 insertion(+), 29 deletions(-)

[PATCH V2 7/7] cpufreq: mvebu: Move cpufreq code into drivers/cpufreq/

Move cpufreq bits for mvebu into drivers/cpufreq/ directory, that's where they really belong to. Compiled tested only. Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

On Tue, Apr 26, 2016 at 04:21:07PM +0800, Peter Chen wrote: > On Tue, Apr 26, 2016 at 07:00:22AM +, Jun Li wrote: > > Hi > > > > > -Original Message- > > > From: Peter Chen [mailto:hzpeterc...@gmail.com] > > > Sent: Tuesday, April 26, 2016 2:28 PM > > > To: Jun Li > >

[PATCH V2 7/7] cpufreq: mvebu: Move cpufreq code into drivers/cpufreq/

Move cpufreq bits for mvebu into drivers/cpufreq/ directory, that's where they really belong to. Compiled tested only. Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Signed-off-by: Viresh Kumar --- MAINTAINERS | 1

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

On Tue, Apr 26, 2016 at 04:21:07PM +0800, Peter Chen wrote: > On Tue, Apr 26, 2016 at 07:00:22AM +, Jun Li wrote: > > Hi > > > > > -Original Message- > > > From: Peter Chen [mailto:hzpeterc...@gmail.com] > > > Sent: Tuesday, April 26, 2016 2:28 PM > > > To: Jun Li > > > Cc: Roger

[PATCH V2 2/7] PM / OPP: Mark cpumask as const in dev_pm_opp_set_sharing_cpus()

dev_pm_opp_set_sharing_cpus() isn't supposed to update the cpumask passed as its parameter, and so it should always have been marked 'const'. Do it now. Signed-off-by: Viresh Kumar --- drivers/base/power/opp/cpu.c | 3 ++- include/linux/pm_opp.h | 4 ++-- 2 files

[PATCH V2 2/7] PM / OPP: Mark cpumask as const in dev_pm_opp_set_sharing_cpus()

dev_pm_opp_set_sharing_cpus() isn't supposed to update the cpumask passed as its parameter, and so it should always have been marked 'const'. Do it now. Signed-off-by: Viresh Kumar --- drivers/base/power/opp/cpu.c | 3 ++- include/linux/pm_opp.h | 4 ++-- 2 files changed, 4

[PATCH V2 4/7] cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2

Existing platforms, which do not support operating-points-v2, can explicitly tell the opp core that some of the CPUs share opp tables, with help of dev_pm_opp_set_sharing_cpus(). For such platforms, explicitly ask the opp core to provide list of CPUs sharing the opp table with current cpu device,

[PATCH V2 3/7] PM / OPP: Add dev_pm_opp_get_sharing_cpus()

OPP core allows a platform to mark OPP table as shared, when the platform isn't using operating-points-v2 bindings. And, so there should be a non DT way of finding out if the OPP table is shared or not. This patch adds dev_pm_opp_get_sharing_cpus(), which first tries to get OPP sharing

[PATCH V2 1/7] PM / OPP: -ENOSYS is applicable only to syscalls

Some of the routines have used -ENOSYS for the cases where the functionality isn't implemented in the kernel. But ENOSYS is supposed to be used only for syscalls. Replace that with -ENOTSUPP, which specifically means that the operation isn't supported. While at it, replace exiting -EINVAL errors

[PATCH V2 1/7] PM / OPP: -ENOSYS is applicable only to syscalls

Some of the routines have used -ENOSYS for the cases where the functionality isn't implemented in the kernel. But ENOSYS is supposed to be used only for syscalls. Replace that with -ENOTSUPP, which specifically means that the operation isn't supported. While at it, replace exiting -EINVAL errors

[PATCH V2 4/7] cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2

Existing platforms, which do not support operating-points-v2, can explicitly tell the opp core that some of the CPUs share opp tables, with help of dev_pm_opp_set_sharing_cpus(). For such platforms, explicitly ask the opp core to provide list of CPUs sharing the opp table with current cpu device,

[PATCH V2 3/7] PM / OPP: Add dev_pm_opp_get_sharing_cpus()

OPP core allows a platform to mark OPP table as shared, when the platform isn't using operating-points-v2 bindings. And, so there should be a non DT way of finding out if the OPP table is shared or not. This patch adds dev_pm_opp_get_sharing_cpus(), which first tries to get OPP sharing

[PATCH V2 5/7] mvebu: Use dev_pm_opp_set_sharing_cpus() to mark OPP tables as shared

That will allow us to avoid using cpufreq-dt platform data. Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth

[PATCH V2 5/7] mvebu: Use dev_pm_opp_set_sharing_cpus() to mark OPP tables as shared

That will allow us to avoid using cpufreq-dt platform data. Cc: Thomas Petazzoni Cc: Jason Cooper Cc: Andrew Lunn Cc: Gregory Clement Cc: Sebastian Hesselbarth Signed-off-by: Viresh Kumar --- arch/arm/mach-mvebu/pmsu.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-)

RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Cathy Avery [mailto:cav...@redhat.com] > Sent: Wednesday, April 27, 2016 0:19 > To: Dexuan Cui ; gre...@linuxfoundation.org; > da...@davemloft.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Jason Wang >

RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Cathy Avery [mailto:cav...@redhat.com] > Sent: Wednesday, April 27, 2016 0:19 > To: Dexuan Cui ; gre...@linuxfoundation.org; > da...@davemloft.net; net...@vger.kernel.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Jason Wang > ; KY Srinivasan ; Haiyang

[lkp] [mm, oom] faad2185f4: vm-scalability.throughput -11.8% regression

FYI, we noticed vm-scalability.throughput -11.8% regression with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit faad2185f482578d50d363746006a1b95dde9d0a ("mm, oom: rework oom detection") on test machine: lkp-hsw-ep2: 72 threads Brickland

[lkp] [mm, oom] faad2185f4: vm-scalability.throughput -11.8% regression

FYI, we noticed vm-scalability.throughput -11.8% regression with the following commit: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit faad2185f482578d50d363746006a1b95dde9d0a ("mm, oom: rework oom detection") on test machine: lkp-hsw-ep2: 72 threads Brickland

Re: [PATCH 1/2] bfp tools: Remove expression with no effect

On 2016/4/25 10:34, Florian Fainelli wrote: Assigning "attr" to "attr" does not have any effect, but was caught by Coverity, so let's remove this. Reported-by: coverity (CID 1354720) Fixes: 1b76c13e4b36 ("bpf tools: Introduce 'bpf' library and add bpf feature check") Signed-off-by: Florian

Re: [PATCH 1/2] bfp tools: Remove expression with no effect

On 2016/4/25 10:34, Florian Fainelli wrote: Assigning "attr" to "attr" does not have any effect, but was caught by Coverity, so let's remove this. Reported-by: coverity (CID 1354720) Fixes: 1b76c13e4b36 ("bpf tools: Introduce 'bpf' library and add bpf feature check") Signed-off-by: Florian

[PATCH] media: fix media_ioctl use-after-free when driver unbinds

When driver unbind is run while media_ioctl is in progress, media_ioctl() fails with use-after-free. This first use-after-free is followed by more user-after-free errors in media_release(), kobject_put(), and cdev_put() as driver unbind continues. This problem is found on uvcvideo, em28xx, and

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

On Wed, Apr 27, 2016 at 11:00:23AM +0800, Wangnan (F) wrote: > > > On 2016/4/27 10:46, Florian Fainelli wrote: > >Le 24/04/2016 19:34, Florian Fainelli a écrit : > >>Hi all, > >> > >>Two trivial patches that were flagged by Coverity. > >> > >>Thanks! > >Ping! Did I send this to the correct

[PATCH] media: fix media_ioctl use-after-free when driver unbinds

When driver unbind is run while media_ioctl is in progress, media_ioctl() fails with use-after-free. This first use-after-free is followed by more user-after-free errors in media_release(), kobject_put(), and cdev_put() as driver unbind continues. This problem is found on uvcvideo, em28xx, and

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

On Wed, Apr 27, 2016 at 11:00:23AM +0800, Wangnan (F) wrote: > > > On 2016/4/27 10:46, Florian Fainelli wrote: > >Le 24/04/2016 19:34, Florian Fainelli a écrit : > >>Hi all, > >> > >>Two trivial patches that were flagged by Coverity. > >> > >>Thanks! > >Ping! Did I send this to the correct

RE: [PATCH 0/3] [RFC] Write dump into container's filesystem for pipe_type core_pattern

Ping Thanks Zhaolei > From: Zhao Lei [mailto:zhao...@cn.fujitsu.com] > Sent: Friday, April 15, 2016 6:47 PM > To: linux-kernel@vger.kernel.org > Cc: contain...@lists.linux-foundation.org; Eric W. Biederman > ; Mateusz Guzik ; > Kamezawa Hiroyuki

RE: [PATCH 0/3] [RFC] Write dump into container's filesystem for pipe_type core_pattern

Ping Thanks Zhaolei > From: Zhao Lei [mailto:zhao...@cn.fujitsu.com] > Sent: Friday, April 15, 2016 6:47 PM > To: linux-kernel@vger.kernel.org > Cc: contain...@lists.linux-foundation.org; Eric W. Biederman > ; Mateusz Guzik ; > Kamezawa Hiroyuki ; Zhao Lei > > Subject: [PATCH 0/3] [RFC] Write

Re: [PATCH 2/2] bfp tools: Fix syscall argument

On 2016/4/25 10:34, Florian Fainelli wrote: Coverity flagged this under CID 1354884 as a sizeof mismatch, it turns out that the argument "attr" passed to syscall should have been a pointer to attr in the first place. Reported-by: coverity (CID 1354884) Fixes: 8f9e05fb298f ("perf tools: Fix

Re: [PATCH 2/2] bfp tools: Fix syscall argument

On 2016/4/25 10:34, Florian Fainelli wrote: Coverity flagged this under CID 1354884 as a sizeof mismatch, it turns out that the argument "attr" passed to syscall should have been a pointer to attr in the first place. Reported-by: coverity (CID 1354884) Fixes: 8f9e05fb298f ("perf tools: Fix

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

On 2016/4/27 10:46, Florian Fainelli wrote: Le 24/04/2016 19:34, Florian Fainelli a écrit : Hi all, Two trivial patches that were flagged by Coverity. Thanks! Ping! Did I send this to the correct mailing-list? Sorry for the late. You are on the right list :)

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

On 2016/4/27 10:46, Florian Fainelli wrote: Le 24/04/2016 19:34, Florian Fainelli a écrit : Hi all, Two trivial patches that were flagged by Coverity. Thanks! Ping! Did I send this to the correct mailing-list? Sorry for the late. You are on the right list :)

Re: [PATCH 06/10] PM / OPP: Add dev_pm_opp_get_sharing_cpus()

On 22-04-16, 15:21, Stephen Boyd wrote: > On 04/21, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c > > index 55cbf9bd8707..9c4eb90759fb 100644 > > --- a/drivers/base/power/opp/cpu.c > > +++ b/drivers/base/power/opp/cpu.c > > @@ -329,3 +329,48 @@

Re: [PATCH 06/10] PM / OPP: Add dev_pm_opp_get_sharing_cpus()

On 22-04-16, 15:21, Stephen Boyd wrote: > On 04/21, Viresh Kumar wrote: > > diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c > > index 55cbf9bd8707..9c4eb90759fb 100644 > > --- a/drivers/base/power/opp/cpu.c > > +++ b/drivers/base/power/opp/cpu.c > > @@ -329,3 +329,48 @@

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Wed, Apr 27, 2016 at 9:58 AM, Shawn Guo wrote: > On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: >> Shawn, >> What's your suggestion? > > I think this needs more discussion, and I just dropped Stefan's patch > from my tree. > > We need to firstly understand

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Wed, Apr 27, 2016 at 9:58 AM, Shawn Guo wrote: > On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: >> Shawn, >> What's your suggestion? > > I think this needs more discussion, and I just dropped Stefan's patch > from my tree. > > We need to firstly understand why this is happening.

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> We need to firstly understand why this is happening. The .prepare hook >> is defined to be non-atomic context, and so that we call sleep function >> in there. We did everything right. Why are we getting the warning?

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Tue, Apr 26, 2016 at 11:45 PM, Dong Aisheng wrote: >> We need to firstly understand why this is happening. The .prepare hook >> is defined to be non-atomic context, and so that we call sleep function >> in there. We did everything right. Why are we getting the warning? If >> I'm correct,

Re: [PATCH v4] ARM: dts: imx6: Add dts for Embest MarS Board

On Tue, Apr 26, 2016 at 08:38:22PM -0300, Sergio Prado wrote: > Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 > Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC > and with a 4MB SPI flash. > > [1] http://www.embest-tech.com/shop/star/marsboard.html >

Re: [PATCH v4] ARM: dts: imx6: Add dts for Embest MarS Board

On Tue, Apr 26, 2016 at 08:38:22PM -0300, Sergio Prado wrote: > Embest MarS Board [1] is a multi-core platform based on Freescale i.MX6 > Cortex-A9 Dual Core, running up to 1GHz with 1 GB of RAM, 4GB of eMMC > and with a 4MB SPI flash. > > [1] http://www.embest-tech.com/shop/star/marsboard.html >

Re: [PATCH 1/2] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset

2016-02-09 0:29 GMT+08:00 Bruce Rogers : On 2/8/2016 at 08:09 AM, Paolo Bonzini wrote: > >> >> On 03/02/2016 23:51, Bruce Rogers wrote: >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index e2951b6..21507b4 100644 >>> ---

Re: [PATCH 1/2] KVM: x86: fix ordering of cr0 initialization code in vmx_cpu_reset

2016-02-09 0:29 GMT+08:00 Bruce Rogers : On 2/8/2016 at 08:09 AM, Paolo Bonzini wrote: > >> >> On 03/02/2016 23:51, Bruce Rogers wrote: >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index e2951b6..21507b4 100644 >>> --- a/arch/x86/kvm/vmx.c >>> +++ b/arch/x86/kvm/vmx.c >>>

RE: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device

> On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin...@intel.com wrote: > > From: "Du, Changbin" > > > > This is a reworked patch based on reverted commit d8f00cd685f5 ("usb: > > hub: do not clear BOS field during reset device"). > > > > The privious one caused double

RE: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device

> On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin...@intel.com wrote: > > From: "Du, Changbin" > > > > This is a reworked patch based on reverted commit d8f00cd685f5 ("usb: > > hub: do not clear BOS field during reset device"). > > > > The privious one caused double mem-free if run to

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

Le 24/04/2016 19:34, Florian Fainelli a écrit : > Hi all, > > Two trivial patches that were flagged by Coverity. > > Thanks! Ping! Did I send this to the correct mailing-list? -- Florian

Re: [PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

On 22-04-16, 15:59, One Thousand Gnomes wrote: > On Fri, 22 Apr 2016 14:42:31 +0200 > "Rafael J. Wysocki" wrote: > > > On Friday, April 22, 2016 08:46:51 AM Viresh Kumar wrote: > > > Some of the routines have use -ENOSYS, which is supposed to be used only > > > for syscalls.

Re: [PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

On 22-04-16, 15:59, One Thousand Gnomes wrote: > On Fri, 22 Apr 2016 14:42:31 +0200 > "Rafael J. Wysocki" wrote: > > > On Friday, April 22, 2016 08:46:51 AM Viresh Kumar wrote: > > > Some of the routines have use -ENOSYS, which is supposed to be used only > > > for syscalls. Replace that with

Re: [PATCH 0/2] bfp tools: Couple Coverity fixes

Le 24/04/2016 19:34, Florian Fainelli a écrit : > Hi all, > > Two trivial patches that were flagged by Coverity. > > Thanks! Ping! Did I send this to the correct mailing-list? -- Florian

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Wed, Apr 27, 2016 at 9:58 AM, Shawn Guo wrote: > On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: >> Shawn, >> What's your suggestion? > > I think this needs more discussion, and I just dropped Stefan's patch > from my tree. > > We need to firstly understand

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Wed, Apr 27, 2016 at 9:58 AM, Shawn Guo wrote: > On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: >> Shawn, >> What's your suggestion? > > I think this needs more discussion, and I just dropped Stefan's patch > from my tree. > > We need to firstly understand why this is happening.

Re: [PATCH V6 01/13] pci, acpi, x86, ia64: Move ACPI host bridge device companion assignment to core code.

[question for Rafael below] On Fri, Apr 15, 2016 at 07:06:36PM +0200, Tomasz Nowicki wrote: > Currently we have two platforms (x86 & ia64) capable of PCI ACPI host > bridge initialization. They both use arch-specific sysdata to pass down > parent device reference and both rely on NULL parent in

Re: [PATCH V6 01/13] pci, acpi, x86, ia64: Move ACPI host bridge device companion assignment to core code.

[question for Rafael below] On Fri, Apr 15, 2016 at 07:06:36PM +0200, Tomasz Nowicki wrote: > Currently we have two platforms (x86 & ia64) capable of PCI ACPI host > bridge initialization. They both use arch-specific sysdata to pass down > parent device reference and both rely on NULL parent in

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

On 27 Apr 2016 04:56, Dmitry V. Levin wrote: > Do not load one entry beyond the end of the syscall table when the > syscall number of a traced process equals to __NR_Linux_syscalls. > Similar bug with regular processes was fixed by commit 3bb457af4fa8 > ("[PARISC] Fix bug when syscall nr is

Re: [PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

On 27 Apr 2016 04:56, Dmitry V. Levin wrote: > Do not load one entry beyond the end of the syscall table when the > syscall number of a traced process equals to __NR_Linux_syscalls. > Similar bug with regular processes was fixed by commit 3bb457af4fa8 > ("[PARISC] Fix bug when syscall nr is

Re: [PATCH V6 06/13] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code.

On Fri, Apr 15, 2016 at 07:06:41PM +0200, Tomasz Nowicki wrote: > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > should include ACPI specific callbacks that parse and set-up the > device IRQ number, equivalent to the DT boot path. Owing to the current > ACPI core scan

Re: [PATCH V6 06/13] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code.

On Fri, Apr 15, 2016 at 07:06:41PM +0200, Tomasz Nowicki wrote: > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > should include ACPI specific callbacks that parse and set-up the > device IRQ number, equivalent to the DT boot path. Owing to the current > ACPI core scan

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: > Platforms that have memory mapped IO port (such as ARM64) need special > handling for PCI I/O resources. For host bridge's resource probing case > these resources need to be fixed up with > pci_register_io_range/pci_remap_iospace

Re: [PATCH V6 05/13] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Fri, Apr 15, 2016 at 07:06:40PM +0200, Tomasz Nowicki wrote: > Platforms that have memory mapped IO port (such as ARM64) need special > handling for PCI I/O resources. For host bridge's resource probing case > these resources need to be fixed up with > pci_register_io_range/pci_remap_iospace

Re: [PATCH V6 03/13] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.

On Fri, Apr 15, 2016 at 07:06:38PM +0200, Tomasz Nowicki wrote: > x86 and ia64 are the only arches that implement pcibios_{add|remove}_bus hooks > and implement them in the same way. Moreover ARM64 is going to do the same. > So it seems that acpi_pci_{add|remove}_bus is generic enough to be

Re: [PATCH V6 03/13] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.

On Fri, Apr 15, 2016 at 07:06:38PM +0200, Tomasz Nowicki wrote: > x86 and ia64 are the only arches that implement pcibios_{add|remove}_bus hooks > and implement them in the same way. Moreover ARM64 is going to do the same. > So it seems that acpi_pci_{add|remove}_bus is generic enough to be

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_dp.c between commit: 86ee27b5aa75 ("drm/i915: Read eDP Display control capability registers") from the drm-intel tree and commit: 9f085ebb1a50 ("rm/i915: Get rid of

linux-next: manual merge of the drm-misc tree with the drm-intel tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/i915/intel_dp.c between commit: 86ee27b5aa75 ("drm/i915: Read eDP Display control capability registers") from the drm-intel tree and commit: 9f085ebb1a50 ("rm/i915: Get rid of

Re: [RFC v6 00/10] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table

On 2016/4/27 0:40, Alex Williamson wrote: On Mon, 25 Apr 2016 18:05:53 +0800 Yongji Xie wrote: Hi Alex, Any comment? TBH, I shuffled this to the bottom of the review pile because you're depending on a patch series for ARM MSI mapping that's still very much in

Re: [RFC v6 00/10] vfio-pci: Allow to mmap sub-page MMIO BARs and MSI-X table

On 2016/4/27 0:40, Alex Williamson wrote: On Mon, 25 Apr 2016 18:05:53 +0800 Yongji Xie wrote: Hi Alex, Any comment? TBH, I shuffled this to the bottom of the review pile because you're depending on a patch series for ARM MSI mapping that's still very much in flux. You've really got 3 or

Please consider using __vring_new_virtqueue in mic_virtio

mic_virtio has a big hack to set up a custom ring, like this: /* * To reassign the used ring here we are directly accessing * struct vring_virtqueue which is a private data structure * in virtio_ring.c. At the minimum, a BUILD_BUG_ON() in *

Please consider using __vring_new_virtqueue in mic_virtio

mic_virtio has a big hack to set up a custom ring, like this: /* * To reassign the used ring here we are directly accessing * struct vring_virtqueue which is a private data structure * in virtio_ring.c. At the minimum, a BUILD_BUG_ON() in *

Re: [PATCH V6 02/13] pci, acpi: Provide generic way to assign bus domain number.

On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote: > As we now have valid PCI host bridge device reference we can > introduce code that is going to find its bus domain number using > ACPI _SEG method. > > Note that _SEG method is optional, therefore _SEG absence means > that all PCI

Re: [PATCH V6 02/13] pci, acpi: Provide generic way to assign bus domain number.

On Fri, Apr 15, 2016 at 07:06:37PM +0200, Tomasz Nowicki wrote: > As we now have valid PCI host bridge device reference we can > introduce code that is going to find its bus domain number using > ACPI _SEG method. > > Note that _SEG method is optional, therefore _SEG absence means > that all PCI

[PATCH v2 0/4] perf tools: Backward ring buffer support

Commit 9ecda41acb97 ("perf/core: Add ::write_backward attribute to perf event") introduces backward ring buffer. This 4 patches add basic support for reading from it, and add a new test case for it. v1 -> v2: Patch 1/5 in v1 has been collected by perf/core, so remove it; Change function names

[PATCH v2 2/4] perf tools: Rename variable in perf_mmap__read()

In perf_mmap__read(), give better names to pointers. Origianl name 'old' and 'head' directly related to pointers in ring buffer control page. For backward ring buffer, the meaning of 'head' point is not 'the first byte of free space', but 'the first byte of the last record'. To reduce confusion,

[PATCH v2 3/4] perf tools: Support reading from backward ring buffer

perf_evlist__mmap_read_backward() is introduced for reading backward ring buffer. Different from reading forward, before reading, caller needs to call perf_evlist__mmap_read_catchup() first. Backward ring buffer should be read from 'head' pointer, not '0'. perf_evlist__mmap_read_catchup() saves

[PATCH v2 0/4] perf tools: Backward ring buffer support

Commit 9ecda41acb97 ("perf/core: Add ::write_backward attribute to perf event") introduces backward ring buffer. This 4 patches add basic support for reading from it, and add a new test case for it. v1 -> v2: Patch 1/5 in v1 has been collected by perf/core, so remove it; Change function names

[PATCH v2 2/4] perf tools: Rename variable in perf_mmap__read()

In perf_mmap__read(), give better names to pointers. Origianl name 'old' and 'head' directly related to pointers in ring buffer control page. For backward ring buffer, the meaning of 'head' point is not 'the first byte of free space', but 'the first byte of the last record'. To reduce confusion,

[PATCH v2 3/4] perf tools: Support reading from backward ring buffer

perf_evlist__mmap_read_backward() is introduced for reading backward ring buffer. Different from reading forward, before reading, caller needs to call perf_evlist__mmap_read_catchup() first. Backward ring buffer should be read from 'head' pointer, not '0'. perf_evlist__mmap_read_catchup() saves

[PATCH v2 1/4] perf tools: Extract perf_mmap__read()

Extract event reader from perf_evlist__mmap_read() to perf__mmap_read(). Future commit will feed it with manually computed 'head' and 'old' pointers. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Cc: Zefan Li

[PATCH v2 4/4] perf tests: Add test to check backward ring buffer

This test checks reading from backward ring buffer. Test result: # ~/perf test 'ring buffer' 45: Test backward reading from ring buffer : Ok Test case is a while loop which calls prctl(PR_SET_NAME) multiple times. Each prctl should issue 2 events: one PERF_RECORD_SAMPLE, one

[PATCH v2 1/4] perf tools: Extract perf_mmap__read()

Extract event reader from perf_evlist__mmap_read() to perf__mmap_read(). Future commit will feed it with manually computed 'head' and 'old' pointers. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Peter Zijlstra Cc: Zefan Li Cc: pi3or...@163.com --- tools/perf/util/evlist.c | 39

[PATCH v2 4/4] perf tests: Add test to check backward ring buffer

This test checks reading from backward ring buffer. Test result: # ~/perf test 'ring buffer' 45: Test backward reading from ring buffer : Ok Test case is a while loop which calls prctl(PR_SET_NAME) multiple times. Each prctl should issue 2 events: one PERF_RECORD_SAMPLE, one

RE: [PATCH] arm64: fix /proc/cpuinfo for elf32

> -Original Message- > From: Suzuki K Poulose [mailto:suzuki.poul...@arm.com] > Sent: Tuesday, April 26, 2016 5:21 PM > To: Zengtao (B); Catalin Marinas > Cc: will.dea...@arm.com; mark.rutl...@arm.com; yang@linaro.org; > linux-kernel@vger.kernel.org; james.mo...@arm.com; >

RE: [PATCH] arm64: fix /proc/cpuinfo for elf32

> -Original Message- > From: Suzuki K Poulose [mailto:suzuki.poul...@arm.com] > Sent: Tuesday, April 26, 2016 5:21 PM > To: Zengtao (B); Catalin Marinas > Cc: will.dea...@arm.com; mark.rutl...@arm.com; yang@linaro.org; > linux-kernel@vger.kernel.org; james.mo...@arm.com; >

Re: [PATCH] cpufreq: Use IS_ENABLED() instead of checking for built-in or module

On 26-04-16, 20:14, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas > > --- > >

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/macsec.c between commit: 748164802c1b ("macsec: add missing macsec prefix in uapi") from the net tree and commit: f60d94c00968 ("macsec: use nla_put_u64_64bit()") from the net-next tree. I fixed it

Re: [PATCH] cpufreq: Use IS_ENABLED() instead of checking for built-in or module

On 26-04-16, 20:14, Javier Martinez Canillas wrote: > The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either > built-in or as a module, use that macro instead of open coding the same. > > Signed-off-by: Javier Martinez Canillas > > --- > > drivers/cpufreq/e_powersaver.c

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/macsec.c between commit: 748164802c1b ("macsec: add missing macsec prefix in uapi") from the net tree and commit: f60d94c00968 ("macsec: use nla_put_u64_64bit()") from the net-next tree. I fixed it

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_main.c between commit: d8edd2469ace ("et/mlx5e: Fix minimum MTU") from the net tree and commit: 0e405443e803 ("net/mlx5e: Improve set features ndo resiliency") from the

linux-next: manual merge of the net-next tree with the net tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: drivers/net/ethernet/mellanox/mlx5/core/en_main.c between commit: d8edd2469ace ("et/mlx5e: Fix minimum MTU") from the net tree and commit: 0e405443e803 ("net/mlx5e: Improve set features ndo resiliency") from the

[PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

Do not load one entry beyond the end of the syscall table when the syscall number of a traced process equals to __NR_Linux_syscalls. Similar bug with regular processes was fixed by commit 3bb457af4fa8 ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls"). This bug was found by strace test

RE: [PATCH 3/4] ACPI / osi: Change default _OSI(Darwin) support

Hi, > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, April 27, 2016 4:13 AM > Subject: Re: [PATCH 3/4] ACPI / osi: Change default _OSI(Darwin) support > > On Tue, Apr 26, 2016 at 9:40 AM, Lv Zheng wrote: > > From:

[PATCH] parisc: fix a bug when syscall number of tracee is __NR_Linux_syscalls

Do not load one entry beyond the end of the syscall table when the syscall number of a traced process equals to __NR_Linux_syscalls. Similar bug with regular processes was fixed by commit 3bb457af4fa8 ("[PARISC] Fix bug when syscall nr is __NR_Linux_syscalls"). This bug was found by strace test

RE: [PATCH 3/4] ACPI / osi: Change default _OSI(Darwin) support

Hi, > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, April 27, 2016 4:13 AM > Subject: Re: [PATCH 3/4] ACPI / osi: Change default _OSI(Darwin) support > > On Tue, Apr 26, 2016 at 9:40 AM, Lv Zheng wrote: > > From: Chen Yu > > > >

RE: [PATCH 2/4] ACPI / osi: Cleanup _OSI("Linux") related code before introducing new support

Hi, Rafael > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, April 27, 2016 4:11 AM > Subject: Re: [PATCH 2/4] ACPI / osi: Cleanup _OSI("Linux") related code before > introducing new support > > On Tue, Apr 26, 2016 at 9:40 AM, Lv Zheng

RE: [PATCH 2/4] ACPI / osi: Cleanup _OSI("Linux") related code before introducing new support

Hi, Rafael > From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of > Rafael J. Wysocki > Sent: Wednesday, April 27, 2016 4:11 AM > Subject: Re: [PATCH 2/4] ACPI / osi: Cleanup _OSI("Linux") related code before > introducing new support > > On Tue, Apr 26, 2016 at 9:40 AM, Lv Zheng

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: > Shawn, > What's your suggestion? I think this needs more discussion, and I just dropped Stefan's patch from my tree. We need to firstly understand why this is happening. The .prepare hook is defined to be non-atomic context, and so

Re: [PATCH 1/2] clk: imx: do not sleep if IRQ's are still disabled

On Tue, Apr 26, 2016 at 07:27:03PM +0800, Dong Aisheng wrote: > Shawn, > What's your suggestion? I think this needs more discussion, and I just dropped Stefan's patch from my tree. We need to firstly understand why this is happening. The .prepare hook is defined to be non-atomic context, and so

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