[PATCH] arm64: skip cpu nodes marked as disabled in DT

Skip the CPU nodes that are marked as disabled in DT. Bug 1828570 Signed-off-by: Rohit Khanna Reviewed-on: http://git-master/r/1245333 Reviewed-by: Alexander Van Brunt --- arch/arm64/kernel/smp.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH] arm64: skip cpu nodes marked as disabled in DT

Skip the CPU nodes that are marked as disabled in DT. Bug 1828570 Signed-off-by: Rohit Khanna Reviewed-on: http://git-master/r/1245333 Reviewed-by: Alexander Van Brunt --- arch/arm64/kernel/smp.c | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/kernel/smp.c

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 12:40, Jan Kiszka wrote: > On 2018-04-25 21:02, Frank Rowand wrote: >> On 04/25/18 11:56, Frank Rowand wrote: >>> On 04/24/18 22:22, Jan Kiszka wrote: On 2018-04-24 23:15, Frank Rowand wrote: > On 04/23/18 22:29, Jan Kiszka wrote: >> On 2018-04-24 00:38, Frank Rowand

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/25/18 12:40, Jan Kiszka wrote: > On 2018-04-25 21:02, Frank Rowand wrote: >> On 04/25/18 11:56, Frank Rowand wrote: >>> On 04/24/18 22:22, Jan Kiszka wrote: On 2018-04-24 23:15, Frank Rowand wrote: > On 04/23/18 22:29, Jan Kiszka wrote: >> On 2018-04-24 00:38, Frank Rowand

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

> > Then my analysis is correct that you simply missed filtering out the > si codes that are not signal specific and do not use the fault layout > in struct siginfo. > ... > I would say that you really need a > white-list of si_codes that whose use of struct siginfo that you know. > Otherwise you

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

> > Then my analysis is correct that you simply missed filtering out the > si codes that are not signal specific and do not use the fault layout > in struct siginfo. > ... > I would say that you really need a > white-list of si_codes that whose use of struct siginfo that you know. > Otherwise you

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > > > Do we really need the new config option?  This could just be > > > manually  tunable via fault injection IIUC. > > > > We do, because we want to enable it in RHEL and Fedora debugging > > kernels, so that it will be tested by the users. > > >

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > > > Do we really need the new config option?  This could just be > > > manually  tunable via fault injection IIUC. > > > > We do, because we want to enable it in RHEL and Fedora debugging > > kernels, so that it will be tested by the users. > > >

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) wrote: > > This patch adds the correct platform data information for the Caroline > > Chromebook, so that the mouse button does not get stuck in pressed state

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Wed, Apr 25, 2018 at 03:26:50PM -0700, Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) wrote: > > This patch adds the correct platform data information for the Caroline > > Chromebook, so that the mouse button does not get stuck in pressed state

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

On Tue, Apr 24, 2018 at 6:04 AM, Daniel Vetter wrote: > On Fri, Apr 20, 2018 at 09:55:32AM -0400, Sean Paul wrote: >> On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote: >> > This fixes a NULL pointer dereference that can happen if the UDL >> > driver is unloaded

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

On Tue, Apr 24, 2018 at 6:04 AM, Daniel Vetter wrote: > On Fri, Apr 20, 2018 at 09:55:32AM -0400, Sean Paul wrote: >> On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote: >> > This fixes a NULL pointer dereference that can happen if the UDL >> > driver is unloaded before the framebuffer

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, David Rientjes wrote: > On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > You need to enable it on boot. Enabling it when the kernel starts to > > execute userspace code is already too late (because you would miss > > kvmalloc calls in the kernel boot path). > > Is your

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, David Rientjes wrote: > On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > You need to enable it on boot. Enabling it when the kernel starts to > > execute userspace code is already too late (because you would miss > > kvmalloc calls in the kernel boot path). > > Is your

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > - dma api hides the cache flushing requirements from us. GPUs love > > non-snooped access, and worse give userspace control over that. We want > > a strict

