Re: [PATCH] x86: Mark hpa as a "Designated Reviewer" for the time being

* Thomas Gleixner wrote: > Peter! > > On Thu, 25 Jan 2018, H. Peter Anvin wrote: > > > Due to some unfortunate events, I have not been directly involved in > > the x86 kernel patch flow for a while now. I have also not been able > > to ramp back up by now like I had hoped

Re: [PATCH] x86: Mark hpa as a "Designated Reviewer" for the time being

* Thomas Gleixner wrote: > Peter! > > On Thu, 25 Jan 2018, H. Peter Anvin wrote: > > > Due to some unfortunate events, I have not been directly involved in > > the x86 kernel patch flow for a while now. I have also not been able > > to ramp back up by now like I had hoped to, and after

[PATCH 1/2 v2] tpm: cmd_ready command can be issued only after granting locality

The correct sequence is to first request locality and only after that perform cmd_ready handshake, otherwise the hardware will drop the subsequent message as from the device point of view the cmd_ready handshake wasn't performed. Symmetrically locality has to be relinquished only after going idle

[PATCH 2/2 v2] tpm: separate cmd_ready/go_idle from runtime_pm

We cannot use go_idle cmd_ready commands via runtime_pm handles as with the introduction of localities this is no longer an optional feature, while runtime pm can be not enabled. Though cmd_ready/go_idle provides power saving feature, it's also part of TPM2 protocol and should be called

[PATCH 1/2 v2] tpm: cmd_ready command can be issued only after granting locality

The correct sequence is to first request locality and only after that perform cmd_ready handshake, otherwise the hardware will drop the subsequent message as from the device point of view the cmd_ready handshake wasn't performed. Symmetrically locality has to be relinquished only after going idle

[PATCH 2/2 v2] tpm: separate cmd_ready/go_idle from runtime_pm

We cannot use go_idle cmd_ready commands via runtime_pm handles as with the introduction of localities this is no longer an optional feature, while runtime pm can be not enabled. Though cmd_ready/go_idle provides power saving feature, it's also part of TPM2 protocol and should be called

[PATCH 0/2] tpm: fix locality and power saving handling

Devices that support locality has failed to transmit due to reserved order of locality request and cmdReady/goIdle handshake. The cmdReady/goIdle should be performed on the requested locality. The first patch corrects the locality and power-save order, adds required polling for completion of

[PATCH 0/2] tpm: fix locality and power saving handling

Devices that support locality has failed to transmit due to reserved order of locality request and cmdReady/goIdle handshake. The cmdReady/goIdle should be performed on the requested locality. The first patch corrects the locality and power-save order, adds required polling for completion of

[PATCH] scsi: aic7xxx: remove really aiclib.c

aiclib.c is unused (and contain no code) since commit 1ff927306e08 ("[SCSI] aic7xxx: remove aiclib.c") 13 years later, finish the cleaning by remove it from tree. Signed-off-by: Corentin Labbe --- drivers/scsi/aic7xxx/aiclib.c | 34 -- 1

[PATCH] scsi: aic7xxx: remove really aiclib.c

aiclib.c is unused (and contain no code) since commit 1ff927306e08 ("[SCSI] aic7xxx: remove aiclib.c") 13 years later, finish the cleaning by remove it from tree. Signed-off-by: Corentin Labbe --- drivers/scsi/aic7xxx/aiclib.c | 34 -- 1 file changed, 34

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep

Re: [4.15-rc9] fs_reclaim lockdep trace

Dave, would you try below patch? >From cae2cbf389ae3cdef1b492622722b4aeb07eb284 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sun, 28 Jan 2018 14:17:14 +0900 Subject: [PATCH] lockdep: Fix fs_reclaim warning. Dave Jones reported fs_reclaim lockdep warnings.

[RFC PATCH] perf cgroup: simplify arguments if track multiple events for a cgroup

