Re: trace name copy/paste in native_write_msr ?

On Fri, Jun 03, 2016 at 11:32:51AM +0100, Dr. David Alan Gilbert wrote: > Hi Andi, > In arch/x86/include/asm/msr.h native_write_msr(_safe) > you added a trace test in 7f47d8cc, should the > tracepoint_active's be testing for __tracepoint_write_msr ? Yes it should. Thanks for noticing. Please

Re: trace name copy/paste in native_write_msr ?

On Fri, Jun 03, 2016 at 11:32:51AM +0100, Dr. David Alan Gilbert wrote: > Hi Andi, > In arch/x86/include/asm/msr.h native_write_msr(_safe) > you added a trace test in 7f47d8cc, should the > tracepoint_active's be testing for __tracepoint_write_msr ? Yes it should. Thanks for noticing. Please

Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, 3 Jun 2016, Chung-Geol Kim wrote: > Yes, you are right, The presentational errors in order to obtain an > understanding of the process. > Therefore, I will be happy to explain again the diagrammatic representation > as shown below. > If using usb 3.0 storage(OTG), you can see as below.

Re: Re: Re: [PATCH] usb: core: fix a double free in the usb driver

On Fri, 3 Jun 2016, Chung-Geol Kim wrote: > Yes, you are right, The presentational errors in order to obtain an > understanding of the process. > Therefore, I will be happy to explain again the diagrammatic representation > as shown below. > If using usb 3.0 storage(OTG), you can see as below.

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

On Friday 03 June 2016 06:59 PM, Guenter Roeck wrote: On 06/03/2016 03:06 AM, Jonathan Cameron wrote: On 01/06/16 13:34, Laxman Dewangan wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C interface from Texas Instruments. The INA3221 monitors both

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

On Friday 03 June 2016 06:59 PM, Guenter Roeck wrote: On 06/03/2016 03:06 AM, Jonathan Cameron wrote: On 01/06/16 13:34, Laxman Dewangan wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C interface from Texas Instruments. The INA3221 monitors both

Re: [PATCH 1/4] of: Add device tree bindings for Evatronix

Hi Ricard, On Thu, 2 Jun 2016 09:47:18 +0200 Ricard Wanderlof wrote: > Devicetree bindings for the driver for the Evatronix NANDFLASH-CTRL NAND flash > controller IP. This controller is used in the Axis ARTPEC-6 SoC. > > The driver supports BCH ECC using the

Re: [PATCH 1/4] of: Add device tree bindings for Evatronix

Hi Ricard, On Thu, 2 Jun 2016 09:47:18 +0200 Ricard Wanderlof wrote: > Devicetree bindings for the driver for the Evatronix NANDFLASH-CTRL NAND flash > controller IP. This controller is used in the Axis ARTPEC-6 SoC. > > The driver supports BCH ECC using the controller's hardware, but there

Re: [PATCH] usb: usbip: fix null pointer dereference

On Fri, 3 Jun 2016, Krzysztof Opasiak wrote: > On 06/02/2016 03:22 PM, Sudip Mukherjee wrote: > > We have been dereferencing udc before checking it. Lets use it after it > > has been checked. > > > > To be honest I have mixed feelings about this patch. > > On one hand it prevents us from

Re: [PATCH] usb: usbip: fix null pointer dereference

On Fri, 3 Jun 2016, Krzysztof Opasiak wrote: > On 06/02/2016 03:22 PM, Sudip Mukherjee wrote: > > We have been dereferencing udc before checking it. Lets use it after it > > has been checked. > > > > To be honest I have mixed feelings about this patch. > > On one hand it prevents us from

[PATCHv4] rcu: tree: correctly handle sparse possible cpus

In many cases in the RCU tree code, we iterate over the set of cpus for a leaf node described by rcu_node::grplo and rcu_node::grphi, checking per-cpu data for each cpu in this range. However, if the set of possible cpus is sparse, some cpus described in this range are not possible, and thus no