Re: [alsa-devel] [PATCH v2 3/4] ALSA: usb-audio: Use Class Specific EP for UAC3 devices.

On Tue, Apr 24, 2018 at 8:24 PM, Jorge Sanjuan wrote: > bmAtributes offset doesn't exist in the UAC3 CS_EP descriptor. > Hence, checking for pitch control as if it was UAC2 doesn't make > any sense. Use the defined UAC3 offsets instead. > > Signed-off-by: Jorge

Re: [alsa-devel] [PATCH v2 3/4] ALSA: usb-audio: Use Class Specific EP for UAC3 devices.

On Tue, Apr 24, 2018 at 8:24 PM, Jorge Sanjuan wrote: > bmAtributes offset doesn't exist in the UAC3 CS_EP descriptor. > Hence, checking for pitch control as if it was UAC2 doesn't make > any sense. Use the defined UAC3 offsets instead. > > Signed-off-by: Jorge Sanjuan Reviewed-by: Ruslan

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) Mathieu Desnoyers wrote: > One problem with your approach is that you can have multiple callers > for the same tracepoint name, where some could be non-preemptible and > others blocking. Also, there is then no clear way for

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, 25 Apr 2018 17:40:56 -0400 (EDT) Mathieu Desnoyers wrote: > One problem with your approach is that you can have multiple callers > for the same tracepoint name, where some could be non-preemptible and > others blocking. Also, there is then no clear way for the callback > registration API

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > You need to enable it on boot. Enabling it when the kernel starts to > execute userspace code is already too late (because you would miss > kvmalloc calls in the kernel boot path). > Is your motivation that since kvmalloc() never falls back to

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, Mikulas Patocka wrote: > You need to enable it on boot. Enabling it when the kernel starts to > execute userspace code is already too late (because you would miss > kvmalloc calls in the kernel boot path). > Is your motivation that since kvmalloc() never falls back to

Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor specific address space

Hi Vicentiu, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Vicentiu-Galanopulo/net-phy-Enable-C45-vendor-specific-MDIO-register-addr-space/20180418-014927 config: x86_64-randconfig-b0-04260315

Re: [PATCH net-next 3/3] net: phy: Enable C45 PHYs with vendor specific address space

Hi Vicentiu, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Vicentiu-Galanopulo/net-phy-Enable-C45-vendor-specific-MDIO-register-addr-space/20180418-014927 config: x86_64-randconfig-b0-04260315

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > On Wed, 2018-04-25 at 17:22 -0400, Mikulas Patocka wrote: > > > > On Wed, 25 Apr 2018, David Rientjes wrote: > > > > > > Do we really need the new config option?  This could just be > > > manually  tunable via fault injection IIUC. > > > > We do,

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 25 Apr 2018, James Bottomley wrote: > On Wed, 2018-04-25 at 17:22 -0400, Mikulas Patocka wrote: > > > > On Wed, 25 Apr 2018, David Rientjes wrote: > > > > > > Do we really need the new config option?  This could just be > > > manually  tunable via fault injection IIUC. > > > > We do,

linux-next: build failure after merge of the qcom tree

Hi Andy, After merging the qcom tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "geni_se_select_mode" [drivers/tty/serial/qcom_geni_serial.ko] undefined! ERROR: "geni_se_init" [drivers/tty/serial/qcom_geni_serial.ko] undefined! ERROR: "geni_se_config_packing"

linux-next: build failure after merge of the qcom tree

Hi Andy, After merging the qcom tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "geni_se_select_mode" [drivers/tty/serial/qcom_geni_serial.ko] undefined! ERROR: "geni_se_init" [drivers/tty/serial/qcom_geni_serial.ko] undefined! ERROR: "geni_se_config_packing"

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, 25 Apr 2018 22:57:12 +0200 "Rafael J. Wysocki" wrote: > FWIW, I run (64-bit) OpenSUSE 42.3 on the failing machine (Acer Aspire S5) > with > my own kernel (custom config based on the distro one). > > The problem here is that the machine doesn't resume from S2R. It

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wed, 25 Apr 2018 22:57:12 +0200 "Rafael J. Wysocki" wrote: > FWIW, I run (64-bit) OpenSUSE 42.3 on the failing machine (Acer Aspire S5) > with > my own kernel (custom config based on the distro one). > > The problem here is that the machine doesn't resume from S2R. It appears to > just

