Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419

On 16 November 2017 at 21:37, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote: >> You still have not explained to us how GOLD avoids the erratum. > > Sorry, I didn't realize you were asking that. If gold spots erratum > sequences,

Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419

On 16 November 2017 at 21:37, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote: >> You still have not explained to us how GOLD avoids the erratum. > > Sorry, I didn't realize you were asking that. If gold spots erratum > sequences, looks like it creates stubs

Re: [v8, 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling

On Thu, Nov 16, 2017 at 11:03:47AM -0800, Andi Kleen wrote: > > It is what I use at kerneltests.org. > > See https://github.com/groeck/linux-build-test/tree/master/rootfs/x86_64 > > for configuration and script. > > > > > I can't reproduce it here with different qemu settings. > > > > >

Re: [v8, 4/5] x86/xsave: Make XSAVE check the base CPUID features before enabling

On Thu, Nov 16, 2017 at 11:03:47AM -0800, Andi Kleen wrote: > > It is what I use at kerneltests.org. > > See https://github.com/groeck/linux-build-test/tree/master/rootfs/x86_64 > > for configuration and script. > > > > > I can't reproduce it here with different qemu settings. > > > > >

[GIT PULL] libnvdimm for 4.15

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.15 ...to receive the libnvdimm and dax update for 4.15. Save for a few late fixes, all of these commits have shipped in -next releases since before the merge window opened, and 0day

[GIT PULL] libnvdimm for 4.15

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-for-4.15 ...to receive the libnvdimm and dax update for 4.15. Save for a few late fixes, all of these commits have shipped in -next releases since before the merge window opened, and 0day

[REGRESSION][v4.13.y][v4.14.y] scsi: libsas: allow async aborts

Hi Christoph, A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it was found that reverting the following commit resolved this bug: 909657615d9b ("scsi: libsas: allow async aborts")   The regression was introduced as of v4.12-rc1, and it still exists in 4.14

[REGRESSION][v4.13.y][v4.14.y] scsi: libsas: allow async aborts

Hi Christoph, A kernel bug report was opened against Ubuntu [0].  After a kernel bisect, it was found that reverting the following commit resolved this bug: 909657615d9b ("scsi: libsas: allow async aborts")   The regression was introduced as of v4.12-rc1, and it still exists in 4.14

[PATCH] qed: fix unnecessary call to memset cocci warnings

Use kzalloc rather than kmalloc followed by memset with 0 drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1280:13-20: WARNING: kzalloc should be used for dcbx_info, instead of kmalloc/memset Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Signed-off-by: Vasyl Gomonovych

[PATCH] qed: fix unnecessary call to memset cocci warnings

Use kzalloc rather than kmalloc followed by memset with 0 drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1280:13-20: WARNING: kzalloc should be used for dcbx_info, instead of kmalloc/memset Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Signed-off-by: Vasyl Gomonovych ---

[GIT PULL 2/3] ARM: SoC driver updates for 4.15

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-drivers for you to fetch changes up to

[GIT PULL 2/3] ARM: SoC driver updates for 4.15

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-drivers for you to fetch changes up to

[GIT PULL 1/3] ARM: SoC platform updates for 4.15

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc for you to fetch changes up to

[GIT PULL 1/3] ARM: SoC platform updates for 4.15

The following changes since commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f: Linux 4.14-rc4 (2017-10-08 20:53:29 -0700) are available in the git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-soc for you to fetch changes up to

[PATCH] media: rc: double keypresses due to timeout expiring to early

Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), double keypresses are reported on the ite-cir driver. This is due two factors: that commit reduced the timeout used for some protocols (it became protocol dependant) and the high default IR timeout used by the ite-cir driver.

[PATCH] media: rc: double keypresses due to timeout expiring to early

Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), double keypresses are reported on the ite-cir driver. This is due two factors: that commit reduced the timeout used for some protocols (it became protocol dependant) and the high default IR timeout used by the ite-cir driver.

