[PATCH v7 5/9] arm64: dts: actions: Add S900 gpio nodes

Add gpio nodes for Actions Semi S900 SoC. Signed-off-by: Manivannan Sadhasivam --- arch/arm64/boot/dts/actions/s900.dtsi | 51 +++ 1 file changed, 51 insertions(+) diff --git a/arch/arm64/boot/dts/actions/s900.dtsi

[PATCH v7 5/9] arm64: dts: actions: Add S900 gpio nodes

Add gpio nodes for Actions Semi S900 SoC. Signed-off-by: Manivannan Sadhasivam --- arch/arm64/boot/dts/actions/s900.dtsi | 51 +++ 1 file changed, 51 insertions(+) diff --git a/arch/arm64/boot/dts/actions/s900.dtsi b/arch/arm64/boot/dts/actions/s900.dtsi index

[PATCH v7 9/9] MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries

Add S900 pinctrl and gpio entries under ARCH_ACTIONS Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 640dabc4c311..d63793ee545e 100644 --- a/MAINTAINERS +++

[PATCH v7 9/9] MAINTAINERS: Add Actions Semi S900 pinctrl and gpio entries

Add S900 pinctrl and gpio entries under ARCH_ACTIONS Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 4 1 file changed, 4 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 640dabc4c311..d63793ee545e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1125,10 +1125,14 @@ F:

[PATCH v7 6/9] arm64: dts: actions: Add gpio line names to Bubblegum-96 board

Add gpio line names to Actions Semi S900 based Bubblegum-96 board. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 195 ++ 1 file changed, 195

[PATCH v7 7/9] gpio: Add gpio driver for Actions OWL S900 SoC

Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers controlling the gpio shares the same register range with pinctrl block. GPIO registers are organized as 6 banks and each bank controls the maximum of 32 gpios. Signed-off-by: Manivannan Sadhasivam

[PATCH v7 6/9] arm64: dts: actions: Add gpio line names to Bubblegum-96 board

Add gpio line names to Actions Semi S900 based Bubblegum-96 board. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 195 ++ 1 file changed, 195 insertions(+) diff --git

[PATCH v7 7/9] gpio: Add gpio driver for Actions OWL S900 SoC

Add gpio driver for Actions Semi OWL family S900 SoC. Set of registers controlling the gpio shares the same register range with pinctrl block. GPIO registers are organized as 6 banks and each bank controls the maximum of 32 gpios. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Andy

[PATCH v7 8/9] MAINTAINERS: Add reviewer for ACTIONS platforms

Since I'll be working on improving support for ACTIONS platforms, adding myself as the reviewer. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a7f76eadae9..640dabc4c311

[PATCH v7 8/9] MAINTAINERS: Add reviewer for ACTIONS platforms

Since I'll be working on improving support for ACTIONS platforms, adding myself as the reviewer. Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a7f76eadae9..640dabc4c311 100644 --- a/MAINTAINERS +++

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On 04/03/2018 02:12 PM, Alison Schofield wrote: > + > + /* > + * topology_sane() considers LLCs that span NUMA nodes to be > + * insane and will display a warning message. Bypass the call > + * to topology_sane() for snc_cpu's to avoid that warning. > + */ > + > + if

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On 04/03/2018 02:12 PM, Alison Schofield wrote: > + > + /* > + * topology_sane() considers LLCs that span NUMA nodes to be > + * insane and will display a warning message. Bypass the call > + * to topology_sane() for snc_cpu's to avoid that warning. > + */ > + > + if

