Re: [PATCH v1 00/14] tee: optee: add dynamic shared memory support

Hi, On Thu, Sep 28, 2017 at 09:03:57PM +0300, Volodymyr Babchuk wrote: > From: Volodymyr Babchuk > > This patch series enables dynamic shared memory support in the TEE > subsystem as a whole and in OP-TEE in particular. > > Global Platform TEE specification [1] allows

Re: [PATCH v1 00/14] tee: optee: add dynamic shared memory support

Hi, On Thu, Sep 28, 2017 at 09:03:57PM +0300, Volodymyr Babchuk wrote: > From: Volodymyr Babchuk > > This patch series enables dynamic shared memory support in the TEE > subsystem as a whole and in OP-TEE in particular. > > Global Platform TEE specification [1] allows client applications > to

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote: > > Does this mean whenever we get a page fault in a RCU read-side critical > > section, we may hit this? > > > > Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the > > fault process is in a RCU read-side critical

Re: [PATCH v1 06/14] tee: optee: add page list manipulation functions

On 29.09.17 03:23, Yury Norov wrote: On Thu, Sep 28, 2017 at 09:04:03PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk These functions will be used to pass information about shared buffers to OP-TEE. Signed-off-by: Volodymyr Babchuk

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Fri, Sep 29, 2017 at 12:01:24PM +0200, Paolo Bonzini wrote: > > Does this mean whenever we get a page fault in a RCU read-side critical > > section, we may hit this? > > > > Could we simply avoid to schedule() in kvm_async_pf_task_wait() if the > > fault process is in a RCU read-side critical

Re: [PATCH v1 06/14] tee: optee: add page list manipulation functions

On 29.09.17 03:23, Yury Norov wrote: On Thu, Sep 28, 2017 at 09:04:03PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk These functions will be used to pass information about shared buffers to OP-TEE. Signed-off-by: Volodymyr Babchuk --- drivers/tee/optee/call.c | 48

Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4

On 09/29, Ingo Molnar wrote: > >* Josh Poimboeuf wrote: > >> On Thu, Sep 28, 2017 at 04:53:09PM -0700, Linus Torvalds wrote: >> > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf >> > wrote: >> > > >> > > Reported-by: kernel test robot

Re: [PATCH] x86/asm: Fix inline asm call constraints for GCC 4.4