if use -G with one cgroup and -e with multiple events, only the first event has correct cgroup setting, all events from the second will track system-wide events. if user want track multiple events for a specific cgroup, user must give parameters like follow: $ perf stat -e e1 -e e2 -e e3 -G

[RFC PATCH] perf cgroup: simplify arguments if track multiple events for a cgroup

if use -G with one cgroup and -e with multiple events, only the first event has correct cgroup setting, all events from the second will track system-wide events. if user want track multiple events for a specific cgroup, user must give parameters like follow: $ perf stat -e e1 -e e2 -e e3 -G

[PATCH] staging: lustre: lnet: return of an error code should be negative

Return value of error codes should typically be negative. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lnet/selftest/framework.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] staging: lustre: lnet: return of an error code should be negative

Return value of error codes should typically be negative. Issue reported by checkpatch.pl Signed-off-by: Sumit Pundir --- drivers/staging/lustre/lnet/selftest/framework.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/selftest/framework.c

Re: [PATCH v3 3/4] soc: qcom: mdt-loader: Return relocation base

On Fri, Jan 05, 2018 at 04:04:19PM -0800, Bjorn Andersson wrote: > In order to implement support for grabbing core dumps in remoteproc it's > necessary to know the relocated base of the image, as the offsets from > the virtual memory base might not be based on the physical address. > > Return the

Re: [PATCH v3 3/4] soc: qcom: mdt-loader: Return relocation base

On Fri, Jan 05, 2018 at 04:04:19PM -0800, Bjorn Andersson wrote: > In order to implement support for grabbing core dumps in remoteproc it's > necessary to know the relocated base of the image, as the offsets from > the virtual memory base might not be based on the physical address. > > Return the

Re: Dell Vostro 3360 multimedia keys

On Sat, Jan 27, 2018 at 6:05 AM, Pali Rohár wrote: > On Tuesday 21 November 2017 19:58:24 Oleksandr Natalenko wrote: >> >> Just to note what I did. Here is my custom /etc/udev/hwdb.d/90-dell- >> vostro-3360.hwdb: >> >> === >>

Re: Dell Vostro 3360 multimedia keys

On Sat, Jan 27, 2018 at 6:05 AM, Pali Rohár wrote: > On Tuesday 21 November 2017 19:58:24 Oleksandr Natalenko wrote: >> >> Just to note what I did. Here is my custom /etc/udev/hwdb.d/90-dell- >> vostro-3360.hwdb: >> >> === >>

Re: [PATCH v1 1/2] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Andy, Thanks for the review. On 01/26/2018 08:17 AM, Andy Shevchenko wrote: On Fri, Jan 26, 2018 at 12:53 AM, wrote: From: Kuppuswamy Sathyanarayanan Currently, we have lot of repetitive code in

Re: [PATCH v1 1/2] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices

Hi Andy, Thanks for the review. On 01/26/2018 08:17 AM, Andy Shevchenko wrote: On Fri, Jan 26, 2018 at 12:53 AM, wrote: From: Kuppuswamy Sathyanarayanan Currently, we have lot of repetitive code in dependent device resource allocation and device creation handling code. This logic can be

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was rsync'ing to. >>> >>> Actually, I can

Re: [4.15-rc9] fs_reclaim lockdep trace

On 2018/01/28 10:16, Tetsuo Handa wrote: > Linus Torvalds wrote: >> On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >>> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >>> > Just triggered this on a server I was rsync'ing to. >>> >>> Actually, I can trigger this really easily,

[PATCH] Documentation/admin-guide: fixes for thunderbolt.rst

From: Randy Dunlap Edits for grammar, punctuation, and a doubled-up word. Signed-off-by: Randy Dunlap Cc: Andreas Noever Cc: Michael Jamet Cc: Mika Westerberg

[PATCH] Documentation/admin-guide: fixes for thunderbolt.rst

