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

On Fri, Nov 17, 2017 at 12:25:12AM +0100, Arnd Bergmann wrote: On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds wrote: On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: ARM: SoC driver updates for v4.15 No. This is completely broken, and I

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

On Fri, Nov 17, 2017 at 12:25:12AM +0100, Arnd Bergmann wrote: On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds wrote: On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: ARM: SoC driver updates for v4.15 No. This is completely broken, and I can't imagine that it has ever compiled for

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

On Thu, Nov 16, 2017 at 11:20:40PM +, Ard Biesheuvel wrote: > So at which point is the IR in a partially linked object file > converted into executable code? At the final module link step (cmd_ld_ko_o) in scripts/Makefile.modpost, added in patch 12. Sami

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

On Thu, Nov 16, 2017 at 11:20:40PM +, Ard Biesheuvel wrote: > So at which point is the IR in a partially linked object file > converted into executable code? At the final module link step (cmd_ld_ko_o) in scripts/Makefile.modpost, added in patch 12. Sami

Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

Hello, On Fri, Nov 17, 2017 at 12:31:41AM +0100, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 4:20:58 PM CET Viresh Kumar wrote: > > On 16-11-17, 15:02, Ionela Voinescu wrote: > > > When it was added in lsk 3.18 in what was then a thermal driver for Juno > > > it was believed to have

Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

Hello, On Fri, Nov 17, 2017 at 12:31:41AM +0100, Rafael J. Wysocki wrote: > On Thursday, November 16, 2017 4:20:58 PM CET Viresh Kumar wrote: > > On 16-11-17, 15:02, Ionela Voinescu wrote: > > > When it was added in lsk 3.18 in what was then a thermal driver for Juno > > > it was believed to have

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner wrote: > On Wed, 15 Nov 2017, Deepa Dinamani wrote: >> > I had on concern about x32, maybe we should check >> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec >> > bits. >> >> Thanks, I think you are right. I had