[PATCH v7 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Add pinctrl driver for Actions Semi S900 SoC. The driver supports pinctrl, pinmux and pinconf functionalities through a range of registers common to both gpio driver and pinctrl driver. Pinmux functionality is available only for the pin groups while the pinconf functionality is available for both

[PATCH v7 3/9] pinctrl: actions: Add Actions S900 pinctrl driver

Add pinctrl driver for Actions Semi S900 SoC. The driver supports pinctrl, pinmux and pinconf functionalities through a range of registers common to both gpio driver and pinctrl driver. Pinmux functionality is available only for the pin groups while the pinconf functionality is available for both

[PATCH v7 4/9] dt-bindings: gpio: Add gpio nodes for Actions S900 SoC

Add gpio nodes for Actions Semi S900 SoC. Signed-off-by: Manivannan Sadhasivam --- .../devicetree/bindings/gpio/actions,owl-gpio.txt | 87 ++ 1 file changed, 87 insertions(+) create mode 100644

[PATCH v7 4/9] dt-bindings: gpio: Add gpio nodes for Actions S900 SoC

Add gpio nodes for Actions Semi S900 SoC. Signed-off-by: Manivannan Sadhasivam --- .../devicetree/bindings/gpio/actions,owl-gpio.txt | 87 ++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/actions,owl-gpio.txt diff --git

[PATCH v7 2/9] arm64: actions: Enable PINCTRL in platforms Kconfig

Select PINCTRL for Actions Semi SoCs Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms

[PATCH v7 2/9] arm64: actions: Enable PINCTRL in platforms Kconfig

Select PINCTRL for Actions Semi SoCs Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index fbedbd8f619a..bae1289bdc3f 100644 ---

[PATCH v7 1/9] arm64: dts: actions: Add pinctrl node for S900

Add pinctrl nodes for Actions Semi S900 SoC Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/boot/dts/actions/s900.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH v7 1/9] arm64: dts: actions: Add pinctrl node for S900

Add pinctrl nodes for Actions Semi S900 SoC Signed-off-by: Manivannan Sadhasivam Reviewed-by: Linus Walleij --- arch/arm64/boot/dts/actions/s900.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/actions/s900.dtsi b/arch/arm64/boot/dts/actions/s900.dtsi index

[PATCH v7 0/9] Add Actions Semi S900 pinctrl and gpio support

This patchset adds pinctrl and gpio support for Actions Semi S900 SoC. Pinctrl and gpio subsystems share the common set of register range but implemented as individual drivers for making it less complex. Pinmux functions are only accessible for pin groups while pinconf parameters are available

[PATCH v7 0/9] Add Actions Semi S900 pinctrl and gpio support

This patchset adds pinctrl and gpio support for Actions Semi S900 SoC. Pinctrl and gpio subsystems share the common set of register range but implemented as individual drivers for making it less complex. Pinmux functions are only accessible for pin groups while pinconf parameters are available

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

On 04/04/2018 10:48 PM, Mark Rutland wrote: > On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: >> Hi Mark, >> >> On 04/04/2018 10:04 PM, Mark Rutland wrote: >>> >>> Zhijian, Sandipan, does this patch work for you? >>> >> >> Yes it does. Thanks for the fix. > > Great! Can I take

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

On 04/04/2018 10:48 PM, Mark Rutland wrote: > On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: >> Hi Mark, >> >> On 04/04/2018 10:04 PM, Mark Rutland wrote: >>> >>> Zhijian, Sandipan, does this patch work for you? >>> >> >> Yes it does. Thanks for the fix. > > Great! Can I take

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote: > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote: > > > I asked Peter Jones for suggestions how to extract this during boot and > > > he suggested

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: > Hi Mark, > > On 04/04/2018 10:04 PM, Mark Rutland wrote: > > > > Zhijian, Sandipan, does this patch work for you? > > > > Yes it does. Thanks for the fix. Great! Can I take that as a Tested-by? Thanks, Mark.

Re: [PATCH 2/2] efi: Add embedded peripheral firmware support

On Tue, Apr 03, 2018 at 06:58:48PM +, Luis R. Rodriguez wrote: > On Tue, Apr 03, 2018 at 08:07:11PM +0200, Lukas Wunner wrote: > > On Tue, Apr 03, 2018 at 10:33:25AM +0200, Hans de Goede wrote: > > > I asked Peter Jones for suggestions how to extract this during boot and > > > he suggested

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

On Wed, Apr 04, 2018 at 10:43:16PM +0530, Sandipan Das wrote: > Hi Mark, > > On 04/04/2018 10:04 PM, Mark Rutland wrote: > > > > Zhijian, Sandipan, does this patch work for you? > > > > Yes it does. Thanks for the fix. Great! Can I take that as a Tested-by? Thanks, Mark.

Re: [PATCH] lockdep: Do not record irq state in debug_check_no_locks_freed()

On Wed, 4 Apr 2018 18:23:05 +0200 Peter Zijlstra wrote: > > Makes sense, could you convert all of them just to make sure there > aren't any left? There's a few others. I'll send another patch. -- Steve

