Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds wrote: > > Your mailer is crap, and destroys utf-8 characters. In particular: > > -M: Michał Mirosław Using pseudo-MIME-encoding, that was actually (before my cut-and-paste mangled

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds wrote: > > Your mailer is crap, and destroys utf-8 characters. In particular: > > -M: Michał Mirosław Using pseudo-MIME-encoding, that was actually (before my cut-and-paste mangled it even more): Micha=c3=85=c2=82

Re: [RFC PATCH v2 1/3] hwmon: pmbus: Add fan control support

On Thu, 2017-07-20 at 00:35 +0930, Joel Stanley wrote: > > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery wrote: > > Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes. > > Nice! I had a bit of a read. I'm not a pmbus expert, so most of the > review is nitpicks

Re: [RFC PATCH v2 1/3] hwmon: pmbus: Add fan control support

On Thu, 2017-07-20 at 00:35 +0930, Joel Stanley wrote: > > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery wrote: > > Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes. > > Nice! I had a bit of a read. I'm not a pmbus expert, so most of the > review is nitpicks about types, etc. >

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

On all supported platforms, the TS Reading (TSR) field in the Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78 degrees C) are plausible, so don't mask out the topmost bit. And the register itself is 16 bits wide, so use readw() rather than readl(). Signed-off-by: Ed Swierk ---

[PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. However, the hw provides isolation and source validation through the SMMU. Turn on ACS but disable all the peer to peer features. Signed-off-by: Feng Kan --- drivers/pci/quirks.c | 15 +++ 1 file

[PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

The APM X-Gene PCIe root port does not support ACS at this point. However, the hw provides isolation and source validation through the SMMU. Turn on ACS but disable all the peer to peer features. Signed-off-by: Feng Kan --- drivers/pci/quirks.c | 15 +++ 1 file changed, 15

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

Using the TSDSS flag to determine whether the thermal sensor is enabled is problematic. Broadwell-DE (Xeon D-1500) does not support dynamic shutdown and the TSDSS flag always reads 0 (contrary to the current datasheet). Even on hardware supporting dynamic shutdown, the driver does nothing to

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

Using the TSDSS flag to determine whether the thermal sensor is enabled is problematic. Broadwell-DE (Xeon D-1500) does not support dynamic shutdown and the TSDSS flag always reads 0 (contrary to the current datasheet). Even on hardware supporting dynamic shutdown, the driver does nothing to

[PATCH v5] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

[PATCH v5] Bluetooth: btusb: Fix memory leak in play_deferred

Currently we are calling usb_submit_urb directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak: unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:26 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: >> >> Must be small and stupid. It applies cleanly for me. >> Do you have changes that are not pushed out publicly? > > Nope, my

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:26 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: >> >> Must be small and stupid. It applies cleanly for me. >> Do you have changes that are not pushed out publicly? > > Nope, my private tree matches the public one. Oh, I see it.

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook wrote: > On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso wrote: >> May I suggest using mmtests with the following config file: >> >>

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook wrote: > On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso wrote: >> May I suggest using mmtests with the following config file: >> >>

[PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

There are certain touch controllers that may come up in either normal (application) or boot mode, depending on whether firmware/configuration is corrupted when they are powered on. In boot mode the kernel does not create input device instance (because it does not necessarily know the

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: > > Must be small and stupid. It applies cleanly for me. > Do you have changes that are not pushed out publicly? Nope, my private tree matches the public one. The failure happens at the chunk for line 5086, fwiw. You

[PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

There are certain touch controllers that may come up in either normal (application) or boot mode, depending on whether firmware/configuration is corrupted when they are powered on. In boot mode the kernel does not create input device instance (because it does not necessarily know the

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap wrote: > > Must be small and stupid. It applies cleanly for me. > Do you have changes that are not pushed out publicly? Nope, my private tree matches the public one. The failure happens at the chunk for line 5086, fwiw. You don't seem to have used

[PATCH v2 3/7] driver core: add device_{add|remove}_group() helpers

We have helpers that work with NULL terminated array of groups, but many drivers only create a single supplemental group, and do not want to declare a group array. Let's provide them with helpers working with a single group. Signed-off-by: Dmitry Torokhov ---

[PATCH v2 3/7] driver core: add device_{add|remove}_group() helpers

We have helpers that work with NULL terminated array of groups, but many drivers only create a single supplemental group, and do not want to declare a group array. Let's provide them with helpers working with a single group. Signed-off-by: Dmitry Torokhov --- include/linux/device.h | 16

[PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov --- drivers/input/rmi4/rmi_f01.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git

[PATCH v2 0/7] New bind/unbingd uevents

Hi Greg, Here is the v2 of bind/unbind uevent patch series. The new bind/unbind will allow triggering firmware update through udev, and the new device sysfs API will cut down on some boilerplate code in drivers. As you requested, I moved the new functions to device.h, in the process I exported

[PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov --- drivers/input/rmi4/rmi_f01.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/input/rmi4/rmi_f01.c

[PATCH v2 0/7] New bind/unbingd uevents

Hi Greg, Here is the v2 of bind/unbind uevent patch series. The new bind/unbind will allow triggering firmware update through udev, and the new device sysfs API will cut down on some boilerplate code in drivers. As you requested, I moved the new functions to device.h, in the process I exported

[PATCH v2 2/7] driver core: make device_{add|remove}_groups() public

Many drivers create additional driver-specific device attributes when binding to the device. To avoid them calling SYSFS API directly, let's export these helpers. Signed-off-by: Dmitry Torokhov --- drivers/base/base.h| 5 - drivers/base/core.c| 2 ++

[PATCH v2 2/7] driver core: make device_{add|remove}_groups() public

Many drivers create additional driver-specific device attributes when binding to the device. To avoid them calling SYSFS API directly, let's export these helpers. Signed-off-by: Dmitry Torokhov --- drivers/base/base.h| 5 - drivers/base/core.c| 2 ++ include/linux/device.h | 5 +

[PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

Now that we have proper managed API to create device attributes, let's use it instead of installing a custom devm action. Signed-off-by: Dmitry Torokhov --- drivers/input/misc/axp20x-pek.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff

[PATCH v2 4/7] driver core: add devm_device_add_group() and friends

Many drivers create additional driver-specific device attributes when binding to the device, and providing managed version of device_create_group() will simplify unbinding and error handling in probe path for such drivers. Without managed version driver writers either have to mix manual and

[PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

Now that we have proper managed API to create device attributes, let's use it instead of installing a custom devm action. Signed-off-by: Dmitry Torokhov --- drivers/input/misc/axp20x-pek.c | 18 +- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git

[PATCH v2 4/7] driver core: add devm_device_add_group() and friends

Many drivers create additional driver-specific device attributes when binding to the device, and providing managed version of device_create_group() will simplify unbinding and error handling in probe path for such drivers. Without managed version driver writers either have to mix manual and

[PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov --- drivers/input/keyboard/gpio_keys.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff

[PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

Now that we have proper managed API to create device attributes, let's start using it instead of the manual unwinding. Signed-off-by: Dmitry Torokhov --- drivers/input/keyboard/gpio_keys.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) diff --git

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Wed, Jul 19, 2017 at 8:03 PM, Paul Moore wrote: > On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: >> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds >> hook since it's dealing with the same information, and all of the

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Wed, Jul 19, 2017 at 8:03 PM, Paul Moore wrote: > On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: >> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds >> hook since it's dealing with the same information, and all of the details >> are finalized during the first call to

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. Must be small and stupid. It applies

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. Must be small and stupid. It applies cleanly for me. Do you have

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. > > I can easily just look at the reject and

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On 07/19/2017 05:08 PM, Linus Torvalds wrote: > On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton > wrote: >> >> Linus, can you please grab this? > > Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. > > I can easily just look at the reject and fix it, but I don't really

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:08 PM, Linus Torvalds wrote: > > I'm throwing out _one_ idea: split it up by the main F: line, so that > maintainership information ends up being hierarchical like the Kconfig > files. Teach "get_maintainer.pl" to just do "find . -name >

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 5:08 PM, Linus Torvalds wrote: > > I'm throwing out _one_ idea: split it up by the main F: line, so that > maintainership information ends up being hierarchical like the Kconfig > files. Teach "get_maintainer.pl" to just do "find . -name > MAINTAINERS" instead? For a

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

,Chris Metcalf ,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel Borkmann ,Markus

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

,Chris Metcalf ,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel Borkmann ,Markus Trippelsdorf ,Peter Foley ,Steven Rostedt ,Tim Chen ,Catalin Marinas ,Matthew Wilcox ,Michal Hocko ,Rob Landley ,Jiri Kosina ,"H . J . Lu" ,Paul Bolle ,Baoquan He

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

,"Paul E . McKenney" ,Andrew Morton ,Christopher Li ,Dou Liyang ,Masahiro Yamada ,Daniel Borkmann ,Markus Trippelsdorf ,Peter Foley ,Steven Rostedt ,Tim Chen ,Ard Biesheuvel ,Catalin Marinas ,Matthew Wilcox ,Michal Hocko ,Rob Landley ,Jiri Kosina ,"H . J . Lu" ,Paul Bolle ,Baoquan He

[PATCH] sparc64: Register hugepages during arch init

Add hstate for each supported hugepage size using arch initcall. This change fixes some hugepage parameter parsing inconsistencies: case 1: no hugepage parameters Without hugepage parameters, only a hugepages-8192kB entry is visible in sysfs. It's different from x86_64 where both 2M and 1G

[PATCH] sparc64: Register hugepages during arch init

Add hstate for each supported hugepage size using arch initcall. This change fixes some hugepage parameter parsing inconsistencies: case 1: no hugepage parameters Without hugepage parameters, only a hugepages-8192kB entry is visible in sysfs. It's different from x86_64 where both 2M and 1G

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton wrote: > > Linus, can you please grab this? Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. I can easily just look at the reject and fix it, but I don't really want to. Why? Because I hate the

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton wrote: > > Linus, can you please grab this? Ugh. It doesn't apply cleanly. Probably for some really small stupid reason. I can easily just look at the reject and fix it, but I don't really want to. Why? Because I hate the MAINTAINERS file. It's

Re: commit 16ecba59 breaks 82574L under heavy load.

On 2017/07/19 10:19, Lennart Sorensen wrote: > On Tue, Jul 18, 2017 at 04:14:35PM -0700, Benjamin Poirier wrote: > > Thanks for the detailed analysis. > > > > Refering to the original discussion around this patch series, it seemed like > > the IMS bit for a condition had to be set for the Other

Re: commit 16ecba59 breaks 82574L under heavy load.

On 2017/07/19 10:19, Lennart Sorensen wrote: > On Tue, Jul 18, 2017 at 04:14:35PM -0700, Benjamin Poirier wrote: > > Thanks for the detailed analysis. > > > > Refering to the original discussion around this patch series, it seemed like > > the IMS bit for a condition had to be set for the Other

Re: [PATCH] scsi: mpt3sas_scsih: remove unnecessary statics

On Wed, 2017-07-19 at 17:06 -0500, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variables raid_device. > Such variables are initialized before being used, on > every execution path throughout the functions. The > static has no benefit and, removing it reduces the > object file

Re: [PATCH] scsi: mpt3sas_scsih: remove unnecessary statics

On Wed, 2017-07-19 at 17:06 -0500, Gustavo A. R. Silva wrote: > Remove unnecessary static on local variables raid_device. > Such variables are initialized before being used, on > every execution path throughout the functions. The > static has no benefit and, removing it reduces the > object file

Re: linux-next: Tree for Jul 19 (drivers/sfi)

On 07/18/2017 09:54 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20170718: > on i386: ../drivers/sfi/sfi_core.c: In function 'sfi_map_memory': ../drivers/sfi/sfi_core.c:104:3: error: implicit declaration of function 'memremap' [-Werror=implicit-function-declaration] return

Re: linux-next: Tree for Jul 19 (drivers/sfi)

On 07/18/2017 09:54 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20170718: > on i386: ../drivers/sfi/sfi_core.c: In function 'sfi_map_memory': ../drivers/sfi/sfi_core.c:104:3: error: implicit declaration of function 'memremap' [-Werror=implicit-function-declaration] return

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: > The SELinux bprm_secureexec hook can be merged with the bprm_set_creds > hook since it's dealing with the same information, and all of the details > are finalized during the first call to the bprm_set_creds hook via >

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: > The SELinux bprm_secureexec hook can be merged with the bprm_set_creds > hook since it's dealing with the same information, and all of the details > are finalized during the first call to the bprm_set_creds hook via > prepare_binprm()

Re: [PATCH] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

Hi Eric, suggestion inline On 17-07-19 01:19 PM, Eric Anholt wrote: BCM2837 is somewhat unusual in that we build its DT on both arm32 and arm64. Most devices are being run in arm32 mode. Having the body of the DT for 2837 separate from 2835/6 has been a source of pain, as we often need to

Re: [PATCH] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

Hi Eric, suggestion inline On 17-07-19 01:19 PM, Eric Anholt wrote: BCM2837 is somewhat unusual in that we build its DT on both arm32 and arm64. Most devices are being run in arm32 mode. Having the body of the DT for 2837 separate from 2835/6 has been a source of pain, as we often need to

[PATCH -next] staging: pi433: depends on SPI

From: Randy Dunlap The pi433 driver uses SPI interfaces so it should depend on SPI. Also, the "default n" can be removed since that is already the default. Fixes these build errors when SPI is not enabled: drivers/staging/pi433/pi433_if.o: In function `pi433_probe':

[PATCH -next] staging: pi433: depends on SPI

From: Randy Dunlap The pi433 driver uses SPI interfaces so it should depend on SPI. Also, the "default n" can be removed since that is already the default. Fixes these build errors when SPI is not enabled: drivers/staging/pi433/pi433_if.o: In function `pi433_probe': pi433_if.c:(.text+0x1135):

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: > The cred_prepared bprm flag has a misleading name. It has nothing to do > with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has > been called. Rename this flag and improve its comment. > > Cc: David

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook wrote: > The cred_prepared bprm flag has a misleading name. It has nothing to do > with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has > been called. Rename this flag and improve its comment. > > Cc: David Howells > Cc: John

Re: [PATCH 3.18 00/28] 3.18.62-stable review

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

Re: [PATCH 3.18 00/28] 3.18.62-stable review

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

Re: [PATCH 4.4 00/57] 4.4.78-stable review

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

Re: [PATCH 4.4 00/57] 4.4.78-stable review

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

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

From: Wanpeng Li This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries to emulate invalid guest state task-switch: kvm_exit: reason TASK_SWITCH rip 0x0 info 4058

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

From: Wanpeng Li This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries to emulate invalid guest state task-switch: kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0 kvm_emulate_insn:

[PATCH 1/4] can: dev: Add support for limiting configured bitrate

Various CAN or CAN-FD IP may be able to run at a faster rate than what the transceiver the CAN node is connected to. This can lead to unexpected errors. However, CAN transceivers typically have fixed limitations and provide no means to discover these limitations at runtime. Therefore, add support

[PATCH 1/4] can: dev: Add support for limiting configured bitrate

Various CAN or CAN-FD IP may be able to run at a faster rate than what the transceiver the CAN node is connected to. This can lead to unexpected errors. However, CAN transceivers typically have fixed limitations and provide no means to discover these limitations at runtime. Therefore, add support

[PATCH 4/4] can: m_can: Add call to of_transceiver_is_fixed

Add call to new generic functions that provides support via a binding to limit the arbitration rate and/or data rate imposed by the physical transceiver connected to the MCAN peripheral. Signed-off-by: Franklin S Cooper Jr --- drivers/net/can/m_can/m_can.c | 2 ++ 1 file

[PATCH 4/4] can: m_can: Add call to of_transceiver_is_fixed

Add call to new generic functions that provides support via a binding to limit the arbitration rate and/or data rate imposed by the physical transceiver connected to the MCAN peripheral. Signed-off-by: Franklin S Cooper Jr --- drivers/net/can/m_can/m_can.c | 2 ++ 1 file changed, 2

Re: [PATCH 4.9 00/72] 4.9.39-stable review

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

Re: [PATCH 4.9 00/72] 4.9.39-stable review

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

Re: [PATCH 4.11 00/88] 4.11.12-stable review

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

[PATCH 0/4] can: Add new binding to limit bit rate used

Add a new generic binding that CAN drivers can use to specify the max arbitration and data bit rate supported by a transceiver. This is useful since in some instances the maximum speeds may be limited by the transceiver used. However, transceivers may not provide a means to determine this

Re: [PATCH 4.11 00/88] 4.11.12-stable review

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

[PATCH 0/4] can: Add new binding to limit bit rate used

Add a new generic binding that CAN drivers can use to specify the max arbitration and data bit rate supported by a transceiver. This is useful since in some instances the maximum speeds may be limited by the transceiver used. However, transceivers may not provide a means to determine this

[PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

Add information regarding fixed transceiver binding. This is especially important for MCAN since the IP allows CAN FD mode to run significantly faster than what most transceivers are capable of. Signed-off-by: Franklin S Cooper Jr ---

[PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

Add information regarding fixed transceiver binding. This is especially important for MCAN since the IP allows CAN FD mode to run significantly faster than what most transceivers are capable of. Signed-off-by: Franklin S Cooper Jr --- Documentation/devicetree/bindings/net/can/m_can.txt | 10

Re: [PATCH 4.12 00/84] 4.12.3-stable review

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

[PATCH 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

Add documentation to describe usage of the new fixed transceiver binding. This new binding is applicable for any CAN device therefore it exist as its own document. Signed-off-by: Franklin S Cooper Jr --- .../bindings/net/can/fixed-transceiver.txt | 31

Re: [PATCH 4.12 00/84] 4.12.3-stable review

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

[PATCH 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

Add documentation to describe usage of the new fixed transceiver binding. This new binding is applicable for any CAN device therefore it exist as its own document. Signed-off-by: Franklin S Cooper Jr --- .../bindings/net/can/fixed-transceiver.txt | 31 ++ 1 file

Re: [PATCH] rtlwifi: remove useless code

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:41:06 -0500 > Remove useless local variables last_read_point and last_txw_point and > the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] net: tulip: remove useless code in tulip_init_one()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:43:33 -0500 > Remove useless local variable multiport_cnt and the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] wireless: airo: remove unnecessary static in writerids()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:37:11 -0500 > Remove unnecessary static on local function pointer _writer_. > Such pointer is initialized before being used, on every > execution path throughout the function. The static has no > benefit and, removing

Re: [PATCH] liquidio: lio_vf_main: remove unnecessary static in setup_io_queues()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:50:15 -0500 > Remove unnecessary static on local variables cpu_id_modulus and cpu_id. > Such variables are initialized before being used, on every execution > path throughout the function. The static has no benefit

Re: [PATCH] rtlwifi: remove useless code

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:41:06 -0500 > Remove useless local variables last_read_point and last_txw_point and > the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] net: tulip: remove useless code in tulip_init_one()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:43:33 -0500 > Remove useless local variable multiport_cnt and the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] wireless: airo: remove unnecessary static in writerids()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:37:11 -0500 > Remove unnecessary static on local function pointer _writer_. > Such pointer is initialized before being used, on every > execution path throughout the function. The static has no > benefit and, removing it reduces the object

Re: [PATCH] liquidio: lio_vf_main: remove unnecessary static in setup_io_queues()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:50:15 -0500 > Remove unnecessary static on local variables cpu_id_modulus and cpu_id. > Such variables are initialized before being used, on every execution > path throughout the function. The static has no benefit and, removing > it reduces

Re: [PATCH] qlcnic: remove unnecessary static in qlcnic_dump_fw()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:45:29 -0500 > Remove unnecessary static on local variable fw_dump_ops. > Such variable is initialized before being used, on every > execution path throughout the function. The static has no > benefit and, removing it

Re: [PATCH] net: ethernet: mediatek: remove useless code in mtk_poll_tx()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:48:06 -0500 > Remove useless local variable _condition_ and the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] net: ethernet: mediatek: remove useless code in mtk_poll_tx()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:48:06 -0500 > Remove useless local variable _condition_ and the code related. > > Signed-off-by: Gustavo A. R. Silva Applied.

Re: [PATCH] qlcnic: remove unnecessary static in qlcnic_dump_fw()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:45:29 -0500 > Remove unnecessary static on local variable fw_dump_ops. > Such variable is initialized before being used, on every > execution path throughout the function. The static has no > benefit and, removing it reduces the object file

Re: [PATCH] liquidio: lio_main: remove unnecessary static in setup_io_queues()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:53:48 -0500 > Remove unnecessary static on local variables cpu_id_modulus and cpu_id. > Such variables are initialized before being used, on every execution > path throughout the function. The static has no benefit

Re: [PATCH] liquidio: lio_main: remove unnecessary static in setup_io_queues()

From: "Gustavo A. R. Silva" Date: Tue, 18 Jul 2017 15:53:48 -0500 > Remove unnecessary static on local variables cpu_id_modulus and cpu_id. > Such variables are initialized before being used, on every execution > path throughout the function. The static has no benefit and, removing > it reduces

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