[PATCHv4] rcu: tree: correctly handle sparse possible cpus

In many cases in the RCU tree code, we iterate over the set of cpus for a leaf node described by rcu_node::grplo and rcu_node::grphi, checking per-cpu data for each cpu in this range. However, if the set of possible cpus is sparse, some cpus described in this range are not possible, and thus no

Re: [PATCH v3] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Rob, On 2016年06月01日 22:45, Rob Herring wrote: On Thu, May 26, 2016 at 09:02:22PM +0800, Xing Zheng wrote: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v3: -

Re: [PATCH v3] ASoC: rockchip: Add machine driver for MAX98357A/RT5514/DA7219

Hi Rob, On 2016年06月01日 22:45, Rob Herring wrote: On Thu, May 26, 2016 at 09:02:22PM +0800, Xing Zheng wrote: There are multi codec devices on the RK3399 platform, we can use this patch support and control these codecs. Signed-off-by: Xing Zheng --- Changes in v3: - rename DOC to

[PATCH] lightnvm: Make functions not used by ouside static

Mark functions not used by ouside of thier implementing file as static. Signed-off-by: Johannes Thumshirn --- drivers/lightnvm/core.c | 2 +- drivers/lightnvm/sysblk.c | 8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/lightnvm/core.c

[PATCH] lightnvm: Make functions not used by ouside static

Mark functions not used by ouside of thier implementing file as static. Signed-off-by: Johannes Thumshirn --- drivers/lightnvm/core.c | 2 +- drivers/lightnvm/sysblk.c | 8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/lightnvm/core.c

[PATCH v2] sched: fix hierarchical order in rq->leaf_cfs_rq_list

Fix the insertion of cfs_rq in rq->leaf_cfs_rq_list to ensure that a child will always called before its parent. The hierarchical order in shares update list has been introduced by commit 67e86250f8ea ("sched: Introduce hierarchal order on shares update list") With the current implementation a

[PATCH v2] sched: fix hierarchical order in rq->leaf_cfs_rq_list

Fix the insertion of cfs_rq in rq->leaf_cfs_rq_list to ensure that a child will always called before its parent. The hierarchical order in shares update list has been introduced by commit 67e86250f8ea ("sched: Introduce hierarchal order on shares update list") With the current implementation a

[RFC PATCH] drm: msm: Add ASoC generic hdmi audio codec support.

This patch adds support to generic audio codec via ASoC hdmi-codec infrastucture which is merged recently. Signed-off-by: Srinivas Kandagatla --- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/hdmi/hdmi.c | 120

[RFC PATCH] drm: msm: Add ASoC generic hdmi audio codec support.

This patch adds support to generic audio codec via ASoC hdmi-codec infrastucture which is merged recently. Signed-off-by: Srinivas Kandagatla --- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/hdmi/hdmi.c | 120 +++-

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On 06/03/2016 06:21 AM, Heikki Krogerus wrote: Hi, On Thu, Jun 02, 2016 at 09:12:19AM -0700, Guenter Roeck wrote: On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote: On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote: On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

