Re: [PATCH 1/4] w83627ehf: Use hwmon_device_register_with_info and sensor groups

On 03/22/2017 05:40 PM, Peter Huewe wrote: This patch replaces the old, deprecated call to hwmon_device_register with the new hwmon_device_register_with_info and converts the whole driver to the new hwmon interface using the hwmon_chip_info methods and the attribute_group method. Unfortunately

Re: [PATCH 1/4] w83627ehf: Use hwmon_device_register_with_info and sensor groups

On 03/22/2017 05:40 PM, Peter Huewe wrote: This patch replaces the old, deprecated call to hwmon_device_register with the new hwmon_device_register_with_info and converts the whole driver to the new hwmon interface using the hwmon_chip_info methods and the attribute_group method. Unfortunately

linux-next: Tree for Mar 23

Hi all, Changes since 20170322: The net-next tree gained a conflict against the net tree. The usb tree gained a conflict against the usb-gadget-fixes tree. The char-misc tree lost its build failure. The livepatching tree gained conflicts against the s390 tree. Non-merge commits (relative

linux-next: Tree for Mar 23

Hi all, Changes since 20170322: The net-next tree gained a conflict against the net tree. The usb tree gained a conflict against the usb-gadget-fixes tree. The char-misc tree lost its build failure. The livepatching tree gained conflicts against the s390 tree. Non-merge commits (relative

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[snip] > Let me explain it in more detail. rt5670 need to set a serious of > registers to prevent the pop noise of powering up/down muting/ > unmuting headphone. That's what rt5670_hp_event() does. But, > what rt286_hp_power_event do is only mute/unmute headphone > which is done by "HPO L" and

Re: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

[snip] > Let me explain it in more detail. rt5670 need to set a serious of > registers to prevent the pop noise of powering up/down muting/ > unmuting headphone. That's what rt5670_hp_event() does. But, > what rt286_hp_power_event do is only mute/unmute headphone > which is done by "HPO L" and

Re: [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

On 22-03-17, 18:53, Leonard Crestez wrote: > If the cpufreq driver tries to modify voltage/freq during suspend/resume > it might need to control an external PMIC via I2C or SPI but those > devices might be already suspended. > > To avoid this scenario we just increase cpufreq to highest setpoint

Re: [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

On 22-03-17, 18:53, Leonard Crestez wrote: > From: Irina Tirdea > > If there are any errors in getting the cpu0 regulators, the driver returns > -ENOENT. In case the regulators are not yet available, the devm_regulator_get > calls will return -EPROBE_DEFER, so that the

Re: [RFC 3/8] cpufreq: imx6q: Set max suspend_freq to avoid changes during suspend

On 22-03-17, 18:53, Leonard Crestez wrote: > If the cpufreq driver tries to modify voltage/freq during suspend/resume > it might need to control an external PMIC via I2C or SPI but those > devices might be already suspended. > > To avoid this scenario we just increase cpufreq to highest setpoint

Re: [RFC 2/8] cpufreq: imx6q: Fix handling EPROBE_DEFER from regulator

On 22-03-17, 18:53, Leonard Crestez wrote: > From: Irina Tirdea > > If there are any errors in getting the cpu0 regulators, the driver returns > -ENOENT. In case the regulators are not yet available, the devm_regulator_get > calls will return -EPROBE_DEFER, so that the driver can be probed

[PATCH] drivers/misc: Aspeed LPC control fix format string warning

resource_size_t is a derivative of phys_addr_t and should also be printed with %pap: drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=] dev_info(dev,

[PATCH] drivers/misc: Aspeed LPC control fix format string warning

resource_size_t is a derivative of phys_addr_t and should also be printed with %pap: drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=] dev_info(dev,

Re: [PATCH v2] cpufreq: schedutil: Trace frequency only if it has changed

On 22-03-17, 18:32, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > sugov_update_commit() calls trace_cpu_frequency() to record the > current CPU frequency if it has not changed in the fast switch case > to prevent utilities from getting confused (they may

Re: [PATCH v2] cpufreq: schedutil: Trace frequency only if it has changed

On 22-03-17, 18:32, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > sugov_update_commit() calls trace_cpu_frequency() to record the > current CPU frequency if it has not changed in the fast switch case > to prevent utilities from getting confused (they may report that the > CPU is idle if

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

Hello Peter, thanks for taking a look. On (03/22/17 18:59), Peter Zijlstra wrote: > On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote: > > sysrq is potentially even trickier. can we always wake_up() kernel > > thread from sysrq? there probably might be cases when we can't rely

Re: [RFC][PATCH 0/4] printk: introduce printing kernel thread

Hello Peter, thanks for taking a look. On (03/22/17 18:59), Peter Zijlstra wrote: > On Mon, Mar 06, 2017 at 09:45:50PM +0900, Sergey Senozhatsky wrote: > > sysrq is potentially even trickier. can we always wake_up() kernel > > thread from sysrq? there probably might be cases when we can't rely

[PATCH net-next 2/2] net: dwc-xlgmac: use dual license

The driver "dwc-xlgmac" is dual-licensed. Declare the dual license with MODULE_LICENSE(). Signed-off-by: Jie Deng --- drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH net-next 2/2] net: dwc-xlgmac: use dual license

The driver "dwc-xlgmac" is dual-licensed. Declare the dual license with MODULE_LICENSE(). Signed-off-by: Jie Deng --- drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c

[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

The driver "dwc-xlgmac" is dual-licensed. This patch adds declaration of dual license in file headers. Signed-off-by: Jie Deng --- drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++ drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++

[PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

The driver "dwc-xlgmac" is dual-licensed. This patch adds declaration of dual license in file headers. Signed-off-by: Jie Deng --- drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++ drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++

[GIT] Networking

1) Several netfilter fixes from Pablo and the crew: a) Handle fragmented packets properly in netfilter conntrack, from Florian Westphal. b) Fix SCTP ICMP packet handling, from Ying Xue. c) Fix big-endian bug in nftables, from Liping Zhang. d) Fix

[GIT] Networking

1) Several netfilter fixes from Pablo and the crew: a) Handle fragmented packets properly in netfilter conntrack, from Florian Westphal. b) Fix SCTP ICMP packet handling, from Ying Xue. c) Fix big-endian bug in nftables, from Liping Zhang. d) Fix

Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