From: Randy Dunlap Edits for grammar, punctuation, and a doubled-up word. Signed-off-by: Randy Dunlap Cc: Andreas Noever Cc: Michael Jamet Cc: Mika Westerberg Cc: Yehezkel Bernat --- Documentation/admin-guide/thunderbolt.rst | 66 ++-- 1 file changed, 33 insertions(+),

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi, On Sat, 27 Jan 2018 17:14:26 +0100 Linus Walleij wrote: > On Tue, Jan 23, 2018 at 9:18 AM, Yong Deng wrote: > > > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 > > interface and CSI1 is used for parallel interface.

Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi, On Sat, 27 Jan 2018 17:14:26 +0100 Linus Walleij wrote: > On Tue, Jan 23, 2018 at 9:18 AM, Yong Deng wrote: > > > Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 > > interface and CSI1 is used for parallel interface. This is not > > documented in datasheet but by

Re: arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable instruction

On Sat, Jan 27, 2018 at 05:13:04PM +0100, Borislav Petkov wrote: > Hey, > > seen this already? > > This is Linus' tree from now + tip/master also from now. Yeah, Steven reported it a few days ago but I was in backport lala land. It's a simple fix: From: Josh Poimboeuf

Re: arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable instruction

On Sat, Jan 27, 2018 at 05:13:04PM +0100, Borislav Petkov wrote: > Hey, > > seen this already? > > This is Linus' tree from now + tip/master also from now. Yeah, Steven reported it a few days ago but I was in backport lala land. It's a simple fix: From: Josh Poimboeuf Subject: [PATCH]

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Maxime, On Fri, 26 Jan 2018 09:10:00 +0100 Maxime Ripard wrote: > On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote: > > Hi Maxime, > > > > On Fri, 26 Jan 2018 09:46:58 +0800 > > Yong wrote: > > > > > Hi Maxime, > > > > > > Do

Re: [linux-sunxi] Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.

Hi Maxime, On Fri, 26 Jan 2018 09:10:00 +0100 Maxime Ripard wrote: > On Fri, Jan 26, 2018 at 11:00:41AM +0800, Yong wrote: > > Hi Maxime, > > > > On Fri, 26 Jan 2018 09:46:58 +0800 > > Yong wrote: > > > > > Hi Maxime, > > > > > > Do you have any experience in solving this problem? > > > It

Re: [PATCH] block: aoenet: Replace GFP_ATOMIC with GFP_KERNEL in aoenet_rcv

On 2018/1/28 1:48, Ed Cashin wrote: If the tool cannot tell whether the protected state is manipulated by *another* piece of code called in atomic context, then it's insufficient. On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai wrote: After checking all possible call

Re: [PATCH] block: aoenet: Replace GFP_ATOMIC with GFP_KERNEL in aoenet_rcv

On 2018/1/28 1:48, Ed Cashin wrote: If the tool cannot tell whether the protected state is manipulated by *another* piece of code called in atomic context, then it's insufficient. On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai wrote: After checking all possible call chains to aoenet_rcv(), my

Re: [PATCH] kbuild: fix W= option checks for extra DTC warnings

2018-01-18 12:31 GMT+09:00 Masahiro Yamada : > Kbuild supports 3 levels of extra warnings, and multiple levels can > be combined, like W=12, W=123. It was added by commit a6de553da01c > ("kbuild: Allow to combine multiple W= levels"). > > From the log of commit

Re: [PATCH] kbuild: fix W= option checks for extra DTC warnings

