Re: [locking] 892ad5acca [ 12.849409] WARNING: bad unlock balance detected!

On Mon, Oct 09, 2017 at 04:24:25PM -0700, Linus Torvalds wrote: > On Mon, Oct 9, 2017 at 8:55 AM, Fengguang Wu wrote: > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > This makes no sense. > > > [ 12.849409] WARNING: bad unlock

Re: [locking] 892ad5acca [ 12.849409] WARNING: bad unlock balance detected!

On Mon, Oct 09, 2017 at 04:24:25PM -0700, Linus Torvalds wrote: > On Mon, Oct 9, 2017 at 8:55 AM, Fengguang Wu wrote: > > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > This makes no sense. > > > [ 12.849409] WARNING: bad unlock balance detected! > > [

Re: [PATCH v9 10/29] x86/insn-eval: Do not BUG on invalid register type

On Sat, 2017-10-07 at 18:22 +0200, Borislav Petkov wrote: > Reviewed-by: Borislav Petkov Thank you! BR, Ricardo

Re: [PATCH v9 10/29] x86/insn-eval: Do not BUG on invalid register type

On Sat, 2017-10-07 at 18:22 +0200, Borislav Petkov wrote: > Reviewed-by: Borislav Petkov Thank you! BR, Ricardo

Re: [PATCH] KVM: remove printing of token address

On Mon, Oct 09, 2017 at 12:58:12PM +0200, Paolo Bonzini wrote: > On 09/10/2017 12:04, Tobin C. Harding wrote: > > On Mon, Oct 09, 2017 at 03:49:38AM -0400, Paolo Bonzini wrote: > >> > >> > >> - Original Message - > >>> From: "Tobin C. Harding" > >>> To: "Paolo Bonzini"

Re: [PATCH] KVM: remove printing of token address

On Mon, Oct 09, 2017 at 12:58:12PM +0200, Paolo Bonzini wrote: > On 09/10/2017 12:04, Tobin C. Harding wrote: > > On Mon, Oct 09, 2017 at 03:49:38AM -0400, Paolo Bonzini wrote: > >> > >> > >> - Original Message - > >>> From: "Tobin C. Harding" > >>> To: "Paolo Bonzini" ,

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

I confirm this works properly now. This was tested with GStreamer with the following command: gst-launch-1.0 videotestsrc ! v4l2vp8enc ! v4l2vp8dec ! kmssink And the following patch, which is work in progress to implement data_offset.

Re: [PATCH 2/2] media: venus: venc: fix bytesused v4l2_plane field

I confirm this works properly now. This was tested with GStreamer with the following command: gst-launch-1.0 videotestsrc ! v4l2vp8enc ! v4l2vp8dec ! kmssink And the following patch, which is work in progress to implement data_offset.

Re: [PATCH 3/6] ARM: sun8i: r40: add 5V regulator for Banana Pi M2 Ultra

于 2017年10月10日 GMT+08:00 上午5:04:07, Maxime Ripard 写到: >On Sun, Oct 08, 2017 at 04:29:03AM +, Icenowy Zheng wrote: >> On newer revisions of the Banana Pi M2 Ultra boards, the 5V power >output >> (used by HDMI, SATA and USB) is controller via a GPIO. >> >>

Re: [PATCH 3/6] ARM: sun8i: r40: add 5V regulator for Banana Pi M2 Ultra

于 2017年10月10日 GMT+08:00 上午5:04:07, Maxime Ripard 写到: >On Sun, Oct 08, 2017 at 04:29:03AM +, Icenowy Zheng wrote: >> On newer revisions of the Banana Pi M2 Ultra boards, the 5V power >output >> (used by HDMI, SATA and USB) is controller via a GPIO. >> >> Add the regulator node for it. >>

Re: [PATCH 2/6] ARM: sun8i: r40: add USB host port nodes for R40

于 2017年10月10日 GMT+08:00 上午5:03:40, Maxime Ripard 写到: >On Sun, Oct 08, 2017 at 04:29:02AM +, Icenowy Zheng wrote: >> From: Icenowy Zheng >> >> Allwinner R40 SoC features a USB OTG port and two USB HOST ports. >> >> Add support for the

Re: [PATCH 2/6] ARM: sun8i: r40: add USB host port nodes for R40

于 2017年10月10日 GMT+08:00 上午5:03:40, Maxime Ripard 写到: >On Sun, Oct 08, 2017 at 04:29:02AM +, Icenowy Zheng wrote: >> From: Icenowy Zheng >> >> Allwinner R40 SoC features a USB OTG port and two USB HOST ports. >> >> Add support for the host ports in the DTSI file. >> >> The OTG

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 11:15:40PM +, Levin, Alexander (Sasha Levin) wrote: > On Mon, Oct 09, 2017 at 04:06:20PM -0700, Alexei Starovoitov wrote: > >On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) > >wrote: > >> On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei

Re: [locking] 892ad5acca [ 12.849409] WARNING: bad unlock balance detected!

On Mon, Oct 9, 2017 at 8:55 AM, Fengguang Wu wrote: > > 0day kernel testing robot got the below dmesg and the first bad commit is This makes no sense. > [ 12.849409] WARNING: bad unlock balance detected! > [ 12.850157] 4.12.0-00420-g892ad5a #1 Not tainted > [

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 11:15:40PM +, Levin, Alexander (Sasha Levin) wrote: > On Mon, Oct 09, 2017 at 04:06:20PM -0700, Alexei Starovoitov wrote: > >On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) > >wrote: > >> On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei

Re: [locking] 892ad5acca [ 12.849409] WARNING: bad unlock balance detected!

On Mon, Oct 9, 2017 at 8:55 AM, Fengguang Wu wrote: > > 0day kernel testing robot got the below dmesg and the first bad commit is This makes no sense. > [ 12.849409] WARNING: bad unlock balance detected! > [ 12.850157] 4.12.0-00420-g892ad5a #1 Not tainted > [ 12.850870]

Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

On Mon, Oct 09, 2017 at 08:56:34PM +0100, Mark Brown wrote: > On Mon, Oct 09, 2017 at 10:43:01PM +0300, Mika Westerberg wrote: > > > If possible, I would rather move this chapter to be before "Networking > > over Thunderbolt cable". Reason is that it then follows NVM flashing > > chapter which is

Re: linux-next: manual merge of the drivers-x86 tree with the net-next tree

On Mon, Oct 09, 2017 at 08:56:34PM +0100, Mark Brown wrote: > On Mon, Oct 09, 2017 at 10:43:01PM +0300, Mika Westerberg wrote: > > > If possible, I would rather move this chapter to be before "Networking > > over Thunderbolt cable". Reason is that it then follows NVM flashing > > chapter which is

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Mon, 9 Oct 2017 17:13:43 -0400 Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are

Re: [PATCH v4 1/2] pid: Replace pid bitmap implementation with IDR API

On Mon, 9 Oct 2017 17:13:43 -0400 Gargi Sharma wrote: > This patch replaces the current bitmap implemetation for > Process ID allocation. Functions that are no longer required, > for example, free_pidmap(), alloc_pidmap(), etc. are removed. > The rest of the functions are modified to use the

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

From: Alexei Starovoitov Date: Mon, 9 Oct 2017 16:06:20 -0700 >> For these archs, wouldn't it then be more efficient to use BUG_ON >> rather than BUG()? > > why more efficient? any data to prove that? It can completely eliminate a branch. For example on powerpc

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

From: Alexei Starovoitov Date: Mon, 9 Oct 2017 16:06:20 -0700 >> For these archs, wouldn't it then be more efficient to use BUG_ON >> rather than BUG()? > > why more efficient? any data to prove that? It can completely eliminate a branch. For example on powerpc if you use BUG() then the code

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 04:06:20PM -0700, Alexei Starovoitov wrote: >On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) wrote: >> On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei Starovoitov wrote: >> >On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: >> >> Fix

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 04:06:20PM -0700, Alexei Starovoitov wrote: >On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) wrote: >> On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei Starovoitov wrote: >> >On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: >> >> Fix

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