Re: [alsa-devel] [PATCH v2 1/4] ALSA: usb-audio: UAC3. Add support for mixer unit.

On Tue, Apr 24, 2018 at 8:24 PM, Jorge Sanjuan wrote: > This adds support for the MIXER UNIT in UAC3. All the information > is obtained from the (HIGH CAPABILITY) Cluster's header. We don't > read the rest of the logical cluster to obtain the channel config > as

Re: [alsa-devel] [PATCH v2 1/4] ALSA: usb-audio: UAC3. Add support for mixer unit.

On Tue, Apr 24, 2018 at 8:24 PM, Jorge Sanjuan wrote: > This adds support for the MIXER UNIT in UAC3. All the information > is obtained from the (HIGH CAPABILITY) Cluster's header. We don't > read the rest of the logical cluster to obtain the channel config > as that wont make any difference in

[PATCH 5/5] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been finding fair number of CM bugs. So provide option to disable it. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/infiniband/Kconfig | 5 - 1 file changed, 4

[PATCH 5/5] IB: make INFINIBAND_ADDR_TRANS configurable

Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been finding fair number of CM bugs. So provide option to disable it. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/infiniband/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS

CIFS_SMB_DIRECT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- fs/cifs/Kconfig

[PATCH 4/5] cifs: smbd: depend on INFINIBAND_ADDR_TRANS

CIFS_SMB_DIRECT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- fs/cifs/Kconfig | 2 +- 1 file changed, 1 insertion(+),

[PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir ---

[PATCH 3/5] ib_srpt: depend on INFINIBAND_ADDR_TRANS

INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/infiniband/ulp/srpt/Kconfig | 2 +- 1 file

[PATCH 2/5] nvmet-rdma: depend on INFINIBAND_ADDR_TRANS

NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir ---

[PATCH 2/5] nvmet-rdma: depend on INFINIBAND_ADDR_TRANS

NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/nvme/target/Kconfig | 2 +- 1 file changed, 1

[PATCH 1/5] nvme: depend on INFINIBAND_ADDR_TRANS

NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir ---

[PATCH 1/5] nvme: depend on INFINIBAND_ADDR_TRANS

NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir --- drivers/nvme/host/Kconfig | 2 +- 1 file changed, 1

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) wrote: > This patch adds the correct platform data information for the Caroline > Chromebook, so that the mouse button does not get stuck in pressed state > after the first click. > > The Samus button keymap and platform data

Re: [PATCH v2] input/touchscreen: atmel_mxt_ts: Add correct touchpad button mapping for the Caroline Chromebook.

On Wed, Apr 25, 2018 at 02:32:58PM +0200, Vittorio Gambaletta (VittGam) wrote: > This patch adds the correct platform data information for the Caroline > Chromebook, so that the mouse button does not get stuck in pressed state > after the first click. > > The Samus button keymap and platform data

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 2018-04-25 at 17:22 -0400, Mikulas Patocka wrote: > > On Wed, 25 Apr 2018, David Rientjes wrote: > > > On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > > > From: Mikulas Patocka > > > Subject: [PATCH] fault-injection: introduce kvmalloc fallback > > > options > >

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

On Wed, 2018-04-25 at 17:22 -0400, Mikulas Patocka wrote: > > On Wed, 25 Apr 2018, David Rientjes wrote: > > > On Wed, 25 Apr 2018, Mikulas Patocka wrote: > > > > > From: Mikulas Patocka > > > Subject: [PATCH] fault-injection: introduce kvmalloc fallback > > > options > > > > > > This patch

