Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

On Wed, Aug 3, 2016 at 3:00 AM, David Miller wrote: > > index 96161b8..ce19c5b 100644 > > --- a/include/uapi/linux/fib_rules.h > > +++ b/include/uapi/linux/fib_rules.h > > @@ -49,6 +49,8 @@ enum { > > FRA_TABLE, /* Extended table id */ > > FRA_FWMASK,

Re: [Regression?] fib_rules: Added NLM_F_EXCL support to fib_nl_newrule breaks Android userspace

On Wed, Aug 3, 2016 at 3:00 AM, David Miller wrote: > > index 96161b8..ce19c5b 100644 > > --- a/include/uapi/linux/fib_rules.h > > +++ b/include/uapi/linux/fib_rules.h > > @@ -49,6 +49,8 @@ enum { > > FRA_TABLE, /* Extended table id */ > > FRA_FWMASK, /* mask for

Re: [PATCH] clk: rockchip: rk3399: add pll up and down when change pll freq

Xing, On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng wrote: > From: Elaine Zhang > > The suggestion that is from IC designer, the correct pll sequence setting > should be like these: > > set pll to slow mode or other plls > set pll down >

Re: [PATCH] clk: rockchip: rk3399: add pll up and down when change pll freq

Xing, On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng wrote: > From: Elaine Zhang > > The suggestion that is from IC designer, the correct pll sequence setting > should be like these: > > set pll to slow mode or other plls > set pll down > set pll params > set pll up > wait pll lock

[RFC][PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds when p == current, but the CAP_SYS_NICE doesn't. Thus while the previous commit was intended to loosen the needed privledges to modify a processes

[RFC][PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

In changing from checking ptrace_may_access(p, PTRACE_MODE_ATTACH_FSCREDS) to capable(CAP_SYS_NICE), I missed that ptrace_my_access succeeds when p == current, but the CAP_SYS_NICE doesn't. Thus while the previous commit was intended to loosen the needed privledges to modify a processes

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

Em Wed, 03 Aug 2016 00:17:10 +0200 Florian Mickler escreveu: > cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?) Yes, my kernel.org address is up. Better to keep it as the canonical address, as this is unlikely to change as it is not associated to an

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

Em Wed, 03 Aug 2016 00:17:10 +0200 Florian Mickler escreveu: > cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?) Yes, my kernel.org address is up. Better to keep it as the canonical address, as this is unlikely to change as it is not associated to an e-mail provider. > >

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

Rafael Aquini wrote: > On Tue, Aug 02, 2016 at 03:27:06PM -0700, Nadav Amit wrote: >> Rafael Aquini wrote: >> >>> While backporting 71b3c126e611 ("x86/mm: Add barriers and document >>> switch_mm()-vs-flush synchronization") >>> we stumbled across a

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

Rafael Aquini wrote: > On Tue, Aug 02, 2016 at 03:27:06PM -0700, Nadav Amit wrote: >> Rafael Aquini wrote: >> >>> While backporting 71b3c126e611 ("x86/mm: Add barriers and document >>> switch_mm()-vs-flush synchronization") >>> we stumbled across a possibly missing barrier at

Re: Please don't replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 04:58:29PM -0400, Linus Torvalds wrote: > [ So I answered similarly to another patch, but I'll just re-iterate > and change the subject line so that it stands out a bit from the > millions of actual patches ] > > On Tue, Aug 2, 2016 at 1:42 PM, Pavel Machek

Re: Please don't replace numeric parameter like 0444 with macro

On Tue, Aug 02, 2016 at 04:58:29PM -0400, Linus Torvalds wrote: > [ So I answered similarly to another patch, but I'll just re-iterate > and change the subject line so that it stands out a bit from the > millions of actual patches ] > > On Tue, Aug 2, 2016 at 1:42 PM, Pavel Machek wrote: > > > >

Re: [PATCH] checkpatch: Look for symbolic permissions and suggest octal instead

On Wed, 2016-08-03 at 01:15 +0100, Al Viro wrote: > On Tue, Aug 02, 2016 at 04:39:24PM -0700, Joe Perches wrote: > > > > S_ uses should be avoided where octal is more intelligible. > Oh, for Cthulhu sake!  So not only we had been dribbled upon with 1200-odd > piles of pointless crap, now we'll be

Re: [PATCH] checkpatch: Look for symbolic permissions and suggest octal instead

On Wed, 2016-08-03 at 01:15 +0100, Al Viro wrote: > On Tue, Aug 02, 2016 at 04:39:24PM -0700, Joe Perches wrote: > > > > S_ uses should be avoided where octal is more intelligible. > Oh, for Cthulhu sake!  So not only we had been dribbled upon with 1200-odd > piles of pointless crap, now we'll be

Re: [PATCH v5 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Tue, Aug 02, 2016 at 02:52:54PM -0400, Lyude wrote: > Now that we can hook into update_crtcs and control the order in which we > update CRTCs at each modeset, we can finish the final step of fixing > Skylake's watermark handling by performing DDB updates at the same time > as plane updates and

Re: [PATCH v5 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

On Tue, Aug 02, 2016 at 02:52:54PM -0400, Lyude wrote: > Now that we can hook into update_crtcs and control the order in which we > update CRTCs at each modeset, we can finish the final step of fixing > Skylake's watermark handling by performing DDB updates at the same time > as plane updates and

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

Hi Luis, On Wed, 3 Aug 2016 00:02:43 +0200 "Luis R. Rodriguez" wrote: > > Thanks for the confirmation. For how long is it known this is broken? > Does anyone care and fix these ? Or is this best effort? This has been broken for many years :-( I have a couple of times almost

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

Hi Luis, On Wed, 3 Aug 2016 00:02:43 +0200 "Luis R. Rodriguez" wrote: > > Thanks for the confirmation. For how long is it known this is broken? > Does anyone care and fix these ? Or is this best effort? This has been broken for many years :-( I have a couple of times almost fixed it, but it

Re: [GIT PULL] KVM changes for 4.8 merge window

On 08/02/2016 10:17 PM, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds > wrote: >> >> No, I don't use the merge from linux-next directly. I just re-generate >> the merge myself, and if the pull request then includes a merge >> resolution

Re: [GIT PULL] KVM changes for 4.8 merge window

On 08/02/2016 10:17 PM, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 2:42 PM, Linus Torvalds > wrote: >> >> No, I don't use the merge from linux-next directly. I just re-generate >> the merge myself, and if the pull request then includes a merge >> resolution (either as just a verbal

Re: linux-next: please clean up the livepatching tree

Hi Stephen On Wed, 3 Aug 2016, Stephen Rothwell wrote: > The livepatching tree > (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next) > today consists of only lots of merges This is a part we keep discussing from time to time, and I still don't understand why it bothers

Re: linux-next: please clean up the livepatching tree

Hi Stephen On Wed, 3 Aug 2016, Stephen Rothwell wrote: > The livepatching tree > (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next) > today consists of only lots of merges This is a part we keep discussing from time to time, and I still don't understand why it bothers

[PATCH] checkpatch: Look for symbolic permissions and suggest octal instead

S_ uses should be avoided where octal is more intelligible. Signed-off-by: Joe Perches --- scripts/checkpatch.pl | 49 +++-- 1 file changed, 43 insertions(+), 6 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl

[PATCH] checkpatch: Look for symbolic permissions and suggest octal instead

S_ uses should be avoided where octal is more intelligible. Signed-off-by: Joe Perches --- scripts/checkpatch.pl | 49 +++-- 1 file changed, 43 insertions(+), 6 deletions(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index

Re: [PATCH v3 2/2] mmc: host: sunxi: add support for A64 mmc controller

Hi Icenowy, On 08/02/2016 12:13 AM, Icenowy Zheng wrote: > A64 SoC features a MMC controller which need only the mod clock, and can > calibrate delay by itself. This patch adds support for the new MMC > controller IP core. > > Signed-off-by: Icenowy Zheng > --- > Changes in

Re: [PATCH v3 2/2] mmc: host: sunxi: add support for A64 mmc controller

Hi Icenowy, On 08/02/2016 12:13 AM, Icenowy Zheng wrote: > A64 SoC features a MMC controller which need only the mod clock, and can > calibrate delay by itself. This patch adds support for the new MMC > controller IP core. > > Signed-off-by: Icenowy Zheng > --- > Changes in v2: > - Rebased on

[PATCH 4/4] (DO NOT APPLY) lib/raid6: Add unroll by 8 to AVX512 optimized gen_syndrome functions

Optimize RAID6 gen_syndrome functions by further unrolling by 8 to take advantage of all the 32 ZMM registers. Note: In theory avx512 unroll by 8 gen_syndrome function should perfom better than the rest of gen_syndrome functions, but it is outperformed by avx512 unroll by 4 gen_syndrome function

[PATCH 4/4] (DO NOT APPLY) lib/raid6: Add unroll by 8 to AVX512 optimized gen_syndrome functions

Optimize RAID6 gen_syndrome functions by further unrolling by 8 to take advantage of all the 32 ZMM registers. Note: In theory avx512 unroll by 8 gen_syndrome function should perfom better than the rest of gen_syndrome functions, but it is outperformed by avx512 unroll by 4 gen_syndrome function

[PATCH 3/4] lib/raid6/test/Makefile: Add avx512 gen_syndrome and recovery functions

Adding avx512 gen_syndrome and recovery functions so as to allow code to be compiled and tested successfully in userspace. This patch is tested in userspace and improvement in performace is observed. Cc: H. Peter Anvin Cc: Jim Kukunas Cc:

[PATCH 2/4] lib/raid6: Add AVX512 optimized recovery functions

Optimize RAID6 recovery functions to take advantage of the 512-bit ZMM integer instructions introduced in AVX512. AVX512 optimized recovery functions, which is simply based on recov_avx2.c written by Jim Kukunas This patch was tested and benchmarked before submission on a hardware that has

[PATCH 3/4] lib/raid6/test/Makefile: Add avx512 gen_syndrome and recovery functions

Adding avx512 gen_syndrome and recovery functions so as to allow code to be compiled and tested successfully in userspace. This patch is tested in userspace and improvement in performace is observed. Cc: H. Peter Anvin Cc: Jim Kukunas Cc: Fenghua Yu Signed-off-by: Megha Dey Signed-off-by:

[PATCH 2/4] lib/raid6: Add AVX512 optimized recovery functions

Optimize RAID6 recovery functions to take advantage of the 512-bit ZMM integer instructions introduced in AVX512. AVX512 optimized recovery functions, which is simply based on recov_avx2.c written by Jim Kukunas This patch was tested and benchmarked before submission on a hardware that has

[PATCH 1/4] lib/raid6: Add AVX512 optimized gen_syndrome functions

Optimize RAID6 gen_syndrom functions to take advantage of the 512-bit ZMM integer instructions introduced in AVX512. AVX512 optimized gen_syndrom functions, which is simply based on avx2.c written by Yuanhan Liu and sse2.c written by hpa. The patch was tested and benchmarked before submission on

[PATCH 1/4] lib/raid6: Add AVX512 optimized gen_syndrome functions

Optimize RAID6 gen_syndrom functions to take advantage of the 512-bit ZMM integer instructions introduced in AVX512. AVX512 optimized gen_syndrom functions, which is simply based on avx2.c written by Yuanhan Liu and sse2.c written by hpa. The patch was tested and benchmarked before submission on

linux-next: please clean up the livepatching tree

Hi Jiri, The livepatching tree (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next) today consists of only lots of merges (and a patch that is also reverted). Please just reset it to somewhere in Linus' tree. -- Cheers, Stephen Rothwell

linux-next: please clean up the livepatching tree

Hi Jiri, The livepatching tree (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next) today consists of only lots of merges (and a patch that is also reverted). Please just reset it to somewhere in Linus' tree. -- Cheers, Stephen Rothwell

[PATCH 0/4] Add AVX512 optimized gen_syndrome and recovery functions

This is the patch set for adding AVX512 optimized gen_syndrome and recovery functions. Optimization of RAID6 using AVX512 instructions should improve the RAID6 performance.These patches are tested and observed the improvement in performance. Gayatri Kammela (4): lib/raid6: Add AVX512 optimized

[PATCH 0/4] Add AVX512 optimized gen_syndrome and recovery functions

This is the patch set for adding AVX512 optimized gen_syndrome and recovery functions. Optimization of RAID6 using AVX512 instructions should improve the RAID6 performance.These patches are tested and observed the improvement in performance. Gayatri Kammela (4): lib/raid6: Add AVX512 optimized

[PATCH] net: make net namespace sysctls belong to container's owner

If net namespace is attached to a user namespace let's make container's root owner of sysctls affecting said network namespace instead of global root. This also allows us to clean up net_ctl_permissions() because we do not need to fudge permissions anymore for the container's owner since it now

[PATCH] net: make net namespace sysctls belong to container's owner

If net namespace is attached to a user namespace let's make container's root owner of sysctls affecting said network namespace instead of global root. This also allows us to clean up net_ctl_permissions() because we do not need to fudge permissions anymore for the container's owner since it now

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

On 08/02/2016 04:26 PM, Joe Perches wrote: > On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote: >> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?) >> >> Am Tue, 02 Aug 2016 09:36:21 -0700 >> schrieb Joe Perches : >> >>> >>> Hello Florian. >>> There

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

On 08/02/2016 04:26 PM, Joe Perches wrote: > On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote: >> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?) >> >> Am Tue, 02 Aug 2016 09:36:21 -0700 >> schrieb Joe Perches : >> >>> >>> Hello Florian. >>> There is at least an

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 17:13:59 -0500 Josh Poimboeuf wrote: > > Then we only need the fp use case when FRAME_POINTER is not set. As > > mcount forces FRAME_POINTER, we only need to worry about the fentry > > case. > > Hm, I'm confused. First, I don't see where mcount forces

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, 2 Aug 2016 17:13:59 -0500 Josh Poimboeuf wrote: > > Then we only need the fp use case when FRAME_POINTER is not set. As > > mcount forces FRAME_POINTER, we only need to worry about the fentry > > case. > > Hm, I'm confused. First, I don't see where mcount forces FRAME_POINTER. Hmm,

[PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code

From: Rafael J. Wysocki When CONFIG_RANDOMIZE_MEMORY is set on x86-64, __PAGE_OFFSET becomes a variable and using it as a symbol in the image memory restoration assembly code under core_restore_code is not correct any more. To avoid that problem, modify

[PATCH] x86/power/64: Do not refer to __PAGE_OFFSET from assembly code

From: Rafael J. Wysocki When CONFIG_RANDOMIZE_MEMORY is set on x86-64, __PAGE_OFFSET becomes a variable and using it as a symbol in the image memory restoration assembly code under core_restore_code is not correct any more. To avoid that problem, modify set_up_temporary_mappings() to compute

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

On Tue, Aug 02, 2016 at 03:27:06PM -0700, Nadav Amit wrote: > Rafael Aquini wrote: > > > While backporting 71b3c126e611 ("x86/mm: Add barriers and document > > switch_mm()-vs-flush synchronization") > > we stumbled across a possibly missing barrier at flush_tlb_page(). > > I

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

On Tue, Aug 02, 2016 at 03:27:06PM -0700, Nadav Amit wrote: > Rafael Aquini wrote: > > > While backporting 71b3c126e611 ("x86/mm: Add barriers and document > > switch_mm()-vs-flush synchronization") > > we stumbled across a possibly missing barrier at flush_tlb_page(). > > I too noticed it and

Re: [RFC][PATCH 6/7] cpufreq: schedutil: Add iowait boosting

On Monday, August 01, 2016 06:35:31 PM Steve Muckle wrote: > On Mon, Aug 01, 2016 at 01:37:59AM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Modify the schedutil cpufreq governor to boost the CPU frequency > > if the UUF_IO flag is passed to it

Re: [RFC][PATCH 6/7] cpufreq: schedutil: Add iowait boosting

On Monday, August 01, 2016 06:35:31 PM Steve Muckle wrote: > On Mon, Aug 01, 2016 at 01:37:59AM +0200, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Modify the schedutil cpufreq governor to boost the CPU frequency > > if the UUF_IO flag is passed to it via cpufreq_update_util(). >

Re: perf test BPF failing on f24: fix

On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote: > Hi Wang, > > Something changed and a function used in a perf test for BPF is > not anymore appearing on vmlinux, albeit still available on > /proc/kallsyms: > > # readelf -wi /lib/modules/4.7.0+/build/vmlinux |

Re: perf test BPF failing on f24: fix

On Tue, Aug 02, 2016 at 04:51:02PM -0300, Arnaldo Carvalho de Melo wrote: > Hi Wang, > > Something changed and a function used in a perf test for BPF is > not anymore appearing on vmlinux, albeit still available on > /proc/kallsyms: > > # readelf -wi /lib/modules/4.7.0+/build/vmlinux |

Re: [PATCH v5 1/2] of: add J-Core timer bindings

On Tue, May 17, 2016 at 11:18:58PM +, Rich Felker wrote: > Signed-off-by: Rich Felker > --- > .../devicetree/bindings/timer/jcore,pit.txt| 25 > ++ > 1 file changed, 25 insertions(+) > create mode 100644

Re: [PATCH v5 1/2] of: add J-Core timer bindings

On Tue, May 17, 2016 at 11:18:58PM +, Rich Felker wrote: > Signed-off-by: Rich Felker > --- > .../devicetree/bindings/timer/jcore,pit.txt| 25 > ++ > 1 file changed, 25 insertions(+) > create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt > >

mmotm 2016-08-02-15-53 uploaded

The mm-of-the-moment snapshot 2016-08-02-15-53 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2016-08-02-15-53 uploaded

The mm-of-the-moment snapshot 2016-08-02-15-53 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH v6 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[PATCH v6 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[PATCH v6 0/6] Finally fix watermarks

Latest version of https://patchwork.freedesktop.org/patch/102581/ . Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update plane watermarks atomically during plane updates drm/i915/skl: Ensure pipes with changed wms get added to the state drm/i915: Move

[PATCH v6 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

[PATCH v6 0/6] Finally fix watermarks

Latest version of https://patchwork.freedesktop.org/patch/102581/ . Lyude (5): drm/i915/skl: Add support for the SAGV, fix underrun hangs drm/i915/skl: Update plane watermarks atomically during plane updates drm/i915/skl: Ensure pipes with changed wms get added to the state drm/i915: Move

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Wednesday, August 3, 2016 12:02:43 AM CEST Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote: > > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote: > > > Are linux-next builds being tested for powerpc with allyesconfig and > > >

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Wednesday, August 3, 2016 12:02:43 AM CEST Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote: > > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote: > > > Are linux-next builds being tested for powerpc with allyesconfig and > > >

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

On Tue, Aug 2, 2016 at 3:27 PM, Nadav Amit wrote: > Rafael Aquini wrote: > >> While backporting 71b3c126e611 ("x86/mm: Add barriers and document >> switch_mm()-vs-flush synchronization") >> we stumbled across a possibly missing barrier at

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

On Tue, Aug 2, 2016 at 3:27 PM, Nadav Amit wrote: > Rafael Aquini wrote: > >> While backporting 71b3c126e611 ("x86/mm: Add barriers and document >> switch_mm()-vs-flush synchronization") >> we stumbled across a possibly missing barrier at flush_tlb_page(). > > I too noticed it and submitted a

Re: [PATCH v4 1/2] of: add J-Core SPI master bindings

On Tue, Aug 2, 2016 at 5:00 PM, Rich Felker wrote: > On Fri, Jul 29, 2016 at 03:58:38PM -0500, Rob Herring wrote: >> On Tue, May 17, 2016 at 11:19:25PM +, Rich Felker wrote: >> > Signed-off-by: Rich Felker >> > --- >> >

Re: [PATCH v4 1/2] of: add J-Core SPI master bindings

On Tue, Aug 2, 2016 at 5:00 PM, Rich Felker wrote: > On Fri, Jul 29, 2016 at 03:58:38PM -0500, Rob Herring wrote: >> On Tue, May 17, 2016 at 11:19:25PM +, Rich Felker wrote: >> > Signed-off-by: Rich Felker >> > --- >> > .../devicetree/bindings/spi/jcore,spi.txt | 30 >> >

[PATCH v6 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v6 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[PATCH v6 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

Re: [PATCH RESEND v2 0/8] Improve Rx/Tx DMA implementation

Hello, Any comments on this patchset? On 07/19/16 13:13, Bhuvanchandra DV wrote: Drop the clock change patch from v2 patchset[1] since it is applied. Changes since v1: Split suspend/resume patch. [1] https://lkml.org/lkml/2016/6/28/124 Bhuvanchandra DV (5): tty: serial: fsl_lpuart: Fix

[PATCH v6 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[PATCH v6 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

Re: [PATCH RESEND v2 0/8] Improve Rx/Tx DMA implementation

Hello, Any comments on this patchset? On 07/19/16 13:13, Bhuvanchandra DV wrote: Drop the clock change patch from v2 patchset[1] since it is applied. Changes since v1: Split suspend/resume patch. [1] https://lkml.org/lkml/2016/6/28/124 Bhuvanchandra DV (5): tty: serial: fsl_lpuart: Fix

[PATCH v6 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are actually changing; the values for

[PATCH v6 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[PATCH v6 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc:

Re: [RFC][PATCH 5/7] cpufreq / sched: UUF_IO flag to indicate iowait condition

On Wed, Aug 3, 2016 at 12:02 AM, Steve Muckle wrote: > On Tue, Aug 02, 2016 at 03:37:02AM +0200, Rafael J. Wysocki wrote: >> On Tue, Aug 2, 2016 at 3:22 AM, Steve Muckle wrote: >> > On Mon, Aug 01, 2016 at 01:37:23AM +0200, Rafael J. Wysocki

Re: [RFC][PATCH 5/7] cpufreq / sched: UUF_IO flag to indicate iowait condition

On Wed, Aug 3, 2016 at 12:02 AM, Steve Muckle wrote: > On Tue, Aug 02, 2016 at 03:37:02AM +0200, Rafael J. Wysocki wrote: >> On Tue, Aug 2, 2016 at 3:22 AM, Steve Muckle wrote: >> > On Mon, Aug 01, 2016 at 01:37:23AM +0200, Rafael J. Wysocki wrote: >> > ... >> >> For this purpose, define a new

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote: > cc'd mche...@s-opensource.com  (Mauro, is your kernel.org address up?) > >  Am Tue, 02 Aug 2016 09:36:21 -0700 > schrieb Joe Perches : > > > > > Hello Florian. > > There is at least an oddity with get_maintainer

Re: get_maintainer.pl and .mailmap entries with more than 2 addresses

On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote: > cc'd mche...@s-opensource.com  (Mauro, is your kernel.org address up?) > >  Am Tue, 02 Aug 2016 09:36:21 -0700 > schrieb Joe Perches : > > > > > Hello Florian. > > There is at least an oddity with get_maintainer handling of a > >

[ANNOUNCE] Tracing Summit 2016 schedule is now available

The Tracing Summit 2016 schedule is now available online at http://tracingsummit.org/wiki/TracingSummit2016 If you are interested to attend, don't forget to register by using the following link: https://www.regonline.com/tracingsummit16 There is no need to register to any other event, and

[ANNOUNCE] Tracing Summit 2016 schedule is now available

The Tracing Summit 2016 schedule is now available online at http://tracingsummit.org/wiki/TracingSummit2016 If you are interested to attend, don't forget to register by using the following link: https://www.regonline.com/tracingsummit16 There is no need to register to any other event, and

[GIT PULL] gcc-plugins update for v4.8-rc1

Hi, Please pull this new gcc-plugin for v4.8-rc1. This is the next gcc plugin from Emese Revfy, funded by CII, and builds on the new gcc-plugin infrastructure now present in Kbuild. It provides a way to generate additional entropy at boot and runtime, which is especially helpful for embedded

[GIT PULL] gcc-plugins update for v4.8-rc1

Hi, Please pull this new gcc-plugin for v4.8-rc1. This is the next gcc plugin from Emese Revfy, funded by CII, and builds on the new gcc-plugin infrastructure now present in Kbuild. It provides a way to generate additional entropy at boot and runtime, which is especially helpful for embedded

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

Rafael Aquini wrote: > While backporting 71b3c126e611 ("x86/mm: Add barriers and document > switch_mm()-vs-flush synchronization") > we stumbled across a possibly missing barrier at flush_tlb_page(). I too noticed it and submitted a similar patch that never got a response

Re: [PATCH] x86/mm: Add barriers and document switch_mm()-vs-flush synchronization follow-up

Rafael Aquini wrote: > While backporting 71b3c126e611 ("x86/mm: Add barriers and document > switch_mm()-vs-flush synchronization") > we stumbled across a possibly missing barrier at flush_tlb_page(). I too noticed it and submitted a similar patch that never got a response [1]. Regards, Nadav

Re: [RFC][PATCH 5/7] cpufreq / sched: UUF_IO flag to indicate iowait condition

On Tue, Aug 02, 2016 at 03:37:02AM +0200, Rafael J. Wysocki wrote: > On Tue, Aug 2, 2016 at 3:22 AM, Steve Muckle wrote: > > On Mon, Aug 01, 2016 at 01:37:23AM +0200, Rafael J. Wysocki wrote: > > ... > >> For this purpose, define a new cpufreq_update_util() flag > >>

Re: [RFC][PATCH 5/7] cpufreq / sched: UUF_IO flag to indicate iowait condition

On Tue, Aug 02, 2016 at 03:37:02AM +0200, Rafael J. Wysocki wrote: > On Tue, Aug 2, 2016 at 3:22 AM, Steve Muckle wrote: > > On Mon, Aug 01, 2016 at 01:37:23AM +0200, Rafael J. Wysocki wrote: > > ... > >> For this purpose, define a new cpufreq_update_util() flag > >> UUF_IO and modify

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote: > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote: > > Are linux-next builds being tested for powerpc with allyesconfig and > > allmodconfig ? I have some changes I'm making and while debugging my > > build issues I

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Tue, Aug 02, 2016 at 02:58:39PM -0700, Guenter Roeck wrote: > On Tue, Aug 02, 2016 at 01:07:09PM -0700, Luis R. Rodriguez wrote: > > Are linux-next builds being tested for powerpc with allyesconfig and > > allmodconfig ? I have some changes I'm making and while debugging my > > build issues I

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 05:16:10PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 16:00:11 -0500 > Josh Poimboeuf wrote: > >[] nmi_raise_cpu_backtrace+0x1b/0x20 > > > > The ret_stack is out of sync with the stack dump because the stack dump > > was started with the

Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues

On Tue, Aug 02, 2016 at 05:16:10PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 16:00:11 -0500 > Josh Poimboeuf wrote: > >[] nmi_raise_cpu_backtrace+0x1b/0x20 > > > > The ret_stack is out of sync with the stack dump because the stack dump > > was started with the regs from the NMI,

Re: [GIT PULL] kbuild changes for v4.8-rc1

On Tue, Aug 2, 2016 at 2:00 PM, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 4:55 PM, Kees Cook wrote: >> >> The version with $SRCARCH is the correct version. (I think akpm may >> have picked up the v1, but Michal requested some changes

Re: [GIT PULL] kbuild changes for v4.8-rc1

On Tue, Aug 2, 2016 at 2:00 PM, Linus Torvalds wrote: > On Tue, Aug 2, 2016 at 4:55 PM, Kees Cook wrote: >> >> The version with $SRCARCH is the correct version. (I think akpm may >> have picked up the v1, but Michal requested some changes that resulted >> in the v2 with the $SRCARCH correction.)

Re: [PATCH v5 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

On Tue, Aug 02, 2016 at 02:52:53PM -0400, Lyude wrote: > Since we have to write ddb allocations at the same time as we do other > plane updates, we're going to need to be able to control the order in > which we execute modesets on each pipe. The easiest way to do this is to > just factor this

Re: [PATCH v5 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

On Tue, Aug 02, 2016 at 02:52:53PM -0400, Lyude wrote: > Since we have to write ddb allocations at the same time as we do other > plane updates, we're going to need to be able to control the order in > which we execute modesets on each pipe. The easiest way to do this is to > just factor this

Re: [PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Peter, thank you for your reply. On Tue, 2016-08-02 at 12:37 +0200, Peter Zijlstra wrote: > On Tue, Jul 26, 2016 at 04:07:14PM +0200, Giovanni Gherdovich wrote: > > > Signed-off-by: Mike Galbraith > > Signed-off-by: Giovanni Gherdovich > > SoB

Re: [PATCH] sched/cputime: Mitigate performance regression in times()/clock_gettime()

Hello Peter, thank you for your reply. On Tue, 2016-08-02 at 12:37 +0200, Peter Zijlstra wrote: > On Tue, Jul 26, 2016 at 04:07:14PM +0200, Giovanni Gherdovich wrote: > > > Signed-off-by: Mike Galbraith > > Signed-off-by: Giovanni Gherdovich > > SoB chain is borken. Either Mike wrote the

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