[PATCH] ARM: sun8i: h3: Enable EMAC with external PHY on Orange Pi Plus 2E

The Orange Pi Plus 2E, unlike the Orange Pi PC and PC Plus which its schematics are based on, uses an external Realtek RTL8211E PHY in RGMII mode, with a GPIO enabling the regulator for I/O signalling power supplies. The PHY's main power supply is enabled by the main 5V power supply. Add the

[PATCH] ARM: sun8i: h3: Enable EMAC with external PHY on Orange Pi Plus 2E

The Orange Pi Plus 2E, unlike the Orange Pi PC and PC Plus which its schematics are based on, uses an external Realtek RTL8211E PHY in RGMII mode, with a GPIO enabling the regulator for I/O signalling power supplies. The PHY's main power supply is enabled by the main 5V power supply. Add the

Re: [PATCH] VFS: Differentiate mount flags (MS_*) from internal superblock flags

On Fri, 2017-06-09 at 16:01 +0100, David Howells wrote: > Differentiate the MS_* flags passed to mount(2) from the internal flags set > in the super_block's s_flags. s_flags are now called SB_*, with the names > and the values for the moment mirroring the MS_* flags that they're > equivalent to.

Re: [PATCH] VFS: Differentiate mount flags (MS_*) from internal superblock flags

On Fri, 2017-06-09 at 16:01 +0100, David Howells wrote: > Differentiate the MS_* flags passed to mount(2) from the internal flags set > in the super_block's s_flags. s_flags are now called SB_*, with the names > and the values for the moment mirroring the MS_* flags that they're > equivalent to.

Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote: Hi Jagan, On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote: + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + status = "okay"; +}; + +_pins { + bias-pull-up; +}; What is connected on that bus?

Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote: Hi Jagan, On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote: + { + pinctrl-names = "default"; + pinctrl-0 = <_pins>; + status = "okay"; +}; + +_pins { + bias-pull-up; +}; What is connected on that bus?

Re: [RFC v4 00/20] Speculative page faults

On 09/06/2017 17:01, Michal Hocko wrote: > On Fri 09-06-17 16:20:49, Laurent Dufour wrote: >> This is a port on kernel 4.12 of the work done by Peter Zijlstra to >> handle page fault without holding the mm semaphore. >> >>

Re: [RFC v4 00/20] Speculative page faults

On 09/06/2017 17:01, Michal Hocko wrote: > On Fri 09-06-17 16:20:49, Laurent Dufour wrote: >> This is a port on kernel 4.12 of the work done by Peter Zijlstra to >> handle page fault without holding the mm semaphore. >> >>

Re: [PATCH v3 2/2] perf: ThunderX2: Add Cavium Thunderx2 SoC UNCORE PMU driver

On Mon, Jun 05, 2017 at 12:21:04PM +0530, Ganapatrao Kulkarni wrote: > This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory > Controller(DMC) and Level 3 Cache(L3C). Can you elaborate a bit on this please? At minimum, it would be worht mentioning: * Whether the PMU has an

Re: [PATCH v3 2/2] perf: ThunderX2: Add Cavium Thunderx2 SoC UNCORE PMU driver

On Mon, Jun 05, 2017 at 12:21:04PM +0530, Ganapatrao Kulkarni wrote: > This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory > Controller(DMC) and Level 3 Cache(L3C). Can you elaborate a bit on this please? At minimum, it would be worht mentioning: * Whether the PMU has an

Re: [PATCH 02/11] IB: nes: convert to use DRIVER_ATTR_RW

On Fri, 2017-06-09 at 11:03 +0200, Greg Kroah-Hartman wrote: > We are trying to get rid of DRIVER_ATTR(), and all of the nes.c driver > attributes can be trivially changed to use DRIVER_ATTR_RW(), making the > code smaller and easier to manage over time. Reviewed-by: Bart Van Assche

Re: [PATCH 02/11] IB: nes: convert to use DRIVER_ATTR_RW

On Fri, 2017-06-09 at 11:03 +0200, Greg Kroah-Hartman wrote: > We are trying to get rid of DRIVER_ATTR(), and all of the nes.c driver > attributes can be trivially changed to use DRIVER_ATTR_RW(), making the > code smaller and easier to manage over time. Reviewed-by: Bart Van Assche

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