Re: [PATCH v6 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

On Thu, Apr 19, 2018 at 04:16:31PM -0600, Lina Iyer wrote: > Allow sleep and wake commands to be cleared from the respective TCSes, > so that they can be re-populated. > > Signed-off-by: Lina Iyer > --- > > Changes in v6: > - remove unnecessary locks around

Re: [PATCH v6 06/10] drivers: qcom: rpmh-rsc: allow invalidation of sleep/wake TCS

On Thu, Apr 19, 2018 at 04:16:31PM -0600, Lina Iyer wrote: > Allow sleep and wake commands to be cleared from the respective TCSes, > so that they can be re-populated. > > Signed-off-by: Lina Iyer > --- > > Changes in v6: > - remove unnecessary locks around __tcs_invalidate > -

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Mon, Mar 26, 2018 at 5:27 PM, Dave Hansen wrote: > > From: Dave Hansen > > I got a bug report that the following code (roughly) was > causing a SIGSEGV: > > mprotect(ptr, size, PROT_EXEC); > mprotect(ptr, size,

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Mon, Mar 26, 2018 at 5:27 PM, Dave Hansen wrote: > > From: Dave Hansen > > I got a bug report that the following code (roughly) was > causing a SIGSEGV: > > mprotect(ptr, size, PROT_EXEC); > mprotect(ptr, size, PROT_NONE); > mprotect(ptr, size, PROT_READ); >

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

On Thu, Apr 26, 2018 at 08:00:18AM +1000, NeilBrown wrote: > On Wed, Apr 25 2018, James Hogan wrote: > > So I'm thinking "!mips_cm_present()" should probably be replaced with > > "!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that > > IPI calls aren't implemented here). > >

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

On Thu, Apr 26, 2018 at 08:00:18AM +1000, NeilBrown wrote: > On Wed, Apr 25 2018, James Hogan wrote: > > So I'm thinking "!mips_cm_present()" should probably be replaced with > > "!r4k_op_needs_ipi(R4K_INDEX)" (and the comment updated to mention that > > IPI calls aren't implemented here). > >

Re: [PATCH] arm64: dts: qcom: Add SDM845 SMEM nodes

On Wed 25 Apr 07:46 PDT 2018, Sibi Sankar wrote: > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi > b/arch/arm64/boot/dts/qcom/sdm845.dtsi > index 9be763da0664..bea985045759 100644 > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > @@ -21,6 +21,27 @@ >

Re: [PATCH] arm64: dts: qcom: Add SDM845 SMEM nodes

On Wed 25 Apr 07:46 PDT 2018, Sibi Sankar wrote: > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi > b/arch/arm64/boot/dts/qcom/sdm845.dtsi > index 9be763da0664..bea985045759 100644 > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi > @@ -21,6 +21,27 @@ >

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Rob, On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote: > On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: > >> On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > >>> On Wednesday, 25 April 2018

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Rob, On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote: > On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: > >> On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > >>> On Wednesday, 25 April 2018

Re: [PATCH 2/2] mips: generic: allow not building DTB in

Hi, On 25/04/2018 23:16:07+0200, Alexandre Belloni wrote: > Allow not building any DTB in the generic kernel so it gets smaller. This > is necessary for ocelot because it can be built as a legacy platform that > needs a built-in DTB and it can also handle a separate DTB once it is > updated with

Re: [PATCH 2/2] mips: generic: allow not building DTB in

Hi, On 25/04/2018 23:16:07+0200, Alexandre Belloni wrote: > Allow not building any DTB in the generic kernel so it gets smaller. This > is necessary for ocelot because it can be built as a legacy platform that > needs a built-in DTB and it can also handle a separate DTB once it is > updated with

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

On Wed, Apr 25 2018, James Hogan wrote: > Hi NeilBrown, > > On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote: >> Cc: sta...@vger.kernel.org (v4.8) > > FYI my preferred form of this is: > > Cc: # 4.8+ Ugh. Cc: looks like an RFC822 header, and # does not

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