2018-01-18 12:31 GMT+09:00 Masahiro Yamada : > Kbuild supports 3 levels of extra warnings, and multiple levels can > be combined, like W=12, W=123. It was added by commit a6de553da01c > ("kbuild: Allow to combine multiple W= levels"). > > From the log of commit 8654cb8d0371 ("dtc: update warning

Re: [PATCH v3] Remove silentoldconfig from help and docs; fix kconfig/conf's help

2018-01-27 7:59 GMT+09:00 Marc Herbert : > As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189 > silentoldconfig has become a misnomer. It has become an internal interface > so remove it from "make help" and Documentation/ to stop confusing people > using it

Re: [PATCH v3] Remove silentoldconfig from help and docs; fix kconfig/conf's help

2018-01-27 7:59 GMT+09:00 Marc Herbert : > As explained by Michal Marek at https://lkml.org/lkml/2011/8/31/189 > silentoldconfig has become a misnomer. It has become an internal interface > so remove it from "make help" and Documentation/ to stop confusing people > using it as seen for instance at

Re: [PATCH] Remove silentoldconfig from "make help"; fix kconfig/conf's help

2018-01-27 8:00 GMT+09:00 Marc Herbert : > Masahiro, > > On 17/01/2018 20:31, Masahiro Yamada wrote: > >> Sorry for my late reply. > > I think we're even now :-) > >>> I'd like to keep that sentence because it's there to explain the legacy and >>> confusing

Re: [PATCH] Remove silentoldconfig from "make help"; fix kconfig/conf's help

2018-01-27 8:00 GMT+09:00 Marc Herbert : > Masahiro, > > On 17/01/2018 20:31, Masahiro Yamada wrote: > >> Sorry for my late reply. > > I think we're even now :-) > >>> I'd like to keep that sentence because it's there to explain the legacy and >>> confusing "--silentoldconfig" name which

Re: [PATCH] kconfig: announce removal of oldnoconfig if used

2018-01-18 20:56 GMT+09:00 Ulf Magnusson : > On Thu, Jan 18, 2018 at 5:13 AM, Masahiro Yamada > wrote: >> The 'oldnoconfig' is really confusing due to its counter-intuitive name. >> It was renamed by commit fb16d8912db5 ("kconfig: replace

Re: [PATCH] kconfig: announce removal of oldnoconfig if used

2018-01-18 20:56 GMT+09:00 Ulf Magnusson : > On Thu, Jan 18, 2018 at 5:13 AM, Masahiro Yamada > wrote: >> The 'oldnoconfig' is really confusing due to its counter-intuitive name. >> It was renamed by commit fb16d8912db5 ("kconfig: replace 'oldnoconfig' >> with 'olddefconfig', and keep the old

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from

Re: [4.15-rc9] fs_reclaim lockdep trace

Linus Torvalds wrote: > On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: >> On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: >> > Just triggered this on a server I was rsync'ing to. >> >> Actually, I can trigger this really easily, even with an rsync from one >> disk to another.

Re: [PATCH] hrtimer: Reset hrtimer cpu base proper on CPU hotplug

On Fri, Jan 26, 2018 at 02:09:17PM -0800, Paul E. McKenney wrote: > On Fri, Jan 26, 2018 at 02:54:32PM +0100, Thomas Gleixner wrote: > > The hrtimer interrupt code contains a hang detection and mitigation > > mechanism, which prevents that a long delayed hrtimer interrupt causes a > > continous

Re: [PATCH] hrtimer: Reset hrtimer cpu base proper on CPU hotplug

On Fri, Jan 26, 2018 at 02:09:17PM -0800, Paul E. McKenney wrote: > On Fri, Jan 26, 2018 at 02:54:32PM +0100, Thomas Gleixner wrote: > > The hrtimer interrupt code contains a hang detection and mitigation > > mechanism, which prevents that a long delayed hrtimer interrupt causes a > > continous

Re: [PATCH v2 00/43] DRM Rockchip rk3399 (Kevin)

On 26 January 2018 at 14:16, Thierry Escande wrote: > Hi, > > This patchset includes cleanups, improvements, and bug fixes for > Rockchip DRM driver and PSR support. > > this patchset depends and needs to be applied on top of Rockchip rk3399 > eDP support [1]. > >

Re: [PATCH v2 00/43] DRM Rockchip rk3399 (Kevin)

On 26 January 2018 at 14:16, Thierry Escande wrote: > Hi, > > This patchset includes cleanups, improvements, and bug fixes for > Rockchip DRM driver and PSR support. > > this patchset depends and needs to be applied on top of Rockchip rk3399 > eDP support [1]. > > [1]

[PATCH] Documentation/cdrom: fix German sharp s in LaTex

From: Randy Dunlap Apparently the LaTex abbreviation for the German "sharp s" (ß) (Unicode U+00DF) has changed from {\sz} to {\ss}. With {\sz}, I get this error at line 1016 (line number after another patch): ! Undefined control sequence. l.1016 ...nel~2.0. Further

[PATCH] Documentation/cdrom: fix German sharp s in LaTex

From: Randy Dunlap Apparently the LaTex abbreviation for the German "sharp s" (ß) (Unicode U+00DF) has changed from {\sz} to {\ss}. With {\sz}, I get this error at line 1016 (line number after another patch): ! Undefined control sequence. l.1016 ...nel~2.0. Further thanks to Heiko Ei{\sz

[PATCH] macintosh/via-pmu68k: Initialize PMU driver with setup_arch and arch_initcall

The PMU watchdog will power down the system if the kernel is slow to start up, e.g. due to unpacking a large initrd. The powerpc version of this driver (via-pmu.c) has a solution for the same problem. It uses this call sequence: setup_arch find_via_pmu init_pmu ...

[PATCH] m68k/mac: Fix apparent race condition in Baboon interrupt dispatch

The algorithm used in baboon_irq() appears to be subject to a race condition: an IRQ flag could be lost if asserted between the MOV instructions from and to the interrupt flag register. However, testing shows that the write to the flag register has no effect. Rewrite this loop to remove the

[PATCH] macintosh/via-pmu68k: Initialize PMU driver with setup_arch and arch_initcall

The PMU watchdog will power down the system if the kernel is slow to start up, e.g. due to unpacking a large initrd. The powerpc version of this driver (via-pmu.c) has a solution for the same problem. It uses this call sequence: setup_arch find_via_pmu init_pmu ...

[PATCH] m68k/mac: Fix apparent race condition in Baboon interrupt dispatch

The algorithm used in baboon_irq() appears to be subject to a race condition: an IRQ flag could be lost if asserted between the MOV instructions from and to the interrupt flag register. However, testing shows that the write to the flag register has no effect. Rewrite this loop to remove the

[PATCH] m68k/mac: Enable PDMA support for PowerBook 190

Stan's tests showed that PDMA improves sequential read performance by a factor of 5 on a PowerBook 190. Last time I tried this on a PowerBook 520 it didn't work, so let's not enable it there until it can be tested with the present mac_scsi driver. Tested-by: Stan Johnson

[PATCH] m68k/mac: Enable PDMA support for PowerBook 190

Stan's tests showed that PDMA improves sequential read performance by a factor of 5 on a PowerBook 190. Last time I tried this on a PowerBook 520 it didn't work, so let's not enable it there until it can be tested with the present mac_scsi driver. Tested-by: Stan Johnson Signed-off-by: Finn

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Sat, Jan 27, 2018 at 09:57:03AM +, Lihao Liang wrote: > On Sat, Jan 27, 2018 at 7:57 AM, Paul E. McKenney > wrote: > > On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > >> On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > >>

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Sat, Jan 27, 2018 at 09:57:03AM +, Lihao Liang wrote: > On Sat, Jan 27, 2018 at 7:57 AM, Paul E. McKenney > wrote: > > On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > >> On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > >> wrote: > >> > On Tue, Jan 23, 2018 at 03:59:25PM

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Fri, Jan 26, 2018 at 11:57:44PM -0800, Paul E. McKenney wrote: > On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > > On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > > wrote: > > > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Fri, Jan 26, 2018 at 11:57:44PM -0800, Paul E. McKenney wrote: > On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > > On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > > wrote: > > > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: > > >> From: Lihao Liang

Re: [PATCH resend 0/6] Fix cdrom autoclose

On Fri, 26 Jan 2018 12:04:56 -0800 James Bottomley wrote: > On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote: > > First time I did not get any feedback for the patches. > > This is likely because no-one who might inspect the code saw the > patches ... what

Re: [PATCH resend 0/6] Fix cdrom autoclose

On Fri, 26 Jan 2018 12:04:56 -0800 James Bottomley wrote: > On Fri, 2018-01-26 at 17:58 +0100, Michal Suchanek wrote: > > First time I did not get any feedback for the patches. > > This is likely because no-one who might inspect the code saw the > patches ... what list are they going to?  I'm

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat, 2018-01-27 at 23:09 +0100, Pavel Machek wrote: > On Sat 2018-01-20 20:31:23, Pandruvada, Srinivas wrote: > > > > On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > > > > > > On Thu, 18 Jan 2018 23:40:26 +0100 > > > Pavel Machek wrote: > > > > > > > > > > > > >

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat, 2018-01-27 at 23:09 +0100, Pavel Machek wrote: > On Sat 2018-01-20 20:31:23, Pandruvada, Srinivas wrote: > > > > On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > > > > > > On Thu, 18 Jan 2018 23:40:26 +0100 > > > Pavel Machek wrote: > > > > > > > > > > > > > > > Hi! > > >

Re: [4.15-rc9] fs_reclaim lockdep trace

On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: > On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > > Just triggered this on a server I was rsync'ing to. > > Actually, I can trigger this really easily, even with an rsync from one > disk to another. Though

Re: [4.15-rc9] fs_reclaim lockdep trace

On Sat, Jan 27, 2018 at 2:24 PM, Dave Jones wrote: > On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > > Just triggered this on a server I was rsync'ing to. > > Actually, I can trigger this really easily, even with an rsync from one > disk to another. Though that also smells a

Re: Mutli-directory module Makefiles

2018-01-26 4:47 GMT+09:00 Jakub Kicinski : > On Thu, 25 Jan 2018 22:08:34 +0900, Masahiro Yamada wrote: >> 2018-01-23 6:46 GMT+09:00 Jakub Kicinski : >> > Hi! >> > >> > in drivers/net/ethernet/netronome/nfp there is a module which is built >> > from C sources in 4

Re: Mutli-directory module Makefiles

2018-01-26 4:47 GMT+09:00 Jakub Kicinski : > On Thu, 25 Jan 2018 22:08:34 +0900, Masahiro Yamada wrote: >> 2018-01-23 6:46 GMT+09:00 Jakub Kicinski : >> > Hi! >> > >> > in drivers/net/ethernet/netronome/nfp there is a module which is built >> > from C sources in 4 directories. What is the best

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev has ideas.

Re: [4.15-rc9] fs_reclaim lockdep trace

On Tue, Jan 23, 2018 at 08:36:51PM -0500, Dave Jones wrote: > Just triggered this on a server I was rsync'ing to. Actually, I can trigger this really easily, even with an rsync from one disk to another. Though that also smells a little like networking in the traces. Maybe netdev has ideas.

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat 2018-01-20 20:31:23, Pandruvada, Srinivas wrote: > On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > > On Thu, 18 Jan 2018 23:40:26 +0100 > > Pavel Machek wrote: > > > > > > > > Hi! > > > > > > > > > > > From an IIO sensor point of view A Gesture sensor: > > >

Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor

On Sat 2018-01-20 20:31:23, Pandruvada, Srinivas wrote: > On Sat, 2018-01-20 at 15:19 +, Jonathan Cameron wrote: > > On Thu, 18 Jan 2018 23:40:26 +0100 > > Pavel Machek wrote: > > > > > > > > Hi! > > > > > > > > > > > From an IIO sensor point of view A Gesture sensor: > > > > Outputs > >

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

Il 26/01/2018 16:55, Giulio Benetti ha scritto: Hi, Il 26/01/2018 15:56, Maxime Ripard ha scritto: On Thu, Jan 25, 2018 at 05:50:18PM +0100, Giulio Benetti wrote: On Sat, Jan 20, 2018 at 07:50:21PM +0100, Giulio Benetti wrote: On previous handling, if specified DRM_MODE_FLAG_N*SYNC, it was

Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly

Il 26/01/2018 16:55, Giulio Benetti ha scritto: Hi, Il 26/01/2018 15:56, Maxime Ripard ha scritto: On Thu, Jan 25, 2018 at 05:50:18PM +0100, Giulio Benetti wrote: On Sat, Jan 20, 2018 at 07:50:21PM +0100, Giulio Benetti wrote: On previous handling, if specified DRM_MODE_FLAG_N*SYNC, it was

[PATCH] staging: lustre: llite: replace variable length array

The functionality of the removed variable length array is already implemented by the function xattr_full_name in fs/xattr.c This fixes the sparse warning: warning: Variable length array is used. Signed-off-by: Sven Dziadek --- drivers/staging/lustre/lustre/llite/xattr.c |

[PATCH] staging: lustre: llite: replace variable length array

The functionality of the removed variable length array is already implemented by the function xattr_full_name in fs/xattr.c This fixes the sparse warning: warning: Variable length array is used. Signed-off-by: Sven Dziadek --- drivers/staging/lustre/lustre/llite/xattr.c | 12 1

[PATCH 3/3] RDMA/iwpm: Improve a size determination in two functions

From: Markus Elfring Date: Sat, 27 Jan 2018 22:05:54 +0100 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 3/3] RDMA/iwpm: Improve a size determination in two functions

From: Markus Elfring Date: Sat, 27 Jan 2018 22:05:54 +0100 Replace the specification of data structures by pointer dereferences as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 2/3] RDMA/iwpm: Adjust a variable initialisation in iwpm_create_nlmsg()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:56:54 +0100 The local variable "skb" will be reassigned by a following statement. Thus adjust the initialisation at the beginning. Signed-off-by: Markus Elfring ---

[PATCH 2/3] RDMA/iwpm: Adjust a variable initialisation in iwpm_create_nlmsg()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:56:54 +0100 The local variable "skb" will be reassigned by a following statement. Thus adjust the initialisation at the beginning. Signed-off-by: Markus Elfring --- drivers/infiniband/core/iwpm_util.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH 1/3] RDMA/iwpm: Delete an error message for a failed memory allocation in iwpm_create_nlmsg()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:48:01 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/3] RDMA/iwpm: Delete an error message for a failed memory allocation in iwpm_create_nlmsg()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:48:01 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/infiniband/core/iwpm_util.c | 5 ++--- 1 file changed, 2