Re: [PATCH tip/core/rcu 1/9] rcu: Provide GP ordering in face of migrations and delays

On Mon, Oct 09, 2017 at 10:16:37AM +0200, Peter Zijlstra wrote: > On Sat, Oct 07, 2017 at 11:28:57AM -0700, Paul E. McKenney wrote: > > But if you are saying that it would be good to have wait_for_completion() > > and complete() directly modeled at some point, no argument. In addition, > > I hope

[GIT] Networking

1) Fix object leak on IPSEC offload failure, from Steffen Klassert. 2) Fix range checks in ipset address range addition operations, from Jozsef Kadlecsik. 3) Fix pernet ops unregistration order in ipset, from Florian Westphal. 4) Add missing netlink attribute policy for nl80211 packet

[GIT] Networking

1) Fix object leak on IPSEC offload failure, from Steffen Klassert. 2) Fix range checks in ipset address range addition operations, from Jozsef Kadlecsik. 3) Fix pernet ops unregistration order in ipset, from Florian Westphal. 4) Add missing netlink attribute policy for nl80211 packet

Re: [PATCH 02/13] EDAC, altera: kill off ACCESS_ONCE()

On 10/09/2017 01:28 PM, Mark Rutland wrote: For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently

Re: [PATCH 02/13] EDAC, altera: kill off ACCESS_ONCE()

On 10/09/2017 01:28 PM, Mark Rutland wrote: For several reasons, it is desirable to use {READ,WRITE}_ONCE() in preference to ACCESS_ONCE(), and new code is expected to use one of the former. So far, there's been no reason to change most existing uses of ACCESS_ONCE(), as these aren't currently

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) wrote: > On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei Starovoitov wrote: > >On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: > >> Fix BUG() calls to use BUG_ON(conditional) macros. > >> > >> This was found

Re: [PATCH v2] net/core: Fix BUG to BUG_ON conditionals.

On Mon, Oct 09, 2017 at 08:26:34PM +, Levin, Alexander (Sasha Levin) wrote: > On Mon, Oct 09, 2017 at 10:15:42AM -0700, Alexei Starovoitov wrote: > >On Mon, Oct 09, 2017 at 11:37:59AM -0400, Tim Hansen wrote: > >> Fix BUG() calls to use BUG_ON(conditional) macros. > >> > >> This was found

Re: [PATCH] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

From: Aleksander Morgado Date: Mon, 9 Oct 2017 14:05:12 +0200 > The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback. > This module allows switching to different USB profiles with the > 'AT+UUSBCONF' command, and provides a ECM network interface when the

Re: linux-next: manual merge of the cgroup tree with the net-next tree

On Mon, Oct 09, 2017 at 07:38:36PM +0100, Mark Brown wrote: > Hi Tejun, > > Today's linux-next merge of the cgroup tree got a conflict in: > > kernel/cgroup/cgroup.c > > between commit: > > 324bda9e6c5ad ("bpf: multi program support for cgroup+bpf") > > from the net-next tree and commit:

Re: [PATCH] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

From: Aleksander Morgado Date: Mon, 9 Oct 2017 14:05:12 +0200 > The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback. > This module allows switching to different USB profiles with the > 'AT+UUSBCONF' command, and provides a ECM network interface when the > 'AT+UUSBCONF=2' profile

Re: linux-next: manual merge of the cgroup tree with the net-next tree

On Mon, Oct 09, 2017 at 07:38:36PM +0100, Mark Brown wrote: > Hi Tejun, > > Today's linux-next merge of the cgroup tree got a conflict in: > > kernel/cgroup/cgroup.c > > between commit: > > 324bda9e6c5ad ("bpf: multi program support for cgroup+bpf") > > from the net-next tree and commit:

Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

Hi Geert, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc4] [cannot apply to next-20171009] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Geert-Uytterhoeven/bitfield

Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