Re: [PATCH] lockdep: Do not record irq state in debug_check_no_locks_freed()

On Wed, 4 Apr 2018 18:23:05 +0200 Peter Zijlstra wrote: > > Makes sense, could you convert all of them just to make sure there > aren't any left? There's a few others. I'll send another patch. -- Steve

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

Hi Mark, On 04/04/2018 10:04 PM, Mark Rutland wrote: > > Zhijian, Sandipan, does this patch work for you? > Yes it does. Thanks for the fix. - Sandipan

Re: [PATCH] tools: restore READ_ONCE() C++ compatibility

Hi Mark, On 04/04/2018 10:04 PM, Mark Rutland wrote: > > Zhijian, Sandipan, does this patch work for you? > Yes it does. Thanks for the fix. - Sandipan

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use "-fno-delete-null-pointer-checks" because we do *not*

Re: [PATCH v2] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 11:34:55 +0900 Sergey Senozhatsky wrote: > On (04/03/18 18:03), Steven Rostedt wrote: > > > > > he'd want you to change all the trace_printk()s to %px with > > > justifications, though. > > > > What trace_printk()s do you want to

Re: [PATCH v2] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 11:34:55 +0900 Sergey Senozhatsky wrote: > On (04/03/18 18:03), Steven Rostedt wrote: > > > > > he'd want you to change all the trace_printk()s to %px with > > > justifications, though. > > > > What trace_printk()s do you want to change? They are throw away > >

Re: [PATCH v5 1/2] KVM: X86: Introduce handle_ud()

On 04/04/2018 13:54, David Hildenbrand wrote: >> +{ >> +enum emulation_result er; >> + >> +er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD); >> +if (er == EMULATE_USER_EXIT) >> +return 0; >> +if (er != EMULATE_DONE) >> +kvm_queue_exception(vcpu, UD_VECTOR);

Re: [PATCH v5 1/2] KVM: X86: Introduce handle_ud()

On 04/04/2018 13:54, David Hildenbrand wrote: >> +{ >> +enum emulation_result er; >> + >> +er = emulate_instruction(vcpu, EMULTYPE_TRAP_UD); >> +if (er == EMULATE_USER_EXIT) >> +return 0; >> +if (er != EMULATE_DONE) >> +kvm_queue_exception(vcpu, UD_VECTOR);

Re: [PATCH] ARM: omap2: fix am43xx build without L2X0

* Arnd Bergmann [180404 10:27]: > When CONFIG_CACHE_L2X0 is disabled, the am43xx specific suspend > implemnentation fails to link: > > arch/arm/mach-omap2/sleep43xx.o: In function `get_l2cache_base': > (.text+0x180): undefined reference to `omap4_get_l2cache_base' > > This adds

Re: [PATCH] ARM: omap2: fix am43xx build without L2X0

* Arnd Bergmann [180404 10:27]: > When CONFIG_CACHE_L2X0 is disabled, the am43xx specific suspend > implemnentation fails to link: > > arch/arm/mach-omap2/sleep43xx.o: In function `get_l2cache_base': > (.text+0x180): undefined reference to `omap4_get_l2cache_base' > > This adds an #ifdef

Re: [PATCH] kvm: x86 : fix a compile warning

On 02/04/2018 03:15, Peng Hao wrote: > fix a "warning: no previous prototype". > > Signed-off-by: Peng Hao > --- > arch/x86/kvm/x86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 18b5ca7..6621319

Re: [PATCH] kvm: x86 : fix a compile warning

On 02/04/2018 03:15, Peng Hao wrote: > fix a "warning: no previous prototype". > > Signed-off-by: Peng Hao > --- > arch/x86/kvm/x86.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 18b5ca7..6621319 100644 > ---

Re: [PATCH] kvm: Add emulation for movups/movupd

On Wed, Apr 04, 2018 at 05:53:04PM +0200, Paolo Bonzini wrote: > On 01/04/2018 17:54, Stefan Fritsch wrote: > > This is very similar to the aligned versions movaps/movapd. ..snip.. > Applied, thanks. Should there be a corresponding test-case? > > Paolo

Re: [PATCH] kvm: Add emulation for movups/movupd

On Wed, Apr 04, 2018 at 05:53:04PM +0200, Paolo Bonzini wrote: > On 01/04/2018 17:54, Stefan Fritsch wrote: > > This is very similar to the aligned versions movaps/movapd. ..snip.. > Applied, thanks. Should there be a corresponding test-case? > > Paolo

Re: [PATCH v5 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

On 04/04/2018 15:35, Wanpeng Li wrote: > 2018-04-04 19:59 GMT+08:00 David Hildenbrand : >> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 1eb495e..a55ecef 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -146,6 +146,9 @@ bool

Re: [PATCH v5 2/2] KVM: X86: Add Force Emulation Prefix for "emulate the next instruction"

On 04/04/2018 15:35, Wanpeng Li wrote: > 2018-04-04 19:59 GMT+08:00 David Hildenbrand : >> >>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >>> index 1eb495e..a55ecef 100644 >>> --- a/arch/x86/kvm/x86.c >>> +++ b/arch/x86/kvm/x86.c >>> @@ -146,6 +146,9 @@ bool __read_mostly

Re: [GIT PULL] libata changes for v4.17-rc1

On Tue, Apr 03, 2018 at 05:59:04PM -0700, Linus Torvalds wrote: > People hotplug ATA _controllers_? :-O > > As opposed to just the disks a'la eSATA? Heh, yeah, it's surprising. IIUC, it's people trying pcie hotplug (I don't know whether they try physically) on SAS controllers on fancy

Re: [GIT PULL] libata changes for v4.17-rc1

On Tue, Apr 03, 2018 at 05:59:04PM -0700, Linus Torvalds wrote: > People hotplug ATA _controllers_? :-O > > As opposed to just the disks a'la eSATA? Heh, yeah, it's surprising. IIUC, it's people trying pcie hotplug (I don't know whether they try physically) on SAS controllers on fancy