[PATCH 0/3] RDMA/iwpm: Adjustments for three function implementations

From: Markus Elfring Date: Sat, 27 Jan 2018 22:12:34 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in iwpm_create_nlmsg() Adjust a variable

[PATCH 0/3] RDMA/iwpm: Adjustments for three function implementations

From: Markus Elfring Date: Sat, 27 Jan 2018 22:12:34 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in iwpm_create_nlmsg() Adjust a variable initialisation in

Re: [PATCH] ARM: dts: imx25-pinfunc: Always set SION for SD CMD

On Sat, Jan 27, 2018 at 09:37:11PM +0100, Benoît Thébaudeau wrote: > On Sat, Jan 27, 2018 at 4:37 PM, Uwe Kleine-König > wrote: > > On Sat, Jan 27, 2018 at 01:07:52AM +0100, Benoît Thébaudeau wrote: > >> The eSDHC does not work properly if the SION bit is not set

Re: [PATCH] ARM: dts: imx25-pinfunc: Always set SION for SD CMD

On Sat, Jan 27, 2018 at 09:37:11PM +0100, Benoît Thébaudeau wrote: > On Sat, Jan 27, 2018 at 4:37 PM, Uwe Kleine-König > wrote: > > On Sat, Jan 27, 2018 at 01:07:52AM +0100, Benoît Thébaudeau wrote: > >> The eSDHC does not work properly if the SION bit is not set for the > >> bidirectional CMD