Hi Geert, [auto build test ERROR on linus/master] [also build test ERROR on v4.14-rc4] [cannot apply to next-20171009] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Geert-Uytterhoeven/bitfield

Re: [PATCH v3 03/22] dt-bindings: arm: scmi: add ARM MHU specific mailbox client bindings

On Mon, Oct 9, 2017 at 9:46 AM, Jassi Brar wrote: > On Mon, Oct 9, 2017 at 7:22 PM, Rob Herring wrote: >> On Fri, Oct 6, 2017 at 9:26 PM, Jassi Brar wrote: >>> On Fri, Oct 6, 2017 at 9:24 PM, Rob Herring

Re: [PATCH v3 03/22] dt-bindings: arm: scmi: add ARM MHU specific mailbox client bindings

On Mon, Oct 9, 2017 at 9:46 AM, Jassi Brar wrote: > On Mon, Oct 9, 2017 at 7:22 PM, Rob Herring wrote: >> On Fri, Oct 6, 2017 at 9:26 PM, Jassi Brar wrote: >>> On Fri, Oct 6, 2017 at 9:24 PM, Rob Herring wrote: On Fri, Oct 6, 2017 at 6:01 AM, Jassi Brar wrote: > On Fri, Oct 6,

[PATCH v6 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v6 04/14] platform/x86: dell-wmi: allow 32k return size in the descriptor

Some platforms this year will be adopting 32k WMI buffer, so don't complain when encountering those. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-wmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/dell-wmi.c

