[PATCH v2 4/6] ARM: cache-l2x0: Do not clear bit 23 in prefetch control register

As per L2C-310 TRM[1]: "... You can control this feature using bits 30,27, and 23 of the Prefetch Control Register. Bit 23 and27 are only used if you set bit 30 HIGH..." which means there is no need to clear bit 23 if bit 30 is being cleared. [1]

Re: [PATCH 3/4] x86: Rewrite switch_to() code

On Sat, May 21, 2016 at 9:04 AM, Brian Gerst wrote: > Move the low-level context switch code to an out-of-line asm stub instead of > using complex inline asm. This allows constructing a new stack frame for the > child process to make it seamlessly flow to ret_from_fork without an extra > test

[PATCH v2 6/6] i.MX: Do not explicitly call l2x0_of_init()

There's no need to explicitly call l2x0_of_init() since it will be called as a part of init_IRQ() (see arch/arm/kernel/irq.c for details). This way we can simplify imx_init_l2cache() and ditch the call to it on i.MX35 (which does not claim compatibility with "arm,pl310-cache") alltogether.

[PATCH v2 6/6] i.MX: Do not explicitly call l2x0_of_init()

There's no need to explicitly call l2x0_of_init() since it will be called as a part of init_IRQ() (see arch/arm/kernel/irq.c for details). This way we can simplify imx_init_l2cache() and ditch the call to it on i.MX35 (which does not claim compatibility with "arm,pl310-cache") alltogether.

[PATCH v2 5/6] i.MX: system.c: Tweak prefetch settings for performance

Update Prefetch Control Register settings to match that of Freescale's Linux tree. As the commit e3addf1b773964eac7f797e8538c69481be4279c states (author Nitin Garg): "... set Prefetch offset to 15, since it improves memcpy performance by 35%. Don't enable Incr double Linefill enable since it

[PATCH v2 5/6] i.MX: system.c: Tweak prefetch settings for performance

Update Prefetch Control Register settings to match that of Freescale's Linux tree. As the commit e3addf1b773964eac7f797e8538c69481be4279c states (author Nitin Garg): "... set Prefetch offset to 15, since it improves memcpy performance by 35%. Don't enable Incr double Linefill enable since it

Re: [PATCH v2] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Blacklisting a module in linux has long been a problem. The current > procedure is to use rd.blacklist=module_name, however, that doesn't > cover the case after the initramfs and before a boot prompt (where one > is supposed to use

Re: [PATCH v2] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Blacklisting a module in linux has long been a problem. The current > procedure is to use rd.blacklist=module_name, however, that doesn't > cover the case after the initramfs and before a boot prompt (where one > is supposed to use /etc/modprobe.d/blacklist.conf to