On Wed, Apr 25 2018, James Hogan wrote: > Hi NeilBrown, > > On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote: >> Cc: sta...@vger.kernel.org (v4.8) > > FYI my preferred form of this is: > > Cc: # 4.8+ Ugh. Cc: looks like an RFC822 header, and # does not introduce a comment in RFC822

linux-next: unable to fetch the kbuild-current tree

Hi Masahiro, Fetching the kbuild-current tree produces this error: fatal: Couldn't find remote ref refs/heads/fixes -- Cheers, Stephen Rothwell pgpSZ7qektEI2.pgp Description: OpenPGP digital signature

linux-next: unable to fetch the kbuild-current tree

Hi Masahiro, Fetching the kbuild-current tree produces this error: fatal: Couldn't find remote ref refs/heads/fixes -- Cheers, Stephen Rothwell pgpSZ7qektEI2.pgp Description: OpenPGP digital signature

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

Hi NeilBrown, On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote: > Cc: sta...@vger.kernel.org (v4.8) FYI my preferred form of this is: Cc: # 4.8+ > /* >* Either no secondary cache or the available caches don't have the >* subset property

Re: [PATCH] power: supply: ab8500_fg: fix spelling mistake: "Disharge" -> "Discharge"

Hi, On Wed, Mar 28, 2018 at 11:48:50PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_dbg message text > > Signed-off-by: Colin Ian King > --- Thanks, queued. -- Sebastian >

Re: [PATCH] MIPS: c-r4k: fix data corruption related to cache coherence.

Hi NeilBrown, On Wed, Apr 25, 2018 at 02:08:15PM +1000, NeilBrown wrote: > Cc: sta...@vger.kernel.org (v4.8) FYI my preferred form of this is: Cc: # 4.8+ > /* >* Either no secondary cache or the available caches don't have the >* subset property so we have to flush the

Re: [PATCH] power: supply: ab8500_fg: fix spelling mistake: "Disharge" -> "Discharge"

Hi, On Wed, Mar 28, 2018 at 11:48:50PM +0100, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in dev_dbg message text > > Signed-off-by: Colin Ian King > --- Thanks, queued. -- Sebastian > drivers/power/supply/ab8500_fg.c | 2 +- > 1 file changed, 1

Re: [PATCH V4 3/6] ARM: dts: imx6sx-sabreauto: add IO expander max7310 support

