[PATCH v2 5/6] ir-rx51: use hrtimer instead of dmtimer

Drop dmtimer usage for pulse timer in favor of hrtimer. That allows removing PWM dmitimer platform data usage. Signed-off-by: Ivaylo Dimitrov --- arch/arm/mach-omap2/board-rx51-peripherals.c | 4 - arch/arm/mach-omap2/pdata-quirks.c | 3 - drivers/media/rc/ir-rx51.c

[PATCH v2 2/6] pwm: omap-dmtimer: Allow for setting dmtimer clock source

OMAP GP timers can have different input clocks that allow different PWM frequencies. However, there is no other way of setting the clock source but through clocks or clock-names properties of the timer itself. This limits PWM functionality to only the frequencies allowed by the particular clock

Re: [PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

Hi Geert, > On May 16, 2016, at 22:06 , Geert Uytterhoeven wrote: > > On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou > wrote: >> Insert overlay symbols to the base tree when applied. >> This makes it possible to apply an overlay that

Re: [PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

Hi Geert, > On May 16, 2016, at 22:06 , Geert Uytterhoeven wrote: > > On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou > wrote: >> Insert overlay symbols to the base tree when applied. >> This makes it possible to apply an overlay that references a label >> that a previously inserted overlay

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, 16 May 2016 21:19:18 +0200 Borislav Petkov wrote: > Btw, arch_static_branch_jump() spells that 5-byte JMP too and not until > too long ago we had it in static_cpu_has()... Those are "special" too. If we can get the compiler to do the Right Thing (TM) then we should let

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, 16 May 2016 21:19:18 +0200 Borislav Petkov wrote: > Btw, arch_static_branch_jump() spells that 5-byte JMP too and not until > too long ago we had it in static_cpu_has()... Those are "special" too. If we can get the compiler to do the Right Thing (TM) then we should let it. > > I

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 16, 2016 10:06:08 AM PDT, Peter Zijlstra wrote: >On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: >> On 2016/5/11 17:31, Peter Zijlstra wrote: >> > Please use the GEN_*_RMWcc() stuff to avoid the setpo where >possible. >> >> Setpo is better. >> In most

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 16, 2016 10:06:08 AM PDT, Peter Zijlstra wrote: >On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: >> On 2016/5/11 17:31, Peter Zijlstra wrote: >> > Please use the GEN_*_RMWcc() stuff to avoid the setpo where >possible. >> >> Setpo is better. >> In most cases, we need to store

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 11, 2016 2:31:39 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 05:16:38PM +0800, zengzhao...@163.com wrote: > >> +static inline unsigned int __arch_parity4(unsigned int w) >> +{ >> +unsigned int res = 0; >> + >> +asm("test $0xf, %1; setpo %b0" >> +

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 11, 2016 2:31:39 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 05:16:38PM +0800, zengzhao...@163.com wrote: > >> +static inline unsigned int __arch_parity4(unsigned int w) >> +{ >> +unsigned int res = 0; >> + >> +asm("test $0xf, %1; setpo %b0" >> +: "+q" (res)

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Mon, May 16, 2016 at 05:48:26PM +0100, Mark Rutland wrote: > 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

Re: [PATCH] rcu: tree: correctly handle sparse possible CPUs

On Mon, May 16, 2016 at 05:48:26PM +0100, Mark Rutland wrote: > 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

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, May 16, 2016 at 03:13:57PM -0400, Steven Rostedt wrote: > I actually thought about this first, but I thought it rather a hack > (although one could argue all of function tracing is a hack ;-) ... I was about to say... > But as the "weak" call was used to fix one location, why not use >

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, May 16, 2016 at 03:13:57PM -0400, Steven Rostedt wrote: > I actually thought about this first, but I thought it rather a hack > (although one could argue all of function tracing is a hack ;-) ... I was about to say... > But as the "weak" call was used to fix one location, why not use >

Re: [PATCH v5 03/12] mm: balloon: use general non-lru movable page feature

Hi, [auto build test ERROR on next-20160506] [cannot apply to v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 03/12] mm: balloon: use general non-lru movable page feature

Hi, [auto build test ERROR on next-20160506] [cannot apply to v4.6-rc7 v4.6-rc6 v4.6-rc5 v4.6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, 16 May 2016 21:03:59 +0200 Borislav Petkov wrote: > On Mon, May 16, 2016 at 11:24:53PM +0900, Namhyung Kim wrote: > > > -GLOBAL(ftrace_stub) > > > +/* This is weak to keep gas from relaxing the jumps */ > > > +WEAK(ftrace_stub) > > > retq > > > END(ftrace_caller) > >

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, 16 May 2016 21:03:59 +0200 Borislav Petkov wrote: > On Mon, May 16, 2016 at 11:24:53PM +0900, Namhyung Kim wrote: > > > -GLOBAL(ftrace_stub) > > > +/* This is weak to keep gas from relaxing the jumps */ > > > +WEAK(ftrace_stub) > > > retq > > > END(ftrace_caller) > > You could also

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Sat, 2016-05-14 at 21:21 -0500, Eric W. Biederman wrote: > James Bottomley writes: > > > On Sat, 2016-05-14 at 10:53 +0100, Djalal Harouni wrote: > > Just a couple of quick comments from a very high level design point. > > - I think a shiftfs is

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Sat, 2016-05-14 at 21:21 -0500, Eric W. Biederman wrote: > James Bottomley writes: > > > On Sat, 2016-05-14 at 10:53 +0100, Djalal Harouni wrote: > > Just a couple of quick comments from a very high level design point. > > - I think a shiftfs is valuable in the same way that overlayfs is >

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

On Mon, May 16 2016, Felipe Balbi wrote: > Michal Nazarewicz writes: > >>> Alan Stern writes: The point is that you don't know whether the host sent more data than expected. All you know is that the host sent more data than the user

Re: [PATCH] usb: gadget: f_fs: report error if excess data received

On Mon, May 16 2016, Felipe Balbi wrote: > Michal Nazarewicz writes: > >>> Alan Stern writes: The point is that you don't know whether the host sent more data than expected. All you know is that the host sent more data than the user asked the kernel for -- but maybe the user

[ANNOUNCE] MDB Linux Kernel Debugger Linux v4.6

The following changes since commit 2dcd0af568b0cf583645c8a317dd12e344b1c72a: Linux 4.6 (2016-05-15 15:43:13 -0700) are available in the git repository at: https://github.com/jeffmerkey/linux.git tags/mdb-v4.6-tag for you to fetch changes up to 8c50856a5d798108aa4d5bfadb0c2172fce2448e:

[ANNOUNCE] MDB Linux Kernel Debugger Linux v4.6

The following changes since commit 2dcd0af568b0cf583645c8a317dd12e344b1c72a: Linux 4.6 (2016-05-15 15:43:13 -0700) are available in the git repository at: https://github.com/jeffmerkey/linux.git tags/mdb-v4.6-tag for you to fetch changes up to 8c50856a5d798108aa4d5bfadb0c2172fce2448e:

Re: [PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou wrote: > Insert overlay symbols to the base tree when applied. > This makes it possible to apply an overlay that references a label > that a previously inserted overlay had. > > Signed-off-by: Pantelis Antoniou

Re: [PATCH v2 4/5] of: overlay: Pick up label symbols from overlays.

On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou wrote: > Insert overlay symbols to the base tree when applied. > This makes it possible to apply an overlay that references a label > that a previously inserted overlay had. > > Signed-off-by: Pantelis Antoniou This patch hasn't changed, so I

Re: [PATCH v2 3/5] of: unittest: hashed phandles unitest

On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou wrote: > Add a benchmarking hashed phandles unittest which report what kind > of speed up we get switching to hashed phandle lookups. > > ### dt-test ### the hash method is 8.2 times faster than the original > >

Re: [PATCH v2 3/5] of: unittest: hashed phandles unitest

On Mon, May 16, 2016 at 6:52 PM, Pantelis Antoniou wrote: > Add a benchmarking hashed phandles unittest which report what kind > of speed up we get switching to hashed phandle lookups. > > ### dt-test ### the hash method is 8.2 times faster than the original > > On the beaglebone we perform

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, May 16, 2016 at 11:24:53PM +0900, Namhyung Kim wrote: > > -GLOBAL(ftrace_stub) > > +/* This is weak to keep gas from relaxing the jumps */ > > +WEAK(ftrace_stub) > > retq > > END(ftrace_caller) You could also force the 5-byte jump. I guess you could also write simply ".long 0" in

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

On 05/16/2016 11:52 AM, Alexander Graf wrote: > If you compile without OF_MDIO support in an RGMII configuration, we fail > to configure the dp83867 phy today by writing garbage into its configuration > registers. > > On the other hand if you do compile with OF_MDIO and the phy gets loaded via >

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Mon, May 16, 2016 at 11:24:53PM +0900, Namhyung Kim wrote: > > -GLOBAL(ftrace_stub) > > +/* This is weak to keep gas from relaxing the jumps */ > > +WEAK(ftrace_stub) > > retq > > END(ftrace_caller) You could also force the 5-byte jump. I guess you could also write simply ".long 0" in

Re: [PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

On 05/16/2016 11:52 AM, Alexander Graf wrote: > If you compile without OF_MDIO support in an RGMII configuration, we fail > to configure the dp83867 phy today by writing garbage into its configuration > registers. > > On the other hand if you do compile with OF_MDIO and the phy gets loaded via >

[PATCH v2 1/2] phy dp83867: Fix compilation with CONFIG_OF_MDIO=m

When CONFIG_OF_MDIO is configured as module, the #define for it really is CONFIG_OF_MDIO_MODULE, not CONFIG_OF_MDIO. So if we are compiling it as module, the dp83867 doesn't see that OF_MDIO was selected and doesn't read the dt rgmii parameters. The fix is simple: Use IS_ENABLED(). It checks for

[PATCH v2 1/2] phy dp83867: Fix compilation with CONFIG_OF_MDIO=m

When CONFIG_OF_MDIO is configured as module, the #define for it really is CONFIG_OF_MDIO_MODULE, not CONFIG_OF_MDIO. So if we are compiling it as module, the dp83867 doesn't see that OF_MDIO was selected and doesn't read the dt rgmii parameters. The fix is simple: Use IS_ENABLED(). It checks for

Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

On Mon, May 16, 2016 at 11:37 AM, Andy Lutomirski wrote: > > All of those fixes were intended to fix incorrect times being > reported, not segfaults. Weird. I'm assuming it's "time going backwards". I can easily see that causing segfaults. I've seen lots of code that

Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

On Mon, May 16, 2016 at 11:37 AM, Andy Lutomirski wrote: > > All of those fixes were intended to fix incorrect times being > reported, not segfaults. Weird. I'm assuming it's "time going backwards". I can easily see that causing segfaults. I've seen lots of code that timestamps events, and can

UBSAN: Undefined behaviour in arch/x86/events/intel/p6.c:115:29

Not sure if this is a genuine warning or a false positive but since some UBSAN warnings have been real and google does not find report about this specific warning, I'll send it in anyway. I have seen similar amd pmu warnings from UBSAN but I do not have any amd machines from that time frame

UBSAN: Undefined behaviour in arch/x86/events/intel/p6.c:115:29

Not sure if this is a genuine warning or a false positive but since some UBSAN warnings have been real and google does not find report about this specific warning, I'll send it in anyway. I have seen similar amd pmu warnings from UBSAN but I do not have any amd machines from that time frame

[PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

If you compile without OF_MDIO support in an RGMII configuration, we fail to configure the dp83867 phy today by writing garbage into its configuration registers. On the other hand if you do compile with OF_MDIO and the phy gets loaded via device tree, you have to have the properties set in the

[PATCH v2 2/2] phy dp83867: Make rgmii parameters optional

If you compile without OF_MDIO support in an RGMII configuration, we fail to configure the dp83867 phy today by writing garbage into its configuration registers. On the other hand if you do compile with OF_MDIO and the phy gets loaded via device tree, you have to have the properties set in the

[PATCH v2 omap 5/6] arm: Add _rcuidle suffix to allow rpm_resume() to be called from idle

This commit applies another _rcuidle suffix to fix an RCU use from idle. > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1122 Not tainted > --- > include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage! > >

Re: [RFC PATCH 4/2] namei: Improve hash mixing if CONFIG_DCACHE_WORD_ACCESS

On Mon, May 2, 2016 at 3:31 AM, George Spelvin wrote: > The hash mixing between adding the next 64 bits of name > was just a bit weak. > > Replaced with a still very fast but slightly more effective > mixing function. I'e applied this patch independently of all your other hash

[PATCH v2 omap 5/6] arm: Add _rcuidle suffix to allow rpm_resume() to be called from idle

This commit applies another _rcuidle suffix to fix an RCU use from idle. > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1122 Not tainted > --- > include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage! > >

Re: [RFC PATCH 4/2] namei: Improve hash mixing if CONFIG_DCACHE_WORD_ACCESS

On Mon, May 2, 2016 at 3:31 AM, George Spelvin wrote: > The hash mixing between adding the next 64 bits of name > was just a bit weak. > > Replaced with a still very fast but slightly more effective > mixing function. I'e applied this patch independently of all your other hash rework to my tree.

[PATCH v2 omap 6/6] arm: Use _rcuidle suffix to allow clk_core_enable() to used from idle

This commit fixes the RCU use-from-idle bug corresponding the following splat: > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1127 Not tainted > --- > include/trace/events/clk.h:45 suspicious rcu_dereference_check() usage! > > other info that might help

[PATCH v2 omap 6/6] arm: Use _rcuidle suffix to allow clk_core_enable() to used from idle

This commit fixes the RCU use-from-idle bug corresponding the following splat: > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1127 Not tainted > --- > include/trace/events/clk.h:45 suspicious rcu_dereference_check() usage! > > other info that might help

[PATCH v2 omap 1/6] arm: Use _rcuidle tracepoint to allow use from idle

Testing on ARM encountered the following pair of lockdep-RCU splats: === [ INFO: suspicious RCU usage. ] 4.6.0-rc4-next-20160422 #1 Not tainted ---

[PATCH v2 omap 1/6] arm: Use _rcuidle tracepoint to allow use from idle

Testing on ARM encountered the following pair of lockdep-RCU splats: === [ INFO: suspicious RCU usage. ] 4.6.0-rc4-next-20160422 #1 Not tainted ---

[PATCH v2 omap 2/6] arm: Use _rcuidle for suspend/resume tracepoints

Further testing with false negatives suppressed by commit 293e2421fe25 ("rcu: Remove superfluous versions of rcu_read_lock_sched_held()") identified a few more unprotected uses of RCU from the idle loop. Because RCU actively ignores idle-loop code (for energy-efficiency reasons, among other

[PATCH v2 omap 4/6] arm: Add _rcuidle suffix to allow rpm_idle() use from idle

This commit appends a few _rcuidle suffixes to fix the following RCU-used-from-idle bug: > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1116 Not tainted > --- > include/trace/events/rpm.h:95 suspicious

[PATCH v2 omap 4/6] arm: Add _rcuidle suffix to allow rpm_idle() use from idle

This commit appends a few _rcuidle suffixes to fix the following RCU-used-from-idle bug: > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1116 Not tainted > --- > include/trace/events/rpm.h:95 suspicious

[PATCH v2 omap 2/6] arm: Use _rcuidle for suspend/resume tracepoints

Further testing with false negatives suppressed by commit 293e2421fe25 ("rcu: Remove superfluous versions of rcu_read_lock_sched_held()") identified a few more unprotected uses of RCU from the idle loop. Because RCU actively ignores idle-loop code (for energy-efficiency reasons, among other

[PATCH v2 omap 3/6] arm: Add _rcuidle tracepoints to allow clk_core_disable() use from idle

This commit adds an _rcuidle suffix to a pair of trace events to prevent the following splat: > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1114 Not tainted > --- > include/trace/events/clk.h:59 suspicious

[PATCH v2 omap 3/6] arm: Add _rcuidle tracepoints to allow clk_core_disable() use from idle

This commit adds an _rcuidle suffix to a pair of trace events to prevent the following splat: > === > [ INFO: suspicious RCU usage. ] > 4.6.0-rc5-next-20160426+ #1114 Not tainted > --- > include/trace/events/clk.h:59 suspicious

[PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

Hello! The following series fixes a number of uses of RCU from the idle loop. These are all due to tracing, so the fix is simply to append _rcuidle to the event-tracing call. Changes since v1: Fix commit-log subjects and add maintainers on CC.

[PATCH omap v2 0/6] Fix OMAP uses of RCU from idle loop

Hello! The following series fixes a number of uses of RCU from the idle loop. These are all due to tracing, so the fix is simply to append _rcuidle to the event-tracing call. Changes since v1: Fix commit-log subjects and add maintainers on CC.

linux-4.6/net/kcm/kcmsock.c:1508: bad if test ?

Hello there, linux-4.6/net/kcm/kcmsock.c:1508]: (style) Checking if unsigned variable 'copied' is less than zero. Source code is if (copied < 0) { but size_t copied; Suggest code rework. Regards David Binderman

linux-4.6/net/kcm/kcmsock.c:1508: bad if test ?

Hello there, linux-4.6/net/kcm/kcmsock.c:1508]: (style) Checking if unsigned variable 'copied' is less than zero. Source code is if (copied < 0) { but size_t copied; Suggest code rework. Regards David Binderman

[GIT PULL] x86/debug change for v4.7

Linus, Please pull the latest x86-debug-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-debug-for-linus # HEAD: 8fad7ec51e1b9e262e0bdd34e800ac1ea5e84dec x86/dumpstack: Combine some printk()s A printk() output simplification. Thanks, Ingo

[GIT PULL] x86/debug change for v4.7

Linus, Please pull the latest x86-debug-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-debug-for-linus # HEAD: 8fad7ec51e1b9e262e0bdd34e800ac1ea5e84dec x86/dumpstack: Combine some printk()s A printk() output simplification. Thanks, Ingo

Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

On Mon, May 16, 2016 at 11:10 AM, Linus Torvalds wrote: > There is something odd being reported in Ubuntu. > > There's a Mono SIGSEGV that was bisected to Andy's commit 1ddf0b1b11aa > ("x86, vdso: Use asm volatile in __getcpu"), and then reported to be > fixed with

Re: Please review arch/x86/kernel/pvclock.c to fix Docker/Mono crashes in new Kernels

On Mon, May 16, 2016 at 11:10 AM, Linus Torvalds wrote: > There is something odd being reported in Ubuntu. > > There's a Mono SIGSEGV that was bisected to Andy's commit 1ddf0b1b11aa > ("x86, vdso: Use asm volatile in __getcpu"), and then reported to be > fixed with commits I'm reasonably

[GIT PULL] x86/build change for v4.7

Linus, Please pull the latest x86-build-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus # HEAD: 7a09b225f31031f8cac9e7801b6004e79f8b0da1 x86/build/defconfig/64: Enable CONFIG_E1000E=y Small defconfig addition. Thanks,

[GIT PULL] x86/build change for v4.7

Linus, Please pull the latest x86-build-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus # HEAD: 7a09b225f31031f8cac9e7801b6004e79f8b0da1 x86/build/defconfig/64: Enable CONFIG_E1000E=y Small defconfig addition. Thanks,

[GIT PULL] x86/cleanups change for v4.7

Linus, Please pull the latest x86-cleanups-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cleanups-for-linus # HEAD: a3819e3e71d5000c176918309284a1fa2f133fcf x86: Fix non-static inlines Inline optimizations. Thanks, Ingo

[GIT PULL] x86/cleanups change for v4.7

Linus, Please pull the latest x86-cleanups-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cleanups-for-linus # HEAD: a3819e3e71d5000c176918309284a1fa2f133fcf x86: Fix non-static inlines Inline optimizations. Thanks, Ingo

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

On Mon, May 16, 2016 at 11:04:31PM +0530, Amit Ghadge wrote: > Fixed a warning issue to use 'unsigned int'. > build warning? I don't see that anywhere in the build output. Please be specific.

[GIT PULL] x86/boot changes for v4.7

Linus, Please pull the latest x86-boot-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus # HEAD: d2d3462f9f08da364c8fbd41e8e32229d610d49d x86/KASLR: Clarify purpose of each get_random_long() The biggest changes in this cycle were: -

Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue

On Mon, May 16, 2016 at 11:04:31PM +0530, Amit Ghadge wrote: > Fixed a warning issue to use 'unsigned int'. > build warning? I don't see that anywhere in the build output. Please be specific.

[GIT PULL] x86/boot changes for v4.7

Linus, Please pull the latest x86-boot-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus # HEAD: d2d3462f9f08da364c8fbd41e8e32229d610d49d x86/KASLR: Clarify purpose of each get_random_long() The biggest changes in this cycle were: -

[PATCH] MIPS: perf: Fix I6400 event numbers

Fix perf hardware performance counter event numbers for I6400. This core does not follow the performance event numbering scheme of previous MIPS cores. All performance counters (both odd and even) are capable of counting any of the available events. Fixes: 4e88a8621301 ("MIPS: Add cases for

[PATCH] MIPS: perf: Fix I6400 event numbers

Fix perf hardware performance counter event numbers for I6400. This core does not follow the performance event numbering scheme of previous MIPS cores. All performance counters (both odd and even) are capable of counting any of the available events. Fixes: 4e88a8621301 ("MIPS: Add cases for

[PATCH v2 2/3] dell_rbu: Update documentation

Signed-off-by: Mario Limonciello --- Documentation/dell_rbu.txt | 24 +++- 1 file changed, 3 insertions(+), 21 deletions(-) diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt index d262e22..b2714e6 100644 ---

[PATCH v2 2/3] dell_rbu: Update documentation

Signed-off-by: Mario Limonciello --- Documentation/dell_rbu.txt | 24 +++- 1 file changed, 3 insertions(+), 21 deletions(-) diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt index d262e22..b2714e6 100644 --- a/Documentation/dell_rbu.txt +++

[PATCH v2 1/3] dell_rbu: Don't fallback to userhelper

when loading firmware dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts dell_rbu to immediately load

[PATCH v2 1/3] dell_rbu: Don't fallback to userhelper

when loading firmware dell_rbu previously would allow a userspace application to craft the payload after dell_rbu was loaded and abuse the udev userspace API. Instead require the payload to be crafted and placed in /lib/firmware/dell_rbu ahead of time. This adjusts dell_rbu to immediately load

[PATCH v2 3/3] firmware_class: drop support for FW_LOADER_USER_HELPER_FALLBACK

The last consumer of this is dell_rbu, and it no longer needs this due to userspace changes in how updates are passed to the OS. Signed-off-by: Mario Limonciello --- drivers/base/Kconfig | 14 -- drivers/base/firmware_class.c | 9 ++--- 2

[PATCH v2 3/3] firmware_class: drop support for FW_LOADER_USER_HELPER_FALLBACK

The last consumer of this is dell_rbu, and it no longer needs this due to userspace changes in how updates are passed to the OS. Signed-off-by: Mario Limonciello --- drivers/base/Kconfig | 14 -- drivers/base/firmware_class.c | 9 ++--- 2 files changed, 2

Re: Stack trace of csum_partial_copy_generic

Hi Nikolay, On Fri, May 13, 2016 at 02:07:47PM +0300, Nikolay Borisov wrote: > Hello Josh, > > I'd like to ask you whether objtool is supposed to produce a > warning when arch/x86/lib/csum-copy_64.o (produced from > arch/x86/lib/csum-copy_64.S). Since I cannot see any specific > usage of rbp

Re: Stack trace of csum_partial_copy_generic

Hi Nikolay, On Fri, May 13, 2016 at 02:07:47PM +0300, Nikolay Borisov wrote: > Hello Josh, > > I'd like to ask you whether objtool is supposed to produce a > warning when arch/x86/lib/csum-copy_64.o (produced from > arch/x86/lib/csum-copy_64.S). Since I cannot see any specific > usage of rbp

[PATCH v2] tpm: Factor out common startup code

Provide some flags in tpm_class_ops to allow drivers to opt-in to the common startup sequence. This is the sequence used by tpm_tis and tpm_crb. All drivers should set this flag. Signed-off-by: Jason Gunthorpe Tested-by: Andrew Zamansky

[PATCH v2] tpm: Factor out common startup code

Provide some flags in tpm_class_ops to allow drivers to opt-in to the common startup sequence. This is the sequence used by tpm_tis and tpm_crb. All drivers should set this flag. Signed-off-by: Jason Gunthorpe Tested-by: Andrew Zamansky --- drivers/char/tpm/st33zp24/st33zp24.c | 4 +---

Re: SHA1-MB algorithm broken on latest kernel

On Mon, 2016-05-16 at 09:44 -0500, Josh Poimboeuf wrote: > On Fri, May 13, 2016 at 10:32:26AM -0700, Megha Dey wrote: > > On Fri, 2016-05-13 at 07:51 +0200, Ingo Molnar wrote: > > > * Herbert Xu wrote: > > > > > > > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey

Re: SHA1-MB algorithm broken on latest kernel

On Mon, 2016-05-16 at 09:44 -0500, Josh Poimboeuf wrote: > On Fri, May 13, 2016 at 10:32:26AM -0700, Megha Dey wrote: > > On Fri, 2016-05-13 at 07:51 +0200, Ingo Molnar wrote: > > > * Herbert Xu wrote: > > > > > > > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote: > > > > > Hi, > > > >

Re: [PATCH v5 0/4] x86, boot: KASLR memory randomization

Any feedback on the patch? Ingo? Kees? Kees mentioned he will take care of the build warning on the KASLR refactor (the function is not used right now). Thanks, Thomas On Thu, May 12, 2016 at 12:28 PM, Thomas Garnier wrote: > This is PATCH v5 for KASLR memory

Re: [PATCHv8 resend 2/2] selftest/x86: add mremap vdso test

On Mon, May 16, 2016 at 9:24 AM, Dmitry Safonov wrote: > On 05/16/2016 04:54 PM, Ingo Molnar wrote: >> >> >> * Dmitry Safonov wrote: >> >>> Should print on success: >>> [root@localhost ~]# ./test_mremap_vdso_32 >>> AT_SYSINFO_EHDR is

I am still waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($4.6 million dollars). I seek your assistance and I assured of your capability to

Re: [PATCH v5 0/4] x86, boot: KASLR memory randomization

Any feedback on the patch? Ingo? Kees? Kees mentioned he will take care of the build warning on the KASLR refactor (the function is not used right now). Thanks, Thomas On Thu, May 12, 2016 at 12:28 PM, Thomas Garnier wrote: > This is PATCH v5 for KASLR memory implementation for x86_64. > >

Re: [PATCHv8 resend 2/2] selftest/x86: add mremap vdso test

On Mon, May 16, 2016 at 9:24 AM, Dmitry Safonov wrote: > On 05/16/2016 04:54 PM, Ingo Molnar wrote: >> >> >> * Dmitry Safonov wrote: >> >>> Should print on success: >>> [root@localhost ~]# ./test_mremap_vdso_32 >>> AT_SYSINFO_EHDR is 0xf773f000 >>> [NOTE] Moving vDSO: [f773f000,

I am still waiting for your response to my numerous un-replied emails to you concerning your family inheritance fund ($4.6 million dollars). I seek your assistance and I assured of your capability to

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Alex On 05/16/2016 12:57 PM, Alexander Graf wrote: > Hi Dan, > > On 16.05.16 15:38, Dan Murphy wrote: >> Alexander >> >> On 05/16/2016 06:28 AM, Alexander Graf wrote: >>> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >>> enabled. >>> It simply passes the device tree

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Mon, May 16, 2016 at 11:42:46AM -0500, Eric W. Biederman wrote: > Seth Forshee writes: > > > On Sat, May 14, 2016 at 09:21:55PM -0500, Eric W. Biederman wrote: > >> I have slowly been working with Seth Forshee on these issues as > >> the last thing I want is to

Re: CQ and RDMA READ/WRITE APIs

On 05/16/2016 01:46 PM, Linus Torvalds wrote: > On Mon, May 16, 2016 at 7:51 AM, Doug Ledford wrote: >> >> The linux kernel as a whole is, but individual files still retain their >> separate copyright, they don't loose it just because they are shipped as >> part of the larger

Re: [RFC v2 PATCH 0/8] VFS:userns: support portable root filesystems

On Mon, May 16, 2016 at 11:42:46AM -0500, Eric W. Biederman wrote: > Seth Forshee writes: > > > On Sat, May 14, 2016 at 09:21:55PM -0500, Eric W. Biederman wrote: > >> I have slowly been working with Seth Forshee on these issues as > >> the last thing I want is to introduce more security

Re: CQ and RDMA READ/WRITE APIs

On 05/16/2016 01:46 PM, Linus Torvalds wrote: > On Mon, May 16, 2016 at 7:51 AM, Doug Ledford wrote: >> >> The linux kernel as a whole is, but individual files still retain their >> separate copyright, they don't loose it just because they are shipped as >> part of the larger kernel. > > .. they

Re: [PATCH] phy dp83867: depend on CONFIG_OF_MDIO

Alex On 05/16/2016 12:57 PM, Alexander Graf wrote: > Hi Dan, > > On 16.05.16 15:38, Dan Murphy wrote: >> Alexander >> >> On 05/16/2016 06:28 AM, Alexander Graf wrote: >>> The DP83867 phy driver doesn't actually work when CONFIG_OF_MDIO isn't >>> enabled. >>> It simply passes the device tree

Re: klp_task_patch: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Mon, May 09, 2016 at 02:23:03PM +0200, Petr Mladek wrote: > On Fri 2016-05-06 07:38:55, Josh Poimboeuf wrote: > > On Thu, May 05, 2016 at 01:57:01PM +0200, Petr Mladek wrote: > > > I have missed that the two commands are called with preemption > > > disabled. So, I had the following crazy

Re: klp_task_patch: was: [RFC PATCH v2 17/18] livepatch: change to a per-task consistency model

On Mon, May 09, 2016 at 02:23:03PM +0200, Petr Mladek wrote: > On Fri 2016-05-06 07:38:55, Josh Poimboeuf wrote: > > On Thu, May 05, 2016 at 01:57:01PM +0200, Petr Mladek wrote: > > > I have missed that the two commands are called with preemption > > > disabled. So, I had the following crazy

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Peter Zijlstra wrote: > On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: > >> Unfortunately, I could not reproduce this again with none of my >> 183-kernels. >> When I first hit a "chain_key collision" issue, it was hard to redproduce, >> so. >> Any

Re: [v4.6-rc7-183-g1410b74e4061]

On 5/16/16, Peter Zijlstra wrote: > On Mon, May 16, 2016 at 07:42:35PM +0200, Sedat Dilek wrote: > >> Unfortunately, I could not reproduce this again with none of my >> 183-kernels. >> When I first hit a "chain_key collision" issue, it was hard to redproduce, >> so. >> Any idea, how I can "force"

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