Re: [PATCH] ARM: dts: imx25-pinfunc: Always set SION for SD CMD

On Sat, Jan 27, 2018 at 4:37 PM, Uwe Kleine-König wrote: > On Sat, Jan 27, 2018 at 01:07:52AM +0100, Benoît Thébaudeau wrote: >> The eSDHC does not work properly if the SION bit is not set for the >> bidirectional CMD signal, whatever the eSDHC instance and the

Re: [PATCH] ARM: dts: imx25-pinfunc: Always set SION for SD CMD

On Sat, Jan 27, 2018 at 4:37 PM, Uwe Kleine-König wrote: > On Sat, Jan 27, 2018 at 01:07:52AM +0100, Benoît Thébaudeau wrote: >> The eSDHC does not work properly if the SION bit is not set for the >> bidirectional CMD signal, whatever the eSDHC instance and the selected >> pad. Therefore, setting

[PATCH 2/2] RDMA/bnxt_re: Use common error handling code in bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 20:56:56 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Signed-off-by: Markus Elfring ---

[PATCH 2/2] RDMA/bnxt_re: Use common error handling code in bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 20:56:56 +0100 Add a jump target so that a bit of exception handling can be better reused at the end of this function. Signed-off-by: Markus Elfring --- drivers/infiniband/hw/bnxt_re/qplib_res.c | 13 +++-- 1 file changed, 7 insertions(+), 6