On Wed, Apr 25, 2018 at 2:36 AM, Anson Huang wrote: > + { > + clock-frequency = <10>; > + pinctrl-names = "default"; > + pinctrl-0 = <_i2c3_2>; > + status = "okay"; > + > + max7310_a: gpio@30 { > + compatible = "maxim,max7310";

Re: [PATCH V4 3/6] ARM: dts: imx6sx-sabreauto: add IO expander max7310 support

On Wed, Apr 25, 2018 at 2:36 AM, Anson Huang wrote: > + { > + clock-frequency = <10>; > + pinctrl-names = "default"; > + pinctrl-0 = <_i2c3_2>; > + status = "okay"; > + > + max7310_a: gpio@30 { > + compatible = "maxim,max7310"; > +

[PATCH v2 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. Since we can not lock the socket in tcp mmap() handler we have to split the operation in two phases. 1) mmap() on a tcp socket simply reserves VMA

[PATCH v2 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

After prior kernel change, mmap() on TCP socket only reserves VMA. We have to use setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) to perform the transfert of pages from skbs in TCP receive queue into such VMA. struct tcp_zerocopy_receive { __u64 address; /* in: address of

[PATCH v2 net-next 1/2] tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive

When adding tcp mmap() implementation, I forgot that socket lock had to be taken before current->mm->mmap_sem. syzbot eventually caught the bug. Since we can not lock the socket in tcp mmap() handler we have to split the operation in two phases. 1) mmap() on a tcp socket simply reserves VMA

[PATCH v2 net-next 2/2] selftests: net: tcp_mmap must use TCP_ZEROCOPY_RECEIVE

After prior kernel change, mmap() on TCP socket only reserves VMA. We have to use setsockopt(fd, IPPROTO_TCP, TCP_ZEROCOPY_RECEIVE, ...) to perform the transfert of pages from skbs in TCP receive queue into such VMA. struct tcp_zerocopy_receive { __u64 address; /* in: address of

[PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

syzbot reported a lockdep issue caused by tcp mmap() support. I implemented Andy Lutomirski nice suggestions to resolve the issue and increase scalability as well. First patch is adding a new setsockopt() operation and changes mmap() behavior. Second patch changes tcp_mmap reference program.

[PATCH v2 net-next 0/2] tcp: mmap: rework zerocopy receive

syzbot reported a lockdep issue caused by tcp mmap() support. I implemented Andy Lutomirski nice suggestions to resolve the issue and increase scalability as well. First patch is adding a new setsockopt() operation and changes mmap() behavior. Second patch changes tcp_mmap reference program.

Re: [PATCH 4.16 00/26] 4.16.5-stable review

On Wed, Apr 25, 2018 at 12:33:09PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.5 release. > There are 26 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

Re: [PATCH 4.16 00/26] 4.16.5-stable review

On Wed, Apr 25, 2018 at 12:33:09PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.5 release. > There are 26 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

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: > Sleep and wake requests are sent when the application processor > subsystem of the SoC is entering deep sleep states like in suspend. > These requests help lower the system power requirements when the > resources are not in use. > >

Re: [PATCH v6 05/10] drivers: qcom: rpmh-rsc: write sleep/wake requests to TCS

On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote: > Sleep and wake requests are sent when the application processor > subsystem of the SoC is entering deep sleep states like in suspend. > These requests help lower the system power requirements when the > resources are not in use. > >

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: > On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney > wrote: > [..] >>> > >>> > Sounds good, thanks. >>> > >>> > Also I found the reason for my boot issue. It was because the >>> >

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

- On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote: > On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney > wrote: > [..] >>> > >>> > Sounds good, thanks. >>> > >>> > Also I found the reason for my boot issue. It was because the >>> > init_srcu_struct in the prototype was

Re: [PATCH v1 1/3] ARM: dts: stm32: add cec support on stm32mp157c

Hi yannick, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v1 1/3] ARM: dts: stm32: add cec support on stm32mp157c

Hi yannick, Thank you for the patch! Yet something to improve: [auto build test ERROR on robh/for-next] [also build test ERROR on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 6/6] reset: Renesas RZ/N1 reboot driver

Hi, On Tue, Apr 17, 2018 at 12:04:21PM +0100, Michel Pollet wrote: > The Renesas RZ/N1 Family (Part #R9A06G0xx) needs a small driver > to reboot the Cortex-A7 cores. This driver is a sub driver of > the sysctrl MFD. > > Signed-off-by: Michel Pollet > --- >

Re: [PATCH v5 6/6] reset: Renesas RZ/N1 reboot driver

Hi, On Tue, Apr 17, 2018 at 12:04:21PM +0100, Michel Pollet wrote: > The Renesas RZ/N1 Family (Part #R9A06G0xx) needs a small driver > to reboot the Cortex-A7 cores. This driver is a sub driver of > the sysctrl MFD. > > Signed-off-by: Michel Pollet > --- > drivers/power/reset/Kconfig |

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 9:29:59 PM CEST Grygorii Strashko wrote: > > On 04/25/2018 02:10 PM, Grygorii Strashko wrote: > > > > > > On 04/25/2018 01:57 PM, Florian Fainelli wrote: > >> On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > >>> > >>> > >>> On 04/25/2018 01:29 PM, Florian Fainelli

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 9:29:59 PM CEST Grygorii Strashko wrote: > > On 04/25/2018 02:10 PM, Grygorii Strashko wrote: > > > > > > On 04/25/2018 01:57 PM, Florian Fainelli wrote: > >> On 04/25/2018 11:47 AM, Grygorii Strashko wrote: > >>> > >>> > >>> On 04/25/2018 01:29 PM, Florian Fainelli

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: >> > Coordinating the backport of a trivial helper in the arm tree is not >> > the end of the world. Really, this cowboy attitude is a good reason >> >

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: >> > Coordinating the backport of a trivial helper in the arm tree is not >> > the end of the world. Really, this cowboy attitude is a good reason >> > why graphics folks

linux-next: Signed-off-by missing for commit in the qcom tree

Hi Andy, Commit 6c3189330321 ("arm64: dts: qcom: Collapse usb support into one node") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell pgpostT32O0eQ.pgp Description: OpenPGP digital signature

linux-next: Signed-off-by missing for commit in the qcom tree

Hi Andy, Commit 6c3189330321 ("arm64: dts: qcom: Collapse usb support into one node") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell pgpostT32O0eQ.pgp Description: OpenPGP digital signature

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, Apr 25, 2018 at 02:27:08PM -0700, Joel Fernandes wrote: > On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney > wrote: > [..] > >> > > >> > Sounds good, thanks. > >> > > >> > Also I found the reason for my boot issue. It was because the > >> > init_srcu_struct in

Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can

On Wed, Apr 25, 2018 at 02:27:08PM -0700, Joel Fernandes wrote: > On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney > wrote: > [..] > >> > > >> > Sounds good, thanks. > >> > > >> > Also I found the reason for my boot issue. It was because the > >> > init_srcu_struct in the prototype was being

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 8:14:35 PM CEST Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > > wrote: > > > Hi Linus, Rafael, all > > > > > > Our GPIO controller driver:

Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers

On Wednesday, April 25, 2018 8:14:35 PM CEST Dmitry Torokhov wrote: > On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote: > > On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli > > wrote: > > > Hi Linus, Rafael, all > > > > > > Our GPIO controller driver: gpio-brcmstb.c has a shutdown

[PATCH v2] selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Script in_netns.sh is a utility function and not its own test so it shouldn't be part of the TEST_PROGS. The in_netns.sh get used by run_afpackettests. To install in_netns.sh without being added to the main run_kselftest.sh script use the TEST_GEN_PROGS_EXTENDED variable. Fixes: 5ff9c1a3dd92

[PATCH v2] selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Script in_netns.sh is a utility function and not its own test so it shouldn't be part of the TEST_PROGS. The in_netns.sh get used by run_afpackettests. To install in_netns.sh without being added to the main run_kselftest.sh script use the TEST_GEN_PROGS_EXTENDED variable. Fixes: 5ff9c1a3dd92

[PATCH] [RESEND] [media] omap3isp: support 64-bit version of omap3isp_stat_data

C libraries with 64-bit time_t use an incompatible format for struct omap3isp_stat_data. This changes the kernel code to support either version, by moving over the normal handling to the 64-bit variant, and adding compatiblity code to handle the old binary format with the existing ioctl command

[PATCH] [RESEND] [media] omap3isp: support 64-bit version of omap3isp_stat_data

C libraries with 64-bit time_t use an incompatible format for struct omap3isp_stat_data. This changes the kernel code to support either version, by moving over the normal handling to the 64-bit variant, and adding compatiblity code to handle the old binary format with the existing ioctl command

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wednesday, April 25, 2018 9:09:29 PM CEST Thomas Gleixner wrote: > On Wed, 25 Apr 2018, Linus Torvalds wrote: > > On Wed, Apr 25, 2018 at 6:45 AM, tip-bot for Thomas Gleixner > > wrote: > > > > > > As stated in the pull request for the unification of CLOCK_MONOTONIC and > > >

Re: [tip:timers/urgent] Revert: Unify CLOCK_MONOTONIC and CLOCK_BOOTTIME

On Wednesday, April 25, 2018 9:09:29 PM CEST Thomas Gleixner wrote: > On Wed, 25 Apr 2018, Linus Torvalds wrote: > > On Wed, Apr 25, 2018 at 6:45 AM, tip-bot for Thomas Gleixner > > wrote: > > > > > > As stated in the pull request for the unification of CLOCK_MONOTONIC and > > > CLOCK_BOOTTIME,

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