On 09/29, Ingo Molnar wrote: > >* Josh Poimboeuf wrote: > >> On Thu, Sep 28, 2017 at 04:53:09PM -0700, Linus Torvalds wrote: >> > On Thu, Sep 28, 2017 at 2:58 PM, Josh Poimboeuf >> > wrote: >> > > >> > > Reported-by: kernel test robot >> > > Fixes: f5caf621ee35 ("x86/asm: Fix inline asm call

Re: [linux-sunxi] Re: [PATCH v2 1/3] ARM: dts: sun8i: Add basic dtsi file for Allwinner R40

On Fri, Sep 29, 2017 at 6:25 PM, Icenowy Zheng wrote: > > > 于 2017年9月28日 GMT+08:00 下午11:11:03, Maxime Ripard > 写到: >>Hi, >> >>On Thu, Sep 28, 2017 at 09:25:41AM +, Icenowy Zheng wrote: >>> +/* >>> + * The

Re: [linux-sunxi] Re: [PATCH v2 1/3] ARM: dts: sun8i: Add basic dtsi file for Allwinner R40

On Fri, Sep 29, 2017 at 6:25 PM, Icenowy Zheng wrote: > > > 于 2017年9月28日 GMT+08:00 下午11:11:03, Maxime Ripard > 写到: >>Hi, >> >>On Thu, Sep 28, 2017 at 09:25:41AM +, Icenowy Zheng wrote: >>> +/* >>> + * The max-frequency properties in all MMC controller nodes >>> +

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, Sep 29, 2017 at 02:27:57AM +1000, Nicholas Piggin wrote: > The biggest power boxes are more tightly coupled than those big > SGI systems, but even so just plodding along taking and releasing > locks in turn would be fine on those SGI ones as well really. Not DoS > level. This is not a

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, Sep 29, 2017 at 02:27:57AM +1000, Nicholas Piggin wrote: > The biggest power boxes are more tightly coupled than those big > SGI systems, but even so just plodding along taking and releasing > locks in turn would be fine on those SGI ones as well really. Not DoS > level. This is not a

Re: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle

On 2017/8/29 20:46, Peter Zijlstra wrote: On Tue, Aug 29, 2017 at 11:46:41AM +, Yang Zhang wrote: In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here we just reuse this logic to update the poll time. It may be a little late to update the poll in ttwu_do_wakeup, but the

Re: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle

On 2017/8/29 20:46, Peter Zijlstra wrote: On Tue, Aug 29, 2017 at 11:46:41AM +, Yang Zhang wrote: In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here we just reuse this logic to update the poll time. It may be a little late to update the poll in ttwu_do_wakeup, but the

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Fri, Sep 29, 2017 at 10:01:24AM +, Paolo Bonzini wrote: > On 29/09/2017 11:30, Boqun Feng wrote: > > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: > > [...] > >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292 > >>> schedule+0x113/0x460 kernel/sched/core.c:3421 > >>>

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Fri, Sep 29, 2017 at 10:01:24AM +, Paolo Bonzini wrote: > On 29/09/2017 11:30, Boqun Feng wrote: > > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: > > [...] > >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292 > >>> schedule+0x113/0x460 kernel/sched/core.c:3421 > >>>

Re: [PATCH v2 1/3] ARM: dts: sun8i: Add basic dtsi file for Allwinner R40

于 2017年9月28日 GMT+08:00 下午11:11:03, Maxime Ripard 写到: >Hi, > >On Thu, Sep 28, 2017 at 09:25:41AM +, Icenowy Zheng wrote: >> +/* >> + * The max-frequency properties in all MMC controller nodes >> + * are conservative

Re: [PATCH v2 1/3] ARM: dts: sun8i: Add basic dtsi file for Allwinner R40

于 2017年9月28日 GMT+08:00 下午11:11:03, Maxime Ripard 写到: >Hi, > >On Thu, Sep 28, 2017 at 09:25:41AM +, Icenowy Zheng wrote: >> +/* >> + * The max-frequency properties in all MMC controller nodes >> + * are conservative values proven to work on Banana Pi M2

Re: [PATCH for-next 3/9] RDMA/hns: Add return statement when kzalloc return NULL in hns_roce_v1_recreate_lp_qp

On Fri, Sep 29, 2017 at 02:07:22PM +0800, Wei Hu (Xavier) wrote: > > > On 2017/9/28 20:59, Leon Romanovsky wrote: > > On Thu, Sep 28, 2017 at 07:56:59PM +0800, Wei Hu (Xavier) wrote: > > > > > > On 2017/9/28 17:13, Leon Romanovsky wrote: > > > > On Thu, Sep 28, 2017 at 12:57:28PM +0800, Wei Hu

Re: [PATCH for-next 3/9] RDMA/hns: Add return statement when kzalloc return NULL in hns_roce_v1_recreate_lp_qp

On Fri, Sep 29, 2017 at 02:07:22PM +0800, Wei Hu (Xavier) wrote: > > > On 2017/9/28 20:59, Leon Romanovsky wrote: > > On Thu, Sep 28, 2017 at 07:56:59PM +0800, Wei Hu (Xavier) wrote: > > > > > > On 2017/9/28 17:13, Leon Romanovsky wrote: > > > > On Thu, Sep 28, 2017 at 12:57:28PM +0800, Wei Hu

Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard wrote: > On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: >> On systems with 2 TCONs such as the A31, it is possible to demux the >> output of the TCONs to one encoder. >> >> Add support for this for the

Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard wrote: > On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: >> On systems with 2 TCONs such as the A31, it is possible to demux the >> output of the TCONs to one encoder. >> >> Add support for this for the A31. >> >> Signed-off-by: Chen-Yu

netlink backwards compatibility in userspace tools

Hi guys, One handy aspect of Netlink is that it's backwards compatible. This means that you can run old userspace utilities on new kernels, even if the new kernel supports new features and netlink attributes. The wire format is stable enough that the data marshaled can be extended without

netlink backwards compatibility in userspace tools

Hi guys, One handy aspect of Netlink is that it's backwards compatible. This means that you can run old userspace utilities on new kernels, even if the new kernel supports new features and netlink attributes. The wire format is stable enough that the data marshaled can be extended without

Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: > On systems with 2 TCONs such as the A31, it is possible to demux the > output of the TCONs to one encoder. > > Add support for this for the A31. > > Signed-off-by: Chen-Yu Tsai > --- >

Re: [PATCH v3 04/14] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Fri, Sep 29, 2017 at 08:22:56AM +, Chen-Yu Tsai wrote: > On systems with 2 TCONs such as the A31, it is possible to demux the > output of the TCONs to one encoder. > > Add support for this for the A31. > > Signed-off-by: Chen-Yu Tsai > --- > drivers/gpu/drm/sun4i/sun4i_tcon.c | 38 >

Re: [PATCH v3 03/14] drm/sun4i: tcon: Add variant callback for TCON output muxing

On Fri, Sep 29, 2017 at 08:22:55AM +, Chen-Yu Tsai wrote: > static const struct sun4i_tcon_quirks sun5i_a13_quirks = { > - .has_unknown_mux = true, > - .has_channel_1 = true, > + .has_unknown_mux= true, > + .has_channel_1 = true, > + .set_mux

Re: [PATCH v3 03/14] drm/sun4i: tcon: Add variant callback for TCON output muxing

On Fri, Sep 29, 2017 at 08:22:55AM +, Chen-Yu Tsai wrote: > static const struct sun4i_tcon_quirks sun5i_a13_quirks = { > - .has_unknown_mux = true, > - .has_channel_1 = true, > + .has_unknown_mux= true, > + .has_channel_1 = true, > + .set_mux

Re: [PATCH v2 2/3] ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra

On Thu, Sep 28, 2017 at 03:38:59PM +, Icenowy Zheng wrote: > > > 于 2017年9月28日 GMT+08:00 下午11:12:25, Maxime Ripard > 写到: > >On Thu, Sep 28, 2017 at 09:25:42AM +, Icenowy Zheng wrote: > >> + { > >> + vmmc-supply = <_dcdc1>; > >> + bus-width = <8>; > >>

Re: [PATCH v2 2/3] ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra

On Thu, Sep 28, 2017 at 03:38:59PM +, Icenowy Zheng wrote: > > > 于 2017年9月28日 GMT+08:00 下午11:12:25, Maxime Ripard > 写到: > >On Thu, Sep 28, 2017 at 09:25:42AM +, Icenowy Zheng wrote: > >> + { > >> + vmmc-supply = <_dcdc1>; > >> + bus-width = <8>; > >> + non-removable; > >> + status

Re: [PATCH v1 04/14] tee: shm: add page accessor functions

Hi Yury, On 29.09.17 01:14, Yury Norov wrote: Hi Volodymyr, On Thu, Sep 28, 2017 at 09:04:01PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk In order to register a shared buffer in TEE, we need accessor function that return list of pages for that buffer.

Re: [PATCH v1 04/14] tee: shm: add page accessor functions

Hi Yury, On 29.09.17 01:14, Yury Norov wrote: Hi Volodymyr, On Thu, Sep 28, 2017 at 09:04:01PM +0300, Volodymyr Babchuk wrote: From: Volodymyr Babchuk In order to register a shared buffer in TEE, we need accessor function that return list of pages for that buffer. Signed-off-by: Volodymyr

[PATCH RFC 3/4] pinctrl: Add support for muxing individual pins

From: Charles Keepax Currently pinmuxing can only be applied to groups, this has lead to several drivers within the kernel adding many pin groups that just contain a single pin to allow muxing of individual pins. Add support to the core for muxing individual

[PATCH RFC 3/4] pinctrl: Add support for muxing individual pins

From: Charles Keepax Currently pinmuxing can only be applied to groups, this has lead to several drivers within the kernel adding many pin groups that just contain a single pin to allow muxing of individual pins. Add support to the core for muxing individual pins. Groups are still used as a

[PATCH RFC 4/4] pinctrl: Add support for parsing individual pinmux from DT

From: Charles Keepax So as to not break existing drivers that rely on pins properties being treated as a group, leave functionality of the existing generic parsing functions the same. Add a new parsing function pinctrl_generic_dt_node_to_map_all that will map

[PATCH RFC 4/4] pinctrl: Add support for parsing individual pinmux from DT

From: Charles Keepax So as to not break existing drivers that rely on pins properties being treated as a group, leave functionality of the existing generic parsing functions the same. Add a new parsing function pinctrl_generic_dt_node_to_map_all that will map pin properties from DT to the newly

[PATCH 0/4] Add support for muxing individual pins

This series add support for muxing individual pins within pin mux, rather than just whole groups. Mainly, I had two motivations here, one to avoid the need to add loads of groups containing individual pins and hardware that actually has some internal concept of groups of pins, and disambiguating

[PATCH 0/4] Add support for muxing individual pins

This series add support for muxing individual pins within pin mux, rather than just whole groups. Mainly, I had two motivations here, one to avoid the need to add loads of groups containing individual pins and hardware that actually has some internal concept of groups of pins, and disambiguating

[PATCH RFC 1/4] pinctrl: Factor out individual pin handling from pinmux_pins_show

Add a new helper function to be called for each pin rather than keeping everything in the same function. Primarily this just reduces the code indentation a bit. Signed-off-by: Charles Keepax --- drivers/pinctrl/pinmux.c | 100

[PATCH RFC 1/4] pinctrl: Factor out individual pin handling from pinmux_pins_show

Add a new helper function to be called for each pin rather than keeping everything in the same function. Primarily this just reduces the code indentation a bit. Signed-off-by: Charles Keepax --- drivers/pinctrl/pinmux.c | 100 +-- 1 file changed, 53

[PATCH RFC 2/4] pinctrl: Rename mux group to group_or_pin to prepare for pin support

From: Charles Keepax To prepare for adding support for muxing individual pins rename the group member of the pinctrl_map_mux and pinctrl_setting_mux structs to group_or_pin. Signed-off-by: Charles Keepax ---

[PATCH RFC 2/4] pinctrl: Rename mux group to group_or_pin to prepare for pin support

From: Charles Keepax To prepare for adding support for muxing individual pins rename the group member of the pinctrl_map_mux and pinctrl_setting_mux structs to group_or_pin. Signed-off-by: Charles Keepax --- drivers/pinctrl/bcm/pinctrl-bcm2835.c | 2 +- drivers/pinctrl/core.h

Mr Neil Trotter

A donation of 1 million British Pounds to you in good faith

Mr Neil Trotter

A donation of 1 million British Pounds to you in good faith

Re: [PATCH] scripts/decodecode: Fix decoding for AArch64 (arm64) instructions

On Thu, Sep 28, 2017 at 07:01:35PM +0100, Will Deacon wrote: > On Thu, Sep 28, 2017 at 03:37:04PM +0100, Dave Martin wrote: > > On Thu, Sep 28, 2017 at 03:14:47PM +0100, Will Deacon wrote: > > > On Thu, Sep 28, 2017 at 01:42:31PM +0100, Dave Martin wrote: > > > > On Thu, Sep 28, 2017 at 11:55:47AM

Re: [PATCH] scripts/decodecode: Fix decoding for AArch64 (arm64) instructions

On Thu, Sep 28, 2017 at 07:01:35PM +0100, Will Deacon wrote: > On Thu, Sep 28, 2017 at 03:37:04PM +0100, Dave Martin wrote: > > On Thu, Sep 28, 2017 at 03:14:47PM +0100, Will Deacon wrote: > > > On Thu, Sep 28, 2017 at 01:42:31PM +0100, Dave Martin wrote: > > > > On Thu, Sep 28, 2017 at 11:55:47AM

[PATCH] drm/virtio: Replace instances of reference/unreference with get/put

Replace reference/unreference with get/put as it is consistent with the kernel coding style. Done using the following semantic patch by coccinelle. @r@ expression e; @@ -drm_gem_object_unreference_unlocked(e); +drm_gem_object_put_unlocked(e); Signed-off-by: Srishti Sharma

[PATCH] drm/virtio: Replace instances of reference/unreference with get/put

Replace reference/unreference with get/put as it is consistent with the kernel coding style. Done using the following semantic patch by coccinelle. @r@ expression e; @@ -drm_gem_object_unreference_unlocked(e); +drm_gem_object_put_unlocked(e); Signed-off-by: Srishti Sharma ---

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On 29/09/2017 11:30, Boqun Feng wrote: > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: > [...] >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292 >>> schedule+0x113/0x460 kernel/sched/core.c:3421 >>> kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158 >> >> It is

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On 29/09/2017 11:30, Boqun Feng wrote: > On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: > [...] >>> __schedule+0x201/0x2240 kernel/sched/core.c:3292 >>> schedule+0x113/0x460 kernel/sched/core.c:3421 >>> kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158 >> >> It is

[PATCH] drm/arm: Replace instances of drm_dev_unref with drm_dev_put.

Replace drm_dev_unref with drm_dev_put as it is more consistent with kernel coding style. Done using the following semantic patch by coccinelle. @r@ expression e; @@ -drm_dev_unref(); +drm_dev_put(); Signed-off-by: Srishti Sharma --- drivers/gpu/drm/arm/hdlcd_drv.c | 4

[PATCH] drm/arm: Replace instances of drm_dev_unref with drm_dev_put.

Replace drm_dev_unref with drm_dev_put as it is more consistent with kernel coding style. Done using the following semantic patch by coccinelle. @r@ expression e; @@ -drm_dev_unref(); +drm_dev_put(); Signed-off-by: Srishti Sharma --- drivers/gpu/drm/arm/hdlcd_drv.c | 4 ++--

[PATCH v2 0/1] mm: only dispaly online cpus of the numa node

v1 -> v2: Replace local variable "cpumask_var_t mask" with dynamic memory alloc: alloc_cpumask_var, to avoid possible stack overflow. Zhen Lei (1): mm: only dispaly online cpus of the numa node drivers/base/node.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.5.0

[PATCH v2 0/1] mm: only dispaly online cpus of the numa node

v1 -> v2: Replace local variable "cpumask_var_t mask" with dynamic memory alloc: alloc_cpumask_var, to avoid possible stack overflow. Zhen Lei (1): mm: only dispaly online cpus of the numa node drivers/base/node.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.5.0

[PATCH v2 1/1] mm: only dispaly online cpus of the numa node

When I executed numactl -H(which read /sys/devices/system/node/nodeX/cpumap and display cpumask_of_node for each node), but I got different result on X86 and arm64. For each numa node, the former only displayed online CPUs, and the latter displayed all possible CPUs. Unfortunately, both Linux

[PATCH v2 1/1] mm: only dispaly online cpus of the numa node

When I executed numactl -H(which read /sys/devices/system/node/nodeX/cpumap and display cpumask_of_node for each node), but I got different result on X86 and arm64. For each numa node, the former only displayed online CPUs, and the latter displayed all possible CPUs. Unfortunately, both Linux

Re: How to verify linux-next

** Re sending ** Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot

Re: How to verify linux-next

** Re sending ** Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

Brandon, On Thu, Sep 28, 2017 at 10:25:32AM -0500, Brandon Streiff wrote: > - Patch #2: We expose the switch time as a PTP clock but don't support > adjustment (max_adj=0). The driver should implement a cyclecounter/timecounter. > Our platform adjusted a systemwide oscillator > from

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

Brandon, On Thu, Sep 28, 2017 at 10:25:32AM -0500, Brandon Streiff wrote: > - Patch #2: We expose the switch time as a PTP clock but don't support > adjustment (max_adj=0). The driver should implement a cyclecounter/timecounter. > Our platform adjusted a systemwide oscillator > from

How to verify linux-next

Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot with linux-next

How to verify linux-next

Hi, I have a general question. How do we normally verify linux-next tree? I wanted to work on linux-next but I am facing some issues. I could able to build linux-next for both x86 and arm, but I could not verify it on any machine. Currently I don't have a real Linux PC to boot with linux-next

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

On 2017年09月29日 00:09, Willem de Bruijn wrote: On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang wrote: On 2017年09月28日 07:25, Willem de Bruijn wrote: In the future, both simple and sophisticated policy like RSS or other guest driven steering policies could be done on top.

Re: [PATCH net-next 0/3] support changing steering policies in tuntap

On 2017年09月29日 00:09, Willem de Bruijn wrote: On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang wrote: On 2017年09月28日 07:25, Willem de Bruijn wrote: In the future, both simple and sophisticated policy like RSS or other guest driven steering policies could be done on top. IMHO there should be a

[PATCH v2] ARM: dts: stm32: Add DMAMUX support for STM32H743 SoC

This patch adds DMAMUX support for STM32H743 SoC. Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Update DTS to be compliant with up-streamed bindings v1: * Initial --- --- arch/arm/boot/dts/stm32h743.dtsi | 12 1

[PATCH v2] ARM: dts: stm32: Add DMAMUX support for STM32H743 SoC

This patch adds DMAMUX support for STM32H743 SoC. Signed-off-by: Pierre-Yves MORDRET --- Version history: v2: * Update DTS to be compliant with up-streamed bindings v1: * Initial --- --- arch/arm/boot/dts/stm32h743.dtsi | 12 1 file changed, 12 insertions(+)

[tip:x86/urgent] x86/asm: Fix inline asm call constraints for GCC 4.4

Commit-ID: b9545e75894b4866c62b36682527f5df1394ac58 Gitweb: https://git.kernel.org/tip/b9545e75894b4866c62b36682527f5df1394ac58 Author: Josh Poimboeuf AuthorDate: Thu, 28 Sep 2017 16:58:26 -0500 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017

[tip:x86/urgent] x86/asm: Fix inline asm call constraints for GCC 4.4

Commit-ID: b9545e75894b4866c62b36682527f5df1394ac58 Gitweb: https://git.kernel.org/tip/b9545e75894b4866c62b36682527f5df1394ac58 Author: Josh Poimboeuf AuthorDate: Thu, 28 Sep 2017 16:58:26 -0500 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017 09:59:17 +0200 x86/asm: Fix inline asm

答复: 答复: [PATCH] mfd: rtsx: Add support for RTS5260

> On Fri, 22 Sep 2017, 冯锐 wrote: > > > > On Fri, Sep 22, 2017 at 05:36:24PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the definitions of some internal > > > >

答复: 答复: [PATCH] mfd: rtsx: Add support for RTS5260

> On Fri, 22 Sep 2017, 冯锐 wrote: > > > > On Fri, Sep 22, 2017 at 05:36:24PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the definitions of some internal > > > > registers and workflow have to

[tip:locking/urgent] locking/rwsem-xadd: Fix missed wakeup due to reordering of load

Commit-ID: 9c29c31830a4eca724e137a9339137204bbb31be Gitweb: https://git.kernel.org/tip/9c29c31830a4eca724e137a9339137204bbb31be Author: Prateek Sood AuthorDate: Thu, 7 Sep 2017 20:00:58 +0530 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017

[tip:locking/urgent] locking/rwsem-xadd: Fix missed wakeup due to reordering of load

Commit-ID: 9c29c31830a4eca724e137a9339137204bbb31be Gitweb: https://git.kernel.org/tip/9c29c31830a4eca724e137a9339137204bbb31be Author: Prateek Sood AuthorDate: Thu, 7 Sep 2017 20:00:58 +0530 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017 10:10:20 +0200 locking/rwsem-xadd: Fix

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: [...] > > __schedule+0x201/0x2240 kernel/sched/core.c:3292 > > schedule+0x113/0x460 kernel/sched/core.c:3421 > > kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158 > > It is kvm_async_pf_task_wait() that calls

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 04:05:14PM +, Paul E. McKenney wrote: [...] > > __schedule+0x201/0x2240 kernel/sched/core.c:3292 > > schedule+0x113/0x460 kernel/sched/core.c:3421 > > kvm_async_pf_task_wait+0x43f/0x940 arch/x86/kernel/kvm.c:158 > > It is kvm_async_pf_task_wait() that calls

[tip:perf/urgent] perf/aux: Only update ->aux_wakeup in non-overwrite mode

Commit-ID: 441430eb54a00586f95f1aefc48e0801bbd6a923 Gitweb: https://git.kernel.org/tip/441430eb54a00586f95f1aefc48e0801bbd6a923 Author: Alexander Shishkin AuthorDate: Wed, 6 Sep 2017 19:08:11 +0300 Committer: Ingo Molnar CommitDate:

[tip:perf/urgent] perf/aux: Only update ->aux_wakeup in non-overwrite mode

Commit-ID: 441430eb54a00586f95f1aefc48e0801bbd6a923 Gitweb: https://git.kernel.org/tip/441430eb54a00586f95f1aefc48e0801bbd6a923 Author: Alexander Shishkin AuthorDate: Wed, 6 Sep 2017 19:08:11 +0300 Committer: Ingo Molnar CommitDate: Fri, 29 Sep 2017 10:06:45 +0200 perf/aux: Only

Re: [PATCH v2] perf/core: Fix updating cgroup time with descendants

On Fri, Sep 29, 2017 at 01:54:44PM +0800, Lin Xiulei wrote: > From: "leilei.lin" > > This fix updating cgroup time when event is being scheduled in > by descendants > > Signed-off-by: leilei.lin > Reviewed-and-tested-by: Jiri Olsa

Re: [PATCH v2] perf/core: Fix updating cgroup time with descendants

On Fri, Sep 29, 2017 at 01:54:44PM +0800, Lin Xiulei wrote: > From: "leilei.lin" > > This fix updating cgroup time when event is being scheduled in > by descendants > > Signed-off-by: leilei.lin > Reviewed-and-tested-by: Jiri Olsa Thanks!

[PATCH v2] x86, stacktrace: avoid recording save_stack_trace wrappers

The save_stack_trace() and save_stack_trace_tsk() wrappers of __save_stack_trace() add themselves to the call stack, and thus appear in the recorded stacktraces. This is redundant and wasteful when we have limited space to record the useful part of the backtrace with e.g. page_owner functionality.

[PATCH v2] x86, stacktrace: avoid recording save_stack_trace wrappers

The save_stack_trace() and save_stack_trace_tsk() wrappers of __save_stack_trace() add themselves to the call stack, and thus appear in the recorded stacktraces. This is redundant and wasteful when we have limited space to record the useful part of the backtrace with e.g. page_owner functionality.

[PATCH] serial: imx: Correct comment imx_flush_buffer()

The comment in imx_flush_buffer() states that the state of 4 registers are to be saved/restored, then only saves and restores 3 registers. The missing register (UBRC) is read only and thus can't be restored. Update the comment to reflect reality. Signed-off-by: Martyn Welch

[PATCH] serial: imx: Correct comment imx_flush_buffer()

The comment in imx_flush_buffer() states that the state of 4 registers are to be saved/restored, then only saves and restores 3 registers. The missing register (UBRC) is read only and thus can't be restored. Update the comment to reflect reality. Signed-off-by: Martyn Welch ---

Re: [PATCH] clk/tegra: Delete an error message for a failed memory allocation in three functions

Acked-By: Peter De Schrijver On Wed, Sep 27, 2017 at 06:53:10PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 27 Sep 2017 18:40:34 +0200 > > Omit extra messages for a memory allocation failure in these functions. >

Re: [PATCH] clk/tegra: Delete an error message for a failed memory allocation in three functions

Acked-By: Peter De Schrijver On Wed, Sep 27, 2017 at 06:53:10PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Wed, 27 Sep 2017 18:40:34 +0200 > > Omit extra messages for a memory allocation failure in these functions. > > This issue was detected by using the Coccinelle

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

From: Andrew Lunn > Sent: 28 September 2017 20:34 ... > > There are 34 counters. In normal case using generic bus I/O or PCI to read > > them > > is very quick, but the switch is mostly accessed using SPI, or even I2C. > > As the SPI > > access is very slow. > > How slow is it? The Marvell

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

From: Andrew Lunn > Sent: 28 September 2017 20:34 ... > > There are 34 counters. In normal case using generic bus I/O or PCI to read > > them > > is very quick, but the switch is mostly accessed using SPI, or even I2C. > > As the SPI > > access is very slow. > > How slow is it? The Marvell

[PATCH] cros_ec: sysfs: Fix memory leak in show/store_kb_wake_angle()

Add missing kfree of allocated cros_ec_command. Fixes: ff00af859354 ("platform/chrome: cros_ec: Add sysfs entry to set keyboard wake lid angle") Signed-off-by: Jeffy Chen --- drivers/platform/chrome/cros_ec_sysfs.c | 15 ++- 1 file changed, 10

[PATCH] cros_ec: sysfs: Fix memory leak in show/store_kb_wake_angle()

Add missing kfree of allocated cros_ec_command. Fixes: ff00af859354 ("platform/chrome: cros_ec: Add sysfs entry to set keyboard wake lid angle") Signed-off-by: Jeffy Chen --- drivers/platform/chrome/cros_ec_sysfs.c | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff

[PATCH] xhci: Cancel cmd_timer before cleanup the command queue in xhci_hc_died()

When the cmd_timer fired, it would try to access the command struct. So cancel it before cleanup the command queue in xhci_hc_died(), to avoid use-after-free reported by KASAN: [ 176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224 [ 176.960846] Write of size 4 at

[PATCH] xhci: Cancel cmd_timer before cleanup the command queue in xhci_hc_died()

When the cmd_timer fired, it would try to access the command struct. So cancel it before cleanup the command queue in xhci_hc_died(), to avoid use-after-free reported by KASAN: [ 176.952537] BUG: KASAN: use-after-free in xhci_handle_command_timeout+0x68/0x224 [ 176.960846] Write of size 4 at

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote: > On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote: > > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > > > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > > > > On Thu, Sep 28, 2017 at

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

On Thu, Sep 28, 2017 at 05:58:30PM -0700, Paul E. McKenney wrote: > On Fri, Sep 29, 2017 at 07:59:09AM +1300, Michael Cree wrote: > > On Thu, Sep 28, 2017 at 08:43:54AM -0700, Paul E. McKenney wrote: > > > On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote: > > > > On Thu, Sep 28, 2017 at

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 01, 2017 at 03:21:02PM +0200, Peter Zijlstra wrote: > Vincent reported that when running in a cgroup, his root > cfs_rq->avg.load_avg dropped to 0 on task idle. > > This is because reweight_entity() will now immediately propagate the > weight change of the group entity to its cfs_rq,

Re: [PATCH -v2 03/18] sched/fair: Cure calc_cfs_shares() vs reweight_entity()

On Fri, Sep 01, 2017 at 03:21:02PM +0200, Peter Zijlstra wrote: > Vincent reported that when running in a cgroup, his root > cfs_rq->avg.load_avg dropped to 0 on task idle. > > This is because reweight_entity() will now immediately propagate the > weight change of the group entity to its cfs_rq,

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

[+ Timur] On Thu, Sep 28, 2017 at 03:38:00PM -0400, Jon Masters wrote: > On 09/27/2017 11:49 AM, Will Deacon wrote: > > > The moral of the story is that read-after-read (same address) ordering > > *only* > > applies if READ_ONCE is used consistently. This means we need to fix page > > table

Re: [RFC PATCH 0/2] Missing READ_ONCE in core and arch-specific pgtable code leading to crashes

[+ Timur] On Thu, Sep 28, 2017 at 03:38:00PM -0400, Jon Masters wrote: > On 09/27/2017 11:49 AM, Will Deacon wrote: > > > The moral of the story is that read-after-read (same address) ordering > > *only* > > applies if READ_ONCE is used consistently. This means we need to fix page > > table

Re: [PATCH] mtd: nand: pxa3xx_nand: Update Kconfig information

Hi Thomas, On ven., sept. 29 2017, Thomas Petazzoni wrote: > Hello, > > Entering nitpick mode. nitpick accpeted! :) I am going to send a v2. Gregory > > On Thu, 28 Sep 2017 16:36:57 +0200, Gregory CLEMENT wrote: > >>This enables the driver for

Re: [PATCH] mtd: nand: pxa3xx_nand: Update Kconfig information

Hi Thomas, On ven., sept. 29 2017, Thomas Petazzoni wrote: > Hello, > > Entering nitpick mode. nitpick accpeted! :) I am going to send a v2. Gregory > > On Thu, 28 Sep 2017 16:36:57 +0200, Gregory CLEMENT wrote: > >>This enables the driver for the NAND flash device found on >> -

Re: [PATCH v2 4/4] mm:swap: skip swapcache for swapin of synchronous device

On Wed, Sep 20, 2017 at 1:43 PM, Minchan Kim wrote: > With fast swap storage, platform want to use swap more aggressively > and swap-in is crucial to application latency. > > The rw_page based synchronous devices like zram, pmem and btt are such > fast storage. When I profile

Re: [PATCH v2 4/4] mm:swap: skip swapcache for swapin of synchronous device

On Wed, Sep 20, 2017 at 1:43 PM, Minchan Kim wrote: > With fast swap storage, platform want to use swap more aggressively > and swap-in is crucial to application latency. > > The rw_page based synchronous devices like zram, pmem and btt are such > fast storage. When I profile swapin performance

<    6   7   8   9   10   11   12   13   >