On 2017/3/23 2:50, David Miller wrote: > From: Jie Deng > Date: Tue, 21 Mar 2017 11:59:04 +0800 > >> This patch adds declaration of dual license in file headers. >> >> Signed-off-by: Jie Deng > My apologies. I applied Arnd's patches. Could you

Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

On 2017/3/23 2:50, David Miller wrote: > From: Jie Deng > Date: Tue, 21 Mar 2017 11:59:04 +0800 > >> This patch adds declaration of dual license in file headers. >> >> Signed-off-by: Jie Deng > My apologies. I applied Arnd's patches. Could you please respin > these two patches against

Re: [RFC v0 0/2] Introduce on-chip interconnect API

On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote: > On 03/03/2017 08:21 AM, Rob Herring wrote: > > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote: > > > Modern SoCs have multiple processors and various dedicated cores (video, > > > gpu, > > > graphics, modem). These

Re: [PATCH v2 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs

Hi, Heiko 在 2017年03月21日 16:55, Heiko Stübner 写道: Hi, Am Donnerstag, 16. März 2017, 21:17:22 CET schrieb c...@rock-chips.com: + assigned-clock-parents = + < HDMIPHY>, < PLL_APLL>, + < PLL_GPLL>, <>, + <>, <>; +

Re: [RFC v0 0/2] Introduce on-chip interconnect API

On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote: > On 03/03/2017 08:21 AM, Rob Herring wrote: > > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote: > > > Modern SoCs have multiple processors and various dedicated cores (video, > > > gpu, > > > graphics, modem). These

Re: [PATCH v2 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs

Hi, Heiko 在 2017年03月21日 16:55, Heiko Stübner 写道: Hi, Am Donnerstag, 16. März 2017, 21:17:22 CET schrieb c...@rock-chips.com: + assigned-clock-parents = + < HDMIPHY>, < PLL_APLL>, + < PLL_GPLL>, <>, + <>, <>; +

RE: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

> -Original Message- > From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com] > Sent: Wednesday, March 22, 2017 1:37 PM > To: Bard Liao > Cc: broo...@kernel.org; lgirdw...@gmail.com; Oder Chiou; > alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v3] ASoC:

