[PATCH v7 9/9] x86/mm: Memory hotplug support for KASLR memory randomization (x86_64)

From: Thomas Garnier Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define the padding used for the physical memory mapping section when KASLR memory is enabled. It ensures there is enough virtual address space when CONFIG_MEMORY_HOTPLUG is used. The default value is 10

[PATCH v7 8/9] x86/mm: Enable KASLR for vmemmap memory region (x86_64)

From: Thomas Garnier Add vmemmap in the list of randomized memory regions. The vmemmap region holds a representation of the physical memory (through a struct page array). An attacker could use this region to disclose the kernel memory layout (walking the page linked list). Signed-off-by:

[PATCH v7 3/9] x86/mm: PUD VA support for physical mapping (x86_64)

From: Thomas Garnier Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expects the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD

[PATCH v7 0/9] x86/mm: memory area address KASLR

This is v7 of Thomas Garnier's KASLR for memory areas (physical memory mapping, vmalloc, vmemmap). It expects to be applied on top of the x86/boot tip. The current implementation of KASLR randomizes only the base address of the kernel and its modules. Research was published showing that static

[PATCH v7 3/9] x86/mm: PUD VA support for physical mapping (x86_64)

From: Thomas Garnier Minor change that allows early boot physical mapping of PUD level virtual addresses. The current implementation expects the virtual address to be PUD aligned. For KASLR memory randomization, we need to be able to randomize the offset used on the PUD table. It has no impact

[PATCH v7 0/9] x86/mm: memory area address KASLR

This is v7 of Thomas Garnier's KASLR for memory areas (physical memory mapping, vmalloc, vmemmap). It expects to be applied on top of the x86/boot tip. The current implementation of KASLR randomizes only the base address of the kernel and its modules. Research was published showing that static

[PATCH v7 2/9] x86/mm: Update physical mapping variable names (x86_64)

From: Thomas Garnier Change the variable names on kernel_physical_mapping_init and related functions to correctly reflect physical and virtual memory addresses. Also add comments on each function to describe usage and alignment constraints. Signed-off-by: Thomas Garnier

[PATCH v7 6/9] x86/mm: Enable KASLR for physical mapping memory region (x86_64)

From: Thomas Garnier Add the physical mapping in the list of randomized memory regions. The physical memory mapping holds most allocations from boot and heap allocators. Knowing the base address and physical memory size, an attacker can deduce the PDE virtual address for

[PATCH v7 2/9] x86/mm: Update physical mapping variable names (x86_64)

From: Thomas Garnier Change the variable names on kernel_physical_mapping_init and related functions to correctly reflect physical and virtual memory addresses. Also add comments on each function to describe usage and alignment constraints. Signed-off-by: Thomas Garnier Signed-off-by: Kees

[PATCH v7 6/9] x86/mm: Enable KASLR for physical mapping memory region (x86_64)

From: Thomas Garnier Add the physical mapping in the list of randomized memory regions. The physical memory mapping holds most allocations from boot and heap allocators. Knowing the base address and physical memory size, an attacker can deduce the PDE virtual address for the vDSO memory page.

[PATCH] thermal: rcar-thermal: enable hwmon when thermal_zone

From: Kuninori Morimoto rcar-thermal is supporting both thermal_zone_of_sensor_register() and thermal_zone_device_register(). But thermal_zone_of_sensor_register() doesn't enable hwmon as default. This patch enables it to keep compatibility Signed-off-by:

[PATCH] thermal: rcar-thermal: enable hwmon when thermal_zone

From: Kuninori Morimoto rcar-thermal is supporting both thermal_zone_of_sensor_register() and thermal_zone_device_register(). But thermal_zone_of_sensor_register() doesn't enable hwmon as default. This patch enables it to keep compatibility Signed-off-by: Kuninori Morimoto --- >> Zhang I

Re: + mm-compaction-split-freepages-without-holding-the-zone-lock-fix.patch added to -mm tree

On Tue, Jun 21, 2016 at 04:14:28PM -0700, a...@linux-foundation.org wrote: > > The patch titled > Subject: mm/compaction: split freepages without holding the zone lock fix > has been added to the -mm tree. Its filename is >

Re: + mm-compaction-split-freepages-without-holding-the-zone-lock-fix.patch added to -mm tree

