[PATCH] [media] ir-spi: Fix issues with lirc API

From: Anton Blanchard The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is inconsistent

[PATCH] [media] ir-spi: Fix issues with lirc API

From: Anton Blanchard The ir-spi driver has 2 issues which prevents it from working with lirc: 1. The ir-spi driver uses 16 bits of SPI data to create one cycle of the waveform. As such our SPI clock needs to be 16x faster than the carrier frequency. The driver is inconsistent in how it

[PATCH] staging: MAINTAINERS: add GBY as ccree maintainer

I work for Arm on maintaining the TrustZone CryptoCell driver. Signed-off-by: Gilad Ben-Yossef --- The original patch went out with the patch set introducing the ccree driver but somehow failed to end up in Linus's tree, maybe because I omitted the "staging:" prefix. ---

[PATCH] staging: MAINTAINERS: add GBY as ccree maintainer

I work for Arm on maintaining the TrustZone CryptoCell driver. Signed-off-by: Gilad Ben-Yossef --- The original patch went out with the patch set introducing the ccree driver but somehow failed to end up in Linus's tree, maybe because I omitted the "staging:" prefix. --- MAINTAINERS | 8

[PATCH v2] block/mq: fix potential deadlock during cpu hotplug

From: Wanpeng Li This can be triggered by hot-unplug one cpu. == [ INFO: possible circular locking dependency detected ] 4.11.0+ #17 Not tainted ---

[PATCH v2] block/mq: fix potential deadlock during cpu hotplug

From: Wanpeng Li This can be triggered by hot-unplug one cpu. == [ INFO: possible circular locking dependency detected ] 4.11.0+ #17 Not tainted --- step_after_susp/2640 is trying to

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Sat, May 6, 2017 at 5:06 AM, Borislav Petkov wrote: > On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: >> (Including the folks from SGI since this was hit on a UV system) > > Wasn't there a BIOS fix supplied at some point which obviated the need > to boot with

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Sat, May 6, 2017 at 5:06 AM, Borislav Petkov wrote: > On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: >> (Including the folks from SGI since this was hit on a UV system) > > Wasn't there a BIOS fix supplied at some point which obviated the need > to boot with efi=old_map on SGI

Re: [PATCH 2/5] PCI: add resizeable BAR infrastructure v5

On Thu, May 4, 2017 at 12:31 PM, Christian König wrote: > From: Christian König > > Just the defines and helper functions to read the possible sizes of a BAR and > update it's size. > > See >

Re: [PATCH 2/5] PCI: add resizeable BAR infrastructure v5

On Thu, May 4, 2017 at 12:31 PM, Christian König wrote: > From: Christian König > > Just the defines and helper functions to read the possible sizes of a BAR and > update it's size. > > See > https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf > and

Re: [PATCH] leds/trigger: system can't enter suspend.

On Sun 2017-05-07 10:01:21, sanshan zhang wrote: > From: zhang sanshan > > system can't enter suspend when enable led heartbeat. > > pm will call heartbeat_pm_notifier when suspend. > system will prepare led states, and led_trigger_unregister > will use led_trigger_set to

Re: [PATCH] leds/trigger: system can't enter suspend.

On Sun 2017-05-07 10:01:21, sanshan zhang wrote: > From: zhang sanshan > > system can't enter suspend when enable led heartbeat. > > pm will call heartbeat_pm_notifier when suspend. > system will prepare led states, and led_trigger_unregister > will use led_trigger_set to set trigger. >

[PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

Create an ops variable to store tcon->ses->server->ops and cache indirections and reduce code size a trivial bit. $ size fs/cifs/cifsacl.o* textdata bss dec hex filename 5338 136 85482156a fs/cifs/cifsacl.o.new 5371 136 85515158b

[PATCH] cifs: cifsacl: Use a temporary ops variable to reduce code length

Create an ops variable to store tcon->ses->server->ops and cache indirections and reduce code size a trivial bit. $ size fs/cifs/cifsacl.o* textdata bss dec hex filename 5338 136 85482156a fs/cifs/cifsacl.o.new 5371 136 85515158b

Re: [PATCH] Staging: rtl8192u: ieee80211: ieee80211_module.c: fix style issue

On Sun, May 7, 2017 at 5:14 AM, Greg KH wrote: > On Thu, May 04, 2017 at 10:06:51PM +0200, Riccardo wrote: >> Fixed a brace coding style issue, found via checkpatch. >> >> Signed-off-by: Riccardo Marotti > > This name doesn't match the name

Re: [PATCH] Staging: rtl8192u: ieee80211: ieee80211_module.c: fix style issue

On Sun, May 7, 2017 at 5:14 AM, Greg KH wrote: > On Thu, May 04, 2017 at 10:06:51PM +0200, Riccardo wrote: >> Fixed a brace coding style issue, found via checkpatch. >> >> Signed-off-by: Riccardo Marotti > > This name doesn't match the name on the From: line of your email :( > Sorry about that!

[PATCH] unicore32/kernel/setup: Use seq_puts() in c_show()

From: Markus Elfring Date: Sun, 7 May 2017 20:15:41 +0200 Strings which did not contain data format specifications should be put into a sequence. Thus use the corresponding function "seq_puts" more. This issue was detected by using the Coccinelle software.

[PATCH] unicore32/kernel/setup: Use seq_puts() in c_show()

From: Markus Elfring Date: Sun, 7 May 2017 20:15:41 +0200 Strings which did not contain data format specifications should be put into a sequence. Thus use the corresponding function "seq_puts" more. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH 2/5] power: supply: bq27xxx: Register power supply with devm

Le lundi 01 mai 2017 à 12:55 +0200, Sebastian Reichel a écrit : > Hi, > > On Sun, Apr 30, 2017 at 08:27:24PM +0200, Paul Kocialkowski wrote: > > This uses the managed devices resources version of the > > power_supply_register_no_ws function to register the power supply. > > > > Signed-off-by:

Re: [PATCH 2/5] power: supply: bq27xxx: Register power supply with devm

Le lundi 01 mai 2017 à 12:55 +0200, Sebastian Reichel a écrit : > Hi, > > On Sun, Apr 30, 2017 at 08:27:24PM +0200, Paul Kocialkowski wrote: > > This uses the managed devices resources version of the > > power_supply_register_no_ws function to register the power supply. > > > > Signed-off-by:

Re: [PATCH v5 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

Hi Oza, [auto build test ERROR on v4.9-rc8] [cannot apply to glikely/devicetree/next iommu/next next-20170505] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v5 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

Hi Oza, [auto build test ERROR on v4.9-rc8] [cannot apply to glikely/devicetree/next iommu/next next-20170505] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] xtensa: Use seq_puts() in c_show()

From: Markus Elfring Date: Sun, 7 May 2017 21:24:51 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software.

BLOCK selects DAX (was: Re: dax: introduce dax_direct_access())

Hi Dan, On Sat, May 6, 2017 at 4:21 AM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/b0686260fecaa924d8eff2ace94bee70506bc308 > Commit: b0686260fecaa924d8eff2ace94bee70506bc308 > Parent:

[PATCH] xtensa: Use seq_puts() in c_show()

From: Markus Elfring Date: Sun, 7 May 2017 21:24:51 +0200 A string which did not contain a data format specification should be put into a sequence. Thus use the corresponding function "seq_puts". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

BLOCK selects DAX (was: Re: dax: introduce dax_direct_access())

Hi Dan, On Sat, May 6, 2017 at 4:21 AM, Linux Kernel Mailing List wrote: > Web: > https://git.kernel.org/torvalds/c/b0686260fecaa924d8eff2ace94bee70506bc308 > Commit: b0686260fecaa924d8eff2ace94bee70506bc308 > Parent: d8f07aee3f2fd959878bf614d4e984900018eb9e > Refname:

Re: [PATCH] iommu: Fix incompatible arg type passed to iommu_get/put_resv_regions