RE: [PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

> -Original Message- > From: Kai-Heng Feng [mailto:kai.heng.f...@canonical.com] > Sent: Wednesday, March 22, 2017 1:37 PM > To: Bard Liao > Cc: broo...@kernel.org; lgirdw...@gmail.com; Oder Chiou; > alsa-de...@alsa-project.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v3] ASoC:

Ftrace: Static function graph not work

Hi all, I test the static function graph for ARM, x86 and x86_64 architecture on linux-3.10 and linux-4.9, and I find it works correctly only for x86_64 on linux-4.9. After the following commit, the function tracer also be registered when registering the function graph tracer. commit

Ftrace: Static function graph not work

Hi all, I test the static function graph for ARM, x86 and x86_64 architecture on linux-3.10 and linux-4.9, and I find it works correctly only for x86_64 on linux-4.9. After the following commit, the function tracer also be registered when registering the function graph tracer. commit

[PATCH v1 RESEND 2/2] x86/efi: Clean up a minor mistake in code comment

EFI allocate runtime services regions from EFI_VA_START, -4G, down to -64G, EFI_VA_END. The mechanism was introduced in commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping"). Clean it up to avoid confusion. Signed-off-by: Baoquan He Cc: Matt Fleming

linux-next: manual merge of the livepatching tree with the s390 tree

Hi all, Today's linux-next merge of the livepatching tree got conflicts in: arch/s390/include/asm/thread_info.h arch/s390/kernel/entry.S between commit: 916cda1aa1b4 ("s390: add a system call for guarded storage") from the s390 tree and commits: 30d64f1904d4 ("livepatch/s390:

[PATCH v1 RESEND 2/2] x86/efi: Clean up a minor mistake in code comment

EFI allocate runtime services regions from EFI_VA_START, -4G, down to -64G, EFI_VA_END. The mechanism was introduced in commit d2f7cbe7b26a7 ("x86/efi: Runtime services virtual mapping"). Clean it up to avoid confusion. Signed-off-by: Baoquan He Cc: Matt Fleming Cc: Ard Biesheuvel Cc: Thomas

linux-next: manual merge of the livepatching tree with the s390 tree

Hi all, Today's linux-next merge of the livepatching tree got conflicts in: arch/s390/include/asm/thread_info.h arch/s390/kernel/entry.S between commit: 916cda1aa1b4 ("s390: add a system call for guarded storage") from the s390 tree and commits: 30d64f1904d4 ("livepatch/s390:

[PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. The EFI region is reserved for EFI

[PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Currently KASLR is enabled on three regions: the direct mapping of physical memory, vamlloc and vmemmap. However EFI region is also mistakenly included for VA space randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. The EFI region is reserved for EFI

[PATCH v3 6/6] powerpc/perf: Add Power8 mem_access event to sysfs

Patch add "mem_access" event to sysfs. This as-is not a raw event supported by Power8 pmu. Instead, it is formed based on raw event encoding specificed in isa207-common.h. Primary PMU event used here is PM_MRK_INST_CMPL. This event tracks only the completed marked instructions. Random sampling

[PATCH v3 6/6] powerpc/perf: Add Power8 mem_access event to sysfs

Patch add "mem_access" event to sysfs. This as-is not a raw event supported by Power8 pmu. Instead, it is formed based on raw event encoding specificed in isa207-common.h. Primary PMU event used here is PM_MRK_INST_CMPL. This event tracks only the completed marked instructions. Random sampling

[PATCH v1 RESEND 0/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Now EFI region is mistakenly counted into KASLR VA space for randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. In fact EFI region reserved for runtime services virtual mapping will be allocated using a top-down schema. It will be reused by kexec/kdump

[PATCH v1 RESEND 0/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Now EFI region is mistakenly counted into KASLR VA space for randomization because of misusing EFI_VA_START macro and assuming EFI_VA_START < EFI_VA_END. In fact EFI region reserved for runtime services virtual mapping will be allocated using a top-down schema. It will be reused by kexec/kdump

[PATCH v3 3/6] powerpc/perf: Support to export MMCRA[TEC*] field to userspace

Threshold feature when used with MMCRA [Threshold Event Counter Event], MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event Counter Multiplier] with the corresponding threshold event count values. Patch to

[PATCH v3 5/6] powerpc/perf: Support to export SIERs bit in Power9

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Sukadev Bhattiprolu Cc: Daniel Axtens Cc: Andrew Donnellan

[PATCH v3 3/6] powerpc/perf: Support to export MMCRA[TEC*] field to userspace

Threshold feature when used with MMCRA [Threshold Event Counter Event], MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event Counter Multiplier] with the corresponding threshold event count values. Patch to

[PATCH v3 5/6] powerpc/perf: Support to export SIERs bit in Power9

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Sukadev Bhattiprolu Cc: Daniel Axtens Cc: Andrew Donnellan Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin

[PATCH v3 2/6] powerpc/perf: Export memory hierarchy info to user space

The LDST field and DATA_SRC in SIER identifies the memory hierarchy level (eg: L1, L2 etc), from which a data-cache miss for a marked instruction was satisfied. Use the 'perf_mem_data_src' object to export this hierarchy level to user space. Cc: Benjamin Herrenschmidt

[PATCH v3 4/6] powerpc/perf: Support to export SIERs bit in Power8

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Daniel Axtens Cc: Andrew Donnellan Cc: Peter Zijlstra

[PATCH v3 2/6] powerpc/perf: Export memory hierarchy info to user space

The LDST field and DATA_SRC in SIER identifies the memory hierarchy level (eg: L1, L2 etc), from which a data-cache miss for a marked instruction was satisfied. Use the 'perf_mem_data_src' object to export this hierarchy level to user space. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc:

[PATCH v3 4/6] powerpc/perf: Support to export SIERs bit in Power8

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Daniel Axtens Cc: Andrew Donnellan Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Wang Nan Cc: Alexei

[PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For this to work on big endian platforms (Which is broken now), we also need a big-endian represenation of perf_mem_data_src. i.e, in a

[PATCH v3 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

From: Sukadev Bhattiprolu perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For this to work on big endian platforms (Which is broken now), we also need a big-endian represenation of perf_mem_data_src. i.e, in a big endian system, if user

[PATCH v3 0/6] powerpc/perf: Export memory hierarchy level

Power8/Power9 Perforence Monitoring Unit (PMU) supports different sampling modes (SM) such as Random Instruction Sampling (RIS), Random Load/Store Facility Sampling (RLS) and Random Branch Sampling (RBS). Sample mode RLS updates Sampled Instruction Event Register [SIER] bits with memory hierarchy

[PATCH v3 0/6] powerpc/perf: Export memory hierarchy level

Power8/Power9 Perforence Monitoring Unit (PMU) supports different sampling modes (SM) such as Random Instruction Sampling (RIS), Random Load/Store Facility Sampling (RLS) and Random Branch Sampling (RBS). Sample mode RLS updates Sampled Instruction Event Register [SIER] bits with memory hierarchy

Re: [PATCH] Documentation: Input: Add uinput documentation

On Wed, Mar 22, 2017 at 11:54:48PM -0300, Marcos Paulo de Souza wrote: > Hi Peter, > > first of all, thanks a lot for reading this patch so quickly and to > point a lot of things to make this doc way better. > > See some notes below. thanks for all the fixes, much appreciated. just two comments

Re: [PATCH] Documentation: Input: Add uinput documentation

On Wed, Mar 22, 2017 at 11:54:48PM -0300, Marcos Paulo de Souza wrote: > Hi Peter, > > first of all, thanks a lot for reading this patch so quickly and to > point a lot of things to make this doc way better. > > See some notes below. thanks for all the fixes, much appreciated. just two comments

Re: [PATCH 3/6] ftrace/x86_32: Add stack frame pointer to ftrace_caller

On Tue, 21 Mar 2017 21:35:05 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The function hook ftrace_caller does not create its own stack frame, and > this causes the ftrace stack trace to miss the first function when doing > stack

Re: [PATCH 3/6] ftrace/x86_32: Add stack frame pointer to ftrace_caller

On Tue, 21 Mar 2017 21:35:05 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > The function hook ftrace_caller does not create its own stack frame, and > this causes the ftrace stack trace to miss the first function when doing > stack traces. > > # echo schedule:stacktrace >

Re: [PATCH 4/4] zram: make deduplication feature optional

On Wed, Mar 22, 2017 at 09:00:59AM +0900, Minchan Kim wrote: > On Thu, Mar 16, 2017 at 11:46:38AM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Benefit of deduplication is dependent on the workload so it's not > > preferable to always enable. Therefore,

Re: [PATCH 4/4] zram: make deduplication feature optional

On Wed, Mar 22, 2017 at 09:00:59AM +0900, Minchan Kim wrote: > On Thu, Mar 16, 2017 at 11:46:38AM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > Benefit of deduplication is dependent on the workload so it's not > > preferable to always enable. Therefore, make it optional. > >

Re: [PATCH 3/4] zram: implement deduplication in zram

On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote: > Hi Joonsoo, > > On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > This patch implements deduplication feature in zram. The purpose > > of this work is naturally

Re: [PATCH 3/4] zram: implement deduplication in zram

On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote: > Hi Joonsoo, > > On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote: > > From: Joonsoo Kim > > > > This patch implements deduplication feature in zram. The purpose > > of this work is naturally to save amount of memory

Re: Purpose of PCI address in ranges property

On 3/20/2017 3:15 AM, Arnd Bergmann wrote: On Sun, Mar 19, 2017 at 3:14 PM, valmiki wrote: Hi, When ranges property is being parsed using of_pci_get_host_bridge_resources, the pci address is being used for calculating the offset for pci_add_resource_offset. What is this

Re: Purpose of PCI address in ranges property

On 3/20/2017 3:15 AM, Arnd Bergmann wrote: On Sun, Mar 19, 2017 at 3:14 PM, valmiki wrote: Hi, When ranges property is being parsed using of_pci_get_host_bridge_resources, the pci address is being used for calculating the offset for pci_add_resource_offset. What is this offset for ? So the

perf_callchain_user oops

Not seen this one before.. Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 task: 8804f4c85440 task.stack: c90001d38000 RIP: 0010:perf_callchain_user+0x11e/0x220 RSP: :c90001d3ba98 EFLAGS: 00010246 RAX:

perf_callchain_user oops

Not seen this one before.. Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 task: 8804f4c85440 task.stack: c90001d38000 RIP: 0010:perf_callchain_user+0x11e/0x220 RSP: :c90001d3ba98 EFLAGS: 00010246 RAX:

[PATCH v3 1/2] module: verify address is read-only

Implement a mechanism to check if a module's address is in the rodata or ro_after_init sections. It mimics the exsiting functions that test if an address is inside a module's text section. Functions that take a module as an argument will be able to verify that the module is in a read-only

[PATCH v3 2/2] extable: verify address is read-only

Provide a mechanism to check if the address of a variable is const or ro_after_init. It mimics the existing functions that test if an address is inside the kernel's text section. Other functions inside the kernel could then use this capability to verify that their arguments are read-only.

[PATCH v3 1/2] module: verify address is read-only

Implement a mechanism to check if a module's address is in the rodata or ro_after_init sections. It mimics the exsiting functions that test if an address is inside a module's text section. Functions that take a module as an argument will be able to verify that the module is in a read-only

[PATCH v3 2/2] extable: verify address is read-only

Provide a mechanism to check if the address of a variable is const or ro_after_init. It mimics the existing functions that test if an address is inside the kernel's text section. Other functions inside the kernel could then use this capability to verify that their arguments are read-only.

[PATCH v3 0/2] provide check for ro_after_init memory sections

Provide a mechanism for other functions to verify that their arguments are read-only. This implements the first half of a suggestion made by Kees Cook for the Kernel Self Protection Project: - provide mechanism to check for ro_after_init memory areas, and reject structures not marked

[PATCH v3 0/2] provide check for ro_after_init memory sections

Provide a mechanism for other functions to verify that their arguments are read-only. This implements the first half of a suggestion made by Kees Cook for the Kernel Self Protection Project: - provide mechanism to check for ro_after_init memory areas, and reject structures not marked

Re: [PATCH] Documentation: Input: Add uinput documentation

Hi Peter, first of all, thanks a lot for reading this patch so quickly and to point a lot of things to make this doc way better. See some notes below. On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote: > Thanks for this, I'm getting enough questions about this, so it's nice to >

Re: [PATCH] Documentation: Input: Add uinput documentation

Hi Peter, first of all, thanks a lot for reading this patch so quickly and to point a lot of things to make this doc way better. See some notes below. On Wed, Mar 22, 2017 at 02:03:31PM +1000, Peter Hutterer wrote: > Thanks for this, I'm getting enough questions about this, so it's nice to >

[PATCH] w83627ehf: Drop support for nct6775/nct6776

Since there exists a dedicated driver for nct6775/nct6776 it makes sense to remove support for these chips from this driver, in order to have only one code base for these types of chips. This also improves maintainability and readability (and size) of this driver. Some not so-obvious changes

[PATCH] w83627ehf: Drop support for nct6775/nct6776

Since there exists a dedicated driver for nct6775/nct6776 it makes sense to remove support for these chips from this driver, in order to have only one code base for these types of chips. This also improves maintainability and readability (and size) of this driver. Some not so-obvious changes

[PATCH] hangcheck-timer: Fix typo in comment

Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c index 4f33737..dcd37b1 100644 --- a/drivers/char/hangcheck-timer.c +++

[PATCH] hangcheck-timer: Fix typo in comment

Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c index 4f33737..dcd37b1 100644 --- a/drivers/char/hangcheck-timer.c +++

[PATCH] hangcheck-timer: Fix typo in comment

Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c index 4f33737..dcd37b1 100644 --- a/drivers/char/hangcheck-timer.c +++

[PATCH] hangcheck-timer: Fix typo in comment

Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c index 4f33737..dcd37b1 100644 --- a/drivers/char/hangcheck-timer.c +++

Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

Hi Rick, [auto build test ERROR on iio/togreg] [also build test ERROR on v4.11-rc3 next-20170322] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Rick-Altherr/Documentation-dt-bindings-Document

Re: kexec regression since 4.9 caused by efi

On 03/22/17 at 04:10pm, Ard Biesheuvel wrote: > On 21 March 2017 at 07:48, Dave Young wrote: > > On 03/20/17 at 10:14am, Dave Young wrote: > >> On 03/17/17 at 01:32pm, Matt Fleming wrote: > >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > >> > > > >> > > Matt, I think it

Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

Hi Rick, [auto build test ERROR on iio/togreg] [also build test ERROR on v4.11-rc3 next-20170322] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Rick-Altherr/Documentation-dt-bindings-Document

Re: kexec regression since 4.9 caused by efi

On 03/22/17 at 04:10pm, Ard Biesheuvel wrote: > On 21 March 2017 at 07:48, Dave Young wrote: > > On 03/20/17 at 10:14am, Dave Young wrote: > >> On 03/17/17 at 01:32pm, Matt Fleming wrote: > >> > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > >> > > > >> > > Matt, I think it should be fine

Re: [PATCH v3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-23 2:20 GMT+08:00 Jim Mattson : > Is cpu_has_vmx_invvpid() sufficient? This indicates support for the > INVVPID instruction, but not necessarily any of the desired INVVPID > types. KVM's vpid_sync_context() assumes that at least one of >

Re: [PATCH v3] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

2017-03-23 2:20 GMT+08:00 Jim Mattson : > Is cpu_has_vmx_invvpid() sufficient? This indicates support for the > INVVPID instruction, but not necessarily any of the desired INVVPID > types. KVM's vpid_sync_context() assumes that at least one of > {VMX_VPID_EXTENT_SINGLE_CONTEXT,

[PATCH v4] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

From: Wanpeng Li This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below: KVM: entry failed, hardware error 0x7 EAX= EBX= ECX= EDX=000306c3

[PATCH v4] KVM: VMX: Fix enable VPID even if INVVPID is not exposed in vmx capability

From: Wanpeng Li This can be reproduced by running L2 on L1, and disable VPID on L0 if w/o commit "KVM: nVMX: Fix nested VPID vmx exec control", the L2 crash as below: KVM: entry failed, hardware error 0x7 EAX= EBX= ECX= EDX=000306c3 ESI= EDI=

Re: [PATCH] genirq: Notify clients whenever there is change in affinity

Hi Prasad, [auto build test ERROR on tip/irq/core] [also build test ERROR on v4.11-rc3 next-20170322] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prasad-Sodagudi/genirq-Notify-clients

Re: [PATCH] genirq: Notify clients whenever there is change in affinity

Hi Prasad, [auto build test ERROR on tip/irq/core] [also build test ERROR on v4.11-rc3 next-20170322] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prasad-Sodagudi/genirq-Notify-clients

Re: [PATCH] net: stmmac: dwmac-rk: Add handling for RGMII_ID/RXID/TXID

From: Wadim Egorov Date: Wed, 22 Mar 2017 16:50:22 +0100 > @@ -74,6 +74,10 @@ struct rk_priv_data { > #define GRF_BIT(nr) (BIT(nr) | BIT(nr+16)) > #define GRF_CLR_BIT(nr) (BIT(nr+16)) > > +#define DELAY_ENABLE(soc, tx, rx) \ > + ((tx) ?

Re: [PATCH] net: stmmac: dwmac-rk: Add handling for RGMII_ID/RXID/TXID

From: Wadim Egorov Date: Wed, 22 Mar 2017 16:50:22 +0100 > @@ -74,6 +74,10 @@ struct rk_priv_data { > #define GRF_BIT(nr) (BIT(nr) | BIT(nr+16)) > #define GRF_CLR_BIT(nr) (BIT(nr+16)) > > +#define DELAY_ENABLE(soc, tx, rx) \ > + ((tx) ? soc##_GMAC_TXCLK_DLY_ENABLE :

[PATCH v3 1/3] sched/deadline: Make find_later_rq() choose a closer cpu in topology

When cpudl_find() returns any among free_cpus, the cpu might not be closer than others, considering sched domain. For example: this_cpu: 15 free_cpus: 0, 1,..., 14 (== later_mask) best_cpu: 0 topology: 0 --+ +--+ 1 --+ | +-- ... --+ 2 --+ | |

[PATCH v3 1/3] sched/deadline: Make find_later_rq() choose a closer cpu in topology

When cpudl_find() returns any among free_cpus, the cpu might not be closer than others, considering sched domain. For example: this_cpu: 15 free_cpus: 0, 1,..., 14 (== later_mask) best_cpu: 0 topology: 0 --+ +--+ 1 --+ | +-- ... --+ 2 --+ | |

Re: [PATCH] net: stmmac: add set_mac to the stmmac_ops

From: Corentin Labbe Date: Wed, 22 Mar 2017 14:29:04 +0100 > @@ -2224,7 +,8 @@ static int stmmac_release(struct net_device *dev) > free_dma_desc_resources(priv); > > /* Disable the MAC Rx/Tx */ > - stmmac_set_mac(priv->ioaddr, false); > + if

Re: [PATCH] net: stmmac: add set_mac to the stmmac_ops

From: Corentin Labbe Date: Wed, 22 Mar 2017 14:29:04 +0100 > @@ -2224,7 +,8 @@ static int stmmac_release(struct net_device *dev) > free_dma_desc_resources(priv); > > /* Disable the MAC Rx/Tx */ > - stmmac_set_mac(priv->ioaddr, false); > + if (priv->hw->mac->set_mac) > +

Re: [PATCH 2] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 21 Mar 2017 23:24:24 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes > --- > Changelog: > v2: > - remove comment about

Re: [PATCH] net: vmxnet3: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Wed, 22 Mar 2017 08:27:57 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

Re: [PATCH 2] net: virtio_net: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 21 Mar 2017 23:24:24 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes > --- > Changelog: > v2: > - remove comment about the missing hardware, > I've tested

Re: [PATCH] net: vmxnet3: use new api ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Wed, 22 Mar 2017 08:27:57 +0100 > The ethtool api {get|set}_settings is deprecated. > We move this driver to new api {get|set}_link_ksettings. > > Signed-off-by: Philippe Reynes Applied.

  1   2   3   4   5   6   7   8   9   10   >