On 06/03/2016 06:21 AM, Heikki Krogerus wrote: Hi, On Thu, Jun 02, 2016 at 09:12:19AM -0700, Guenter Roeck wrote: On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote: On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote: On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Thu, Jun 02, 2016 at 02:21:10PM +0200, Michal Hocko wrote: > Testing with the patch makes some sense as well, but I would like to > hear from Andrea whether the approach is good because I am wondering why > he hasn't done that before - it feels so much simpler than the current > code. The

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Thu, Jun 02, 2016 at 02:21:10PM +0200, Michal Hocko wrote: > Testing with the patch makes some sense as well, but I would like to > hear from Andrea whether the approach is good because I am wondering why > he hasn't done that before - it feels so much simpler than the current > code. The

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Fri 03-06-16 15:45:09, Michal Hocko wrote: > On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote: > [...] > > Michal, I'll try to test during the weekend (away from the affected box > > now), but in the worst case it can as late as next Thursday (gonna travel > > next week). > > No problem. I

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Fri 03-06-16 15:45:09, Michal Hocko wrote: > On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote: > [...] > > Michal, I'll try to test during the weekend (away from the affected box > > now), but in the worst case it can as late as next Thursday (gonna travel > > next week). > > No problem. I

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Fri, Jun 03, 2016 at 01:47:34PM +0100, Will Deacon wrote: > > Now, the normal atomic_foo_acquire() stuff uses smp_mb() as per > > smp_mb__after_atomic(), its just ARM64 and PPC that go all 'funny' and > > need this extra barrier. Blergh. So lets shelf this issue for a bit. > > Hmm... I

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Fri, Jun 03, 2016 at 01:47:34PM +0100, Will Deacon wrote: > > Now, the normal atomic_foo_acquire() stuff uses smp_mb() as per > > smp_mb__after_atomic(), its just ARM64 and PPC that go all 'funny' and > > need this extra barrier. Blergh. So lets shelf this issue for a bit. > > Hmm... I

RE: [PATCH v2 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: 02 June 2016 04:48 > To: pramod.ku...@broadcom.com > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; > catalin.mari...@arm.com;

RE: [PATCH v2 5/7] net:mdio-mux: Add MDIO mux driver for iProc SoCs

Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: 02 June 2016 04:48 > To: pramod.ku...@broadcom.com > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; > catalin.mari...@arm.com;

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 06:32:38AM -0700, Paul E. McKenney wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03,

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 06:32:38AM -0700, Paul E. McKenney wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03,

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote: [...] > Michal, I'll try to test during the weekend (away from the affected box > now), but in the worst case it can as late as next Thursday (gonna travel > next week). No problem. I would really like to hear from Andrea before we give this a

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On Fri 03-06-16 22:38:13, Sergey Senozhatsky wrote: [...] > Michal, I'll try to test during the weekend (away from the affected box > now), but in the worst case it can as late as next Thursday (gonna travel > next week). No problem. I would really like to hear from Andrea before we give this a

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Fri, Jun 03, 2016 at 01:47:34PM +0100, Will Deacon wrote: > Even on x86, I think you need a fence here: > > X86 lock > { > } > P0| P1; > MOV EAX,$1| MOV EAX,$1; > LOCK XCHG [x],EAX | LOCK XCHG [y],EAX ; > MOV EBX,[y] | MOV EBX,[x]

Re: [PATCH -v4 5/7] locking, arch: Update spin_unlock_wait()

On Fri, Jun 03, 2016 at 01:47:34PM +0100, Will Deacon wrote: > Even on x86, I think you need a fence here: > > X86 lock > { > } > P0| P1; > MOV EAX,$1| MOV EAX,$1; > LOCK XCHG [x],EAX | LOCK XCHG [y],EAX ; > MOV EBX,[y] | MOV EBX,[x]

Re: [PATCH 1/2] clk: rockchip: release io resource when failing to init clk

Am Freitag, 3. Juni 2016, 08:54:18 schrieb Shawn Lin: > We should call iounmap to relase reg_base since it's not going > to be used any more if failing to init clk. > > Signed-off-by: Shawn Lin applied to my clk-fixes branch for 4.7, after adding a line to the patch-

Re: [PATCH 1/2] clk: rockchip: release io resource when failing to init clk

Am Freitag, 3. Juni 2016, 08:54:18 schrieb Shawn Lin: > We should call iounmap to relase reg_base since it's not going > to be used any more if failing to init clk. > > Signed-off-by: Shawn Lin applied to my clk-fixes branch for 4.7, after adding a line to the patch- description explaining that

RE: [PATCH v2 1/7] mdio:mux: Enhanced MDIO mux framework for integrated multiplexers

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: 01 June 2016 18:32 > To: Pramod Kumar > Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin > Marinas; Will Deacon; Kishon Vijay Abraham I; David S. Miller; >

RE: [PATCH v2 1/7] mdio:mux: Enhanced MDIO mux framework for integrated multiplexers

Hi Andrew, > -Original Message- > From: Andrew Lunn [mailto:and...@lunn.ch] > Sent: 01 June 2016 18:32 > To: Pramod Kumar > Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin > Marinas; Will Deacon; Kishon Vijay Abraham I; David S. Miller; >

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote: > >> latest version here: > >> > >> lkml.kernel.org/r/1453921746-16178-1-git-send-email-...@redhat.comz > > > >It's ready as far as I am concerned. > >Basically we are just waiting for ack from hpa. > > And I'm still discussing

Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?

On Thu, Mar 03, 2016 at 11:05:43AM -0800, H. Peter Anvin wrote: > >> latest version here: > >> > >> lkml.kernel.org/r/1453921746-16178-1-git-send-email-...@redhat.comz > > > >It's ready as far as I am concerned. > >Basically we are just waiting for ack from hpa. > > And I'm still discussing

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On (06/03/16 12:05), Michal Hocko wrote: > > > RIP collect_mm_slot() + 0x42/0x84 > > > khugepaged > > > > So is this really collect_mm_slot called directly from khugepaged or is > > some inlining going on there? inlining I suppose. > > > prepare_to_wait_event > > > maybe_pmd_mkwrite > > >

Re: [linux-next: Tree for Jun 1] __khugepaged_exit rwsem_down_write_failed lockup

On (06/03/16 12:05), Michal Hocko wrote: > > > RIP collect_mm_slot() + 0x42/0x84 > > > khugepaged > > > > So is this really collect_mm_slot called directly from khugepaged or is > > some inlining going on there? inlining I suppose. > > > prepare_to_wait_event > > > maybe_pmd_mkwrite > > >

[PATCH V3 4/9] cpufreq: exynos: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 4/9] cpufreq: exynos: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 5/9] cpufreq: ia64: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 5/9] cpufreq: ia64: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