Re: [RFC] mm: memory.low heirarchical behavior

On Wed, Mar 21, 2018 at 07:08:06PM +, Roman Gushchin wrote: > > On Tue, Mar 20, 2018 at 10:33:53PM +, Roman Gushchin wrote: > > > This patch aims to address an issue in current memory.low semantics, > > > which makes it hard to use it in a hierarchy, where some leaf memory > > > cgroups

Re: [RFC] mm: memory.low heirarchical behavior

On Wed, Mar 21, 2018 at 07:08:06PM +, Roman Gushchin wrote: > > On Tue, Mar 20, 2018 at 10:33:53PM +, Roman Gushchin wrote: > > > This patch aims to address an issue in current memory.low semantics, > > > which makes it hard to use it in a hierarchy, where some leaf memory > > > cgroups

Re: [PATCH] HID: input: fix battery level reporting on BT mice

On Wed, Apr 4, 2018 at 1:51 AM, Martin van Es wrote: > > On Wednesday, April 4, 2018 10:33:16 AM CEST Jiri Kosina wrote: > > Can I add your Tested-by: while applying the commit? > > That's ok. Martin is also the reporter of the issue, I did not put down his name because I

Re: [PATCH] HID: input: fix battery level reporting on BT mice

On Wed, Apr 4, 2018 at 1:51 AM, Martin van Es wrote: > > On Wednesday, April 4, 2018 10:33:16 AM CEST Jiri Kosina wrote: > > Can I add your Tested-by: while applying the commit? > > That's ok. Martin is also the reporter of the issue, I did not put down his name because I wasn't sure if he

Re: [PATCH 2/3] adp5061: Add support for battery charging enable

Hi Stefan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16 next-20180404] [cannot apply to battery/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH 2/3] adp5061: Add support for battery charging enable

Hi Stefan, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16 next-20180404] [cannot apply to battery/master] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH] x86: kvm: hide the unused 'cpu' variable

On 04/04/2018 13:51, David Hildenbrand wrote: > On 04.04.2018 12:44, Arnd Bergmann wrote: >> The local variable was newly introduced but is only accessed in one >> place on x86_64, but not on 32-bit: >> >> arch/x86/kvm/vmx.c: In function 'vmx_save_host_state': >> arch/x86/kvm/vmx.c:2175:6: error:

Re: [PATCH] x86: kvm: hide the unused 'cpu' variable