On Tue, Jun 21, 2016 at 04:14:28PM -0700, a...@linux-foundation.org wrote: > > The patch titled > Subject: mm/compaction: split freepages without holding the zone lock fix > has been added to the -mm tree. Its filename is >

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Heiko, On Mon, Jun 13, 2016 at 3:46 PM, Heiko Stübner wrote: > Am Sonntag, 12. Juni 2016, 17:48:48 schrieb Xing Zheng: >> The functions and features VOP0 more complete than VOP1's, we need to >> use it dclk_vop0_div operate VPLLI, and let VOP0 as the default primary >> screen.

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Heiko, On Mon, Jun 13, 2016 at 3:46 PM, Heiko Stübner wrote: > Am Sonntag, 12. Juni 2016, 17:48:48 schrieb Xing Zheng: >> The functions and features VOP0 more complete than VOP1's, we need to >> use it dclk_vop0_div operate VPLLI, and let VOP0 as the default primary >> screen. >> >>

Re: [PATCH v4 0/2] ASoC: da7219: Convert driver to use generic FW functions

On Tue, Jun 21, 2016 at 10:54:39PM +, Opensource [Adam Thomson] wrote: > On 21 June 2016 23:30, Rafael J. Wysocki wrote: > > I'm fine with the first patch and the second one carries a couple of > > ACKs already, so do you want me to apply them both? None of whom are from anyone who works on

Re: [PATCH v4 0/2] ASoC: da7219: Convert driver to use generic FW functions

On Tue, Jun 21, 2016 at 10:54:39PM +, Opensource [Adam Thomson] wrote: > On 21 June 2016 23:30, Rafael J. Wysocki wrote: > > I'm fine with the first patch and the second one carries a couple of > > ACKs already, so do you want me to apply them both? None of whom are from anyone who works on

Re: cmpxchg and x86 flags output

On 06/21/16 10:24, H. Peter Anvin wrote: > On 06/21/16 02:06, David Howells wrote: >> >> However, there's probably not a great deal of difference to be had if the >> inline asm codes the appropriate instruction in each case for something like >> x86*. The emitted code ought to look the same. The

Re: cmpxchg and x86 flags output

On 06/21/16 10:24, H. Peter Anvin wrote: > On 06/21/16 02:06, David Howells wrote: >> >> However, there's probably not a great deal of difference to be had if the >> inline asm codes the appropriate instruction in each case for something like >> x86*. The emitted code ought to look the same. The

[PATCH -next 0/4] cgroup: bpf: cgroup2 membership test on skb

This series is to implement a bpf-way to check the cgroup2 membership of a skb (sk_buff). It is similar to the feature added in netfilter: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") The current target is the tc-like usage.

[PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

Adds a bpf helper, bpf_skb_in_cgroup, to decide if a skb->sk belongs to a descendant of a cgroup2. It is similar to the feature added in netfilter: commit c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") The user is expected to populate a BPF_MAP_TYPE_CGROUP_ARRAY which will be

[PATCH -next 0/4] cgroup: bpf: cgroup2 membership test on skb

This series is to implement a bpf-way to check the cgroup2 membership of a skb (sk_buff). It is similar to the feature added in netfilter: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") The current target is the tc-like usage.

[PATCH -next 3/4] cgroup: bpf: Add bpf_skb_in_cgroup_proto

Adds a bpf helper, bpf_skb_in_cgroup, to decide if a skb->sk belongs to a descendant of a cgroup2. It is similar to the feature added in netfilter: commit c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") The user is expected to populate a BPF_MAP_TYPE_CGROUP_ARRAY which will be

[PATCH -next 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

Add a BPF_MAP_TYPE_CGROUP_ARRAY and its bpf_map_ops's implementations. To update an element, the caller is expected to obtain a cgroup2 backed fd by open(cgroup2_dir) and then update the array with that fd. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc:

[PATCH -next 4/4] cgroup: bpf: Add an example to do cgroup checking in BPF

test_cgrp2_array_pin.c: A userland program that creates a bpf_map (BPF_MAP_TYPE_GROUP_ARRAY), pouplates/updates it with a cgroup2's backed fd and pins it to a bpf-fs's file. The pinned file can be loaded by tc and then used by the bpf prog later. This program can also update an existing pinned

[PATCH -next 4/4] cgroup: bpf: Add an example to do cgroup checking in BPF

test_cgrp2_array_pin.c: A userland program that creates a bpf_map (BPF_MAP_TYPE_GROUP_ARRAY), pouplates/updates it with a cgroup2's backed fd and pins it to a bpf-fs's file. The pinned file can be loaded by tc and then used by the bpf prog later. This program can also update an existing pinned

[PATCH -next 2/4] cgroup: bpf: Add BPF_MAP_TYPE_CGROUP_ARRAY

Add a BPF_MAP_TYPE_CGROUP_ARRAY and its bpf_map_ops's implementations. To update an element, the caller is expected to obtain a cgroup2 backed fd by open(cgroup2_dir) and then update the array with that fd. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Tejun

[PATCH -next 1/4] cgroup: Add cgroup_get_from_fd

Add a helper function to get a cgroup2 from a fd. It will be stored in a bpf array (BPF_MAP_TYPE_CGROUP_ARRAY) which will be introduced in the later patch. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Tejun Heo

[PATCH -next 1/4] cgroup: Add cgroup_get_from_fd

Add a helper function to get a cgroup2 from a fd. It will be stored in a bpf array (BPF_MAP_TYPE_CGROUP_ARRAY) which will be introduced in the later patch. Signed-off-by: Martin KaFai Lau Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Tejun Heo --- include/linux/cgroup.h | 1 +

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, > cap_t *cap, >

[PATCH] media: s5p-mfc fix null pointer deference in clk_core_enable()

Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. At this point, system hangs and needs to be power cycled. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release()

Re: [PATCH v7 3/5] tpm: Clean up reading of timeout and duration capabilities

On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote: > --- a/drivers/char/tpm/tpm-interface.c > +++ b/drivers/char/tpm/tpm-interface.c > @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id, > cap_t *cap, > tpm_cmd.params.getcap_in.subcap_size =

[PATCH] media: s5p-mfc fix null pointer deference in clk_core_enable()

Fix null pointer deference in clk_core_enable() when driver unbind is run when there is an application has an active pipeline playing. At this point, system hangs and needs to be power cycled. s5p_mfc_release() gets called after s5p_mfc_final_pm() disables and does clk_put() and s5p_mfc_release()

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

On Tue, Jun 21, 2016 at 11:12:54PM +0200, Julia Lawall wrote: > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote: > > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit : > > > Help Coccinelle when used against Linux with a set of sensible defaults > > > options for Linux. This hints to coccinelle

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

On Tue, Jun 21, 2016 at 11:12:54PM +0200, Julia Lawall wrote: > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote: > > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit : > > > Help Coccinelle when used against Linux with a set of sensible defaults > > > options for Linux. This hints to coccinelle

Re: [4.7-rc3 June 16th code][EXT4] Rename file corruption?

On Thu, Jun 16, 2016 at 01:47:57AM -0700, Christoph Hellwig wrote: > We see somewhat similar rename corruption on XFS, also under heavy > compile workloads. The reporters have already ruled out the XFS changes > from the 4.7 merge window, so this looks a lot like the VFS changes > that went into

Re: [4.7-rc3 June 16th code][EXT4] Rename file corruption?

On Thu, Jun 16, 2016 at 01:47:57AM -0700, Christoph Hellwig wrote: > We see somewhat similar rename corruption on XFS, also under heavy > compile workloads. The reporters have already ruled out the XFS changes > from the 4.7 merge window, so this looks a lot like the VFS changes > that went into

Re: [PATCH v3 7/8] coccicheck: refer to coccicheck bottest wiki for documentation

On Tue, Jun 21, 2016 at 11:18:41PM +0200, Julia Lawall wrote: > > > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote: > > > Hi, > > > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit : > > > Sprinkling *tons* of documentation on the script is not a good > > > idea, instead refer to a wiki for

Re: [PATCH v3 7/8] coccicheck: refer to coccicheck bottest wiki for documentation

On Tue, Jun 21, 2016 at 11:18:41PM +0200, Julia Lawall wrote: > > > On Tue, 21 Jun 2016, Nicolas Palix (LIG) wrote: > > > Hi, > > > > Le 21/06/16 à 21:21, Luis R. Rodriguez a écrit : > > > Sprinkling *tons* of documentation on the script is not a good > > > idea, instead refer to a wiki for

Re: [PATCH 1/4] drivers: input: powerkey for HISI 65xx SoC

On Tue, Jun 14, 2016 at 3:43 PM, John Stultz wrote: > From: Jorge Ramirez-Ortiz > > This driver provides a input driver for the power button on the > HiSi 65xx SoC for boards like HiKey. > > This driver was originally by Zhiliang Xue

Re: [PATCH 1/4] drivers: input: powerkey for HISI 65xx SoC

On Tue, Jun 14, 2016 at 3:43 PM, John Stultz wrote: > From: Jorge Ramirez-Ortiz > > This driver provides a input driver for the power button on the > HiSi 65xx SoC for boards like HiKey. > > This driver was originally by Zhiliang Xue > then basically rewritten by Jorge, but preserving the

Re: camera application for testing (was Re: v4l subdevs without big device)

Hi Sakari, On Sunday 01 May 2016 17:08:31 Sakari Ailus wrote: > On Sat, Apr 30, 2016 at 12:13:59AM +0200, Pavel Machek wrote: > > Hi! > > > > What is reasonable camera application for testing? > > > > N900 looks like a low-end digital camera. I have now have the hardware > > working (can set

Re: [PATCH] ACPI: Execute the _PTS method when system reboot

On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote: > The _PTS control method is defined in the section 7.4.1 of acpi 6.0 > spec. The _PTS control method is executed by the OS during the sleep > transition process for S1, S2, S3, S4, and for orderly S5 shutdown. > The sleeping state value (For

Re: camera application for testing (was Re: v4l subdevs without big device)

Hi Sakari, On Sunday 01 May 2016 17:08:31 Sakari Ailus wrote: > On Sat, Apr 30, 2016 at 12:13:59AM +0200, Pavel Machek wrote: > > Hi! > > > > What is reasonable camera application for testing? > > > > N900 looks like a low-end digital camera. I have now have the hardware > > working (can set

Re: [PATCH] ACPI: Execute the _PTS method when system reboot

On Monday, May 09, 2016 05:50:11 AM Ocean HY1 He wrote: > The _PTS control method is defined in the section 7.4.1 of acpi 6.0 > spec. The _PTS control method is executed by the OS during the sleep > transition process for S1, S2, S3, S4, and for orderly S5 shutdown. > The sleeping state value (For

Re: [PATCH v2 00/17] DS1341 support and code cleanup

>> >> Andrey Smirnov (17): >> RTC: ds1307: Add DS1341 variant >> RTC: ds1307: Disable square wave and timers as default >> RTC: ds1307: Add devicetree bindings for DS1341 >> RTC: ds1307: Add DS1341 specific power-saving options >> RTC: ds1307: Convert ds1307_can_wakeup_device into a

Re: [PATCH v2 00/17] DS1341 support and code cleanup

>> >> Andrey Smirnov (17): >> RTC: ds1307: Add DS1341 variant >> RTC: ds1307: Disable square wave and timers as default >> RTC: ds1307: Add devicetree bindings for DS1341 >> RTC: ds1307: Add DS1341 specific power-saving options >> RTC: ds1307: Convert ds1307_can_wakeup_device into a

[PATCH v2] ASoC: cs53l30: Add MUTE pin control support via GPIO

The codec chip has a physical MUTE pin to let users control it via GPIO. So this patch add a mute control support to the driver. Signed-off-by: Nicolin Chen --- Changelog: v1->v2 * Revise the DT binding part regarding the active state of the mute pin

[PATCH v2] ASoC: cs53l30: Add MUTE pin control support via GPIO

The codec chip has a physical MUTE pin to let users control it via GPIO. So this patch add a mute control support to the driver. Signed-off-by: Nicolin Chen --- Changelog: v1->v2 * Revise the DT binding part regarding the active state of the mute pin .../devicetree/bindings/sound/cs53l30.txt

Re: [PATCH v2 02/17] RTC: ds1307: Disable square wave and timers as default

On Tue, Jun 21, 2016 at 2:17 PM, Alexandre Belloni wrote: > On 21/06/2016 at 00:22:35 -0700, Andrey Smirnov wrote : >> Disable square wave and timers as default for DS1337/39/41 and >> DS3231. The rationale being that configuring a chip this way puts it >>

Re: [PATCH v2 02/17] RTC: ds1307: Disable square wave and timers as default

On Tue, Jun 21, 2016 at 2:17 PM, Alexandre Belloni wrote: > On 21/06/2016 at 00:22:35 -0700, Andrey Smirnov wrote : >> Disable square wave and timers as default for DS1337/39/41 and >> DS3231. The rationale being that configuring a chip this way puts it >> into a known state with lower power

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

On Tue, Jun 21, 2016 at 10:29:53PM +0200, Julia Lawall wrote: [...] > mkid -i C --output .id-utils.index > > [...] Coccinelle searches for the index in the directory > on which it is working Can you clarify if this is $PWD from which we spawn spatch or the --dir, or the current directory that

Re: [PATCH v3 5/8] scripts: add Linux .cocciconfig for coccinelle

On Tue, Jun 21, 2016 at 10:29:53PM +0200, Julia Lawall wrote: [...] > mkid -i C --output .id-utils.index > > [...] Coccinelle searches for the index in the directory > on which it is working Can you clarify if this is $PWD from which we spawn spatch or the --dir, or the current directory that

Re: [PATCH] compat: remove compat_printk

On Fri, 17 Jun 2016 16:26:21 +0200 Arnd Bergmann wrote: > After 7e8e385aaf6e ("x86/compat: Remove sys32_vm86_warning"), this > function has become unused, so we can remove it as well. hm, > @@ -1077,15 +1076,6 @@ static struct ctl_table kern_table[] = { > .extra1

Re: [PATCH] compat: remove compat_printk

On Fri, 17 Jun 2016 16:26:21 +0200 Arnd Bergmann wrote: > After 7e8e385aaf6e ("x86/compat: Remove sys32_vm86_warning"), this > function has become unused, so we can remove it as well. hm, > @@ -1077,15 +1076,6 @@ static struct ctl_table kern_table[] = { > .extra1 = _one,

Re: [LKP] [lkp] [x86 tsc] 19fa5e7364: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x72/0x80

2016-06-21 21:59 GMT+08:00 Wanpeng Li : > Hi Paolo, > 2016-06-21 18:24 GMT+08:00 Wanpeng Li : >> 2016-06-21 18:10 GMT+08:00 Paolo Bonzini : >>> >>> >>> On 21/06/2016 08:08, Wanpeng Li wrote: Cc KVM ML, Paolo, Radim, >> FYI,

Re: [LKP] [lkp] [x86 tsc] 19fa5e7364: WARNING: CPU: 0 PID: 0 at arch/x86/mm/extable.c:50 ex_handler_rdmsr_unsafe+0x72/0x80

2016-06-21 21:59 GMT+08:00 Wanpeng Li : > Hi Paolo, > 2016-06-21 18:24 GMT+08:00 Wanpeng Li : >> 2016-06-21 18:10 GMT+08:00 Paolo Bonzini : >>> >>> >>> On 21/06/2016 08:08, Wanpeng Li wrote: Cc KVM ML, Paolo, Radim, >> FYI, raw QEMU command line is: >> >>

Re: [PATCH v4 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On Mon, Jun 20, 2016 at 12:56 PM, Aleksey Makarov wrote: > Hi Rafael, > > You said you are ok with the ACPI part of the patches [4]. > The patchset has received ACK from Will [5]. Can you consider pulling it > please? I've queued this up for v4.8, but can you please

Re: [PATCH v4 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

On Mon, Jun 20, 2016 at 12:56 PM, Aleksey Makarov wrote: > Hi Rafael, > > You said you are ok with the ACPI part of the patches [4]. > The patchset has received ACK from Will [5]. Can you consider pulling it > please? I've queued this up for v4.8, but can you please base your patches on the

Re: ktime_get_ts64() splat during resume

On Tuesday, June 21, 2016 11:04:41 AM Kees Cook wrote: > On Mon, Jun 20, 2016 at 9:35 PM, Logan Gunthorpe wrote: > > Hey Rafael, > > > > This patch appears to be working on my laptop. Thanks. > > Same for me: resume still works with KASLR in my tests too. Thanks for the

Re: ktime_get_ts64() splat during resume

On Tuesday, June 21, 2016 11:04:41 AM Kees Cook wrote: > On Mon, Jun 20, 2016 at 9:35 PM, Logan Gunthorpe wrote: > > Hey Rafael, > > > > This patch appears to be working on my laptop. Thanks. > > Same for me: resume still works with KASLR in my tests too. Thanks for the confirmation! Rafael

Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options

> So wouldn't you want to set one mode while running and the lower power > mode while suspended? I'm trying to understand the frequency of changing > this. If it is always one setting for a board, then yes it belongs in > DT. If it is a user decision, then it probably shouldn't be in DT. I don't

Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options

> So wouldn't you want to set one mode while running and the lower power > mode while suspended? I'm trying to understand the frequency of changing > this. If it is always one setting for a board, then yes it belongs in > DT. If it is a user decision, then it probably shouldn't be in DT. I don't

RE: [PATCH v4 0/2] ASoC: da7219: Convert driver to use generic FW functions

On 21 June 2016 23:30, Rafael J. Wysocki wrote: > > This patch set converts the da7219 codec driver to use device/fwnode > > functions > > to access properties, instead of the DT only of_* functions, allowing ACPI > > to be used as well. > > > > The DT bindings for da7219 have a device node for

RE: [PATCH v4 0/2] ASoC: da7219: Convert driver to use generic FW functions

On 21 June 2016 23:30, Rafael J. Wysocki wrote: > > This patch set converts the da7219 codec driver to use device/fwnode > > functions > > to access properties, instead of the DT only of_* functions, allowing ACPI > > to be used as well. > > > > The DT bindings for da7219 have a device node for

[PATCH] Input: elantech - add more IC body types to the list

The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and according to Elan both 11 and 12 are valid IC types and should be identified as hw_version 4. Reported-by: Patrick Lessard Signed-off-by: Dmitry Torokhov ---

[PATCH] Input: elantech - add more IC body types to the list

The touchpad in HP Pavilion 14-ab057ca reports it's version as 12 and according to Elan both 11 and 12 are valid IC types and should be identified as hw_version 4. Reported-by: Patrick Lessard Signed-off-by: Dmitry Torokhov --- drivers/input/mouse/elantech.c | 8 +--- 1 file changed, 1

sparse bad constant expression caused by 7322dd755e7d ("byteswap: try to avoid __builtin_constant_p gcc bug", 2016-05-05)

Hi, I recently ran into a sparse error when running sparse on Intel's i40e kernel driver against v4.7-rc3. CC [M] drivers/net/ethernet/intel/i40e/i40e_nvm.o include/linux/sctp.h:172:51: error: bad constant expression include/linux/sctp.h:174:51: error: bad constant expression

sparse bad constant expression caused by 7322dd755e7d ("byteswap: try to avoid __builtin_constant_p gcc bug", 2016-05-05)

Hi, I recently ran into a sparse error when running sparse on Intel's i40e kernel driver against v4.7-rc3. CC [M] drivers/net/ethernet/intel/i40e/i40e_nvm.o include/linux/sctp.h:172:51: error: bad constant expression include/linux/sctp.h:174:51: error: bad constant expression

Re: [PATCH 0/5] Fix and improve clock controller for the RK322x SoCs

Am Dienstag, 21. Juni 2016, 12:53:26 schrieb Xing Zheng: > Hi, > These patchset fix some clocks bugs, and improve clock configuration > for i2s/spdif/MAC on RK322x SoCs. applied to my clock-branch with the following changes: - fixed the error in patch1 - missing ")" in COMPOSITE_FRAC(0,

Re: [PATCH 0/5] Fix and improve clock controller for the RK322x SoCs

Am Dienstag, 21. Juni 2016, 12:53:26 schrieb Xing Zheng: > Hi, > These patchset fix some clocks bugs, and improve clock configuration > for i2s/spdif/MAC on RK322x SoCs. applied to my clock-branch with the following changes: - fixed the error in patch1 - missing ")" in COMPOSITE_FRAC(0,

Re: [PATCH v2 13/17] RTC: ds1307: Report oscillator problems more intelligently

On Tue, Jun 21, 2016 at 2:22 PM, Alexandre Belloni wrote: > On 21/06/2016 at 00:22:46 -0700, Andrey Smirnov wrote : >> Report oscillator problems more intelligently, by printing more >> information about what cause the issue and not yelling "SET TIME!" at >>

Re: [PATCH v2 13/17] RTC: ds1307: Report oscillator problems more intelligently

On Tue, Jun 21, 2016 at 2:22 PM, Alexandre Belloni wrote: > On 21/06/2016 at 00:22:46 -0700, Andrey Smirnov wrote : >> Report oscillator problems more intelligently, by printing more >> information about what cause the issue and not yelling "SET TIME!" at >> the user. >> > > Well, the proper way

[PATCH] clk: qcom: Remove gcc_aggre1_pnoc_ahb_clk from msm8996

This clk is critical to operation of the SoC and should never be turned off. Furthermore, there are no consumers of this clk so let's just delete it so things like eMMC work. Reported-by: Srinivas Kandagatla Signed-off-by: Stephen Boyd ---

[PATCH] clk: qcom: Remove gcc_aggre1_pnoc_ahb_clk from msm8996

This clk is critical to operation of the SoC and should never be turned off. Furthermore, there are no consumers of this clk so let's just delete it so things like eMMC work. Reported-by: Srinivas Kandagatla Signed-off-by: Stephen Boyd --- drivers/clk/qcom/gcc-msm8996.c | 16

Re: [PATCH v02 2/5] perf/x86/intel: fix for MSR_LAST_BRANCH_FROM_x bug when no TSX

> This patch introduces it for wrmsrl's done for testing LBR support. > Future patch in series adds the quirk for context switch, that would > be required if LBR callstack is to be enabled for ring 0. Patches are fine for me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH v02 2/5] perf/x86/intel: fix for MSR_LAST_BRANCH_FROM_x bug when no TSX

> This patch introduces it for wrmsrl's done for testing LBR support. > Future patch in series adds the quirk for context switch, that would > be required if LBR callstack is to be enabled for ring 0. Patches are fine for me. Reviewed-by: Andi Kleen -Andi

Re: [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq

On Tue, Jun 21, 2016 at 06:23:34PM -0400, Rik van Riel wrote: > > >   cpu = smp_processor_id(); > > Per this smp_processor_id() usage, preemption is disabled. > > This code is called from the timer code. Surely preemption > is already disabled? That's what I said. > > > > > > + /* > > > +  *

Re: [PATCH 5/5] irqtime: drop local_irq_save/restore from irqtime_account_irq

On Tue, Jun 21, 2016 at 06:23:34PM -0400, Rik van Riel wrote: > > >   cpu = smp_processor_id(); > > Per this smp_processor_id() usage, preemption is disabled. > > This code is called from the timer code. Surely preemption > is already disabled? That's what I said. > > > > > > + /* > > > +  *

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 8:07 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 11:01 AM, wrote: >>> -Original Message- >>> From: Peter Jones [mailto:pjo...@redhat.com] >>> Sent: Tuesday, June 21, 2016 10:19 AM >>> To: Rafael J. Wysocki

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 8:07 PM, Andy Lutomirski wrote: > On Tue, Jun 21, 2016 at 11:01 AM, wrote: >>> -Original Message- >>> From: Peter Jones [mailto:pjo...@redhat.com] >>> Sent: Tuesday, June 21, 2016 10:19 AM >>> To: Rafael J. Wysocki >>> Cc: ACPI Devel Maling List ; Limonciello,

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 8:01 PM, wrote: >> -Original Message- >> From: Peter Jones [mailto:pjo...@redhat.com] >> Sent: Tuesday, June 21, 2016 10:19 AM >> To: Rafael J. Wysocki >> Cc: ACPI Devel Maling List ;

Re: [PATCH] ACPI: don't show an error when we're not in charge of PCIe hotplug.

On Tue, Jun 21, 2016 at 8:01 PM, wrote: >> -Original Message- >> From: Peter Jones [mailto:pjo...@redhat.com] >> Sent: Tuesday, June 21, 2016 10:19 AM >> To: Rafael J. Wysocki >> Cc: ACPI Devel Maling List ; Limonciello, Mario >> ; Linux Kernel Mailing List > ker...@vger.kernel.org>;

Re: [PATCH] ASoC: cs53l30: Add MUTE pin control support via GPIO

On Tue, Jun 21, 2016 at 04:34:37PM -0500, Rob Herring wrote: > On Mon, Jun 20, 2016 at 06:54:44PM -0700, Nicolin Chen wrote: > > The codec chip has a physical MUTE pin to let users control it via > > GPIO. So this patch add a mute control support to the driver. > > > > Signed-off-by: Nicolin Chen

Re: [PATCH] ASoC: cs53l30: Add MUTE pin control support via GPIO

On Tue, Jun 21, 2016 at 04:34:37PM -0500, Rob Herring wrote: > On Mon, Jun 20, 2016 at 06:54:44PM -0700, Nicolin Chen wrote: > > The codec chip has a physical MUTE pin to let users control it via > > GPIO. So this patch add a mute control support to the driver. > > > > Signed-off-by: Nicolin Chen

[PATCH v2 1/6] Documentation: hid: Intel ISH HID document

Document explaining ISH HID operation and implementation. Signed-off-by: Srinivas Pandruvada --- Documentation/hid/intel-ish-hid.txt | 449 1 file changed, 449 insertions(+) create mode 100644

[PATCH v2 2/6] hid: intel_ish-hid: ISH Transport layer

From: Daniel Drubin The ISH transport layer (ishtp) is a bi-directional protocol implemented on the top of PCI based inter processor communication layer. This layer offers: - Connection management - Flow control with the firmware - Multiple client sessions - Client

[PATCH v2 1/6] Documentation: hid: Intel ISH HID document

Document explaining ISH HID operation and implementation. Signed-off-by: Srinivas Pandruvada --- Documentation/hid/intel-ish-hid.txt | 449 1 file changed, 449 insertions(+) create mode 100644 Documentation/hid/intel-ish-hid.txt diff --git

[PATCH v2 2/6] hid: intel_ish-hid: ISH Transport layer

From: Daniel Drubin The ISH transport layer (ishtp) is a bi-directional protocol implemented on the top of PCI based inter processor communication layer. This layer offers: - Connection management - Flow control with the firmware - Multiple client sessions - Client message transfer - Client

[PATCH v2 6/6] hid: hid-sensor-hub: Add ISH quirk

Need enum quirk to change the base of enums to 1 for power and report descriptors. Signed-off-by: Srinivas Pandruvada --- drivers/hid/hid-sensor-hub.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/hid/hid-sensor-hub.c

[PATCH v2 3/6] hid: intel-ish-hid: ipc layer

From: Daniel Drubin This layer is responsible for - Enumerating over PCI bus - Inform FW about host readiness - Provide HW interface to transport layer for control and messages - Interrupt handling and routing Signed-off-by: Srinivas Pandruvada

[PATCH v2 6/6] hid: hid-sensor-hub: Add ISH quirk

Need enum quirk to change the base of enums to 1 for power and report descriptors. Signed-off-by: Srinivas Pandruvada --- drivers/hid/hid-sensor-hub.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 3d5ba5b..658a607

[PATCH v2 3/6] hid: intel-ish-hid: ipc layer

From: Daniel Drubin This layer is responsible for - Enumerating over PCI bus - Inform FW about host readiness - Provide HW interface to transport layer for control and messages - Interrupt handling and routing Signed-off-by: Srinivas Pandruvada --- drivers/hid/intel-ish-hid/Makefile

[PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

Change log v2: - Overview in documentation show analogy with usbhid implementation - sparse errors for statics. Also pointed by Jiri - Clearly marking exported function header file. Clean up all exports unused inteface functions - Changed to tristate from boolean as pointed by Jiri: this required

[PATCH v2 4/6] hid: intel-ish-hid: ISH HID client driver

From: Daniel Drubin This driver is responsible for implementing ISH HID client, which gets HID description and report. Once it has completely gets report descriptors, it registers as a HID LL drivers. This implements necessary callbacks so that it can be used by HID

[PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

Change log v2: - Overview in documentation show analogy with usbhid implementation - sparse errors for statics. Also pointed by Jiri - Clearly marking exported function header file. Clean up all exports unused inteface functions - Changed to tristate from boolean as pointed by Jiri: this required

[PATCH v2 4/6] hid: intel-ish-hid: ISH HID client driver

From: Daniel Drubin This driver is responsible for implementing ISH HID client, which gets HID description and report. Once it has completely gets report descriptors, it registers as a HID LL drivers. This implements necessary callbacks so that it can be used by HID sensor hub driver.

[PATCH v2 5/6] iio: hid-sensors: use asynchronous resume

Some platforms power off sensor hubs during S3 suspend, which will require longer time to resume. This hurts system resume time, so resume asynchronously. Signed-off-by: Srinivas Pandruvada --- drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 21

[PATCH v2 5/6] iio: hid-sensors: use asynchronous resume

Some platforms power off sensor hubs during S3 suspend, which will require longer time to resume. This hurts system resume time, so resume asynchronously. Signed-off-by: Srinivas Pandruvada --- drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 21 -

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