The drivers aren't required to provide a sorted frequency table today, and its not optimal to work on an unsorted frequency tables. To simplify and improve code performance, always keep policy->freq_table sorted in ascending order. Now that freq_table is sorted, update

[PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in ascending order

The drivers aren't required to provide a sorted frequency table today, and its not optimal to work on an unsorted frequency tables. To simplify and improve code performance, always keep policy->freq_table sorted in ascending order. Now that freq_table is sorted, update

[PATCH V3 9/9] cpufreq: drivers: Free frequency tables after being used

The cpufreq core doesn't use these tables anymore after cpufreq_table_validate_and_show() has returned. And so these can be freed early. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 7 +++ drivers/cpufreq/at32ap-cpufreq.c| 6 +++---

[PATCH V3 6/9] cpufreq: imx: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 9/9] cpufreq: drivers: Free frequency tables after being used

The cpufreq core doesn't use these tables anymore after cpufreq_table_validate_and_show() has returned. And so these can be freed early. Signed-off-by: Viresh Kumar --- drivers/cpufreq/acpi-cpufreq.c | 7 +++ drivers/cpufreq/at32ap-cpufreq.c| 6 +++---

[PATCH V3 6/9] cpufreq: imx: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 3/9] cpufreq: elanfreq: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 1/9] cpufreq: Use policy->freq_table in ->target_index()

The 'policy' already contains a pointer to the freq table, use that instead of using driver specific tables name. This is done in order to make sure that the 'index' passed to the ->target_index() callback is used *only* to index into the policy->freq_table and nothing else. Later patches would

[PATCH V3 3/9] cpufreq: elanfreq: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 1/9] cpufreq: Use policy->freq_table in ->target_index()

The 'policy' already contains a pointer to the freq table, use that instead of using driver specific tables name. This is done in order to make sure that the 'index' passed to the ->target_index() callback is used *only* to index into the policy->freq_table and nothing else. Later patches would