Re: [PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion

On Thu, Nov 16, 2017 at 10:04 AM, Thomas Gleixner wrote: > On Wed, 15 Nov 2017, Deepa Dinamani wrote: >> > I had on concern about x32, maybe we should check >> > for "COMPAT_USE_64BIT_TIME" before zeroing out the tv_nsec >> > bits. >> >> Thanks, I think you are right. I had the check conditional

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 11/16/2017 11:49 AM, Cornelia Huck wrote: On Thu, 16 Nov 2017 10:23:25 -0500 Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck wrote: On Tue, 31 Oct 2017 15:39:09 -0400 Tony Krowiak wrote: On 10/13/2017 01:38 PM, Tony

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 11/16/2017 11:49 AM, Cornelia Huck wrote: On Thu, 16 Nov 2017 10:23:25 -0500 Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck wrote: On Tue, 31 Oct 2017 15:39:09 -0400 Tony Krowiak wrote: On 10/13/2017 01:38 PM, Tony Krowiak wrote: Ping Tony Krowiak (19): KVM: s390:

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 11/16/2017 03:25 PM, Pierre Morel wrote: On 16/11/2017 18:03, Cornelia Huck wrote: On Thu, 16 Nov 2017 17:06:58 +0100 Pierre Morel wrote: On 16/11/2017 16:23, Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck wrote: On Tue, 31 Oct 2017 15:39:09 -0400

Re: [RFC 00/19] KVM: s390/crypto/vfio: guest dedicated crypto adapters

On 11/16/2017 03:25 PM, Pierre Morel wrote: On 16/11/2017 18:03, Cornelia Huck wrote: On Thu, 16 Nov 2017 17:06:58 +0100 Pierre Morel wrote: On 16/11/2017 16:23, Tony Krowiak wrote: On 11/14/2017 08:57 AM, Cornelia Huck wrote: On Tue, 31 Oct 2017 15:39:09 -0400 Tony Krowiak wrote: On

Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

On Thursday, November 16, 2017 4:20:58 PM CET Viresh Kumar wrote: > On 16-11-17, 15:02, Ionela Voinescu wrote: > > When it was added in lsk 3.18 in what was then a thermal driver for Juno > > it was believed to have an effect in thermal mitigation, but that was > > not proven later as to justify

Re: [PATCH] refcount_t: documentation for memory ordering differences

On Tue, Nov 14, 2017 at 11:55 PM, Elena Reshetova wrote: > Some functions from refcount_t API provide different > memory ordering guarantees that their atomic counterparts. > This adds a document outlining these differences. Thanks for writing this up! One

Re: [PATCH] refcount_t: documentation for memory ordering differences

On Tue, Nov 14, 2017 at 11:55 PM, Elena Reshetova wrote: > Some functions from refcount_t API provide different > memory ordering guarantees that their atomic counterparts. > This adds a document outlining these differences. Thanks for writing this up! One bike-shedding thing I'll bring up

Re: [PATCH 4/4] cpu_cooling: Drop static-power related stuff

On Thursday, November 16, 2017 4:20:58 PM CET Viresh Kumar wrote: > On 16-11-17, 15:02, Ionela Voinescu wrote: > > When it was added in lsk 3.18 in what was then a thermal driver for Juno > > it was believed to have an effect in thermal mitigation, but that was > > not proven later as to justify

[GIT PULL 3/3] ARM: SoC DT 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-dt for you to fetch changes up to

[GIT PULL 3/3] ARM: SoC DT 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-dt for you to fetch changes up to

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: > +#ifdef __KERNEL__ > +# include > +#else/* #ifdef __KERNEL__ */ Sigh. > +# include > +#endif /* #else #ifdef __KERNEL__ */ > + > +#include > + > +#ifdef __LP64__ > +# define CPU_OP_FIELD_u32_u64(field)

Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call

On Tue, 14 Nov 2017, Mathieu Desnoyers wrote: > +#ifdef __KERNEL__ > +# include > +#else/* #ifdef __KERNEL__ */ Sigh. > +# include > +#endif /* #else #ifdef __KERNEL__ */ > + > +#include > + > +#ifdef __LP64__ > +# define CPU_OP_FIELD_u32_u64(field)

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

On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds wrote: > On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: >> >> ARM: SoC driver updates for v4.15 > > No. This is completely broken, and I can't imagine that it has ever > compiled for *anybody*.

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

On Thu, Nov 16, 2017 at 11:29 PM, Linus Torvalds wrote: > On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: >> >> ARM: SoC driver updates for v4.15 > > No. This is completely broken, and I can't imagine that it has ever > compiled for *anybody*. > >

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Thu, Nov 16, 2017 at 3:13 PM, wrote: > > It's possible, but I didn't want to add a bunch of clutter to the > commit message. Right now it's somewhat easy to track it back to > automatic selection because: > > 1. I'm signed off on all of them, so I could chime in

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Thu, Nov 16, 2017 at 3:13 PM, wrote: > > It's possible, but I didn't want to add a bunch of clutter to the > commit message. Right now it's somewhat easy to track it back to > automatic selection because: > > 1. I'm signed off on all of them, so I could chime in in the case > concerns/issues

[PATCH 2/4] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file

This commit adds include file guards to ts72xx.h Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/ts72xx.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h index 2255ba29fdd6..d67f203f769a 100644 ---

[PATCH 2/4] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file

This commit adds include file guards to ts72xx.h Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/ts72xx.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h index 2255ba29fdd6..d67f203f769a 100644 ---

[PATCH 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board

This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design. This patchset consists of following patches: - ts72xx.[c|h] cosmetic cleanup/improvement - Move the common code for ts72xx and BK3 to ts72xx-common.c - this code can be reused by other designs build

[PATCH 3/4] ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board

This commit creates a new file ts72xx-common.c [1], which consists of code being potentially re-usable by other clones of reference ts72xx design. To achieve this goal, a new symbol - TS72XX_COMMON has been introduced. Signed-off-by: Lukasz Majewski ---

[PATCH 3/4] ARM: ep93xx: ts72xx: Exclude reusable part of the ts72xx board

This commit creates a new file ts72xx-common.c [1], which consists of code being potentially re-usable by other clones of reference ts72xx design. To achieve this goal, a new symbol - TS72XX_COMMON has been introduced. Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/Kconfig |

[PATCH 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board

This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design. This patchset consists of following patches: - ts72xx.[c|h] cosmetic cleanup/improvement - Move the common code for ts72xx and BK3 to ts72xx-common.c - this code can be reused by other designs build

[PATCH 1/4] ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable

This commit cleans up the code by using dedicated macros instead of full definitions. Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/ts72xx.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-ep93xx/ts72xx.c

[PATCH 4/4] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

The BK3 board is a derivative of the ts72xx reference design. Hence, it can re-use code from the ts72xx-common.c file. Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/Kconfig | 7 arch/arm/mach-ep93xx/Makefile | 1 + arch/arm/mach-ep93xx/bk3.c| 88

[PATCH 1/4] ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable

This commit cleans up the code by using dedicated macros instead of full definitions. Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/ts72xx.c | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/arch/arm/mach-ep93xx/ts72xx.c

[PATCH 4/4] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

The BK3 board is a derivative of the ts72xx reference design. Hence, it can re-use code from the ts72xx-common.c file. Signed-off-by: Lukasz Majewski --- arch/arm/mach-ep93xx/Kconfig | 7 arch/arm/mach-ep93xx/Makefile | 1 + arch/arm/mach-ep93xx/bk3.c| 88

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

On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote: > Hi, > > On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez > wrote: > > On 16/11/2017 18:05, Russell King - ARM Linux wrote: > > > >> On Thu, Nov 16, 2017 at 05:42:36PM +0100, Marc Gonzalez wrote: > >> >

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

On Thu, Nov 16, 2017 at 02:15:02PM -0800, Doug Anderson wrote: > Hi, > > On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez > wrote: > > 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

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

On 16 November 2017 at 23:09, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote: >> OK, so my concern here is that this code probably only operates on >> fully linked binaries, and not partially linked object files like >> kernel

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

On 16 November 2017 at 23:09, Sami Tolvanen wrote: > On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote: >> OK, so my concern here is that this code probably only operates on >> fully linked binaries, and not partially linked object files like >> kernel modules. > > Right. That makes

RE: [Patch v7 03/22] CIFS: SMBD: Add rdma mount option

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > Add "rdma" to CIFS mount options to connect to SMB Direct. > Add checks to validate this is used on SMB 3.X dialects. > > To connect to SMBDirect, use "mount.cifs -o rdma,vers=3.x". > At

RE: [Patch v7 03/22] CIFS: SMBD: Add rdma mount option

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > Add "rdma" to CIFS mount options to connect to SMB Direct. > Add checks to validate this is used on SMB 3.X dialects. > > To connect to SMBDirect, use "mount.cifs -o rdma,vers=3.x". > At the time of this patch, 3.x can be 3.0, 3.02 or

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Wed, Nov 15, 2017 at 09:43:41AM -0800, Josh Hunt wrote: >I just started noticing the AUTOSEL tags yesterday and I think that's >a great idea to tag patches, but was there any thought to also putting >something in the commit message this way they're easily identifiable >in the git logs? I think

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Wed, Nov 15, 2017 at 09:43:41AM -0800, Josh Hunt wrote: >I just started noticing the AUTOSEL tags yesterday and I think that's >a great idea to tag patches, but was there any thought to also putting >something in the commit message this way they're easily identifiable >in the git logs? I think

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

On Thu, Nov 16, 2017 at 02:41:39PM -0800, chetan L wrote: > On Thu, Nov 16, 2017 at 1:29 PM, Jerome Glisse wrote: > > > > > For the NUMA discussion this is related to CPU less node ie not wanting > > to add any more CPU less node (node with only memory) and they are other > >

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

On Thu, Nov 16, 2017 at 02:41:39PM -0800, chetan L wrote: > On Thu, Nov 16, 2017 at 1:29 PM, Jerome Glisse wrote: > > > > > For the NUMA discussion this is related to CPU less node ie not wanting > > to add any more CPU less node (node with only memory) and they are other > > aspect too. For

Re: Re: edt-ft5x06 question

Hi Simon, sorry for the mess with mailing list. My mail filter gave me problems and removed e-mails from linux-input mailing list. > Hi Giulio > > On Tue, 2017-11-14 at 22:42 +0100, Giulio Benetti wrote: > > I'm using ft5206 with edt-ft5x06.c driver, > > but what I see is that registers with

Re: Re: edt-ft5x06 question

Hi Simon, sorry for the mess with mailing list. My mail filter gave me problems and removed e-mails from linux-input mailing list. > Hi Giulio > > On Tue, 2017-11-14 at 22:42 +0100, Giulio Benetti wrote: > > I'm using ft5206 with edt-ft5x06.c driver, > > but what I see is that registers with

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

On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote: > OK, so my concern here is that this code probably only operates on > fully linked binaries, and not partially linked object files like > kernel modules. Right. That makes sense. > What is preventing us from using the large model

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

On Thu, Nov 16, 2017 at 10:14:17PM +, Ard Biesheuvel wrote: > OK, so my concern here is that this code probably only operates on > fully linked binaries, and not partially linked object files like > kernel modules. Right. That makes sense. > What is preventing us from using the large model

RE: [Patch v7 02/22] CIFS: SMBD: Introduce kernel config option CONFIG_CIFS_SMB_DIRECT

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > Build SMB Direct code when this option is set. > > Signed-off-by: Long Li > --- > fs/cifs/Kconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote: > On 12 November 2017 at 01:37, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to > > instruct the PM

RE: [Patch v7 02/22] CIFS: SMBD: Introduce kernel config option CONFIG_CIFS_SMB_DIRECT

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > Build SMB Direct code when this option is set. > > Signed-off-by: Long Li > --- > fs/cifs/Kconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig > index f724361..8d05fff 100644 > ---

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote: > On 12 November 2017 at 01:37, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to > > instruct the PM core and middle-layer (bus type, PM domain, etc.)

RE: [Patch v7 01/22] CIFS: SMBD: Add parameter rdata to smb2_new_read_req

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > This patch is for preparing upper layer for doing SMB read via RDMA write. > > When we assemble the SMB read packet header, we need to know the I/O layout > if this request is to use a

RE: [Patch v7 01/22] CIFS: SMBD: Add parameter rdata to smb2_new_read_req

2017-11-07 0:54 GMT-08:00 Long Li : > From: Long Li > > This patch is for preparing upper layer for doing SMB read via RDMA write. > > When we assemble the SMB read packet header, we need to know the I/O layout > if this request is to use a RDMA write. rdata has all the information we need > for

Re: [alsa-devel] [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On 11/16/2017 04:24 PM, Linus Torvalds wrote: On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart wrote: Add 'default m' when sensible No. This is not sensible, and is not at all what I suggested. Actual new code should *never* be default 'm' or

Re: [alsa-devel] [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On 11/16/2017 04:24 PM, Linus Torvalds wrote: On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart wrote: Add 'default m' when sensible No. This is not sensible, and is not at all what I suggested. Actual new code should *never* be default 'm' or 'y'. You may think it's supremely

[RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

From: Arnd Bergmann 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 NULL") rather than

[RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

From: Arnd Bergmann 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 NULL") rather than 3b1b975003e4 ("drm:

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

On Thu, Oct 26, 2017 at 07:59:39AM +0300, Amir Goldstein wrote: > On Wed, Oct 25, 2017 at 11:47 PM, 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

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

On Thu, Oct 26, 2017 at 07:59:39AM +0300, Amir Goldstein wrote: > On Wed, Oct 25, 2017 at 11:47 PM, 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 is

Re: [PATCH 0/7] Support for automatic checkpatch running in the kernel

On Thu, Nov 16, 2017 at 9:01 AM, Knut Omang wrote: > The most important checkpatch feature added is the --ignore-cfg feature, which > takes a file argument and parses that file according to this minimal language: > ># comments >line_len >except

Re: [PATCH 0/7] Support for automatic checkpatch running in the kernel

On Thu, Nov 16, 2017 at 9:01 AM, Knut Omang wrote: > The most important checkpatch feature added is the --ignore-cfg feature, which > takes a file argument and parses that file according to this minimal language: > ># comments >line_len >except checkpatch_type [files ...]

[PATCH v4] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v4] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

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

On Fri, 17 Nov 2017 00:29:20 +0300 Yury Norov wrote: > On Thu, Nov 16, 2017 at 01:55:31PM +, Robin Murphy wrote: > > Given that this whole mrs_s infrastructure is a workaround for older > > assemblers which don't support the "S" > > syntax for arbitrary unnamed

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

On Fri, 17 Nov 2017 00:29:20 +0300 Yury Norov wrote: > On Thu, Nov 16, 2017 at 01:55:31PM +, Robin Murphy wrote: > > Given that this whole mrs_s infrastructure is a workaround for older > > assemblers which don't support the "S" > > syntax for arbitrary unnamed system registers (which

Re: [PATCH 4.9 00/39] 4.9.63-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.63 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.13 00/44] 4.13.14-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.13.14 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.9 00/39] 4.9.63-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.63 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.13 00/44] 4.13.14-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.13.14 release. > There are 44 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

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

Hi all, On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann wrote: > > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko wrote: > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote: > >> > >> After merging the akpm-current tree, today's linux-next build (powerpc >

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

Hi all, On Mon, 13 Nov 2017 12:43:08 +0100 Arnd Bergmann wrote: > > On Mon, Nov 13, 2017 at 9:09 AM, Michal Hocko wrote: > > On Mon 13-11-17 16:42:06, Stephen Rothwell wrote: > >> > >> After merging the akpm-current tree, today's linux-next build (powerpc > >> ppc64_defconfig) produced this

Re: [PATCH 4.4 00/28] 4.4.99-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.99 release. > There are 28 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.4 00/28] 4.4.99-stable review

On 11/16/2017 10:42 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.99 release. > There are 28 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/20] 3.18.82-stable review

On 11/16/2017 10:28 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.82 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 3.18 00/20] 3.18.82-stable review