-to-iommu_get-put_resv_regions/20170507-153552 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: x86_64-kexec (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH

Re: [PATCH] iommu: Fix incompatible arg type passed to iommu_get/put_resv_regions

-to-iommu_get-put_resv_regions/20170507-153552 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: x86_64-kexec (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH

[PATCH] drm/i915: Make vblank evade warnings optional

From: Ville Syrjälä Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline

Re: [PATCH 7/9] iio: hid-sensor-accel-3d: Drop unnecessary static

On 04/05/17 21:10, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > use, on every possible execution path through the function. The static has > no benefit, and dropping it reduces the code size. > > The semantic patch that fixes this problem is as

[PATCH] drm/i915: Make vblank evade warnings optional

From: Ville Syrjälä Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline othrwise there's no real need to

Re: [PATCH 7/9] iio: hid-sensor-accel-3d: Drop unnecessary static

On 04/05/17 21:10, Julia Lawall wrote: > Drop static on a local variable, when the variable is initialized before > use, on every possible execution path through the function. The static has > no benefit, and dropping it reduces the code size. > > The semantic patch that fixes this problem is as

Re: [PATCH] perf, tools, script: Allow adding and removing fields

On Fri, May 05, 2017 at 12:43:40PM -0700, Andi Kleen wrote: > On Fri, May 05, 2017 at 09:57:54AM +0200, Jiri Olsa wrote: > > On Thu, May 04, 2017 at 03:26:20PM -0700, Andi Kleen wrote: > > > On Tue, May 02, 2017 at 08:41:47AM +0200, Jiri Olsa wrote: > > > > On Mon, May 01, 2017 at 12:47:46PM

Re: [PATCH 4/5] power: supply: bq27xxx: Look for status change on external power change

Hi, Le vendredi 05 mai 2017 à 10:04 +0200, Pali Rohár a écrit : > On Sunday 30 April 2017 20:27:26 Paul Kocialkowski wrote: > > This introduces a dedicated status change work to look for power > > status change. It is triggered by external power change notifications > > and periodically retries

Re: [PATCH] perf, tools, script: Allow adding and removing fields

On Fri, May 05, 2017 at 12:43:40PM -0700, Andi Kleen wrote: > On Fri, May 05, 2017 at 09:57:54AM +0200, Jiri Olsa wrote: > > On Thu, May 04, 2017 at 03:26:20PM -0700, Andi Kleen wrote: > > > On Tue, May 02, 2017 at 08:41:47AM +0200, Jiri Olsa wrote: > > > > On Mon, May 01, 2017 at 12:47:46PM

Re: [PATCH 4/5] power: supply: bq27xxx: Look for status change on external power change

Hi, Le vendredi 05 mai 2017 à 10:04 +0200, Pali Rohár a écrit : > On Sunday 30 April 2017 20:27:26 Paul Kocialkowski wrote: > > This introduces a dedicated status change work to look for power > > status change. It is triggered by external power change notifications > > and periodically retries

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

* Dan Williams wrote: > On Sat, May 6, 2017 at 2:46 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > >> wrote: > >> > On Fri, 2017-05-05

Re: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

* Dan Williams wrote: > On Sat, May 6, 2017 at 2:46 AM, Ingo Molnar wrote: > > > > * Dan Williams wrote: > > > >> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > >> wrote: > >> > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: > >> >> On Fri, May 5, 2017 at 1:39 PM, Kani,

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

On Sat, Apr 08, 2017 at 08:32:36PM +0200, Guillaume Brogi wrote: > On Sat, Apr 08, 2017 at 12:31:25PM +0200, Greg Kroah-Hartman wrote: > > On Sun, Mar 26, 2017 at 12:24:14AM +0100, Guillaume Brogi wrote: > > > > > > This patch fixes the following sparse warnings: > > >

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

On Sat, Apr 08, 2017 at 08:32:36PM +0200, Guillaume Brogi wrote: > On Sat, Apr 08, 2017 at 12:31:25PM +0200, Greg Kroah-Hartman wrote: > > On Sun, Mar 26, 2017 at 12:24:14AM +0100, Guillaume Brogi wrote: > > > > > > This patch fixes the following sparse warnings: > > >

Re: [BUG] crash when removing sun4i_gpadc_iio module

On 02/05/17 07:46, Corentin Labbe wrote: > Hello Beyond picking up in a quick code inspection I'm afraid. Quentin can you take a look at this? I guess its triggering as a result of the call to read the temperature failing, but beyond that - no idea! Jonathan > > When inserting sun4i_gpadc_iio

Re: [PATCH 2/2] tsl2x7x_core: use octal permission representation

On 04/05/17 21:38, Enric Balletbo i Serra wrote: > Fix the output from checkpatch.pl like: > Symbolic permissions 'S_IRUSR' are not preferred. > Consider using octal permissions '0400'. > > Also fix the alignment DEVICE_ATTR variables as should match open > parenthesis. > > Signed-off-by:

Re: [BUG] crash when removing sun4i_gpadc_iio module

On 02/05/17 07:46, Corentin Labbe wrote: > Hello Beyond picking up in a quick code inspection I'm afraid. Quentin can you take a look at this? I guess its triggering as a result of the call to read the temperature failing, but beyond that - no idea! Jonathan > > When inserting sun4i_gpadc_iio

Re: [PATCH 2/2] tsl2x7x_core: use octal permission representation

On 04/05/17 21:38, Enric Balletbo i Serra wrote: > Fix the output from checkpatch.pl like: > Symbolic permissions 'S_IRUSR' are not preferred. > Consider using octal permissions '0400'. > > Also fix the alignment DEVICE_ATTR variables as should match open > parenthesis. > > Signed-off-by:

Re: [PATCH 1/2] tsl2x7x_core: remove paragraph about writing to the FSF's mailing address

On 04/05/17 21:38, Enric Balletbo i Serra wrote: > Do not include the paragraph about writing to the Free Software > Foundation's mailing address from the sample GPL notice. The FSF > has changed addresses in the past, and may do so again. Linux > already includes a copy of the GPL. > >

Re: [PATCH 1/2] tsl2x7x_core: remove paragraph about writing to the FSF's mailing address

On 04/05/17 21:38, Enric Balletbo i Serra wrote: > Do not include the paragraph about writing to the Free Software > Foundation's mailing address from the sample GPL notice. The FSF > has changed addresses in the past, and may do so again. Linux > already includes a copy of the GPL. > >

Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On 2017-05-08 00:02, Richard Weinberger wrote: Ahh, *very* recent is the keyword then. ;) I was a bit confused since in your paper the overhead is less than 1%. Yes, only for very recent platforms (Skylake). While working on the paper we were surprised that we found overheads that small.

[PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

A kernel cloned from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) fails when booting on an Intel Atom device with the RTL8723BS wifi chipset due to an error in

Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

On 2017-05-08 00:02, Richard Weinberger wrote: Ahh, *very* recent is the keyword then. ;) I was a bit confused since in your paper the overhead is less than 1%. Yes, only for very recent platforms (Skylake). While working on the paper we were surprised that we found overheads that small.