[PATCH v6 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c |

[PATCH v6 03/14] platform/x86: dell-wmi: clean up wmi descriptor check

Some cases the wrong type was used for errors and checks can be done more cleanly. Signed-off-by: Mario Limonciello Reviewed-by: Edward O'Callaghan Suggested-by: Andy Shevchenko --- drivers/platform/x86/dell-wmi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH v6 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v6 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v6 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs

The only driver using this was dell-wmi, and it really was a hack. The driver was getting a data attribute from another driver and this type of action should not be encouraged. Rather drivers that need to interact with one another should pass data back and forth via exported functions.

[PATCH v6 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver

All communication on individual GUIDs should occur in separate drivers. Allowing a driver to communicate with the bus to another GUID is just a hack that discourages drivers to adopt the bus model. The information found from the WMI descriptor driver is now exported for use by other drivers.

[PATCH v6 10/14] platform/x86: dell-smbios: add filtering capability for requests

There are some categories of tokens and SMBIOS calls that it makes sense to protect userspace from accessing. These are calls that may write to one time use fields or activate hardware debugging capabilities. They are not intended for general purpose use. This same functionality may be be later

[PATCH v6 10/14] platform/x86: dell-smbios: add filtering capability for requests

There are some categories of tokens and SMBIOS calls that it makes sense to protect userspace from accessing. These are calls that may write to one time use fields or activate hardware debugging capabilities. They are not intended for general purpose use. This same functionality may be be later

[PATCH v6 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello ---

[PATCH v6 07/14] platform/x86: dell-smbios: only run if proper oem string is detected

The proper way to indicate that a system is a 'supported' Dell System is by the presence of this string in OEM strings. Allowing the driver to load on non-Dell systems will have undefined results. Signed-off-by: Mario Limonciello --- drivers/platform/x86/dell-smbios.c | 7 +++ 1 file

[PATCH v6 12/14] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

[PATCH v6 12/14] platform/x86: dell-smbios-smm: test for WSMT

WSMT is as an attestation to the OS that the platform won't modify memory outside of pre-defined areas. If a platform has WSMT enabled in BIOS setup, SMM calls through dcdbas will fail. The only way to access platform data in these instances is through the WMI SMBIOS calling interface.

[PATCH v6 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

[PATCH v6 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens

Currently userspace tools can access system tokens via the dcdbas kernel module and a SMI call that will cause the platform to execute SMM code. With a goal in mind of deprecating the dcdbas kernel module a different method for accessing these tokens from userspace needs to be created. This is

Re: [PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

On Mon, Oct 09, 2017 at 03:45:51PM -0700, Prakash Sangappa wrote: > Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should > be available in Linux 4.14 release. This patch is for the manpage > changes documenting this API. > > Documents the following commit: > > commit

Re: [PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

On Mon, Oct 09, 2017 at 03:45:51PM -0700, Prakash Sangappa wrote: > Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should > be available in Linux 4.14 release. This patch is for the manpage > changes documenting this API. > > Documents the following commit: > > commit

[PATCH v6 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v6 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver

The dell-smbios stack only currently uses an SMI interface which grants direct access to physical memory to the firmware SMM methods via a pointer. This dispatcher driver adds a WMI-ACPI interface that is detected by WMI probe and preferred over the SMI interface in dell-smbios. Changing this to

[PATCH v3 1/2] KVM: X86: Processor States following Reset or INIT

From: Wanpeng Li - XCR0 is reset to 1 by RESET but not INIT - XSS is zeroed by both RESET and INIT - BNDCFGU, BND0-BND3, BNDCFGS are zeroed by both RESET and INIT This patch does this according to SDM. Cc: Paolo Bonzini Cc: Radim Krčmář

Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

On Mon, 9 Oct 2017 10:40:49 +0200, Geert Uytterhoeven wrote: > On most architectures[*], gcc turns __builtin_ffsll() into a call to > __ffsdi2(), which is not provided by any architecture, leading to > failures like: > > rcar-gen3-cpg.c:(.text+0x289): undefined reference to `__ffsdi2' > >

[PATCH v3 1/2] KVM: X86: Processor States following Reset or INIT

From: Wanpeng Li - XCR0 is reset to 1 by RESET but not INIT - XSS is zeroed by both RESET and INIT - BNDCFGU, BND0-BND3, BNDCFGS are zeroed by both RESET and INIT This patch does this according to SDM. Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Jim Mattson Signed-off-by: Wanpeng Li --- v2 ->

Re: [PATCH] bitfield: Use __ffs64(x) to fix missing __ffsdi2()

On Mon, 9 Oct 2017 10:40:49 +0200, Geert Uytterhoeven wrote: > On most architectures[*], gcc turns __builtin_ffsll() into a call to > __ffsdi2(), which is not provided by any architecture, leading to > failures like: > > rcar-gen3-cpg.c:(.text+0x289): undefined reference to `__ffsdi2' > >

[PATCH v3 2/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

From: Wanpeng Li SDM mentioned: "If either the “unrestricted guest” VM-execution control or the “mode-based execute control for EPT” VM- execution control is 1, the “enable EPT” VM-execution control must also be 1." However, we can still observe unrestricted_guest

[PATCH v3 2/2] KVM: VMX: Don't expose unrestricted_guest is enabled if ept is disabled

From: Wanpeng Li SDM mentioned: "If either the “unrestricted guest” VM-execution control or the “mode-based execute control for EPT” VM- execution control is 1, the “enable EPT” VM-execution control must also be 1." However, we can still observe unrestricted_guest is Y after inserting the

[PATCH v6 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v6 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

This splits up the dell-smbios driver into two drivers: * dell-smbios * dell-smbios-smm dell-smbios can operate with multiple different dispatcher drivers to perform SMBIOS operations. Also modify the interface that dell-laptop and dell-wmi use align to this model more closely. Rather than a

[PATCH v6 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v6 13/14] platform/x86: wmi: create character devices when requested by drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v6 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method

Drivers properly using the wmibus can pass their wmi_device pointer rather than the GUID back to the WMI bus to evaluate the proper methods. Any "new" drivers added that use the WMI bus should use this rather than the old wmi_evaluate_method that would take the GUID. Signed-off-by: Mario

[PATCH v6 13/14] platform/x86: wmi: create character devices when requested by drivers

For WMI operations that are only Set or Query read or write sysfs attributes created by WMI vendor drivers make sense. For other WMI operations that are run on Method, there needs to be a way to guarantee to userspace that the results from the method call belong to the data request to the method

[PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

[PATCH v6 14/14] platform/x86: dell-smbios-wmi: introduce userspace interface

It's important for the driver to provide a R/W ioctl to ensure that two competing userspace processes don't race to provide or read each others data. This userspace character device will be used to perform SMBIOS calls from any applications. It provides an ioctl that will allow passing the WMI

Re: [PATCH] bcache: mark expected switch fall-throughs in STRTO_H

On 10/09/2017 02:54 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Cc: Kent Overstreet Cc: Shaohua Li Cc: linux-bca...@vger.kernel.org Cc:

Re: [PATCH] bcache: mark expected switch fall-throughs in STRTO_H

On 10/09/2017 02:54 PM, Gustavo A. R. Silva wrote: In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Cc: Kent Overstreet Cc: Shaohua Li Cc: linux-bca...@vger.kernel.org Cc: linux-r...@vger.kernel.org Signed-off-by: Gustavo A. R. Silva

[PATCH v6 00/14] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v6 00/14] Introduce support for Dell SMBIOS over WMI

The existing way that the dell-smbios helper module and associated other drivers (dell-laptop, dell-wmi) communicate with the platform really isn't secure. It requires creating a buffer in physical DMA32 memory space and passing that to the platform via SMM. Since the platform got a physical

[PATCH v6 02/14] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

[PATCH v6 02/14] platform/x86: dell-wmi: increase severity of some failures

There is a lot of error checking in place for the format of the WMI descriptor buffer, but some of the potentially raised issues should be considered critical failures. If the buffer size or header don't match, this is a good indication that the buffer format changed in a way that the rest of the

[PATCH v3 5/5] uio: uio_pdrv_genirq: Add "marvell,88e2040" to dt compatible list

The marvell,88e2040 is a N-BaseT Ethernet PHY which requires a userspace driver. uio_pdrv_genirq can be used to provide interrupts to such a userspace driver. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: add default compatible string to

[PATCH v3 5/5] uio: uio_pdrv_genirq: Add "marvell,88e2040" to dt compatible list

The marvell,88e2040 is a N-BaseT Ethernet PHY which requires a userspace driver. uio_pdrv_genirq can be used to provide interrupts to such a userspace driver. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: add default compatible string to uio_pdrv_genirq") - As suggested by

[PATCH v3 1/5] uio: dt-bindings: document existing binding for uio-pdrv-genirq

Document the device tree bindings for the uio-prv-genirq driver. Provide some examples on how it can be used. Signed-off-by: Chris Packham --- Changes in v3: - New. Document existing binding first. .../devicetree/bindings/uio/uio-pdrv-genirq.txt| 27

[PATCH v3 1/5] uio: dt-bindings: document existing binding for uio-pdrv-genirq

Document the device tree bindings for the uio-prv-genirq driver. Provide some examples on how it can be used. Signed-off-by: Chris Packham --- Changes in v3: - New. Document existing binding first. .../devicetree/bindings/uio/uio-pdrv-genirq.txt| 27 ++ 1 file changed,

[PATCH v3 3/5] uio: dt-bindings: Add binding for "marvell,88e2040"

The marvell,88e2040 is a N-BaseT Ethernet PHY which requires a userspace driver. The only kernel presence is an interrupt handler which uio_pdrv_genirq can provide. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: dt-bindings: document binding

[PATCH v3 2/5] uio: dt-bindings: Add binding for "st,stm32f100"

The stm32f100 is a general purpose micro controller. Document a binding that allows a user-space driver to be implemented for these devices. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: dt-bindings: document binding for uio-pdrv-genirq") -

[PATCH v3 3/5] uio: dt-bindings: Add binding for "marvell,88e2040"

The marvell,88e2040 is a N-BaseT Ethernet PHY which requires a userspace driver. The only kernel presence is an interrupt handler which uio_pdrv_genirq can provide. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: dt-bindings: document binding for uio-pdrv-genirq") - split the

[PATCH v3 2/5] uio: dt-bindings: Add binding for "st,stm32f100"

The stm32f100 is a general purpose micro controller. Document a binding that allows a user-space driver to be implemented for these devices. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: dt-bindings: document binding for uio-pdrv-genirq") - split the bindings up into the

[PATCH v3 4/5] uio: uio_pdrv_genirq: Add st,stm32f100 to dt compatible list

The stm32f100 is a general purpose micro controller. Allow users to interact with one as a uio device. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: add default compatible string to uio_pdrv_genirq") - remove superfluous change suggested by

[PATCH v3 0/5] using uio_pdrv_genirq without module param

I found myself about to add a driver that was a sub-optimal clone of uio_pdrv_genirq the only difference was that I didn't want to modify the args passed to the kernel by my bootloader. If uio_pdrv_genirq had a default of_match entry I could simply use that. This series attempts to implement this.

[PATCH v3 4/5] uio: uio_pdrv_genirq: Add st,stm32f100 to dt compatible list

The stm32f100 is a general purpose micro controller. Allow users to interact with one as a uio device. Signed-off-by: Chris Packham --- Changes in v3: - (replaces "uio: add default compatible string to uio_pdrv_genirq") - remove superfluous change suggested by checkpatch.pl - As suggested by

[PATCH v3 0/5] using uio_pdrv_genirq without module param

I found myself about to add a driver that was a sub-optimal clone of uio_pdrv_genirq the only difference was that I didn't want to modify the args passed to the kernel by my bootloader. If uio_pdrv_genirq had a default of_match entry I could simply use that. This series attempts to implement this.

[PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e Author: Prakash Sangappa

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 09/27/2017 04:34 AM, Mark Rutland wrote: > On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote: >> As ARMv8 servers get deployed, I keep getting the same set of questions >> from end-users of those systems: what do all the hex numbers mean in >> /proc/cpuinfo and could you make them so I

[PATCH v2] Userfaultfd: Add description for UFFD_FEATURE_SIGBUS

Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should be available in Linux 4.14 release. This patch is for the manpage changes documenting this API. Documents the following commit: commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e Author: Prakash Sangappa Date: Wed Sep 6

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 09/27/2017 04:34 AM, Mark Rutland wrote: > On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote: >> As ARMv8 servers get deployed, I keep getting the same set of questions >> from end-users of those systems: what do all the hex numbers mean in >> /proc/cpuinfo and could you make them so I

Re: [PATCH] mm/page-writeback.c: fix bug caused by disable periodic writeback

On Sat, 7 Oct 2017 06:58:04 +0800 Yafang Shao wrote: > After disable periodic writeback by writing 0 to > dirty_writeback_centisecs, the handler wb_workfn() will not be > entered again until the dirty background limit reaches or > sync syscall is executed or no enough free

Re: [PATCH] mm/page-writeback.c: fix bug caused by disable periodic writeback

On Sat, 7 Oct 2017 06:58:04 +0800 Yafang Shao wrote: > After disable periodic writeback by writing 0 to > dirty_writeback_centisecs, the handler wb_workfn() will not be > entered again until the dirty background limit reaches or > sync syscall is executed or no enough free memory available or >

Re: Warning on __wait_on_bit

Hi, Tom On Sat, Sep 30, 2017 at 1:55 AM, Tom Green wrote: > Hi Tejun Cong Shaohua, > > I just observed the same problem in https://lkml.org/lkml/2016/12/9/373. It > seems to be exactly same as decribed in https://lwn.net/Articles/628628/. > Any progress? Thanks. Sorry

Re: Warning on __wait_on_bit

Hi, Tom On Sat, Sep 30, 2017 at 1:55 AM, Tom Green wrote: > Hi Tejun Cong Shaohua, > > I just observed the same problem in https://lkml.org/lkml/2016/12/9/373. It > seems to be exactly same as decribed in https://lwn.net/Articles/628628/. > Any progress? Thanks. Sorry for the delay, I was on

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