[PATCH 1/2] RDMA/bnxt_re: Delete two error messages for a failed memory allocation in bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 20:40:11 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] RDMA/bnxt_re: Delete two error messages for a failed memory allocation in bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 20:40:11 +0100 Omit extra messages for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/infiniband/hw/bnxt_re/qplib_res.c | 5 - 1 file changed, 5

[PATCH 0/2] RDMA/bnxt_re: Adjustments for bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:10:12 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete two error messages for a failed memory allocation Use common error handling code

[PATCH 0/2] RDMA/bnxt_re: Adjustments for bnxt_qplib_alloc_dpi_tbl()

From: Markus Elfring Date: Sat, 27 Jan 2018 21:10:12 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete two error messages for a failed memory allocation Use common error handling code drivers/infiniband/hw/bnxt_re/qplib_res.c

[PATCH stable] cifs: empty TargetInfo leads to crash on recovery

commit cabfb3680f78 upstream. [ resend from Oct 20, 2014, see [1] ] A trivially patched Samba server (see [2] [3]) can cause a remote kernel crash (see [4]) in a client's CIFS kernel module upon session recovery, under kernels prior to v4.11. The server patch can made by a single source line

[PATCH stable] cifs: empty TargetInfo leads to crash on recovery

commit cabfb3680f78 upstream. [ resend from Oct 20, 2014, see [1] ] A trivially patched Samba server (see [2] [3]) can cause a remote kernel crash (see [4]) in a client's CIFS kernel module upon session recovery, under kernels prior to v4.11. The server patch can made by a single source line

Re: [RFC v3 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

On 26/01/18 22:59, Lyude Paul wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios (which should be safe to use). > >

Re: [RFC v3 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

On 26/01/18 22:59, Lyude Paul wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios (which should be safe to use). > >

Re: [RFC v3 2/4] drm/nouveau: Add support for BLCG on Kepler1

On 26/01/18 22:59, Lyude Paul wrote: > This enables BLCG optimization for kepler1. When using clockgating, > nvidia's firmware has a set of registers which are initially programmed > by the vbios with various engine delays and other mysterious settings > that are safe enough to bring up the GPU.

Re: [RFC v3 2/4] drm/nouveau: Add support for BLCG on Kepler1

On 26/01/18 22:59, Lyude Paul wrote: > This enables BLCG optimization for kepler1. When using clockgating, > nvidia's firmware has a set of registers which are initially programmed > by the vbios with various engine delays and other mysterious settings > that are safe enough to bring up the GPU.

  1   2   3   4   >