[PATCH v5] staging: rtl8723bs: remove re-positioned call to kfree in os_dep/ioctl_cfg80211.c

A kernel cloned from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and built with the latest RTL8723BS driver included (CONFIG_RTL8723BS=m) fails when booting on an Intel Atom device with the RTL8723BS wifi chipset due to an error in

Re: [PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings.

On Sun, Apr 30, 2017 at 6:26 PM, Karim Eshapa wrote: > On Fri, 28 Apr 2017 12:02:58 +0200, Greg KH wrote: >> On Wed, Apr 26, 2017 at 06:15:40PM +0200, Karim Eshapa wrote: >> >>> Fixing sparse warnings incorrect type assignment. >>> >>> Signed-off-by: Karim Eshapa

Re: BLOCK selects DAX (was: Re: dax: introduce dax_direct_access())

On Sun, May 7, 2017 at 9:20 AM, Geert Uytterhoeven wrote: > Hi Dan, > > On Sat, May 6, 2017 at 4:21 AM, Linux Kernel Mailing List > wrote: >> Web: >> https://git.kernel.org/torvalds/c/b0686260fecaa924d8eff2ace94bee70506bc308 >> Commit:

Re: [PATCH] drivers:staging:wlan-ng:hfa384x_usb: Fixing sparse warnings.

On Sun, Apr 30, 2017 at 6:26 PM, Karim Eshapa wrote: > On Fri, 28 Apr 2017 12:02:58 +0200, Greg KH wrote: >> On Wed, Apr 26, 2017 at 06:15:40PM +0200, Karim Eshapa wrote: >> >>> Fixing sparse warnings incorrect type assignment. >>> >>> Signed-off-by: Karim Eshapa >>> --- >>>

Re: BLOCK selects DAX (was: Re: dax: introduce dax_direct_access())

On Sun, May 7, 2017 at 9:20 AM, Geert Uytterhoeven wrote: > Hi Dan, > > On Sat, May 6, 2017 at 4:21 AM, Linux Kernel Mailing List > wrote: >> Web: >> https://git.kernel.org/torvalds/c/b0686260fecaa924d8eff2ace94bee70506bc308 >> Commit: b0686260fecaa924d8eff2ace94bee70506bc308 >>

Re: [PATCH 1/5] PCI: add a define for the PCI resource type mask

On Thu, May 4, 2017 at 12:31 PM, Christian König wrote: > From: Christian König > > We use this mask multiple times in the bus setup. Couple of nitpicks below. Otherwise, FWIW: Reviewed-by: Andy Shevchenko >

Re: [PATCH 1/5] PCI: add a define for the PCI resource type mask

On Thu, May 4, 2017 at 12:31 PM, Christian König wrote: > From: Christian König > > We use this mask multiple times in the bus setup. Couple of nitpicks below. Otherwise, FWIW: Reviewed-by: Andy Shevchenko > +#define PCI_RES_TYPE_MASK (IORESOURCE_IO | IORESOURCE_MEM | \ > +

Re: [PATCH v2] iio: stm32 trigger: Add support for TRGO2 triggers

On 02/05/17 13:33, Fabrice Gasnier wrote: > Add support for TRGO2 trigger that can be found on STM32F7. > Add additional master modes supported by TRGO2. > Register additional "tim[1/8]_trgo2" triggers for timer1 & timer8. > Detect TRGO2 timer capability (master mode selection 2). > >

Re: [PATCH v2] iio: stm32 trigger: Add support for TRGO2 triggers

On 02/05/17 13:33, Fabrice Gasnier wrote: > Add support for TRGO2 trigger that can be found on STM32F7. > Add additional master modes supported by TRGO2. > Register additional "tim[1/8]_trgo2" triggers for timer1 & timer8. > Detect TRGO2 timer capability (master mode selection 2). > >

Re: [PATCH v2 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support

On 04/05/17 13:13, Eugen Hristev wrote: > Added support for the external hardware trigger on pin ADTRG, > integrated the three possible edge triggers into the subsystem > and created buffer management for data retrieval > > Signed-off-by: Eugen Hristev > --- >

Re: [PATCH v2 3/3] iio: tools: generic_buffer: increase trigger length

On 04/05/17 13:13, Eugen Hristev wrote: > Increased trigger length to 64 in order to cope with trigger names > like fc03.adc-dev0-external-rising > > Signed-off-by: Eugen Hristev Might as well change this now. Applied to the togreg branch of iio.git. Thanks,

Re: [PATCH v2 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support

On 04/05/17 13:13, Eugen Hristev wrote: > Added support for the external hardware trigger on pin ADTRG, > integrated the three possible edge triggers into the subsystem > and created buffer management for data retrieval > > Signed-off-by: Eugen Hristev > --- > Changes in v2: > - Moved buffer

Re: [PATCH v2 3/3] iio: tools: generic_buffer: increase trigger length

On 04/05/17 13:13, Eugen Hristev wrote: > Increased trigger length to 64 in order to cope with trigger names > like fc03.adc-dev0-external-rising > > Signed-off-by: Eugen Hristev Might as well change this now. Applied to the togreg branch of iio.git. Thanks, Jonathan > --- > Changes in

[PATCH] char: random: casting prevents missing calculations

Cast (long)jiffies and (long)state->last_time beacause they tends to unsigned long. may cause a problem specially when comparison happens (< 0). Signed-off-by: Karim Eshapa --- drivers/char/random.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] char: random: casting prevents missing calculations

Cast (long)jiffies and (long)state->last_time beacause they tends to unsigned long. may cause a problem specially when comparison happens (< 0). Signed-off-by: Karim Eshapa --- drivers/char/random.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/random.c

Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

On 01/05/17 01:50, Jonathan Cameron wrote: > On 27/04/17 14:29, Benjamin Gaignard wrote: >> Add validate function to be use to use the correct trigger. >> Add an attribute to configure device mode like for quadrature and >> enable modes >> >> Signed-off-by: Benjamin Gaignard

[RFC 10/10] x86,kvm: Teach KVM's VMX code that CR3 isn't a constant

When PCID is enabled, CR3's PCID bits can change during context switches, so KVM won't be able to treat CR3 as a per-mm constant any more. I structured this like the existing CR4 handling. Under ordinary circumstances (PCID disabled or if the current PCID and the value that's already in the VMCS

[RFC 10/10] x86,kvm: Teach KVM's VMX code that CR3 isn't a constant

When PCID is enabled, CR3's PCID bits can change during context switches, so KVM won't be able to treat CR3 as a per-mm constant any more. I structured this like the existing CR4 handling. Under ordinary circumstances (PCID disabled or if the current PCID and the value that's already in the VMCS

Re: [PATCH 2/2] iio: make stm32 trigger driver use INDIO_HARDWARE_TRIGGERED mode

On 01/05/17 01:50, Jonathan Cameron wrote: > On 27/04/17 14:29, Benjamin Gaignard wrote: >> Add validate function to be use to use the correct trigger. >> Add an attribute to configure device mode like for quadrature and >> enable modes >> >> Signed-off-by: Benjamin Gaignard > Hmm. I think I

[RFC 02/10] x86/mm: Reduce indentation in flush_tlb_func()

The leave_mm() case can just exit the function early so we don't need to indent the entire remainder of the function. Cc: Rik van Riel Cc: Dave Hansen Cc: Nadav Amit Cc: Michal Hocko Cc: Andrew Morton

[PATCH 3/3] Staging: rtl8712: ieee80211: fixed camelcase coding style issue

Fixed coding style issue Signed-off-by: Jaya Durga --- drivers/staging/rtl8712/ieee80211.c | 7 --- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 25 + drivers/staging/rtl8712/rtl871x_ioctl_rtl.c | 9 -

[RFC 02/10] x86/mm: Reduce indentation in flush_tlb_func()

The leave_mm() case can just exit the function early so we don't need to indent the entire remainder of the function. Cc: Rik van Riel Cc: Dave Hansen Cc: Nadav Amit Cc: Michal Hocko Cc: Andrew Morton Signed-off-by: Andy Lutomirski --- arch/x86/mm/tlb.c | 34

[PATCH 3/3] Staging: rtl8712: ieee80211: fixed camelcase coding style issue

Fixed coding style issue Signed-off-by: Jaya Durga --- drivers/staging/rtl8712/ieee80211.c | 7 --- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 25 + drivers/staging/rtl8712/rtl871x_ioctl_rtl.c | 9 - drivers/staging/rtl8712/rtl871x_mlme.c

[RFC 06/10] x86/mm: Refactor flush_tlb_mm_range() to merge local and remote cases

The local flush path is very similar to the remote flush path. Merge them. This is intended to make no difference to behavior whatsoever. It removes some code and will make future changes to the flushing mechanics simpler. This patch does remove one small optimization: flush_tlb_mm_range() now

[PATCH 1/2] mm/slub: remove a redundant assignment in ___slab_alloc()

When the code comes to this point, there are two cases: 1. cpu_slab is deactivated 2. cpu_slab is empty In both cased, cpu_slab->freelist is NULL at this moment. This patch removes the redundant assignment of cpu_slab->freelist. Signed-off-by: Wei Yang --- mm/slub.c

[RFC 06/10] x86/mm: Refactor flush_tlb_mm_range() to merge local and remote cases

The local flush path is very similar to the remote flush path. Merge them. This is intended to make no difference to behavior whatsoever. It removes some code and will make future changes to the flushing mechanics simpler. This patch does remove one small optimization: flush_tlb_mm_range() now

[PATCH 1/2] mm/slub: remove a redundant assignment in ___slab_alloc()

When the code comes to this point, there are two cases: 1. cpu_slab is deactivated 2. cpu_slab is empty In both cased, cpu_slab->freelist is NULL at this moment. This patch removes the redundant assignment of cpu_slab->freelist. Signed-off-by: Wei Yang --- mm/slub.c | 1 - 1 file changed, 1

[RFC 08/10] x86/mm: Remove the UP tlbflush code; always use the formerly SMP code

The UP tlbflush generates somewhat nicer code than the SMP version. Aside from that, it's fallen quite a bit behind the SMP code: - flush_tlb_mm_range() didn't flush individual pages if the range was small. - The lazy TLB code was much weaker. This usually wouldn't matter, but, if a

Re: [PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

On Tue, Apr 18, 2017 at 04:19:00PM -0500, Tom Lendacky wrote: > The efi_mem_type() function currently returns a 0, which maps to > EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for > the supplied physical address. Returning EFI_RESERVED_TYPE implies that > a memmap entry

[RFC 08/10] x86/mm: Remove the UP tlbflush code; always use the formerly SMP code

The UP tlbflush generates somewhat nicer code than the SMP version. Aside from that, it's fallen quite a bit behind the SMP code: - flush_tlb_mm_range() didn't flush individual pages if the range was small. - The lazy TLB code was much weaker. This usually wouldn't matter, but, if a

Re: [PATCH v5 15/32] efi: Update efi_mem_type() to return an error rather than 0

On Tue, Apr 18, 2017 at 04:19:00PM -0500, Tom Lendacky wrote: > The efi_mem_type() function currently returns a 0, which maps to > EFI_RESERVED_TYPE, if the function is unable to find a memmap entry for > the supplied physical address. Returning EFI_RESERVED_TYPE implies that > a memmap entry

[RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

Lazy TLB state is current managed in a rather baroque manner. AFAICT, there are three possible states: - Non-lazy. This means that we're running a user thread or a kernel thread that has called use_mm(). current->mm == current->active_mm == cpu_tlbstate.active_mm and

[RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc

Rather than passing all the contents of flush_tlb_info to flush_tlb_others(), pass a pointer to the structure directly. For consistency, this also removes the unnecessary cpu parameter from uv_flush_tlb_others() to make its signature match the other *flush_tlb_others() functions. This serves two

[RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm

Lazy TLB state is current managed in a rather baroque manner. AFAICT, there are three possible states: - Non-lazy. This means that we're running a user thread or a kernel thread that has called use_mm(). current->mm == current->active_mm == cpu_tlbstate.active_mm and

[RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc

Rather than passing all the contents of flush_tlb_info to flush_tlb_others(), pass a pointer to the structure directly. For consistency, this also removes the unnecessary cpu parameter from uv_flush_tlb_others() to make its signature match the other *flush_tlb_others() functions. This serves two

[RFC 00/10] x86 TLB flush cleanups, moving toward PCID support

As I've been working on polishing my PCID code, a major problem I've encountered is that there are too many x86 TLB flushing code paths and that they have too many inconsequential differences. The result was that earlier versions of the PCID code were a colossal mess and very difficult to

Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

Daniel, On Fri, May 5, 2017 at 9:40 AM, Daniel Gruss wrote: > I'm sure the overhead on older systems is larger than on recent systems. Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R) CPU E3-1240 V2. KVM guests are 4.10 w/o CONFIG_KAISER and

[RFC 00/10] x86 TLB flush cleanups, moving toward PCID support

As I've been working on polishing my PCID code, a major problem I've encountered is that there are too many x86 TLB flushing code paths and that they have too many inconsequential differences. The result was that earlier versions of the PCID code were a colossal mess and very difficult to

Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

Daniel, On Fri, May 5, 2017 at 9:40 AM, Daniel Gruss wrote: > I'm sure the overhead on older systems is larger than on recent systems. Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R) CPU E3-1240 V2. KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without

Re: [PATCH 2/2] [PATCH 2/2] iio: adc: sun4i-gpadc-iio: Fix module autoload when OF devices are registered

On 02/05/17 03:09, Chen-Yu Tsai wrote: > On Tue, May 2, 2017 at 6:45 AM, Eduardo Molinas wrote: >> If the driver is built as a module, it won't be autloaded if the devices >> are registered via OF code because the OF device table >> entries are not exported as aliases >> >>

[RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic

try_to_unmap_flush() used to open-code a rather x86-centric flush sequence: local_flush_tlb() + flush_tlb_others(). Rearrange the code so that the arch (only x86 for now) provides arch_tlbbatch_add_mm() and arch_tlbbatch_flush() and the core code calls those functions instead. I'll want this for

Re: [PATCH 2/2] [PATCH 2/2] iio: adc: sun4i-gpadc-iio: Fix module autoload when OF devices are registered

On 02/05/17 03:09, Chen-Yu Tsai wrote: > On Tue, May 2, 2017 at 6:45 AM, Eduardo Molinas wrote: >> If the driver is built as a module, it won't be autloaded if the devices >> are registered via OF code because the OF device table >> entries are not exported as aliases >> >> Before the patch: >> $

[RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic

try_to_unmap_flush() used to open-code a rather x86-centric flush sequence: local_flush_tlb() + flush_tlb_others(). Rearrange the code so that the arch (only x86 for now) provides arch_tlbbatch_add_mm() and arch_tlbbatch_flush() and the core code calls those functions instead. I'll want this for

[RFC 05/10] x86/mm: Change the leave_mm() condition for local TLB flushes

On a remote TLB flush, we leave_mm() if we're TLBSTATE_LAZY. For a local flush_tlb_mm_range(), we leave_mm() if !current->mm. These are approximately the same condition -- the scheduler sets lazy TLB mode when switching to a thread with no mm. I'm about to merge the local and remote flush code,

[RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()

flush_tlb_page() was very similar to flush_tlb_mm_range() except that it had a couple of issues: - It was missing an smp_mb() in the case where current->active_mm != mm. (This is a longstanding bug reported by Nadav Amit.) - It was missing tracepoints and vm counter updates. The only

[RFC 07/10] x86/mm: Use new merged flush logic in arch_tlbbatch_flush()

Now there's only one copy of the local tlb flush logic for non-kernel pages on SMP kernels. The only functional change is that arch_tlbbatch_flush() will now leave_mm() on the local CPU if that CPU is in the batch and is in TLBSTATE_LAZY mode. Cc: Rik van Riel Cc: Dave Hansen

[RFC 05/10] x86/mm: Change the leave_mm() condition for local TLB flushes

On a remote TLB flush, we leave_mm() if we're TLBSTATE_LAZY. For a local flush_tlb_mm_range(), we leave_mm() if !current->mm. These are approximately the same condition -- the scheduler sets lazy TLB mode when switching to a thread with no mm. I'm about to merge the local and remote flush code,

[RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range()

flush_tlb_page() was very similar to flush_tlb_mm_range() except that it had a couple of issues: - It was missing an smp_mb() in the case where current->active_mm != mm. (This is a longstanding bug reported by Nadav Amit.) - It was missing tracepoints and vm counter updates. The only

[RFC 07/10] x86/mm: Use new merged flush logic in arch_tlbbatch_flush()

Now there's only one copy of the local tlb flush logic for non-kernel pages on SMP kernels. The only functional change is that arch_tlbbatch_flush() will now leave_mm() on the local CPU if that CPU is in the batch and is in TLBSTATE_LAZY mode. Cc: Rik van Riel Cc: Dave Hansen Cc: Nadav Amit

Re: Adding supprot for Bluetooth 0x13d3, 0x3404 "BCM20702A0" on asus G750JX

Thanks Sent:Sunday, May 07, 2017 at 5:52 PM From:jane hondig [via Linux Kernel] ml+s2935n1381846...@n7.nabble.com To:jane hondig beautim...@cheerful.com Subject:Re: Adding supprot for Bluetooth 0x13d3, 0x3404 BCM20702A0 on asus G750JX That is clear. I went ahead with semantic.gs and got

Re: Adding supprot for Bluetooth 0x13d3, 0x3404 "BCM20702A0" on asus G750JX

Thanks Sent:Sunday, May 07, 2017 at 5:52 PM From:jane hondig [via Linux Kernel] ml+s2935n1381846...@n7.nabble.com To:jane hondig beautim...@cheerful.com Subject:Re: Adding supprot for Bluetooth 0x13d3, 0x3404 BCM20702A0 on asus G750JX That is clear. I went ahead with semantic.gs and got

<    1   2   3   4   5   >