Re: [PATCH] sched/fair: Consider RT/IRQ pressure in capacity_spare_wake

Hi Vincent, Thanks a lot for your reply, and sorry for the late reply. Actually I just started paternity leave so that's why the delay. My working hours and completely random at the moment :-) On Fri, Nov 10, 2017 at 12:29 AM, Vincent Guittot wrote: > On 9 November

Re: [PATCH] sched/fair: Consider RT/IRQ pressure in capacity_spare_wake

Hi Vincent, Thanks a lot for your reply, and sorry for the late reply. Actually I just started paternity leave so that's why the delay. My working hours and completely random at the moment :-) On Fri, Nov 10, 2017 at 12:29 AM, Vincent Guittot wrote: > On 9 November 2017 at 19:52, Joel Fernandes

Re: [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling

On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann wrote: > An otherwise correct cleanup patch from Dan Carpenter turned a broken > failure handling from a feature patch by Hans Verkuil into a kernel > Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking > for

Re: [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling

On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann wrote: > An otherwise correct cleanup patch from Dan Carpenter turned a broken > failure handling from a feature patch by Hans Verkuil into a kernel > Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking > for IS_ERR() instead of

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

On Thu, Nov 16, 2017 at 10:30:45PM +0100, Lukas Wunner wrote: > On Thu, Nov 16, 2017 at 12:58:27PM -0800, John Stultz wrote: > > On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > > >After updating to Linus' HEAD today, I'm seeing the following odd > > > boot time

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

On Thu, Nov 16, 2017 at 10:30:45PM +0100, Lukas Wunner wrote: > On Thu, Nov 16, 2017 at 12:58:27PM -0800, John Stultz wrote: > > On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > > >After updating to Linus' HEAD today, I'm seeing the following odd > > > boot time crash with the HiKey

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

Hi Alex On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote: > On Wed, 15 Nov 2017 15:54:56 -0800 > Jacob Pan wrote: > > > Hi Alex and all, > > > > Just wondering if you could merge Robin's patch for the next rc. From > > all our testing, this seems

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

Hi Alex On Thu, Nov 16, 2017 at 02:32:44PM -0700, Alex Williamson wrote: > On Wed, 15 Nov 2017 15:54:56 -0800 > Jacob Pan wrote: > > > Hi Alex and all, > > > > Just wondering if you could merge Robin's patch for the next rc. From > > all our testing, this seems to be a solid fix and should be

Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

Jacek On 11/16/2017 02:14 PM, Jacek Anaszewski wrote: > Hi Dan and Pavel, > > On 11/15/2017 11:23 PM, Pavel Machek wrote: >> Hi! >> Shouldn't the driver be targeted for backlight subsystem then? Adding backlight maintainers. >>> >>> Great point! I was not aware of the

Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

Jacek On 11/16/2017 02:14 PM, Jacek Anaszewski wrote: > Hi Dan and Pavel, > > On 11/15/2017 11:23 PM, Pavel Machek wrote: >> Hi! >> Shouldn't the driver be targeted for backlight subsystem then? Adding backlight maintainers. >>> >>> Great point! I was not aware of the

[PATCH v2] tpm: Add explicit chip->ops locking for sysfs attributes.

Add explicit chip->ops locking for all sysfs attributes. This lets us support those attributes on tpm2 devices. Signed-off-by: Guenter Roeck --- v2: It makes sense to actually compile the code. drivers/char/tpm/tpm-chip.c | 4 -- drivers/char/tpm/tpm-sysfs.c | 127

[PATCH v2] tpm: Add explicit chip->ops locking for sysfs attributes.

Add explicit chip->ops locking for all sysfs attributes. This lets us support those attributes on tpm2 devices. Signed-off-by: Guenter Roeck --- v2: It makes sense to actually compile the code. drivers/char/tpm/tpm-chip.c | 4 -- drivers/char/tpm/tpm-sysfs.c | 127

Re: dts: fun with chip names Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On 11/16/2017 02:36 PM, Rob Herring wrote: > On Thu, Nov 16, 2017 at 2:11 PM, Pavel Machek wrote: >> Hi! >> > +Required properties: > + - compatible: > + "ti,lm3692x" Don't use wildcards in compatible strings. >>> >>> Do you mean to remove the x? How

Re: dts: fun with chip names Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On 11/16/2017 02:36 PM, Rob Herring wrote: > On Thu, Nov 16, 2017 at 2:11 PM, Pavel Machek wrote: >> Hi! >> > +Required properties: > + - compatible: > + "ti,lm3692x" Don't use wildcards in compatible strings. >>> >>> Do you mean to remove the x? How do we denote

Re: [PATCH] drm/amd/display: remove unnecessary cast and use kcalloc instead of kzalloc

On Wed, Nov 15, 2017 at 10:45 AM, Colin King wrote: > From: Colin Ian King > > Use kcalloc instead of kzalloc and the cast on the return from kzalloc is > unnecessary and can be removed. > > Signed-off-by: Colin Ian King

Re: [PATCH] drm/amd/display: remove unnecessary cast and use kcalloc instead of kzalloc

On Wed, Nov 15, 2017 at 10:45 AM, Colin King wrote: > From: Colin Ian King > > Use kcalloc instead of kzalloc and the cast on the return from kzalloc is > unnecessary and can be removed. > > Signed-off-by: Colin Ian King Reviewed and pushed. Thanks! Alex > --- >

Re: [PATCH v2 00/18] Add support for clang LTO

On Thu, Nov 16, 2017 at 11:53:00PM +0300, Yury Norov wrote: > I would suggest you to add the patch that checks their versions and > disables LTO if needed. Sure, sounds reasonable. I'll add this in the next version. Sami

Re: [PATCH v2 00/18] Add support for clang LTO

On Thu, Nov 16, 2017 at 11:53:00PM +0300, Yury Norov wrote: > I would suggest you to add the patch that checks their versions and > disables LTO if needed. Sure, sounds reasonable. I'll add this in the next version. Sami

Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419

On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote: > You still have not explained to us how GOLD avoids the erratum. Sorry, I didn't realize you were asking that. If gold spots erratum sequences, looks like it creates stubs to break them up:

Re: [PATCH v2 08/18] arm64: don't disable ADR_PREL_PG_HI21* with ARM64_ERRATUM_843419

On Thu, Nov 16, 2017 at 04:34:03PM +, Ard Biesheuvel wrote: > You still have not explained to us how GOLD avoids the erratum. Sorry, I didn't realize you were asking that. If gold spots erratum sequences, looks like it creates stubs to break them up:

Re: [PATCH] qed: fix unnecessary call to memset cocci warnings

Sorry.

Re: [PATCH] qed: fix unnecessary call to memset cocci warnings

Sorry.

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Wed, 15 Nov 2017 15:54:56 -0800 Jacob Pan wrote: > Hi Alex and all, > > Just wondering if you could merge Robin's patch for the next rc. From > all our testing, this seems to be a solid fix and should be included in > the stable releases as well. Hi Jacob,

Re: [PATCH] iommu/vt-d: Fix scatterlist offset handling

On Wed, 15 Nov 2017 15:54:56 -0800 Jacob Pan wrote: > Hi Alex and all, > > Just wondering if you could merge Robin's patch for the next rc. From > all our testing, this seems to be a solid fix and should be included in > the stable releases as well. Hi Jacob, Sorry, this wasn't on my radar, I

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Thu, Nov 16, 2017 at 02:28:15PM -0700, Ross Zwisler wrote: > On Thu, Oct 26, 2017 at 08:56:38AM +1100, Dave Chinner wrote: > > Perhaps stat -c %b $SCRATCH_MNT/test ? > > Maybe, but doesn't the output of 'stat -c %b' depend on the block size the > filesystem is using? I think to use stat I'd

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Thu, Nov 16, 2017 at 02:28:15PM -0700, Ross Zwisler wrote: > On Thu, Oct 26, 2017 at 08:56:38AM +1100, Dave Chinner wrote: > > Perhaps stat -c %b $SCRATCH_MNT/test ? > > Maybe, but doesn't the output of 'stat -c %b' depend on the block size the > filesystem is using? I think to use stat I'd

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

Hi John, thanks for reporting this and apologies for the breakage. On Thu, Nov 16, 2017 at 12:58:27PM -0800, John Stultz wrote: > On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > >After updating to Linus' HEAD today, I'm seeing the following odd > > boot time

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

Hi John, thanks for reporting this and apologies for the breakage. On Thu, Nov 16, 2017 at 12:58:27PM -0800, John Stultz wrote: > On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > >After updating to Linus' HEAD today, I'm seeing the following odd > > boot time crash with the HiKey board

Re: [PATCH v2 11/18] arm64: make mrs_s and msr_s macros work with LTO

On Thu, Nov 16, 2017 at 01:55:31PM +, Robin Murphy wrote: > On 16/11/17 13:07, Yury Norov wrote: > > On Thu, Nov 16, 2017 at 11:54:33AM +, Will Deacon wrote: > > > On Wed, Nov 15, 2017 at 01:34:21PM -0800, Sami Tolvanen wrote: > > > > From: Alex Matveev > > > > > > > >

Re: [PATCH v2 11/18] arm64: make mrs_s and msr_s macros work with LTO

On Thu, Nov 16, 2017 at 01:55:31PM +, Robin Murphy wrote: > On 16/11/17 13:07, Yury Norov wrote: > > On Thu, Nov 16, 2017 at 11:54:33AM +, Will Deacon wrote: > > > On Wed, Nov 15, 2017 at 01:34:21PM -0800, Sami Tolvanen wrote: > > > > From: Alex Matveev > > > > > > > > Use UNDEFINE_MRS_S

[PATCH 2/2] ALSA: pcxhr: Use common error handling code in pcxhr_probe()

From: Markus Elfring Date: Thu, 16 Nov 2017 22:11:52 +0100 Add jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 2/2] ALSA: pcxhr: Use common error handling code in pcxhr_probe()

From: Markus Elfring Date: Thu, 16 Nov 2017 22:11:52 +0100 Add jump targets so that a bit of exception handling can be better reused at the end of this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- sound/pci/pcxhr/pcxhr.c | 62

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Wed, Nov 15, 2017 at 07:29:10PM -0800, chetan L wrote: > On Wed, Nov 15, 2017 at 7:23 PM, chetan L wrote: > > On Wed, Nov 15, 2017 at 6:44 PM, Jerome Glisse wrote: > >> On Wed, Nov 15, 2017 at 06:10:08PM -0800, chet l wrote: > >>> >> You may think it

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Wed, Nov 15, 2017 at 07:29:10PM -0800, chetan L wrote: > On Wed, Nov 15, 2017 at 7:23 PM, chetan L wrote: > > On Wed, Nov 15, 2017 at 6:44 PM, Jerome Glisse wrote: > >> On Wed, Nov 15, 2017 at 06:10:08PM -0800, chet l wrote: > >>> >> You may think it as a CCIX device or CAPI device. > >>> >>

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Thu, Oct 26, 2017 at 08:56:38AM +1100, Dave Chinner wrote: > On Wed, Oct 25, 2017 at 02:47:04PM -0600, Ross Zwisler wrote: > > Add a test that exercises DAX's new MAP_SYNC flag. > > > > This test creates a file and writes to it via an mmap(), but never syncs > > via fsync/msync. This process

Re: [fstests PATCH v3] generic: add test for DAX MAP_SYNC support

On Thu, Oct 26, 2017 at 08:56:38AM +1100, Dave Chinner wrote: > On Wed, Oct 25, 2017 at 02:47:04PM -0600, Ross Zwisler wrote: > > Add a test that exercises DAX's new MAP_SYNC flag. > > > > This test creates a file and writes to it via an mmap(), but never syncs > > via fsync/msync. This process

[PATCH 1/2] ALSA: pcxhr: Adjust six function calls together with a variable assignment

From: Markus Elfring Date: Thu, 16 Nov 2017 21:50:21 +0100 The script "checkpatch.pl" pointed information out like the following. ERROR: do not use assignment in if condition Thus fix the affected source code places. Signed-off-by: Markus Elfring

[PATCH 1/2] ALSA: pcxhr: Adjust six function calls together with a variable assignment

From: Markus Elfring Date: Thu, 16 Nov 2017 21:50:21 +0100 The script "checkpatch.pl" pointed information out like the following. ERROR: do not use assignment in if condition Thus fix the affected source code places. Signed-off-by: Markus Elfring --- sound/pci/pcxhr/pcxhr.c | 22

[PATCH 0/2] ALSA: pcxhr: Fine-tuning for three function implementations

From: Markus Elfring Date: Thu, 16 Nov 2017 22:20:02 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Adjust six function calls together with a variable assignment Use common error handling code in

Re: [PATCH 3.18 08/20] tun/tap: sanitize TUNSETSNDBUF input

On Thu, Nov 16, 2017 at 12:28 PM, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Craig Gallek > > > [ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d

[PATCH 0/2] ALSA: pcxhr: Fine-tuning for three function implementations

From: Markus Elfring Date: Thu, 16 Nov 2017 22:20:02 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Adjust six function calls together with a variable assignment Use common error handling code in pcxhr_probe()

Re: [PATCH 3.18 08/20] tun/tap: sanitize TUNSETSNDBUF input

On Thu, Nov 16, 2017 at 12:28 PM, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Craig Gallek > > > [ Upstream commit 93161922c658c714715686cd0cf69b090cb9bf1d ] > > Syzkaller found several variants of the

[PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

Add explicit chip->ops locking for all sysfs attributes. This lets us support those attributes on tpm2 devices. Signed-off-by: Guenter Roeck --- drivers/char/tpm/tpm-chip.c | 4 -- drivers/char/tpm/tpm-sysfs.c | 125 --- 2 files

[PATCH] tpm: Add explicit chip->ops locking for sysfs attributes.

Add explicit chip->ops locking for all sysfs attributes. This lets us support those attributes on tpm2 devices. Signed-off-by: Guenter Roeck --- drivers/char/tpm/tpm-chip.c | 4 -- drivers/char/tpm/tpm-sysfs.c | 125 --- 2 files changed, 93

Re: [PATCH 10/13] x86/alternative: Support indirect call replacement

On Wed, Oct 25, 2017 at 01:25:02PM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Add alternative patching support for replacing an instruction with an > > indirect call. This will be needed for the paravirt alternatives. > > > > Signed-off-by: Josh Poimboeuf

Re: [PATCH 10/13] x86/alternative: Support indirect call replacement

On Wed, Oct 25, 2017 at 01:25:02PM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Add alternative patching support for replacing an instruction with an > > indirect call. This will be needed for the paravirt alternatives. > > > > Signed-off-by: Josh Poimboeuf > > ---

Re: [PATCH] x86/mce: add support SRAO reported via CMC check

On Thu, Nov 16, 2017 at 11:00:40AM +0800, Xie XiuQi wrote: > How about this patch? > + /* > + * known AO MCACODs reported via MCE or CMC: > + * > + * SRAO could be signaled either via a machine check exception or > + * CMCI with the corresponding bit S 1 or 0. So we don't

Re: [PATCH] x86/mce: add support SRAO reported via CMC check

On Thu, Nov 16, 2017 at 11:00:40AM +0800, Xie XiuQi wrote: > How about this patch? > + /* > + * known AO MCACODs reported via MCE or CMC: > + * > + * SRAO could be signaled either via a machine check exception or > + * CMCI with the corresponding bit S 1 or 0. So we don't

Re: [RFC PATCH for 4.15 04/24] Restartable sequences: x86 32/64 architecture support

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: Please fix the subject line: x86: Add support for restartable sequences or something like that. And for the actual rseq patches please come up with a proper short susbsytem prefix for restartable sequences. There is no point in occupying half of

Re: [RFC PATCH for 4.15 04/24] Restartable sequences: x86 32/64 architecture support

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: Please fix the subject line: x86: Add support for restartable sequences or something like that. And for the actual rseq patches please come up with a proper short susbsytem prefix for restartable sequences. There is no point in occupying half of

Re: [RFC] Improving udelay/ndelay on platforms where that is possible

On 16/11/2017 18:05, Russell King - ARM Linux wrote: > On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote: > >> Requesting 100 µs and spinning only 25 µs is still a problem, >> don't you agree? > > Which is why, as I've said *many* times already, that drivers are written > with leaway

Re: [RFC] Improving udelay/ndelay on platforms where that is possible

On 16/11/2017 18:05, Russell King - ARM Linux wrote: > On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote: > >> Requesting 100 µs and spinning only 25 µs is still a problem, >> don't you agree? > > Which is why, as I've said *many* times already, that drivers are written > with leaway

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: > +#ifdef __KERNEL__ > +# include > +#else/* #ifdef __KERNEL__ */ Please drop these comments. They are distracting and not helpful at all. They are valuable for long #ideffed sections but then the normal form is: /* __KERNEL__ */ /*

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: > +#ifdef __KERNEL__ > +# include > +#else/* #ifdef __KERNEL__ */ Please drop these comments. They are distracting and not helpful at all. They are valuable for long #ideffed sections but then the normal form is: /* __KERNEL__ */ /*

Re: [git pull] drm for v4.15

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie wrote: > > This sounds more like a Monty Python sketch than a serious question. It's a serious question when the files start appearing in random places where they don't belong. There's a place for automatically generated files.

Re: [git pull] drm for v4.15

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie wrote: > > This sounds more like a Monty Python sketch than a serious question. It's a serious question when the files start appearing in random places where they don't belong. There's a place for automatically generated files. But that "there is a

Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On Wed, Oct 25, 2017 at 11:46:18AM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Convert the hard-coded native patch assembly code strings to macros to > > facilitate sharing common code between 32-bit and 64-bit. > > > > These macros will also be used by a future

Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

On Wed, Oct 25, 2017 at 11:46:18AM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Convert the hard-coded native patch assembly code strings to macros to > > facilitate sharing common code between 32-bit and 64-bit. > > > > These macros will also be used by a future

Re: [patch V3 09/11] LICENSES: Add Linux syscall note exception

On Thu, 16 Nov 2017 19:33:15 +0100 Thomas Gleixner wrote: > Copied from the Linux kernel COPYING file. > > Add the required tags for reference and tooling. > > Signed-off-by: Thomas Gleixner > > --- > LICENSES/exceptions/Linux-syscall-note | 25

Re: [patch V3 09/11] LICENSES: Add Linux syscall note exception

On Thu, 16 Nov 2017 19:33:15 +0100 Thomas Gleixner wrote: > Copied from the Linux kernel COPYING file. > > Add the required tags for reference and tooling. > > Signed-off-by: Thomas Gleixner > > --- > LICENSES/exceptions/Linux-syscall-note | 25 + > 1 file changed,

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > Hey folks, >After updating to Linus' HEAD today, I'm seeing the following odd > boot time crash with the HiKey board (which uses the serdev driver). > > [1.963009] Unable to handle kernel read from unreadable

Re: Boot crash @hci_uart_tx_wakeup+0x38/0x148 w/ Linus' HEAD?

On Wed, Nov 15, 2017 at 6:00 PM, John Stultz wrote: > Hey folks, >After updating to Linus' HEAD today, I'm seeing the following odd > boot time crash with the HiKey board (which uses the serdev driver). > > [1.963009] Unable to handle kernel read from unreadable memory at > virtual

Re: [patch V3 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

The following is all extreme nits; you can ignore all of it and the file will be just fine. I assume you're planning to merge this directly with the rest; feel free to add my ack if that's worth anything. If you want me to take it, instead, just let me know. On Thu, 16 Nov 2017 19:33:07 +0100

Re: [patch V3 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

The following is all extreme nits; you can ignore all of it and the file will be just fine. I assume you're planning to merge this directly with the rest; feel free to add my ack if that's worth anything. If you want me to take it, instead, just let me know. On Thu, 16 Nov 2017 19:33:07 +0100

Re: [git pull] drm for v4.15

On 16 November 2017 at 14:59, Linus Torvalds wrote: > On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: >> >> There is some code touched on sound/soc, but I think the sound tree >> should have the same commits from the same base,so this may

Re: [git pull] drm for v4.15

On 16 November 2017 at 14:59, Linus Torvalds wrote: > On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote: >> >> There is some code touched on sound/soc, but I think the sound tree >> should have the same commits from the same base,so this may luck different >> if you pulled it as I generated my

Re: [PATCH 2/2] leds: lp8860: Add regulator enable during init

Hi Dan, Thanks for the patch set. Both patches applied to the for-4.16 branch of linux-leds.git. Best regards, Jacek Anaszewski On 11/15/2017 08:52 PM, Dan Murphy wrote: > Add the regulator enable call during initialization. > If init fails then disable the regulator. > > Also during init the

Re: [PATCH 2/2] leds: lp8860: Add regulator enable during init

Hi Dan, Thanks for the patch set. Both patches applied to the for-4.16 branch of linux-leds.git. Best regards, Jacek Anaszewski On 11/15/2017 08:52 PM, Dan Murphy wrote: > Add the regulator enable call during initialization. > If init fails then disable the regulator. > > Also during init the

Re: [PATCH v2 00/18] Add support for clang LTO

On Wed, Nov 15, 2017 at 01:34:10PM -0800, Sami Tolvanen wrote: > This series adds build system support for compiling the kernel with clang > Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in > for linking. Some background for clang's LTO support is available here: > >

Re: [PATCH v2 00/18] Add support for clang LTO

On Wed, Nov 15, 2017 at 01:34:10PM -0800, Sami Tolvanen wrote: > This series adds build system support for compiling the kernel with clang > Link Time Optimization (LTO), using GNU gold with the LLVMgold plug-in > for linking. Some background for clang's LTO support is available here: > >

[PATCH] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

The Dell SMBIOS WMI interface will fail for some more complex calls unless a WMI hotfix has been included. Most platforms have this fix available in a maintenance BIOS release. In the case the driver is loaded on a platform without this fix, disable the userspace interface. A hotfix indicator

Re: [PATCH 02/13] x86/paravirt: Fix output constraint macro names

On Wed, Oct 25, 2017 at 11:33:43AM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Some of the paravirt '*_CLOBBERS' macros refer to output constraints > > instead of clobbers, which makes the code extra confusing. Rename the > > output constraint related macros to

[PATCH] platform/x86: dell-smbios-wmi: Disable userspace interface if missing hotfix

The Dell SMBIOS WMI interface will fail for some more complex calls unless a WMI hotfix has been included. Most platforms have this fix available in a maintenance BIOS release. In the case the driver is loaded on a platform without this fix, disable the userspace interface. A hotfix indicator

Re: [PATCH 02/13] x86/paravirt: Fix output constraint macro names

On Wed, Oct 25, 2017 at 11:33:43AM +0200, Juergen Gross wrote: > On 04/10/17 17:58, Josh Poimboeuf wrote: > > Some of the paravirt '*_CLOBBERS' macros refer to output constraints > > instead of clobbers, which makes the code extra confusing. Rename the > > output constraint related macros to

Re: linux-next: build warning after merge of the netfilter-next tree

Hi Pablo, On Thu, 16 Nov 2017 15:18:00 +0100 Pablo Neira Ayuso wrote: > > The patch is already at davem's tree. It's flying there. Excellent, thanks. -- Cheers, Stephen Rothwell

Re: linux-next: build warning after merge of the netfilter-next tree

Hi Pablo, On Thu, 16 Nov 2017 15:18:00 +0100 Pablo Neira Ayuso wrote: > > The patch is already at davem's tree. It's flying there. Excellent, thanks. -- Cheers, Stephen Rothwell

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

On Thu, Nov 16, 2017 at 08:37:58PM +, Mathieu Desnoyers wrote: > I usually never space-align with open parenthesis "(". Is it a coding > style requirement of the kernel for multi-line if () conditions ? Not sure, but it is the predominant pattern in most of the code. > Would the following

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

On Thu, Nov 16, 2017 at 08:37:58PM +, Mathieu Desnoyers wrote: > I usually never space-align with open parenthesis "(". Is it a coding > style requirement of the kernel for multi-line if () conditions ? Not sure, but it is the predominant pattern in most of the code. > Would the following

[PATCH] rdma: Add Jason as a co-maintainer

As was discussed in September and October, add Jason along with Doug to have a team maintainership model for the RDMA subystem. Mellanox Technologies will be funding Jason's independent work on the maintainership. Signed-off-by: Jason Gunthorpe --- .mailmap| 2 ++

[PATCH] rdma: Add Jason as a co-maintainer

As was discussed in September and October, add Jason along with Doug to have a team maintainership model for the RDMA subystem. Mellanox Technologies will be funding Jason's independent work on the maintainership. Signed-off-by: Jason Gunthorpe --- .mailmap| 2 ++ MAINTAINERS | 1 + 2

[GIT PULL] bcm2835-dt-next-fixes-2017-11-15

Hi Florian, This is a little fix from Stefan for a warning that popped up when our -next and dtc's -next got merged. Hopefully it can get pulled for 4.15 soon. The following changes since commit fd3372db18d3d44ae4579243a8eacb5247d8c03a: ARM: dts: bcm2837-rpi-3-b: Add bcm43438 serial slave

[GIT PULL] bcm2835-dt-next-fixes-2017-11-15

Hi Florian, This is a little fix from Stefan for a warning that popped up when our -next and dtc's -next got merged. Hopefully it can get pulled for 4.15 soon. The following changes since commit fd3372db18d3d44ae4579243a8eacb5247d8c03a: ARM: dts: bcm2837-rpi-3-b: Add bcm43438 serial slave

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

- On Nov 16, 2017, at 2:14 PM, Peter Zijlstra pet...@infradead.org wrote: > On Tue, Nov 14, 2017 at 03:03:51PM -0500, Mathieu Desnoyers wrote: >> +static bool rseq_update_cpu_id(struct task_struct *t) >> +{ >> +uint32_t cpu_id = raw_smp_processor_id(); >> + >> +if (__put_user(cpu_id,

Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call

- On Nov 16, 2017, at 2:14 PM, Peter Zijlstra pet...@infradead.org wrote: > On Tue, Nov 14, 2017 at 03:03:51PM -0500, Mathieu Desnoyers wrote: >> +static bool rseq_update_cpu_id(struct task_struct *t) >> +{ >> +uint32_t cpu_id = raw_smp_processor_id(); >> + >> +if (__put_user(cpu_id,

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