Re: [PATCH v5 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Hi Heiko, On 2016/6/14 21:28, Heiko Stübner wrote: Am Montag, 13. Juni 2016, 10:38:39 schrieb Heiko Stübner: Am Montag, 13. Juni 2016, 10:10:09 schrieb Frank Wang: Signed-off-by: Frank Wang looks really cool now, thanks for addressing all the review comments

Re: [PATCH v5 1/2] Documentation: bindings: add DT documentation for Rockchip USB2PHY

Hi Heiko, On 2016/6/14 21:28, Heiko Stübner wrote: Am Montag, 13. Juni 2016, 10:38:39 schrieb Heiko Stübner: Am Montag, 13. Juni 2016, 10:10:09 schrieb Frank Wang: Signed-off-by: Frank Wang looks really cool now, thanks for addressing all the review comments Reviewed-by: Heiko Stuebner

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

Hi Heiko & Guenter, On 2016/6/14 22:00, Heiko Stübner wrote: Am Dienstag, 14. Juni 2016, 06:50:31 schrieb Guenter Roeck: On Tue, Jun 14, 2016 at 6:27 AM, Heiko Stübner wrote: Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang: The newer SoCs (rk3366, rk3399) take a

Re: [PATCH v5 2/2] phy: rockchip-inno-usb2: add a new driver for Rockchip usb2phy

Hi Heiko & Guenter, On 2016/6/14 22:00, Heiko Stübner wrote: Am Dienstag, 14. Juni 2016, 06:50:31 schrieb Guenter Roeck: On Tue, Jun 14, 2016 at 6:27 AM, Heiko Stübner wrote: Am Montag, 13. Juni 2016, 10:10:10 schrieb Frank Wang: The newer SoCs (rk3366, rk3399) take a different usb-phy IP

Re: [PATCH v1 3/3] mm: per-process reclaim

On Mon, Jun 13, 2016 at 01:06:35PM -0400, Rik van Riel wrote: > On Mon, 2016-06-13 at 16:50 +0900, Minchan Kim wrote: > > These day, there are many platforms available in the embedded market > > and sometime, they has more hints about workingset than kernel so > > they want to involve memory

Re: [PATCH v1 3/3] mm: per-process reclaim

On Mon, Jun 13, 2016 at 01:06:35PM -0400, Rik van Riel wrote: > On Mon, 2016-06-13 at 16:50 +0900, Minchan Kim wrote: > > These day, there are many platforms available in the embedded market > > and sometime, they has more hints about workingset than kernel so > > they want to involve memory

Re: [PATCH v1 0/3] per-process reclaim

On Mon, Jun 13, 2016 at 06:59:40PM +0530, Vinayak Menon wrote: > On 6/13/2016 1:20 PM, Minchan Kim wrote: > > Hi all, > > > > http://thread.gmane.org/gmane.linux.kernel/1480728 > > > > I sent per-process reclaim patchset three years ago. Then, last > > feedback from akpm was that he want to know

Re: [PATCH v1 0/3] per-process reclaim

On Mon, Jun 13, 2016 at 06:59:40PM +0530, Vinayak Menon wrote: > On 6/13/2016 1:20 PM, Minchan Kim wrote: > > Hi all, > > > > http://thread.gmane.org/gmane.linux.kernel/1480728 > > > > I sent per-process reclaim patchset three years ago. Then, last > > feedback from akpm was that he want to know

Re: [ldv-project] [net] libertas: potential race condition

On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote: > 08.06.2016 02:51, James Cameron пишет: > >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > >>>Hi! > >>> > >>>There is a potential race condition in >

Re: [ldv-project] [net] libertas: potential race condition

On Tue, Jun 14, 2016 at 05:16:11PM +0400, Pavel Andrianov wrote: > 08.06.2016 02:51, James Cameron пишет: > >On Tue, Jun 07, 2016 at 09:39:55AM -0500, Dan Williams wrote: > >>On Tue, 2016-06-07 at 13:30 +0400, Pavel Andrianov wrote: > >>>Hi! > >>> > >>>There is a potential race condition in >

[PATCH 4/5] staging/lustre: Remove stray line from selftest/selftest.h

The 'copy of GPLv2]' is an ending from template that's no longer needed, so remove it to avoid any extra confusion. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lnet/selftest/selftest.h | 1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 2/5] staging/lustre: Replace sun.com GPLv2 URL with gnu.org one.

http://www.sun.com/software/products/lustre/docs/GPLv2.pdf is no longer around, so replace it with (hopefully more permanent) http://http://www.gnu.org/licenses/gpl-2.0.html Signed-off-by: Oleg Drokin Reported-by: Xose Vazquez Perez ---

[PATCH 4/5] staging/lustre: Remove stray line from selftest/selftest.h

The 'copy of GPLv2]' is an ending from template that's no longer needed, so remove it to avoid any extra confusion. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lnet/selftest/selftest.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/selftest/selftest.h

[PATCH 2/5] staging/lustre: Replace sun.com GPLv2 URL with gnu.org one.

http://www.sun.com/software/products/lustre/docs/GPLv2.pdf is no longer around, so replace it with (hopefully more permanent) http://http://www.gnu.org/licenses/gpl-2.0.html Signed-off-by: Oleg Drokin Reported-by: Xose Vazquez Perez --- drivers/staging/lustre/include/linux/libcfs/curproc.h

[PATCH 0/5] Lustre: Remove defunct SUN addresses

This patch removes a paragraph about contacting SUN Microsystems from a lot of Lustre files since there's no more SUN Microsystems. A pointer to GPLv2 URL is also switched from defunct sun.com to gnu.org. For a good measure a couple of places that refer to "Please contact Oracle" are also

Re: [PATCH v1 3/3] mm: per-process reclaim

On Mon, Jun 13, 2016 at 06:07:09PM +0800, Hillf Danton wrote: > > +static ssize_t reclaim_write(struct file *file, const char __user *buf, > > + size_t count, loff_t *ppos) > > +{ > > + struct task_struct *task; > > + char buffer[PROC_NUMBUF]; > > + struct mm_struct

[PATCH 0/5] Lustre: Remove defunct SUN addresses

This patch removes a paragraph about contacting SUN Microsystems from a lot of Lustre files since there's no more SUN Microsystems. A pointer to GPLv2 URL is also switched from defunct sun.com to gnu.org. For a good measure a couple of places that refer to "Please contact Oracle" are also

Re: [PATCH v1 3/3] mm: per-process reclaim

On Mon, Jun 13, 2016 at 06:07:09PM +0800, Hillf Danton wrote: > > +static ssize_t reclaim_write(struct file *file, const char __user *buf, > > + size_t count, loff_t *ppos) > > +{ > > + struct task_struct *task; > > + char buffer[PROC_NUMBUF]; > > + struct mm_struct

[PATCH 3/5] staging/lustre/lov: Fix gpl URL in lov_pool.c

There's no longer a matching sun.com URL, so refer to gnu.org copy. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lustre/lov/lov_pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c

[PATCH 5/5] staging/lustre/libcfs: Remove "Please contact Oracle" from header

The "Please contact Oracle Corporation" lines are removed since not only Oracle has nothing to do with Lustre anymore, there's a pointer to GPL already that's independent of any particular company. Signed-off-by: Oleg Drokin ---

[PATCH 3/5] staging/lustre/lov: Fix gpl URL in lov_pool.c

There's no longer a matching sun.com URL, so refer to gnu.org copy. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/lustre/lov/lov_pool.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lustre/lov/lov_pool.c

[PATCH 5/5] staging/lustre/libcfs: Remove "Please contact Oracle" from header

The "Please contact Oracle Corporation" lines are removed since not only Oracle has nothing to do with Lustre anymore, there's a pointer to GPL already that's independent of any particular company. Signed-off-by: Oleg Drokin --- drivers/staging/lustre/include/linux/libcfs/libcfs_fail.h | 4

Re: [PATCH v1 0/3] per-process reclaim

Hi Chen, On Mon, Jun 13, 2016 at 07:50:00PM +0800, Chen Feng wrote: > Hi Minchan, > > On 2016/6/13 15:50, Minchan Kim wrote: > > Hi all, > > > > http://thread.gmane.org/gmane.linux.kernel/1480728 > > > > I sent per-process reclaim patchset three years ago. Then, last > > feedback from akpm was

Re: [PATCH v1 0/3] per-process reclaim

Hi Chen, On Mon, Jun 13, 2016 at 07:50:00PM +0800, Chen Feng wrote: > Hi Minchan, > > On 2016/6/13 15:50, Minchan Kim wrote: > > Hi all, > > > > http://thread.gmane.org/gmane.linux.kernel/1480728 > > > > I sent per-process reclaim patchset three years ago. Then, last > > feedback from akpm was

Re: [PATCH v1 3/3] mm: per-process reclaim

Hi Johannes, On Mon, Jun 13, 2016 at 11:06:53AM -0400, Johannes Weiner wrote: > Hi Minchan, > > On Mon, Jun 13, 2016 at 04:50:58PM +0900, Minchan Kim wrote: > > These day, there are many platforms available in the embedded market > > and sometime, they has more hints about workingset than kernel

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

On Thu, May 26, 2016 at 09:49:42PM +0800, Zhangjian (Bamvor) wrote: > Hi, yury > > The coredump is usable in our platform. It miss the following definition: > +#define compat_elf_greg_telf_greg_t > +#define compat_elf_gregset_t elf_gregset_t > > And it leads to the wrong register save in

Re: [PATCH v1 3/3] mm: per-process reclaim

Hi Johannes, On Mon, Jun 13, 2016 at 11:06:53AM -0400, Johannes Weiner wrote: > Hi Minchan, > > On Mon, Jun 13, 2016 at 04:50:58PM +0900, Minchan Kim wrote: > > These day, there are many platforms available in the embedded market > > and sometime, they has more hints about workingset than kernel

Re: [PATCH 16/23] arm64: ilp32: introduce binfmt_ilp32.c

On Thu, May 26, 2016 at 09:49:42PM +0800, Zhangjian (Bamvor) wrote: > Hi, yury > > The coredump is usable in our platform. It miss the following definition: > +#define compat_elf_greg_telf_greg_t > +#define compat_elf_gregset_t elf_gregset_t > > And it leads to the wrong register save in

Re: acpi: broken suspend to RAM with v4.7-rc1

On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov wrote: > Hi Lv, > > On 13 Jun, Zheng, Lv wrote: >> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >> > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki >> > Subject: Re: acpi: broken suspend to RAM

Re: acpi: broken suspend to RAM with v4.7-rc1

On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov wrote: > Hi Lv, > > On 13 Jun, Zheng, Lv wrote: >> > From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >> > ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki >> > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1 >> > >> > On

Re: BPF runtime for systemtap

On Tue, Jun 14, 2016 at 1:06 PM, Richard Henderson wrote: > I'm pleased to be able to announce an initial implementation of an (e)bpf > backend for systemtap. For the subset of systemtap probes that can use > kprobes, we can use a bpf filter instead of loading a kernel module. >

Re: BPF runtime for systemtap

On Tue, Jun 14, 2016 at 1:06 PM, Richard Henderson wrote: > I'm pleased to be able to announce an initial implementation of an (e)bpf > backend for systemtap. For the subset of systemtap probes that can use > kprobes, we can use a bpf filter instead of loading a kernel module. > > As this

Re: modules: add ro_after_init support

+++ Kees Cook [14/06/16 14:33 -0700]: On Mon, Jun 13, 2016 at 5:13 PM, Jessica Yu wrote: Add ro_after_init support for modules by adding a new page-aligned section in the module layout (after rodata) for ro_after_init data and enabling RO protection for that section after

Re: modules: add ro_after_init support

+++ Kees Cook [14/06/16 14:33 -0700]: On Mon, Jun 13, 2016 at 5:13 PM, Jessica Yu wrote: Add ro_after_init support for modules by adding a new page-aligned section in the module layout (after rodata) for ro_after_init data and enabling RO protection for that section after module init runs.

cmpxchg and x86 flags output

The x86 gcc now has the ability to return the value of flags output. In most use cases, this has been trivial to use in the kernel. However, cmpxchg() presents a problem. The current definition of cmpxchg() and its variants is: out = cmpxchg(ptr, old, new); ... which is then

cmpxchg and x86 flags output

The x86 gcc now has the ability to return the value of flags output. In most use cases, this has been trivial to use in the kernel. However, cmpxchg() presents a problem. The current definition of cmpxchg() and its variants is: out = cmpxchg(ptr, old, new); ... which is then

Re: [PATCH] gpio: add Intel WhiskeyCove GPIO driver

On Tue, Jun 14, 2016 at 01:09:31PM +0300, Mika Westerberg wrote: > On Fri, Jun 10, 2016 at 11:01:51PM -0700, Bin Gao wrote: > > +static const struct platform_device_id pmic_gpio_id_table[] = { > > + { "bxt_wcove_gpio", }, > > +}; > > Do you really need this? > > > + > > +static struct

Re: [PATCH] gpio: add Intel WhiskeyCove GPIO driver

On Tue, Jun 14, 2016 at 01:09:31PM +0300, Mika Westerberg wrote: > On Fri, Jun 10, 2016 at 11:01:51PM -0700, Bin Gao wrote: > > +static const struct platform_device_id pmic_gpio_id_table[] = { > > + { "bxt_wcove_gpio", }, > > +}; > > Do you really need this? > > > + > > +static struct

Re: [PATCH] dax: use devm_add_action_or_reset

On Sun, Jun 12, 2016 at 7:48 AM, Sudip Mukherjee wrote: > If devm_add_action() fails we are explicitly calling the cleanup to free > the resources allocated. Lets use the helper devm_add_action_or_reset() > and return directly in case of error, as we know that the

Re: [PATCH] dax: use devm_add_action_or_reset

On Sun, Jun 12, 2016 at 7:48 AM, Sudip Mukherjee wrote: > If devm_add_action() fails we are explicitly calling the cleanup to free > the resources allocated. Lets use the helper devm_add_action_or_reset() > and return directly in case of error, as we know that the cleanup > function has been

Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max

On Tue, Jun 14, 2016 at 03:40:35PM +, Topi Miettinen wrote: > On 06/13/16 22:27, Jann Horn wrote: > > On Mon, Jun 13, 2016 at 10:44:18PM +0300, Topi Miettinen wrote: > >> Track maximum number of processes per user and present it > >> in /proc/self/limits. > >> > >> Signed-off-by: Topi

Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max

On Tue, Jun 14, 2016 at 03:40:35PM +, Topi Miettinen wrote: > On 06/13/16 22:27, Jann Horn wrote: > > On Mon, Jun 13, 2016 at 10:44:18PM +0300, Topi Miettinen wrote: > >> Track maximum number of processes per user and present it > >> in /proc/self/limits. > >> > >> Signed-off-by: Topi

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

As PCC will be used by other clients not only CPPC. This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 4 include/linux/mailbox_client.h | 4 2 files changed, 4

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

As PCC will be used by other clients not only CPPC. This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 4 include/linux/mailbox_client.h | 4 2 files changed, 4 insertions(+), 4

Re: [v2 PATCH 3/4] Documentation: bindings: add dt documentation for cdn DP controller

On Mon, Jun 13, 2016 at 05:39:48PM +0800, Chris Zhong wrote: > This patch adds a binding that describes the cdn DP controller for > rk3399. > > Signed-off-by: Chris Zhong > > --- > > Changes in v2: None > Changes in v1: > - add extcon node description > - add

Re: [v2 PATCH 3/4] Documentation: bindings: add dt documentation for cdn DP controller

On Mon, Jun 13, 2016 at 05:39:48PM +0800, Chris Zhong wrote: > This patch adds a binding that describes the cdn DP controller for > rk3399. > > Signed-off-by: Chris Zhong > > --- > > Changes in v2: None > Changes in v1: > - add extcon node description > - add #sound-dai-cells description > >

[PATCH v1 1/1] x86/platform/intel-mid: Enable GPIO expanders on Edison

Intel Edison board provides GPIO expanders connected to I2C bus. Add necessary file to get those enumerated. Signed-off-by: Andy Shevchenko --- arch/x86/platform/intel-mid/device_libs/Makefile | 6 +- .../intel-mid/device_libs/platform_pcal9555a.c | 99

[PATCH v1 1/1] x86/platform/intel-mid: Enable GPIO expanders on Edison

Intel Edison board provides GPIO expanders connected to I2C bus. Add necessary file to get those enumerated. Signed-off-by: Andy Shevchenko --- arch/x86/platform/intel-mid/device_libs/Makefile | 6 +- .../intel-mid/device_libs/platform_pcal9555a.c | 99 ++ 2 files

Re: [PATCH v2 net-next v2 12/12] net: dsa: mv88e6xxx: add addressing mode to info

Hi, Andrew Lunn writes: > On Tue, Jun 14, 2016 at 06:24:17PM -0400, Vivien Didelot wrote: >> Hi Andrew, >> >> Andrew Lunn writes: >> >> >> - ret = mdiobus_read_nested(bus, addr, reg); >> >> + ret = mdiobus_read_nested(bus, sw_addr + addr, reg); >> >> if (ret

Re: [PATCH v2 net-next v2 12/12] net: dsa: mv88e6xxx: add addressing mode to info

Hi, Andrew Lunn writes: > On Tue, Jun 14, 2016 at 06:24:17PM -0400, Vivien Didelot wrote: >> Hi Andrew, >> >> Andrew Lunn writes: >> >> >> - ret = mdiobus_read_nested(bus, addr, reg); >> >> + ret = mdiobus_read_nested(bus, sw_addr + addr, reg); >> >> if (ret < 0) >> >> return

Re: [PATCH 01/23] all: syscall wrappers: add documentation

Hi Catalin, David, all > COMPAT_SYSCALL_WRAP2(creat, ...): > mov w0, w0 > b > > > > Cost wise, this seems like it all cancels out in the end, but what > > > do I know? > > > > I think you know something, and I also think Heiko and other s390 guys > > know something as

Re: [PATCH 01/23] all: syscall wrappers: add documentation

Hi Catalin, David, all > COMPAT_SYSCALL_WRAP2(creat, ...): > mov w0, w0 > b > > > > Cost wise, this seems like it all cancels out in the end, but what > > > do I know? > > > > I think you know something, and I also think Heiko and other s390 guys > > know something as

Re: [RFC PATCH-tip 6/6] xfs: Enable reader optimistic spinning for DAX inodes

On Tue, Jun 14, 2016 at 02:12:39PM -0400, Waiman Long wrote: > This patch enables reader optimistic spinning for inodes that are > under a DAX-based mount point. > > On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, > the fio test with multithreaded randrw and randwrite tests

Re: [RFC PATCH-tip 6/6] xfs: Enable reader optimistic spinning for DAX inodes

On Tue, Jun 14, 2016 at 02:12:39PM -0400, Waiman Long wrote: > This patch enables reader optimistic spinning for inodes that are > under a DAX-based mount point. > > On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel, > the fio test with multithreaded randrw and randwrite tests

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Tuesday, June 14, 2016 07:47:45 AM Jacob Pan wrote: > On Tue, 14 Jun 2016 02:21:41 +0200 > "Rafael J. Wysocki" wrote: > > > On Tue, Jun 14, 2016 at 2:06 AM, Jacob Pan > > wrote: > > > On Mon, 13 Jun 2016 23:56:18 +0200 > > > "Rafael J.

Re: [PATCH 1/2] powercap/rapl: add support for skx

On Tuesday, June 14, 2016 07:47:45 AM Jacob Pan wrote: > On Tue, 14 Jun 2016 02:21:41 +0200 > "Rafael J. Wysocki" wrote: > > > On Tue, Jun 14, 2016 at 2:06 AM, Jacob Pan > > wrote: > > > On Mon, 13 Jun 2016 23:56:18 +0200 > > > "Rafael J. Wysocki" wrote: > > > > > >> On Monday, June 13, 2016

[PATCH v3] mfd: qcom_rpm: fix offset error for msm8660

The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files : all were using

[PATCH v3] mfd: qcom_rpm: fix offset error for msm8660

The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files : all were using

Re: [PATCH 0/3] Convert clk-fixed into module platform driver

Hi Stephen Assume this device tree overlay: { axi_clk: axi_clk { compatible = "fixed-clock"; #clock-cells = <0x0>; clock-frequency = <12500>; }; iic_0: iic { #address-cells = <1>; #size-cells = <1>; compatible = "xlnx,xps-iic-2.00.a"; reg = < 0x0003 0x1 >; interrupt-parent =

Re: [PATCH 0/3] Convert clk-fixed into module platform driver

Hi Stephen Assume this device tree overlay: { axi_clk: axi_clk { compatible = "fixed-clock"; #clock-cells = <0x0>; clock-frequency = <12500>; }; iic_0: iic { #address-cells = <1>; #size-cells = <1>; compatible = "xlnx,xps-iic-2.00.a"; reg = < 0x0003 0x1 >; interrupt-parent =

[PATCH v2] mfd: qcom_rpm: fix offset error for msm8660

The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files : all were using

[PATCH v2] mfd: qcom_rpm: fix offset error for msm8660

The RPM in MSM8660/APQ8060 has different offsets to the selector ACK and request context ACK registers. Make all these register offsets part of the per-SoC data and assign the right values. The bug was found by verifying backwards to the vendor tree in the out-of-tree files : all were using

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, 2016-06-14 at 18:54 -0400, Oleg Drokin wrote: > On Jun 14, 2016, at 6:52 PM, Jeff Layton wrote: > > > > I think I'd still prefer to have it unlock the mutex in the event that > > it's not going to use it after all. While that kind of thing is ok for > > now, it's stuff like that that can

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, 2016-06-14 at 18:54 -0400, Oleg Drokin wrote: > On Jun 14, 2016, at 6:52 PM, Jeff Layton wrote: > > > > I think I'd still prefer to have it unlock the mutex in the event that > > it's not going to use it after all. While that kind of thing is ok for > > now, it's stuff like that that can

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Jun 14, 2016, at 6:52 PM, Jeff Layton wrote: > I think I'd still prefer to have it unlock the mutex in the event that > it's not going to use it after all. While that kind of thing is ok for > now, it's stuff like that that can turn into a subtle source of bugs > later. > > Also, I think I'd

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Jun 14, 2016, at 6:52 PM, Jeff Layton wrote: > I think I'd still prefer to have it unlock the mutex in the event that > it's not going to use it after all. While that kind of thing is ok for > now, it's stuff like that that can turn into a subtle source of bugs > later. > > Also, I think I'd

Re: [PATCH v3 7/8] acpi: add support for configfs

Hi Octavian, On Wednesday, June 15, 2016 06:43:21 AM kbuild test robot wrote: > Hi, > > [auto build test ERROR on pm/linux-next] > [also build test ERROR on v4.7-rc3] > [cannot apply to next-20160614] > [if your patch is applied to the wrong git tree, please drop us a note

Re: [PATCH v3 7/8] acpi: add support for configfs

Hi Octavian, On Wednesday, June 15, 2016 06:43:21 AM kbuild test robot wrote: > Hi, > > [auto build test ERROR on pm/linux-next] > [also build test ERROR on v4.7-rc3] > [cannot apply to next-20160614] > [if your patch is applied to the wrong git tree, please drop us a note

Re: [PATCH] Add kernel parameter to blacklist modules

On 06/14/2016 04:51 PM, Henrique de Moraes Holschuh wrote: > > And if such a module blacklist feature ends up being invoked by the > "nuke_module_from_orbit=" parameter, I will pay the author > (and the subsystem maintainer that manages to get that merged) a couple > beers should we ever meet

Re: [PATCH] Add kernel parameter to blacklist modules

On 06/14/2016 04:51 PM, Henrique de Moraes Holschuh wrote: > > And if such a module blacklist feature ends up being invoked by the > "nuke_module_from_orbit=" parameter, I will pay the author > (and the subsystem maintainer that manages to get that merged) a couple > beers should we ever meet

Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > rcu/next > head: 13ee0de9cd2444b57ce30c4f1607b49b90aa0c38 > commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make > call_rcu_tasks()

Re: [rcu:rcu/next 25/36] include/linux/irqflags.h:79:3: error: implicit declaration of function 'arch_irqs_disabled_flags'

On Mon, Jun 06, 2016 at 02:04:03AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > rcu/next > head: 13ee0de9cd2444b57ce30c4f1607b49b90aa0c38 > commit: f251ac814fc5787765009e60d54a2bd4277350c8 [25/36] rcu: Make > call_rcu_tasks()

Re: [PATCH v4] udp reuseport: fix packet of same flow hashed to different socket

From: Su Xuemin Date: Mon, 13 Jun 2016 11:02:50 +0800 > From: "Su, Xuemin" > > There is a corner case in which udp packets belonging to a same > flow are hashed to different socket when hslot->count changes from 10 > to 11: > > 1) When

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, 2016-06-14 at 14:50 -0400, J . Bruce Fields wrote: > On Tue, Jun 14, 2016 at 11:53:27AM -0400, Oleg Drokin wrote: > > > > > > On Jun 14, 2016, at 11:38 AM, J . Bruce Fields wrote: > > > > > > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > > > > > > > > It used to

Re: [PATCH v4] udp reuseport: fix packet of same flow hashed to different socket

From: Su Xuemin Date: Mon, 13 Jun 2016 11:02:50 +0800 > From: "Su, Xuemin" > > There is a corner case in which udp packets belonging to a same > flow are hashed to different socket when hslot->count changes from 10 > to 11: > > 1) When hslot->count <= 10, __udp_lib_lookup() searches

Re: [PATCH v2] nfsd: Always lock state exclusively.

On Tue, 2016-06-14 at 14:50 -0400, J . Bruce Fields wrote: > On Tue, Jun 14, 2016 at 11:53:27AM -0400, Oleg Drokin wrote: > > > > > > On Jun 14, 2016, at 11:38 AM, J . Bruce Fields wrote: > > > > > > > > On Sun, Jun 12, 2016 at 09:26:27PM -0400, Oleg Drokin wrote: > > > > > > > > It used to

Re: [v2 PATCH 1/4] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

On Mon, Jun 13, 2016 at 05:39:46PM +0800, Chris Zhong wrote: > This patch adds a binding that describes the Rockchip USB Type-C PHY > for rk3399 > > Signed-off-by: Chris Zhong > > --- > > Changes in v2: > - add some registers description > > Changes in v1: > - add extcon

Re: [v2 PATCH 1/4] Documentation: bindings: add dt doc for Rockchip USB Type-C PHY

On Mon, Jun 13, 2016 at 05:39:46PM +0800, Chris Zhong wrote: > This patch adds a binding that describes the Rockchip USB Type-C PHY > for rk3399 > > Signed-off-by: Chris Zhong > > --- > > Changes in v2: > - add some registers description > > Changes in v1: > - add extcon node description > -

[RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP

Currently, when down_read() fails, the active read locking isn't undone until the rwsem_down_read_failed() function grabs the wait_lock. If the wait_lock is contended, it may takes a while to get the lock. During that period, writer lock stealing will be disabled because of the active read lock.

[RFC PATCH-tip v2 2/6] locking/rwsem: Stop active read lock ASAP

Currently, when down_read() fails, the active read locking isn't undone until the rwsem_down_read_failed() function grabs the wait_lock. If the wait_lock is contended, it may takes a while to get the lock. During that period, writer lock stealing will be disabled because of the active read lock.

[RFC PATCH-tip v2 3/6] locking/rwsem: Enable count-based spinning on reader

When the rwsem is owned by reader, writers stop optimistic spinning simply because there is no easy way to figure out if all the readers are actively running or not. However, there are scenarios where the readers are unlikely to sleep and optimistic spinning can help performance. This patch

[RFC PATCH-tip v2 4/6] locking/rwsem: move down rwsem_down_read_failed function

Move the rwsem_down_read_failed() function down to below the optimistic spinning section before enabling optimistic spinning for the readers. There is no change in code. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 116

[RFC PATCH-tip v2 6/6] locking/rwsem: Enable spinning readers

This patch enables readers to optimistically spin when the rspin_threshold is non-zero. That threshold value should only be set when the lock owners of the rwsem are unlikely to go to sleep. Otherwise enabling reader spinning may make the performance worse in some cases. On a 4-socket Haswell

[RFC PATCH-tip v2 3/6] locking/rwsem: Enable count-based spinning on reader

When the rwsem is owned by reader, writers stop optimistic spinning simply because there is no easy way to figure out if all the readers are actively running or not. However, there are scenarios where the readers are unlikely to sleep and optimistic spinning can help performance. This patch

[RFC PATCH-tip v2 4/6] locking/rwsem: move down rwsem_down_read_failed function

Move the rwsem_down_read_failed() function down to below the optimistic spinning section before enabling optimistic spinning for the readers. There is no change in code. Signed-off-by: Waiman Long --- kernel/locking/rwsem-xadd.c | 116 +- 1 files

[RFC PATCH-tip v2 6/6] locking/rwsem: Enable spinning readers

This patch enables readers to optimistically spin when the rspin_threshold is non-zero. That threshold value should only be set when the lock owners of the rwsem are unlikely to go to sleep. Otherwise enabling reader spinning may make the performance worse in some cases. On a 4-socket Haswell

[RFC PATCH-tip v2 5/6] locking/rwsem: Change RWSEM_WAITING_BIAS for better disambiguation

When the count value is in between 0 and RWSEM_WAITING_BIAS, there are 2 possibilities. Either a writer is present and there is no waiter or there are waiters and readers. There is no easy way to know which is true unless the wait_lock is taken. This patch changes the RWSEM_WAITING_BIAS from

[RFC PATCH-tip v2 5/6] locking/rwsem: Change RWSEM_WAITING_BIAS for better disambiguation

When the count value is in between 0 and RWSEM_WAITING_BIAS, there are 2 possibilities. Either a writer is present and there is no waiter or there are waiters and readers. There is no easy way to know which is true unless the wait_lock is taken. This patch changes the RWSEM_WAITING_BIAS from

[RFC PATCH-tip v2 0/6] locking/rwsem: Enable reader optimistic spinning

v1->v2: - Fixed a 0day build error. - Add a new patch 1 to make osq_lock() a proper acquire memory barrier. - Replaced the explicit enabling of reader spinning by an autotuning mechanism that disable reader spinning for those rwsems that may not benefit from reader spinning. - Remove

[RFC PATCH-tip v2 0/6] locking/rwsem: Enable reader optimistic spinning

v1->v2: - Fixed a 0day build error. - Add a new patch 1 to make osq_lock() a proper acquire memory barrier. - Replaced the explicit enabling of reader spinning by an autotuning mechanism that disable reader spinning for those rwsems that may not benefit from reader spinning. - Remove

[RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers are provided when osq_lock() is successful or when osq_unlock() is called. Signed-off-by: Waiman Long ---

[RFC PATCH-tip v2 1/6] locking/osq: Make lock/unlock proper acquire/release barrier

The osq_lock() and osq_unlock() function may not provide the necessary acquire and release barrier in some cases. This patch makes sure that the proper barriers are provided when osq_lock() is successful or when osq_unlock() is called. Signed-off-by: Waiman Long --- kernel/locking/osq_lock.c |

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