[PATCH V3 7/9] cpufreq: maple: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 0/9] cpufreq: Sort policy->freq_table

Hi Rafael, So all my patches are contained in two series. The first one is: [PATCH V3 0/8] cpufreq: cleanups and reorganization which I have sent this morning. It does some cleanup and shall be applied regardless of this series. This series improves the performance of

[PATCH V3 2/9] cpufreq: blackfin: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 7/9] cpufreq: maple: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

[PATCH V3 0/9] cpufreq: Sort policy->freq_table

Hi Rafael, So all my patches are contained in two series. The first one is: [PATCH V3 0/8] cpufreq: cleanups and reorganization which I have sent this morning. It does some cleanup and shall be applied regardless of this series. This series improves the performance of

[PATCH V3 2/9] cpufreq: blackfin: Use 'index' only to index into policy->freq_table

Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'.

Re: [PATCH v2,3/5] dt-bindings: mtu3: add devicetree bindings

On 31/05/16 07:52, Chunfeng Yun wrote: add a DT binding doc for MediaTek USB3 DRD driver Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/usb/mtu3.txt | 85 1 file changed, 85 insertions(+) create mode 100644

Re: [PATCH v2,3/5] dt-bindings: mtu3: add devicetree bindings

On 31/05/16 07:52, Chunfeng Yun wrote: add a DT binding doc for MediaTek USB3 DRD driver Signed-off-by: Chunfeng Yun --- Documentation/devicetree/bindings/usb/mtu3.txt | 85 1 file changed, 85 insertions(+) create mode 100644

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 02:27:52PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03, 2016

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 02:27:52PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03, 2016

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > > > On Wednesday 25 May

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > > > On Wednesday 25 May

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote: > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > > > On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote: > > > > On Jun 02 2016 or thereabouts, Andy