On 04/04/2018 13:51, David Hildenbrand wrote: > On 04.04.2018 12:44, Arnd Bergmann wrote: >> The local variable was newly introduced but is only accessed in one >> place on x86_64, but not on 32-bit: >> >> arch/x86/kvm/vmx.c: In function 'vmx_save_host_state': >> arch/x86/kvm/vmx.c:2175:6: error:

[PATCH] KVM: vmx: unify adjacent #ifdefs

vmx_save_host_state has multiple ifdefs for CONFIG_X86_64 that have no other code between them. Simplify by reducing them to a single conditional. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff

[PATCH] KVM: vmx: unify adjacent #ifdefs

vmx_save_host_state has multiple ifdefs for CONFIG_X86_64 that have no other code between them. Simplify by reducing them to a single conditional. Signed-off-by: Paolo Bonzini --- arch/x86/kvm/vmx.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL checks being deleted from the > >

Re: [PATCH 1/3] mm: memcontrol: Use cgroup_rstat for event accounting

Hello, On Wed, Apr 04, 2018 at 04:34:47PM +0200, Michal Hocko wrote: > > > The lazy updates are neat, but I'm a little concerned at the memory > > > footprint. On a 64-cpu machine for example, this adds close to 9000 > > > words to struct mem_cgroup. And we really only need the accuracy for > > >

Re: [PATCH 1/3] mm: memcontrol: Use cgroup_rstat for event accounting

Hello, On Wed, Apr 04, 2018 at 04:34:47PM +0200, Michal Hocko wrote: > > > The lazy updates are neat, but I'm a little concerned at the memory > > > footprint. On a 64-cpu machine for example, this adds close to 9000 > > > words to struct mem_cgroup. And we really only need the accuracy for > > >

Re: [v3,4/4] watchdog: add Gateworks System Controller support