Le 09/06/2017 15:28, Thomas Renninger a écrit : > On Thursday, June 08, 2017 08:24:01 PM Greg KH wrote: >> On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: >>> --- >>> arch/x86/kernel/Makefile| 1 + >>> arch/x86/kernel/cpuinfo_sysfs.c | 166 >

Re: [RFC PATCH 2/3] Implement sysfs based cpuinfo for x86 cpus.

Le 09/06/2017 15:28, Thomas Renninger a écrit : > On Thursday, June 08, 2017 08:24:01 PM Greg KH wrote: >> On Thu, Jun 08, 2017 at 06:56:14PM +0200, Felix Schnizlein wrote: >>> --- >>> arch/x86/kernel/Makefile| 1 + >>> arch/x86/kernel/cpuinfo_sysfs.c | 166 >

Re: [PATCH v8 6/9] drivers: perf: hisi: Add support for Hisilicon Djtag driver

On 09/06/2017 15:30, Will Deacon wrote: On Fri, Jun 09, 2017 at 03:18:39PM +0100, John Garry wrote: On 08/06/2017 17:35, Mark Rutland wrote: Hi, On Mon, May 22, 2017 at 08:48:32PM +0800, Shaokun Zhang wrote: +/* + * hisi_djtag_lock_v2: djtag lock to avoid djtag access conflict b/w kernel + *

Re: [PATCH v8 6/9] drivers: perf: hisi: Add support for Hisilicon Djtag driver

On 09/06/2017 15:30, Will Deacon wrote: On Fri, Jun 09, 2017 at 03:18:39PM +0100, John Garry wrote: On 08/06/2017 17:35, Mark Rutland wrote: Hi, On Mon, May 22, 2017 at 08:48:32PM +0800, Shaokun Zhang wrote: +/* + * hisi_djtag_lock_v2: djtag lock to avoid djtag access conflict b/w kernel + *

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

On Fri, 09 Jun 2017 17:05:52 +0300 Felipe Balbi wrote: > Hi, > > Steven Rostedt writes: > > On Fri, 9 Jun 2017 09:13:27 +0300 > > Felipe Balbi wrote: > > > >> Allow for ftrace data to be exported over a USB

Re: [PATCH] usb: gadget: functions: add ftrace export over USB

On Fri, 09 Jun 2017 17:05:52 +0300 Felipe Balbi wrote: > Hi, > > Steven Rostedt writes: > > On Fri, 9 Jun 2017 09:13:27 +0300 > > Felipe Balbi wrote: > > > >> Allow for ftrace data to be exported over a USB Gadget > >> Controller. With this, we have a potentially very fast pipe for > >>

Re: [RFC v4 00/20] Speculative page faults

On Fri 09-06-17 16:20:49, Laurent Dufour wrote: > This is a port on kernel 4.12 of the work done by Peter Zijlstra to > handle page fault without holding the mm semaphore. > > http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-0-6-Another-go-at-speculative-page-faults-tt965642.html#none > >

Re: [PATCH v5 2/3] nvmem: add snvs_lpgpr driver

Hi Oleksij, please add the NXP guys in CC in order to give them a chance to review. Am 09.06.2017 um 14:57 schrieb Oleksij Rempel: > This is a driver for Low Power General Purpose Register (LPGPR) > available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) > of this chip. > > It is a 32-bit

Re: [RFC v4 00/20] Speculative page faults

On Fri 09-06-17 16:20:49, Laurent Dufour wrote: > This is a port on kernel 4.12 of the work done by Peter Zijlstra to > handle page fault without holding the mm semaphore. > > http://linux-kernel.2935.n7.nabble.com/RFC-PATCH-0-6-Another-go-at-speculative-page-faults-tt965642.html#none > >

Re: [PATCH v5 2/3] nvmem: add snvs_lpgpr driver

Hi Oleksij, please add the NXP guys in CC in order to give them a chance to review. Am 09.06.2017 um 14:57 schrieb Oleksij Rempel: > This is a driver for Low Power General Purpose Register (LPGPR) > available on i.MX6 SoCs in Secure Non-Volatile Storage (SNVS) > of this chip. > > It is a 32-bit

Re: [PATCH v5 1/3] nvmem: dt: document SNVS LPGPR binding

Hi Oleksij, Am 09.06.2017 um 14:57 schrieb Oleksij Rempel: > Documentation bindings for the Low Power General Purpose Register > available on i.MX6 SoCs in the Secure Non-Volatile Storage. > > Signed-off-by: Oleksij Rempel > --- >

Re: [PATCH v5 1/3] nvmem: dt: document SNVS LPGPR binding

Hi Oleksij, Am 09.06.2017 um 14:57 schrieb Oleksij Rempel: > Documentation bindings for the Low Power General Purpose Register > available on i.MX6 SoCs in the Secure Non-Volatile Storage. > > Signed-off-by: Oleksij Rempel > --- > .../devicetree/bindings/nvmem/snvs-lpgpr.txt | 19 >

Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote: > Hi, > > I'm getting some hangs while fuzzing the kernel with syzkaller. > > Possibly it happens during the execution of the following syzkaller program: > > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32,

Re: usb/gadget: potential deadlock in gadgetfs_suspend

On Fri, Jun 9, 2017 at 2:41 PM, Andrey Konovalov wrote: > Hi, > > I'm getting some hangs while fuzzing the kernel with syzkaller. > > Possibly it happens during the execution of the following syzkaller program: > > mmap(&(0x7f00/0xb9)=nil, (0xb9), 0x3, 0x32, > 0x,

Re: [PATCH] arm64: allwinner: a64: Add initial NanoPi A64 support

On Fri, Jun 09, 2017 at 01:03:56PM +, Jagan Teki wrote: > From: Jagan Teki > > NanoPi A64 is a new board of high performance with low cost > designed by FriendlyElec., using the Allwinner A64 SOC. > > Nanopi A64 features > - Allwinner A64, 64-bit Quad-core

Re: [PATCH] arm64: allwinner: a64: Add initial NanoPi A64 support

On Fri, Jun 09, 2017 at 01:03:56PM +, Jagan Teki wrote: > From: Jagan Teki > > NanoPi A64 is a new board of high performance with low cost > designed by FriendlyElec., using the Allwinner A64 SOC. > > Nanopi A64 features > - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz,

Re: [PATCH v2 04/11] drm: sun4i: add support for H3's TCON0/1

On Wed, Jun 07, 2017 at 10:21:02PM +0800, Icenowy Zheng wrote: > > > 于 2017年6月7日 GMT+08:00 下午10:19:57, Maxime Ripard > 写到: > >On Wed, Jun 07, 2017 at 05:44:56PM +0800, Icenowy Zheng wrote: > >> 于 2017年6月7日 GMT+08:00 下午5:43:43, Maxime Ripard >

Re: [PATCH v2 04/11] drm: sun4i: add support for H3's TCON0/1

On Wed, Jun 07, 2017 at 10:21:02PM +0800, Icenowy Zheng wrote: > > > 于 2017年6月7日 GMT+08:00 下午10:19:57, Maxime Ripard > 写到: > >On Wed, Jun 07, 2017 at 05:44:56PM +0800, Icenowy Zheng wrote: > >> 于 2017年6月7日 GMT+08:00 下午5:43:43, Maxime Ripard > > 写到: > >> >On Mon, Jun 05, 2017 at 03:03:47AM

Re: [RFC][PATCH 0/5] Getting rid of smp_mb__before_spinlock

On Wed, Jun 07, 2017 at 06:15:01PM +0200, Peter Zijlstra wrote: > There was a thread on this somewhere about a year ago, I finally remembered to > finish this :-) > > This series removes two smp_mb__before_spinlock() (ab)users and converts the > scheduler to use smp_mb__after_spinlock(), which

Re: [RFC][PATCH 0/5] Getting rid of smp_mb__before_spinlock

On Wed, Jun 07, 2017 at 06:15:01PM +0200, Peter Zijlstra wrote: > There was a thread on this somewhere about a year ago, I finally remembered to > finish this :-) > > This series removes two smp_mb__before_spinlock() (ab)users and converts the > scheduler to use smp_mb__after_spinlock(), which

Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

Hi Jagan, On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote: > + { > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + status = "okay"; > +}; > + > +_pins { > + bias-pull-up; > +}; What is connected on that bus? > + { > + pinctrl-names = "default"; > +

Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

Hi Jagan, On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote: > + { > + pinctrl-names = "default"; > + pinctrl-0 = <_pins>; > + status = "okay"; > +}; > + > +_pins { > + bias-pull-up; > +}; What is connected on that bus? > + { > + pinctrl-names = "default"; > +

Re: [PATCH 0/3] USB: add API for interface driver to vote for autosuspend

On Thu, 8 Jun 2017, Yueyao Zhu wrote: > From: Yueyao Zhu > > Currently, if a USB driver would like to enable autosuspend on the USB > device, usb_enable_autosuspend() seems to be the only option. However, > this acts on the device level, and other interfaces might not desire

Re: [PATCH 0/3] USB: add API for interface driver to vote for autosuspend

On Thu, 8 Jun 2017, Yueyao Zhu wrote: > From: Yueyao Zhu > > Currently, if a USB driver would like to enable autosuspend on the USB > device, usb_enable_autosuspend() seems to be the only option. However, > this acts on the device level, and other interfaces might not desire > to autosuspend

Re: [RFC PATCH 1/8] Documentation: add DT binding for ARM System Control and Management Interface(SCMI) protocol

On 09/06/17 15:16, Rob Herring wrote: > On Wed, Jun 07, 2017 at 05:10:05PM +0100, Sudeep Holla wrote: >> This patch adds devicetree binding for System Control and Management >> Interface (SCMI) Message Protocol used between the Application Cores(AP) >> and the System Control Processor(SCP). The

Re: [RFC PATCH 1/8] Documentation: add DT binding for ARM System Control and Management Interface(SCMI) protocol

On 09/06/17 15:16, Rob Herring wrote: > On Wed, Jun 07, 2017 at 05:10:05PM +0100, Sudeep Holla wrote: >> This patch adds devicetree binding for System Control and Management >> Interface (SCMI) Message Protocol used between the Application Cores(AP) >> and the System Control Processor(SCP). The

Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2

On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: > 在 2017-06-07 22:38，Maxime Ripard 写道： > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > >I have no idea what this is supposed to be doing either. > > > > > > > >I might be wrong, but I really feel like there's

Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2

On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: > 在 2017-06-07 22:38，Maxime Ripard 写道： > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > >I have no idea what this is supposed to be doing either. > > > > > > > >I might be wrong, but I really feel like there's

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

On Fri 09-06-17 10:08:53, Johannes Weiner wrote: > On Thu, Jun 08, 2017 at 04:36:07PM +0200, Michal Hocko wrote: > > Does anybody see any problem with the patch or I can send it for the > > inclusion? > > > > On Fri 19-05-17 13:26:04, Michal Hocko wrote: > > > From: Michal Hocko

Re: [RFC PATCH 2/2] mm, oom: do not trigger out_of_memory from the #PF

On Fri 09-06-17 10:08:53, Johannes Weiner wrote: > On Thu, Jun 08, 2017 at 04:36:07PM +0200, Michal Hocko wrote: > > Does anybody see any problem with the patch or I can send it for the > > inclusion? > > > > On Fri 19-05-17 13:26:04, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > Any

Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2

Hi Jernej, On Wed, Jun 07, 2017 at 08:15:12PM +0200, Jernej Škrabec wrote: > Hi! > > Dne sreda, 07. junij 2017 ob 16:38:27 CEST je Maxime Ripard napisal(a): > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > >I have no idea what this is supposed to be doing either. > > > >

Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2

Hi Jernej, On Wed, Jun 07, 2017 at 08:15:12PM +0200, Jernej Škrabec wrote: > Hi! > > Dne sreda, 07. junij 2017 ob 16:38:27 CEST je Maxime Ripard napisal(a): > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > >I have no idea what this is supposed to be doing either. > > > >

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > Commit: > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > visible before page table updates") > > added smp_mb__before_spinlock() to set_tlb_flush_pending(). I think we > can solve the same problem

Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Wed, Jun 07, 2017 at 06:15:02PM +0200, Peter Zijlstra wrote: > Commit: > > af2c1401e6f9 ("mm: numa: guarantee that tlb_flush_pending updates are > visible before page table updates") > > added smp_mb__before_spinlock() to set_tlb_flush_pending(). I think we > can solve the same problem

TREAT AS URGENTLY PLEASE,

FROM MR JAMES KABORE AUDITING AND ACCOUNTING UNIT. BANK OF AFRICA. BURKINA FASO. Attn: Sir/ Madam, FROM MR JAMES KABORE Staff of Bank Of Africa in Burkina Faso. I would like you to indicate your interest to receive the transfer of ($10.5 Million Dollars) which I will like you to stand as the

TREAT AS URGENTLY PLEASE,

FROM MR JAMES KABORE AUDITING AND ACCOUNTING UNIT. BANK OF AFRICA. BURKINA FASO. Attn: Sir/ Madam, FROM MR JAMES KABORE Staff of Bank Of Africa in Burkina Faso. I would like you to indicate your interest to receive the transfer of ($10.5 Million Dollars) which I will like you to stand as the

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Fri, 9 Jun 2017, Kai-Heng Feng wrote: > As Alan Stern points out [1], the PME signal is not enabled when > controller is in D3, therefore it's not being woken up when new deivces > get plugged in. > > Workaround this bug by preventing the controller enters D3 power state. > > [1]

Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Fri, 9 Jun 2017, Kai-Heng Feng wrote: > As Alan Stern points out [1], the PME signal is not enabled when > controller is in D3, therefore it's not being woken up when new deivces > get plugged in. > > Workaround this bug by preventing the controller enters D3 power state. > > [1]

Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile

On 09/06/17 14:56, YT Shen wrote: > On Wed, 2017-05-31 at 14:42 +0200, Matthias Brugger wrote: [...] >>> + cpu0: cpu@0 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a35"; >> >> do you mean cortex-a53? > No, the cpu is cortex-a35. >

Re: [PATCH v2 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile

On 09/06/17 14:56, YT Shen wrote: > On Wed, 2017-05-31 at 14:42 +0200, Matthias Brugger wrote: [...] >>> + cpu0: cpu@0 { >>> + device_type = "cpu"; >>> + compatible = "arm,cortex-a35"; >> >> do you mean cortex-a53? > No, the cpu is cortex-a35. >

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/9/2017 9:11 AM, Geert Uytterhoeven wrote: Hi Babu, On Fri, Jun 9, 2017 at 3:55 PM, Babu Moger wrote: On 6/9/2017 2:16 AM, Geert Uytterhoeven wrote: On Fri, Jun 9, 2017 at 9:05 AM, Geert Uytterhoeven wrote: Here is the original discussion

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

On 6/9/2017 9:11 AM, Geert Uytterhoeven wrote: Hi Babu, On Fri, Jun 9, 2017 at 3:55 PM, Babu Moger wrote: On 6/9/2017 2:16 AM, Geert Uytterhoeven wrote: On Fri, Jun 9, 2017 at 9:05 AM, Geert Uytterhoeven wrote: Here is the original discussion

Re: [PATCH 1/8] rbtree: Cache leftmost node internally

On Fri, 09 Jun 2017, Jan Kara wrote: Looks good to me. Just one nit below: Thanks for having a look! @@ -150,6 +161,7 @@ extern void __rb_erase_color(struct rb_node *parent, struct rb_root *root, static __always_inline struct rb_node * __rb_erase_augmented(struct rb_node *node, struct

Re: [PATCH 1/8] rbtree: Cache leftmost node internally

On Fri, 09 Jun 2017, Jan Kara wrote: Looks good to me. Just one nit below: Thanks for having a look! @@ -150,6 +161,7 @@ extern void __rb_erase_color(struct rb_node *parent, struct rb_root *root, static __always_inline struct rb_node * __rb_erase_augmented(struct rb_node *node, struct

RE: [PATCH] Drivers: unisys: visorhba - style fix

> -Original Message- > From: Derek Robson [mailto:robso...@gmail.com] > Sent: Friday, June 9, 2017 1:16 AM > To: Kershner, David A ; > gre...@linuxfoundation.org; Binder, David Anthony > ; Sell, Timothy C ; >

RE: [PATCH] Drivers: unisys: visorhba - style fix

> -Original Message- > From: Derek Robson [mailto:robso...@gmail.com] > Sent: Friday, June 9, 2017 1:16 AM > To: Kershner, David A ; > gre...@linuxfoundation.org; Binder, David Anthony > ; Sell, Timothy C ; > Wadgaonkar, Sameer Laxmikant ; > Thompson, Bryan E. ; robso...@gmail.com > Cc:

[PATCH] l2tp: cast l2tp traffic counter to unsigned

This fixes a counter problem on 32bit systems: When the rx_bytes counter reached 2 GiB, it jumpd to (2^64 Bytes - 2GiB) Bytes. rtnl_link_stats64 has __u64 type and atomic_long_read returns atomic_long_t which is signed. Due to the conversation we get an incorrect value on 32bit systems if the MSB

[PATCH] l2tp: cast l2tp traffic counter to unsigned

This fixes a counter problem on 32bit systems: When the rx_bytes counter reached 2 GiB, it jumpd to (2^64 Bytes - 2GiB) Bytes. rtnl_link_stats64 has __u64 type and atomic_long_read returns atomic_long_t which is signed. Due to the conversation we get an incorrect value on 32bit systems if the MSB

Re: [PATCH v8 6/9] drivers: perf: hisi: Add support for Hisilicon Djtag driver

On Fri, Jun 09, 2017 at 03:18:39PM +0100, John Garry wrote: > On 08/06/2017 17:35, Mark Rutland wrote: > >Hi, > > > >On Mon, May 22, 2017 at 08:48:32PM +0800, Shaokun Zhang wrote: > >>+/* > >>+ * hisi_djtag_lock_v2: djtag lock to avoid djtag access conflict b/w kernel > >>+ * and UEFI. > > > >The

Re: [PATCH v8 6/9] drivers: perf: hisi: Add support for Hisilicon Djtag driver

On Fri, Jun 09, 2017 at 03:18:39PM +0100, John Garry wrote: > On 08/06/2017 17:35, Mark Rutland wrote: > >Hi, > > > >On Mon, May 22, 2017 at 08:48:32PM +0800, Shaokun Zhang wrote: > >>+/* > >>+ * hisi_djtag_lock_v2: djtag lock to avoid djtag access conflict b/w kernel > >>+ * and UEFI. > > > >The

Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote: > The LP87565 chip is a power management IC for Portable Navigation Systems > and Tablet Computing devices. It contains the following components: > > - Configurable Bucks(Single and multi-phase). > - Configurable General

Re: Sleeping BUG in khugepaged for i586

On 06/09/2017 01:48 AM, Vlastimil Babka wrote: On 06/08/2017 10:30 PM, Michal Hocko wrote: But I guess you are primary after syncing the preemptive mode for 64 and 32b systems, right? I agree that having a different model is more than unfortunate because 32b gets much less testing coverage and

Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote: > The LP87565 chip is a power management IC for Portable Navigation Systems > and Tablet Computing devices. It contains the following components: > > - Configurable Bucks(Single and multi-phase). > - Configurable General

Re: Sleeping BUG in khugepaged for i586

On 06/09/2017 01:48 AM, Vlastimil Babka wrote: On 06/08/2017 10:30 PM, Michal Hocko wrote: But I guess you are primary after syncing the preemptive mode for 64 and 32b systems, right? I agree that having a different model is more than unfortunate because 32b gets much less testing coverage and

Re: [PATCH v2 1/3] dt-bindings: remoteproc: Add Keystone DSP remoteproc binding

On Wed, Jun 07, 2017 at 07:24:45PM -0500, Suman Anna wrote: > Add the device tree bindings document for the Texas Instrument's > Keystone 2 DSP remoteproc devices. > > Signed-off-by: Suman Anna > Signed-off-by: Sam Nelson > --- > v2 Changes: > - Modified the

Re: [PATCH v2 1/3] dt-bindings: remoteproc: Add Keystone DSP remoteproc binding

On Wed, Jun 07, 2017 at 07:24:45PM -0500, Suman Anna wrote: > Add the device tree bindings document for the Texas Instrument's > Keystone 2 DSP remoteproc devices. > > Signed-off-by: Suman Anna > Signed-off-by: Sam Nelson > --- > v2 Changes: > - Modified the patch title > - Dropped unstable

Re: [PATCH v8 02/34] [media] dt-bindings: Add bindings for i.MX media driver

On Thu, Jun 08, 2017 at 10:08:35AM -0700, Steve Longerbeam wrote: > > > On 06/08/2017 09:45 AM, Steve Longerbeam wrote: > > Hi Rob, Mark, > > > > Are there any remaining technical issues with this > > binding doc? At this point an Ack from you is the only > > thing holding up merge of the

Re: [PATCH v8 02/34] [media] dt-bindings: Add bindings for i.MX media driver

On Thu, Jun 08, 2017 at 10:08:35AM -0700, Steve Longerbeam wrote: > > > On 06/08/2017 09:45 AM, Steve Longerbeam wrote: > > Hi Rob, Mark, > > > > Are there any remaining technical issues with this > > binding doc? At this point an Ack from you is the only > > thing holding up merge of the

[RFC v4 05/20] mm: RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need

[RFC v4 05/20] mm: RCU free VMAs

From: Peter Zijlstra Manage the VMAs with SRCU such that we can do a lockless VMA lookup. We put the fput(vma->vm_file) in the SRCU callback, this keeps files valid during speculative faults, this is possible due to the delayed fput work by Al Viro -- do we need srcu_barrier() in unmount

[RFC v4 11/20] mm/spf: Protect changes to vm_flags

Protect VMA's flags change against the speculative page fault handler. Signed-off-by: Laurent Dufour --- fs/proc/task_mmu.c | 2 ++ mm/mempolicy.c | 2 ++ mm/mlock.c | 9 ++--- mm/mmap.c | 2 ++ mm/mprotect.c | 2 ++ 5 files changed, 14

[RFC v4 11/20] mm/spf: Protect changes to vm_flags

Protect VMA's flags change against the speculative page fault handler. Signed-off-by: Laurent Dufour --- fs/proc/task_mmu.c | 2 ++ mm/mempolicy.c | 2 ++ mm/mlock.c | 9 ++--- mm/mmap.c | 2 ++ mm/mprotect.c | 2 ++ 5 files changed, 14 insertions(+), 3

[RFC v4 07/20] mm/spf: Try spin lock in speculative path

There is a deadlock when a CPU is doing a speculative page fault and another one is calling do_unmap(). The deadlock occurred because the speculative path try to spinlock the pte while the interrupt are disabled. When the other CPU in the unmap's path has locked the pte then is waiting for all

[RFC v4 07/20] mm/spf: Try spin lock in speculative path

There is a deadlock when a CPU is doing a speculative page fault and another one is calling do_unmap(). The deadlock occurred because the speculative path try to spinlock the pte while the interrupt are disabled. When the other CPU in the unmap's path has locked the pte then is waiting for all

[RFC v4 09/20] mm/spf: don't set fault entry's fields if locking failed

In the case pte_map_lock failed to lock the pte or if the VMA is no more valid, the fault entry's fields should not be set so that caller won't try to unlock it. Signed-off-by: Laurent Dufour --- mm/memory.c | 14 +- 1 file changed, 9 insertions(+), 5

[RFC v4 09/20] mm/spf: don't set fault entry's fields if locking failed

In the case pte_map_lock failed to lock the pte or if the VMA is no more valid, the fault entry's fields should not be set so that caller won't try to unlock it. Signed-off-by: Laurent Dufour --- mm/memory.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[RFC v4 03/20] mm: Introduce pte_spinlock

This is needed because in handle_pte_fault() pte_offset_map() is called and then fe->ptl is fetched and spin_locked. This was previously embedded in the call to pte_offset_map_lock(). Signed-off-by: Laurent Dufour --- mm/memory.c | 15 +++ 1 file

[RFC v4 03/20] mm: Introduce pte_spinlock

This is needed because in handle_pte_fault() pte_offset_map() is called and then fe->ptl is fetched and spin_locked. This was previously embedded in the call to pte_offset_map_lock(). Signed-off-by: Laurent Dufour --- mm/memory.c | 15 +++ 1 file changed, 11 insertions(+), 4

Re: [PATCH 14/15] devicetree/bindings: Add GCW vendor prefix

On Wed, Jun 07, 2017 at 10:04:38PM +0200, Paul Cercueil wrote: > Games Consoles Worldwide, mostly known under the acronym GCW, is the > creator of the GCW Zero open-source video game system. > > Signed-off-by: Paul Cercueil > --- >

Re: [PATCH 14/15] devicetree/bindings: Add GCW vendor prefix

On Wed, Jun 07, 2017 at 10:04:38PM +0200, Paul Cercueil wrote: > Games Consoles Worldwide, mostly known under the acronym GCW, is the > creator of the GCW Zero open-source video game system. > > Signed-off-by: Paul Cercueil > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >

[RFC v4 14/20] mm/spf: protect madvise vs speculative pf

This patch protects madvise's effect against the speculative page fault handler. Signed-off-by: Laurent Dufour --- mm/madvise.c | 4 1 file changed, 4 insertions(+) diff --git a/mm/madvise.c b/mm/madvise.c index 25b78ee4fc2c..d1fa6a7ee604 100644 ---

[RFC v4 14/20] mm/spf: protect madvise vs speculative pf

This patch protects madvise's effect against the speculative page fault handler. Signed-off-by: Laurent Dufour --- mm/madvise.c | 4 1 file changed, 4 insertions(+) diff --git a/mm/madvise.c b/mm/madvise.c index 25b78ee4fc2c..d1fa6a7ee604 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@

[RFC v4 10/20] mm/spf; fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

Re: [PATCH 05/15] serial: 8250_ingenic: Add support for the JZ4770 SoC

On Wed, Jun 07, 2017 at 10:04:29PM +0200, Paul Cercueil wrote: > The JZ4770 SoC's UART is no different from the other JZ SoCs, so this > commit simply adds the ingenic,jz4770-uart compatible string. > > Signed-off-by: Paul Cercueil > --- >

[RFC v4 10/20] mm/spf; fix lock dependency against mapping->i_mmap_rwsem

kworker/32:1/819 is trying to acquire lock: (>vm_sequence){+.+...}, at: [] zap_page_range_single+0xd0/0x1a0 but task is already holding lock: (>i_mmap_rwsem){..}, at: [] unmap_mapping_range+0x7c/0x160 which lock already depends on the new lock. the existing dependency chain (in reverse

Re: [PATCH 05/15] serial: 8250_ingenic: Add support for the JZ4770 SoC

On Wed, Jun 07, 2017 at 10:04:29PM +0200, Paul Cercueil wrote: > The JZ4770 SoC's UART is no different from the other JZ SoCs, so this > commit simply adds the ingenic,jz4770-uart compatible string. > > Signed-off-by: Paul Cercueil > --- >

[RFC v4 16/20] mm/spf: Don't call user fault callback in the speculative path

The handle_userfault() function assumes that the mmap_sem is held which is not true in the case of a speculative page fault handling. When doing a speculative page fault, lets retry it in the usual path to call handle_userfault(). Signed-off-by: Laurent Dufour ---

[RFC v4 12/20] mm/spf Protect vm_policy's changes against speculative pf

Mark the VMA touched when policy changes are applied to it so that speculative page fault will be aborted. Signed-off-by: Laurent Dufour --- mm/mempolicy.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c

[RFC v4 16/20] mm/spf: Don't call user fault callback in the speculative path

The handle_userfault() function assumes that the mmap_sem is held which is not true in the case of a speculative page fault handling. When doing a speculative page fault, lets retry it in the usual path to call handle_userfault(). Signed-off-by: Laurent Dufour --- mm/memory.c | 4 1 file

[RFC v4 12/20] mm/spf Protect vm_policy's changes against speculative pf

Mark the VMA touched when policy changes are applied to it so that speculative page fault will be aborted. Signed-off-by: Laurent Dufour --- mm/mempolicy.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c index 13d32c25226c..5e44b3e69a0d

[RFC v4 20/20] mm/spf: Clear FAULT_FLAG_KILLABLE in the speculative path

The flag FAULT_FLAG_KILLABLE should be unset to not allow the mmap_sem to released in __lock_page_or_retry(). In this patch the unsetting of the flag FAULT_FLAG_ALLOW_RETRY is also moved into handle_speculative_fault() since this has to be done for all architectures. Signed-off-by: Laurent

[RFC v4 20/20] mm/spf: Clear FAULT_FLAG_KILLABLE in the speculative path

The flag FAULT_FLAG_KILLABLE should be unset to not allow the mmap_sem to released in __lock_page_or_retry(). In this patch the unsetting of the flag FAULT_FLAG_ALLOW_RETRY is also moved into handle_speculative_fault() since this has to be done for all architectures. Signed-off-by: Laurent

[RFC v4 19/20] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with WM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. Signed-off-by: Laurent Dufour

[RFC v4 17/20] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/fault.c | 18

[RFC v4 17/20] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/mm/fault.c | 18 ++ 1 file changed, 18

[RFC v4 19/20] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with WM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. Signed-off-by: Laurent Dufour ---

[RFC v4 15/20] mm/spf: protect mremap() against speculative pf

mremap() is modifying the VMA layout and thus must be protected against the speculative page fault handler. Signed-off-by: Laurent Dufour --- mm/mremap.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/mremap.c b/mm/mremap.c index

[RFC v4 18/20] x86/mm: Update the handle_speculative_fault's path

If handle_speculative_fault failed due to a VM ERROR, we try again the slow path to allow the signal to be delivered. Signed-off-by: Laurent Dufour --- arch/x86/mm/fault.c | 21 + 1 file changed, 9 insertions(+), 12 deletions(-) diff --git

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