On 11/16/2017 10:28 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.82 release. > There are 20 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

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

On Thu, Nov 16, 2017 at 1:29 PM, Jerome Glisse wrote: > > For the NUMA discussion this is related to CPU less node ie not wanting > to add any more CPU less node (node with only memory) and they are other > aspect too. For instance you do not necessarily have good

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

On Thu, Nov 16, 2017 at 1:29 PM, Jerome Glisse wrote: > > For the NUMA discussion this is related to CPU less node ie not wanting > to add any more CPU less node (node with only memory) and they are other > aspect too. For instance you do not necessarily have good informations > from the device

[PATCH] firmware: cleanup FIRMWARE_IN_KERNEL message

The help for FIRMWARE_IN_KERNEL still references the firmware_install command that was recently removed by commit 5620a0d1aacd ("firmware: delete in-kernel firmware"). Clean up the message to direct the user to their distribution's linux-firmware package, and remove any reference to firmware

[PATCH] firmware: cleanup FIRMWARE_IN_KERNEL message

The help for FIRMWARE_IN_KERNEL still references the firmware_install command that was recently removed by commit 5620a0d1aacd ("firmware: delete in-kernel firmware"). Clean up the message to direct the user to their distribution's linux-firmware package, and remove any reference to firmware

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

On Thu, Nov 16, 2017 at 1:45 PM, Lukas Wunner wrote: > 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: >> > >

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