Re: [PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > On Fri, 2016-06-03 at 14:23 +0200, Benjamin Tissoires wrote: > > > On Jun 03 2016 or thereabouts, Andy Shevchenko wrote: > > > On Fri, 2016-06-03 at 11:38 +0200, Benjamin Tissoires wrote: > > > > On Jun 02 2016 or thereabouts, Andy

Re: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

Le 03/06/2016 11:22, Yang, Wenyou a écrit : >> -Original Message- >> From: Rob Herring [mailto:r...@kernel.org] >> Sent: 2016年6月3日 9:54 >> To: Yang, Wenyou >> Cc: Alan Stern ; Greg Kroah-Hartman >> ; Ferre,

Re: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

Le 03/06/2016 11:22, Yang, Wenyou a écrit : >> -Original Message- >> From: Rob Herring [mailto:r...@kernel.org] >> Sent: 2016年6月3日 9:54 >> To: Yang, Wenyou >> Cc: Alan Stern ; Greg Kroah-Hartman >> ; Ferre, Nicolas ; >> Pawel Moll ; Mark Brown ; Ian >> Campbell ; Kumar Gala ; >> Alexandre

Re: [PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

Hi Andrew, The updated version includes a build fix for [PATCH 2/3. I also dropped the powerpc related changes from the series because that have dependencies against other patches not yet merged upstream. I am adding the same below for reference. >From 1f0975adfd3138f3709b2dec8771065ddc38de40

Re: [PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

Hi Andrew, The updated version includes a build fix for [PATCH 2/3. I also dropped the powerpc related changes from the series because that have dependencies against other patches not yet merged upstream. I am adding the same below for reference. >From 1f0975adfd3138f3709b2dec8771065ddc38de40

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

On 06/03/2016 03:06 AM, Jonathan Cameron wrote: On 01/06/16 13:34, Laxman Dewangan wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C interface from Texas Instruments. The INA3221 monitors both shunt voltage drops and bus supply voltages in addition to

Re: [PATCH 2/3] iio: adc: ina3221: Add support for IIO ADC driver for TI INA3221

On 06/03/2016 03:06 AM, Jonathan Cameron wrote: On 01/06/16 13:34, Laxman Dewangan wrote: The INA3221 is a three-channel, high-side current and bus voltage monitor with an I2C interface from Texas Instruments. The INA3221 monitors both shunt voltage drops and bus supply voltages in addition to

Re: [RFC PATCH v1 2/6] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

Hi, On Fri, Jun 3, 2016 at 5:47 AM, Shawn Lin wrote: > Ah, I missed the previous version as I think it should be from > non-version to v2 rather than from non-version to v1, which IIRC is from > Doug. :) Yup, patch-numbering is 1-based, not 0-based, so typically you

Re: [RFC PATCH v1 2/6] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

Hi, On Fri, Jun 3, 2016 at 5:47 AM, Shawn Lin wrote: > Ah, I missed the previous version as I think it should be from > non-version to v2 rather than from non-version to v1, which IIRC is from > Doug. :) Yup, patch-numbering is 1-based, not 0-based, so typically you have no-version => v2 => v3

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Hi, On Thu, Jun 02, 2016 at 09:12:19AM -0700, Guenter Roeck wrote: > On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote: > > On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote: > > > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote: > > > > On Thu, 2016-05-19

Re: [RFC PATCHv2] usb: USB Type-C Connector Class

Hi, On Thu, Jun 02, 2016 at 09:12:19AM -0700, Guenter Roeck wrote: > On Thu, Jun 02, 2016 at 01:18:53PM +0300, Heikki Krogerus wrote: > > On Wed, Jun 01, 2016 at 04:29:26PM -0700, Guenter Roeck wrote: > > > On Wed, Jun 01, 2016 at 11:26:09AM +0200, Oliver Neukum wrote: > > > > On Thu, 2016-05-19

Re: [PATCH] nvme: lightnvme: make MLC num_pairs little endian

On 06/03/2016 02:44 PM, Johannes Thumshirn wrote: According to the OpenChannel SSD interface specification the NAND flash MLC page pairing information's number of page page pairings field is the first two bytes in the MLC Page Pairing data structure. The hardware's data structure itself is

Re: [PATCH] nvme: lightnvme: make MLC num_pairs little endian

On 06/03/2016 02:44 PM, Johannes Thumshirn wrote: According to the OpenChannel SSD interface specification the NAND flash MLC page pairing information's number of page page pairings field is the first two bytes in the MLC Page Pairing data structure. The hardware's data structure itself is

[PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

For hugetlb like THP (and unlike regular page), we do tlb flush after dropping ptl. Because of the above, we don't need to track force_flush like we do now. Instead we can simply call tlb_remove_page() which will do the flush if needed. No functionality change in this patch. Signed-off-by:

[PATCH v2 1/3] mm/hugetlb: Simplify hugetlb unmap

For hugetlb like THP (and unlike regular page), we do tlb flush after dropping ptl. Because of the above, we don't need to track force_flush like we do now. Instead we can simply call tlb_remove_page() which will do the flush if needed. No functionality change in this patch. Signed-off-by:

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Fri, Jun 03, 2016 at 11:17:16AM +0200, Philipp Hahn wrote: > Hello, > > Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, > >> probably triggered by

Re: kernel BUG at linux-3.16.7-ckt25/fs/dcache.c:2373!

On Fri, Jun 03, 2016 at 11:17:16AM +0200, Philipp Hahn wrote: > Hello, > > Am 02.06.2016 um 22:02 schrieb J. Bruce Fields: > > On Thu, Jun 02, 2016 at 09:51:27AM +0200, Philipp Hahn wrote: > >> probably during heavy IO our file server crashed on a BUG_ON in dache.c, > >> probably triggered by

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

On Fri, Jun 3, 2016 at 4:48 PM, Matthias Brugger wrote: > On 03/06/16 08:12, Horng-Shyang Liao wrote: >> On Thu, 2016-06-02 at 10:46 +0200, Matthias Brugger wrote: >>> I keep thinking about how to get rid of the two data structures, >>> task_busy_list and the

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

On Fri, Jun 3, 2016 at 4:48 PM, Matthias Brugger wrote: > On 03/06/16 08:12, Horng-Shyang Liao wrote: >> On Thu, 2016-06-02 at 10:46 +0200, Matthias Brugger wrote: >>> I keep thinking about how to get rid of the two data structures, >>> task_busy_list and the task_release_wq. We need the latter

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

On 03/06/16 14:13, Horng-Shyang Liao wrote: Hi Matthias, On Fri, 2016-06-03 at 13:18 +0200, Matthias Brugger wrote: On 03/06/16 08:12, Horng-Shyang Liao wrote: Hi Mathias, Please see my inline reply. On Thu, 2016-06-02 at 10:46 +0200, Matthias Brugger wrote: On 01/06/16 11:57,

Re: [PATCH v8 2/3] CMDQ: Mediatek CMDQ driver

On 03/06/16 14:13, Horng-Shyang Liao wrote: Hi Matthias, On Fri, 2016-06-03 at 13:18 +0200, Matthias Brugger wrote: On 03/06/16 08:12, Horng-Shyang Liao wrote: Hi Mathias, Please see my inline reply. On Thu, 2016-06-02 at 10:46 +0200, Matthias Brugger wrote: On 01/06/16 11:57,

Re: [PATCH v2] sched/cputime: add steal clock warp handling

On Fri, 2016-06-03 at 13:21 +0800, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that sometimes st is 100% instantaneous, then idle is > 100%  > even if there is a cpu hog on the guest cpu after the cpu hotplug > comes  > back(N.B. this can not always be readily

Re: [PATCH v2] sched/cputime: add steal clock warp handling

On Fri, 2016-06-03 at 13:21 +0800, Wanpeng Li wrote: > From: Wanpeng Li > > I observed that sometimes st is 100% instantaneous, then idle is > 100%  > even if there is a cpu hog on the guest cpu after the cpu hotplug > comes  > back(N.B. this can not always be readily reproduced). I add trace to 

[PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

This update the generic and arch specific implementation to return true if we need to do a tlb flush. That means if a __tlb_remove_page indicate a flush is needed, the page we try to remove need to be tracked and added again after the flush. We need to track it because we have already update the

[PATCH v2 2/3] mm: Change the interface for __tlb_remove_page

This update the generic and arch specific implementation to return true if we need to do a tlb flush. That means if a __tlb_remove_page indicate a flush is needed, the page we try to remove need to be tracked and added again after the flush. We need to track it because we have already update the

[PATCH v2 3/3] mm/mmu_gather: Track page size with mmu gather and force flush if page size change

This allows arch which need to do special handing with respect to different page size when flushing tlb to implement the same in mmu gather Signed-off-by: Aneesh Kumar K.V --- arch/arm/include/asm/tlb.h | 18 ++ arch/ia64/include/asm/tlb.h | 18

[PATCH v2 3/3] mm/mmu_gather: Track page size with mmu gather and force flush if page size change

This allows arch which need to do special handing with respect to different page size when flushing tlb to implement the same in mmu gather Signed-off-by: Aneesh Kumar K.V --- arch/arm/include/asm/tlb.h | 18 ++ arch/ia64/include/asm/tlb.h | 18 ++

Re: [PATCH v3 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

Tony, On 06/03/16 14:03, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Collected the patches (4 of them) at the beginning which touches mach-omap2 > - Smaller changes in the moved patches to make sure they compile. > > Changes since v1: > - patches (2) added to remove the inclusion of

Re: [PATCH v3 00/27] fb/drm: omapdss: Clean up the headers and separate the two stack

Tony, On 06/03/16 14:03, Peter Ujfalusi wrote: > Hi, > > Changes since v2: > - Collected the patches (4 of them) at the beginning which touches mach-omap2 > - Smaller changes in the moved patches to make sure they compile. > > Changes since v1: > - patches (2) added to remove the inclusion of

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