On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn wrote: >> The 'use case' we have been using this in for a couple years is that >> users who want to use this watchdog will enable it externally (we have >> a command in the bootloader) and if enabled the kernel driver (that >> I'm

Re: [v3,4/4] watchdog: add Gateworks System Controller support

On Mon, Apr 2, 2018 at 9:32 AM, Andrew Lunn wrote: >> The 'use case' we have been using this in for a couple years is that >> users who want to use this watchdog will enable it externally (we have >> a command in the bootloader) and if enabled the kernel driver (that >> I'm proposing here which

Re: [PATCH] netdevsim: remove incorrect __net_initdata annotations

From: Arnd Bergmann Date: Wed, 4 Apr 2018 18:03:41 +0200 > On Wed, Apr 4, 2018 at 5:52 PM, David Miller wrote: >> From: Arnd Bergmann >> Date: Wed, 4 Apr 2018 14:12:39 +0200 >> >>> The __net_initdata section cannot currently be used for

Re: [PATCH] netdevsim: remove incorrect __net_initdata annotations

From: Arnd Bergmann Date: Wed, 4 Apr 2018 18:03:41 +0200 > On Wed, Apr 4, 2018 at 5:52 PM, David Miller wrote: >> From: Arnd Bergmann >> Date: Wed, 4 Apr 2018 14:12:39 +0200 >> >>> The __net_initdata section cannot currently be used for structures that >>> get cleaned up in an exitcall using

Re: [RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

Hi Alex, On 04/04/18 16:33, Alex G. wrote: > On 04/04/2018 02:18 AM, James Morse wrote: >> On 03/04/18 18:08, Alexandru Gagniuc wrote: >>> BIOSes like to send NMIs for a number of silly reasons often deemed >>> to be "fatal". For example pin bounce during a PCIE hotplug/unplug >>> might cause the

Re: [RFC PATCH 3/4] acpi: apei: Do not panic() in NMI because of GHES messages

Hi Alex, On 04/04/18 16:33, Alex G. wrote: > On 04/04/2018 02:18 AM, James Morse wrote: >> On 03/04/18 18:08, Alexandru Gagniuc wrote: >>> BIOSes like to send NMIs for a number of silly reasons often deemed >>> to be "fatal". For example pin bounce during a PCIE hotplug/unplug >>> might cause the

Re: [GIT PULL] x86/build changes for v4.17

(re-sending as plain text) On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > There are known-bugs with building a kernel with clang right now (I > pointed one out a few days ago about NULL checks being deleted from the > clang output for no good reason, which really is

Re: [GIT PULL] x86/build changes for v4.17

(re-sending as plain text) On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > There are known-bugs with building a kernel with clang right now (I > pointed one out a few days ago about NULL checks being deleted from the > clang output for no good reason, which really is scary for obvious >

Re: INFO: rcu detected stall in bitmap_parselist

On Thu, Apr 05, 2018 at 12:58:46AM +0900, Tetsuo Handa wrote: > Yury Norov wrote: > > Hi Tetsuo, > > > > Thanks for the patch. > > > > On Wed, Apr 04, 2018 at 09:21:43PM +0900, Tetsuo Handa wrote: > > > Yury, are you OK with this patch? > > > > > > > > > >From

Re: INFO: rcu detected stall in bitmap_parselist

On Thu, Apr 05, 2018 at 12:58:46AM +0900, Tetsuo Handa wrote: > Yury Norov wrote: > > Hi Tetsuo, > > > > Thanks for the patch. > > > > On Wed, Apr 04, 2018 at 09:21:43PM +0900, Tetsuo Handa wrote: > > > Yury, are you OK with this patch? > > > > > > > > > >From

Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

On Wed, Apr 04, 2018 at 09:38:56AM -0700, Luck, Tony wrote: > On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote: > > Right, I remember being careful with that. Which again brings me to the > > RANDSTRUCT thing, which will mess that up. > > No RANDSTRUCT config options set for my

Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

On Wed, Apr 04, 2018 at 09:38:56AM -0700, Luck, Tony wrote: > On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote: > > Right, I remember being careful with that. Which again brings me to the > > RANDSTRUCT thing, which will mess that up. > > No RANDSTRUCT config options set for my

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:27:10 -0700 Kees Cook wrote: > On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > >> If you are concerned about attack surface, I could make it a bit

Re: [RFC][PATCH] tracing, printk: Force no hashing when trace_printk() is used

On Wed, 4 Apr 2018 09:27:10 -0700 Kees Cook wrote: > On Wed, Apr 4, 2018 at 12:49 AM, Peter Zijlstra wrote: > > On Tue, Apr 03, 2018 at 05:06:12PM -0400, Steven Rostedt wrote: > >> If you are concerned about attack surface, I could make it a bit more > >> difficult to tweak by malicious

Re: [PATCH 2/4] nvmet-rdma: Use new SGL alloc/free helper for requests

On 4/4/2018 6:43 AM, Sagi Grimberg wrote: IIRC, this might result in nvmet-rdma executing data-transfer even for failed requests in some error cases. I'm not sure this is the only case, but have you tested what happens in error cases? That's why I set transfer_len to zero when we exit this

Re: [PATCH 2/4] nvmet-rdma: Use new SGL alloc/free helper for requests

On 4/4/2018 6:43 AM, Sagi Grimberg wrote: IIRC, this might result in nvmet-rdma executing data-transfer even for failed requests in some error cases. I'm not sure this is the only case, but have you tested what happens in error cases? That's why I set transfer_len to zero when we exit this

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>>

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>> > Theodore Y. Ts'o wrote: >>> > >>> > > Whoa.

[GIT PULL] RISC-V changes for 4.17

The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.17-mw0 for you to fetch changes up to

[GIT PULL] RISC-V changes for 4.17

The following changes since commit 0adb32858b0bddf4ada5f364a84ed60b196dbcda: Linux 4.16 (2018-04-01 14:20:27 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.17-mw0 for you to fetch changes up to

Re: [PATCH] w1: gpio: fix problem with platfom data in w1-gpio

2018-03-29 12:01 GMT+02:00 Greg Kroah-Hartman : > On Thu, Mar 29, 2018 at 11:47:25AM +0200, Paweł Dembicki wrote: >> 2018-03-17 12:55 GMT+01:00 Greg Kroah-Hartman : >> >> > Where is this patch supposed to go? Is this a stable backport patch,

Re: [PATCH] w1: gpio: fix problem with platfom data in w1-gpio

2018-03-29 12:01 GMT+02:00 Greg Kroah-Hartman : > On Thu, Mar 29, 2018 at 11:47:25AM +0200, Paweł Dembicki wrote: >> 2018-03-17 12:55 GMT+01:00 Greg Kroah-Hartman : >> >> > Where is this patch supposed to go? Is this a stable backport patch, or >> > something to go into Linus's tree? >> >> I

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > This has been rebutted over

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Wed, Apr 04, 2018 at 09:15:39AM -0700, Davidlohr Bueso wrote: > On Mon, 02 Apr 2018, Davidlohr Bueso wrote: > > > The case for the rt task throttling (which this workload also hits) can be > > ignored in > > that the skip_update call is actually bogus and quite the contrary (the > > request

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: > >> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >> > Theodore Y. Ts'o wrote: >> > >> > > Whoa. Why doesn't

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Wed, Apr 04, 2018 at 09:15:39AM -0700, Davidlohr Bueso wrote: > On Mon, 02 Apr 2018, Davidlohr Bueso wrote: > > > The case for the rt task throttling (which this workload also hits) can be > > ignored in > > that the skip_update call is actually bogus and quite the contrary (the > > request

Re: [GIT PULL] Kernel lockdown for secure boot

On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett wrote: > On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o wrote: > >> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >> > Theodore Y. Ts'o wrote: >> > >> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why >> > >

Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote: > Right, I remember being careful with that. Which again brings me to the > RANDSTRUCT thing, which will mess that up. No RANDSTRUCT config options set for my build. > Does the below cure things? It makes absolutely no difference

Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on IA64

On Wed, Apr 04, 2018 at 09:25:13AM +0200, Peter Zijlstra wrote: > Right, I remember being careful with that. Which again brings me to the > RANDSTRUCT thing, which will mess that up. No RANDSTRUCT config options set for my build. > Does the below cure things? It makes absolutely no difference

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Wed, Apr 4, 2018 at 9:17 AM, David Howells wrote: > Andy Lutomirski wrote: > >> Since this thread has devolved horribly, I'm going to propose a solution. >> >> 1. Split the "lockdown" state into three levels: (please don't >> bikeshed about the names

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

On Wed, Apr 4, 2018 at 9:17 AM, David Howells wrote: > Andy Lutomirski wrote: > >> Since this thread has devolved horribly, I'm going to propose a solution. >> >> 1. Split the "lockdown" state into three levels: (please don't >> bikeshed about the names right now.) >> >> LOCKDOWN_NONE: normal

[PATCH] tools: restore READ_ONCE() C++ compatibility

Our userspace defines READ_ONCE() in a way that clang doesn't like, as we have an anonymous union in which neither field is initialized. WRITE_ONCE() is fine since it initializes the __val field. For READ_ONCE() we can keep clang and GCC happy with a dummy initialization of the __c field, so

[PATCH] tools: restore READ_ONCE() C++ compatibility

Our userspace defines READ_ONCE() in a way that clang doesn't like, as we have an anonymous union in which neither field is initialized. WRITE_ONCE() is fine since it initializes the __val field. For READ_ONCE() we can keep clang and GCC happy with a dummy initialization of the __c field, so

Re: [PATCH v2] tools: fix cross-compile var clobbering

On 04/04/2018 06:20 AM, Jiri Slaby wrote: On 01/07/2018, 10:40 PM, Martin Kelly wrote: From: Martin Kelly ... --- a/tools/power/acpi/Makefile.config +++ b/tools/power/acpi/Makefile.config @@ -56,9 +56,6 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM} # to compile vs uClibc,

Re: [PATCH v2] tools: fix cross-compile var clobbering

On 04/04/2018 06:20 AM, Jiri Slaby wrote: On 01/07/2018, 10:40 PM, Martin Kelly wrote: From: Martin Kelly ... --- a/tools/power/acpi/Makefile.config +++ b/tools/power/acpi/Makefile.config @@ -56,9 +56,6 @@ INSTALL_SCRIPT = ${INSTALL_PROGRAM} # to compile vs uClibc, that can be done here as

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Mon, 02 Apr 2018, Davidlohr Bueso wrote: The case for the rt task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted). While at it, how about this trivial patch?

Re: [PATCH] sched/rt: Fix rq->clock_update_flags < RQCF_ACT_SKIP warning

On Mon, 02 Apr 2018, Davidlohr Bueso wrote: The case for the rt task throttling (which this workload also hits) can be ignored in that the skip_update call is actually bogus and quite the contrary (the request bits are removed/reverted). While at it, how about this trivial patch?

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