On Thu, Nov 16, 2017 at 1:45 PM, Lukas Wunner wrote: > 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

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

On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: > > ARM: SoC driver updates for v4.15 No. This is completely broken, and I can't imagine that it has ever compiled for *anybody*. drivers/soc/renesas/r8a77970-sysc.c:14:10: fatal error: dt-bindings/power/r8a77970-sysc.h: No

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

On Thu, Nov 16, 2017 at 2:02 PM, Arnd Bergmann wrote: > > ARM: SoC driver updates for v4.15 No. This is completely broken, and I can't imagine that it has ever compiled for *anybody*. drivers/soc/renesas/r8a77970-sysc.c:14:10: fatal error: dt-bindings/power/r8a77970-sysc.h: No such file or

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

On 16 November 2017 at 22:14, Ard Biesheuvel wrote: > 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. >>

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

On 16 November 2017 at 22:14, Ard Biesheuvel wrote: > 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

Re: [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart wrote: > Add 'default m' when sensible No. This is not sensible, and is not at all what I suggested. Actual new code should *never* be default 'm' or 'y'. You may think it's supremely important because

Re: [PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

On Thu, Nov 16, 2017 at 2:16 PM, Pierre-Louis Bossart wrote: > Add 'default m' when sensible No. This is not sensible, and is not at all what I suggested. Actual new code should *never* be default 'm' or 'y'. You may think it's supremely important because you maintain it, but so does EVERY

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

Hey Eric, This is a pretty late response to the thread, but in case you're curious, since Ubuntu forgot to backport this (I already emailed them about it), I actually experienced a set of boxes that hit this bug in the wild and were crashing every 2 weeks or so, when under highload. It's pretty

Re: [PATCH] fork: fix incorrect fput of ->exe_file causing use-after-free

Hey Eric, This is a pretty late response to the thread, but in case you're curious, since Ubuntu forgot to backport this (I already emailed them about it), I actually experienced a set of boxes that hit this bug in the wild and were crashing every 2 weeks or so, when under highload. It's pretty

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

On Thu, Nov 16, 2017 at 2:20 PM, John Stultz wrote: > On Thu, Nov 16, 2017 at 1:50 PM, John Stultz wrote: >> On Wed, Nov 15, 2017 at 4:37 AM, Arnd Bergmann wrote: >>> An otherwise correct cleanup patch from Dan Carpenter turned a

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

On Thu, Nov 16, 2017 at 2:20 PM, John Stultz wrote: > On Thu, Nov 16, 2017 at 1:50 PM, John Stultz wrote: >> 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

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

On Thu, Nov 16, 2017 at 1:50 PM, John Stultz wrote: > 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 >>

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

On Thu, Nov 16, 2017 at 1:50 PM, John Stultz wrote: > 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

Re: [PATCH 0/3] add more clock definitions for hi3798cv200-poplar board

On 11/16, Shawn Guo wrote: > Hi Stephen, > > On Wed, Oct 18, 2017 at 07:00:26AM -0400, Jiancheng Xue wrote: > > Add more clock definitions for hi3798cv200-poplar board. > > > > Younian Wang (1): > > clk: hisilicon: correct ir clock rate for hi3798cv200 SoC > > > > tianshuliang (2): > > clk:

Re: [PATCH 0/3] add more clock definitions for hi3798cv200-poplar board

On 11/16, Shawn Guo wrote: > Hi Stephen, > > On Wed, Oct 18, 2017 at 07:00:26AM -0400, Jiancheng Xue wrote: > > Add more clock definitions for hi3798cv200-poplar board. > > > > Younian Wang (1): > > clk: hisilicon: correct ir clock rate for hi3798cv200 SoC > > > > tianshuliang (2): > > clk:

[PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

Add 'default m' when sensible, move common dependencies in if/endif block and clarify which options default to n - distro configurations should not enable legacy Baytrail stuff and NOCODEC (test only) Basic tests run with defconfig, oldconfig, olddefconfig, there should be no functionality

[PATCH] ASoC: Intel: Add defaults for SND_SST_ options and machine drivers

Add 'default m' when sensible, move common dependencies in if/endif block and clarify which options default to n - distro configurations should not enable legacy Baytrail stuff and NOCODEC (test only) Basic tests run with defconfig, oldconfig, olddefconfig, there should be no functionality

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

Hi, On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez wrote: > 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

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

Hi, On Thu, Nov 16, 2017 at 1:05 PM, Marc Gonzalez wrote: > 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

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