[PATCH v3 05/11] clk: tegra: prepare dfll driver for PWM regulator

This patch prepares the dfll driver to work with PWM regulators. To do this we introduce a new array lut_uv which gives the voltage for a given index generated by the dfll logic. This index will then be translated to a PMIC voltage ID in case of I2C using the i2c_lut. In case of a PWM regulator, it

[PATCH v3 04/11] clk: tegra: add CVB tables for Tegra210 CPU DFLL

Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 426 + drivers/clk/tegra/cvb.h| 1 + 2 files changed, 427 insertions(+) diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c b/drivers/clk/tegra/clk-tegra124-d

[PATCH v3 01/11] regulator: core: add API to get voltage constraints

From: Laxman Dewangan Add API to get min/max rail voltage configured from platform for given rails. Changes to the commit message by Peter De Schrijver Signed-off-by: Laxman Dewangan --- drivers/regulator/core.c | 31 +++ include/linux/regulator/consumer

[PATCH v3 03/11] clk: tegra: dfll registration for multiple SoCs

In a future patch, support for the DFLL in Tegra210 will be introduced. This requires support for more than 1 set of CVB and CPU max frequency tables. Signed-off-by: Peter De Schrijver --- drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 37 -- 1 file changed, 30 insertio

[PATCH v3 06/11] clk: tegra: dfll: support PWM regulator control

The DFLL can directly generate a PWM signal to control the regulator IC rather then sending i2c messages. This patch adds support for this mode. In this mode the hardware LUT is not used and also there is no regulator object involved because there is no way to control the regulator voltage without

Re: [PATCH v4 4/5] irqchip/gic-v3-its: add ability to resend MAPC on resume

On 03/02/18 01:24, Derek Basehore wrote: > This adds functionality to resend the MAPC command to an ITS node on > resume. If the ITS is powered down during suspend and the collections > are not backed by memory, the ITS will lose that state. This just sets > up the known state for the collections a

Re: [PATCH v1 0/1] spi_ks8995: use regmap to access chip registers.

On Tue, Feb 6, 2018 at 11:14 AM, Andrew Lunn wrote: > Rather than invest time in this driver, it would be better to look > into writing a DSA driver. Thank you Andrew. I know little of DSA, but at first sight it appears to be a _very_ complicated beast for a switch PHY which only needs a few stat

[PATCH net] rxrpc: Fix received abort handling

AF_RXRPC is incorrectly sending back to the server any abort it receives for a client connection. This is due to the final-ACK offload to the connection event processor patch. The abort code is copied into the last-call information on the connection channel and then the event processor is set. I

[PATCH v3 0/8] use 64-bit arithmetic instead of 32-bit

Add suffix LL and ULL to various constants in order to give the compiler complete information about the proper arithmetic to use. Such constants are used in contexts that expect expressions of type u64 (64 bits, unsigned) and s64 (64 bits, signed). The mentioned expressions are currently being eva

[PATCH v3 2/8] dvb-frontends: ves1820: use 64-bit arithmetic instead of 32-bit

Add suffix ULL to constant 10 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression fpxin = state->config->xin * 10 is currently being evaluate

[PATCH v3 1/8] rtl2832: use 64-bit arithmetic instead of 32-bit in rtl2832_set_frontend

Add suffix ULL to constant 7 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression dev->pdata->clk * 7 is currently being evaluated using 32-bi

[PATCH] HID: core: Delete an error message for a failed memory allocation in open_collection()

From: Markus Elfring Date: Tue, 6 Feb 2018 17:40:51 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/hid/hid-core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 de

[PATCH v3 3/8] i2c: max2175: use 64-bit arithmetic instead of 32-bit

Add suffix LL to constant 2 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type s64 (64 bits, signed). The expression 2 * (clock_rate - abs_nco_freq) is currently being evaluated us

[PATCH v3 4/8] i2c: ov9650: use 64-bit arithmetic instead of 32-bit

Add suffix ULL to constants 1 and 100 in order to give the compiler complete information about the proper arithmetic to use. Notice that these constants are used in contexts that expect expressions of type u64 (64 bits, unsigned). The following expressions: (u64)(fi->interval.numerator *

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

Hi Kamil, Thanks for providing the fix to this issue. On 5 February 2018 at 23:10, Kamil Konieczny wrote: > > In AES-ECB mode crypt is done with key only, so any use of IV > can cause kernel Oops, as reported by Anand Moon. If possible could you avoid the name in commit message. > Fixed it by

[PATCH v2] ARM: dts: imx6ull: add Toradex Colibri iMX6ULL support

Add support for the Computer on Module Colibri iMX6ULL and its Bluetooth/Wifi variant along with the development/evaluation carrier board device trees. Follow the usual hierarchic include model, maintaining shared configuration in imx6ull-colibri.dtsi and imx6ull-colibri-eval-v3.dtsi respectively.

[PATCH v3 5/8] pci: cx88-input: use 64-bit arithmetic instead of 32-bit

Add suffix LL to constant 100 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type ktime_t (64 bits, signed). The expression ir->polling * 100 is currently being evaluated us

[PATCH] mm: Always print RLIMIT_DATA warning

The documentation for ignore_rlimit_data says that it will print a warning at first misuse. Yet it doesn't seem to do that. Fix the code to print the warning even when we allow the process to continue. Signed-off-by: David Woodhouse --- We should probably also do what Linus suggested in https://

[PATCH v7 02/24] x86/mm: Define CONFIG_SPECULATIVE_PAGE_FAULT

Introduce CONFIG_SPECULATIVE_PAGE_FAULT which turns on the Speculative Page Fault handler when building for 64bits with SMP. Cc: Thomas Gleixner Signed-off-by: Laurent Dufour --- arch/x86/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d9878

[PATCH v7 01/24] mm: Introduce CONFIG_SPECULATIVE_PAGE_FAULT

This configuration variable will be used to build the code needed to handle speculative page fault. By default it is turned off, and activated depending on architecture support. Suggested-by: Thomas Gleixner Signed-off-by: Laurent Dufour --- mm/Kconfig | 3 +++ 1 file changed, 3 insertions(+)

Re: [PATCH v1 0/1] spi_ks8995: use regmap to access chip registers.

On Tue, Feb 06, 2018 at 11:41:14AM -0500, Sven Van Asbroeck wrote: > On Tue, Feb 6, 2018 at 11:14 AM, Andrew Lunn wrote: > > Rather than invest time in this driver, it would be better to look > > into writing a DSA driver. > > Thank you Andrew. I know little of DSA, but at first sight it appears

[PATCH v7 00/24] Speculative page faults

This is a port on kernel 4.15 of the work done by Peter Zijlstra to handle page fault without holding the mm semaphore [1]. The idea is to try to handle user space page faults without holding the mmap_sem. This should allow better concurrency for massively threaded process since the page fault han

[PATCH v7 04/24] mm: Dont assume page-table invariance during faults

From: Peter Zijlstra One of the side effects of speculating on faults (without holding mmap_sem) is that we can race with free_pgtables() and therefore we cannot assume the page-tables will stick around. Remove the reliance on the pte pointer. Signed-off-by: Peter Zijlstra (Intel) In most of

[PATCH v7 03/24] powerpc/mm: Define CONFIG_SPECULATIVE_PAGE_FAULT

Define CONFIG_SPECULATIVE_PAGE_FAULT for BOOK3S_64 and SMP. This enables the Speculative Page Fault handler. Support is only provide for BOOK3S_64 currently because: - require CONFIG_PPC_STD_MMU because checks done in set_access_flags_filter() - require BOOK3S because we can't support for book3e

[PATCH v7 06/24] mm: Introduce pte_spinlock for FAULT_FLAG_SPECULATIVE

When handling page fault without holding the mmap_sem the fetch of the pte lock pointer and the locking will have to be done while ensuring that the VMA is not touched in our back. So move the fetch and locking operations in a dedicated function. Signed-off-by: Laurent Dufour --- mm/memory.c |

[PATCH v7 07/24] mm: VMA sequence count

From: Peter Zijlstra Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence counts such that we can easily test if a VMA is changed. The unmap_page_range() one allows us to make assumptions about page-tables; when we find the seqcount hasn't changed we can assume page-tables are

[PATCH v7 05/24] mm: Prepare for FAULT_FLAG_SPECULATIVE

From: Peter Zijlstra When speculating faults (without holding mmap_sem) we need to validate that the vma against which we loaded pages is still valid when we're ready to install the new PTE. Therefore, replace the pte_offset_map_lock() calls that (re)take the PTL with pte_map_lock() which can fa

[PATCH v7 11/24] mm: Cache some VMA fields in the vm_fault structure

When handling speculative page fault, the vma->vm_flags and vma->vm_page_prot fields are read once the page table lock is released. So there is no more guarantee that these fields would not change in our back. They will be saved in the vm_fault structure before the VMA is checked for changes. This

[PATCH v7 12/24] mm/migrate: Pass vm_fault pointer to migrate_misplaced_page()

migrate_misplaced_page() is only called during the page fault handling so it's better to pass the pointer to the struct vm_fault instead of the vma. This way during the speculative page fault path the saved vma->vm_flags could be used. Signed-off-by: Laurent Dufour --- include/linux/migrate.h |

[PATCH v7 14/24] mm: Introduce __maybe_mkwrite()

The current maybe_mkwrite() is getting passed the pointer to the vma structure to fetch the vm_flags field. When dealing with the speculative page fault handler, it will be better to rely on the cached vm_flags value stored in the vm_fault structure. This patch introduce a __maybe_mkwrite() servi

[PATCH v7 15/24] mm: Introduce __vm_normal_page()

When dealing with the speculative fault path we should use the VMA's field cached value stored in the vm_fault structure. Currently vm_normal_page() is using the pointer to the VMA to fetch the vm_flags value. This patch provides a new __vm_normal_page() which is receiving the vm_flags flags value

[PATCH v7 10/24] mm: Protect SPF handler against anon_vma changes

The speculative page fault handler must be protected against anon_vma changes. This is because page_add_new_anon_rmap() is called during the speculative path. In addition, don't try speculative page fault if the VMA don't have an anon_vma structure allocated because its allocation should be protec

[PATCH v7 16/24] mm: Introduce __page_add_new_anon_rmap()

When dealing with speculative page fault handler, we may race with VMA being split or merged. In this case the vma->vm_start and vm->vm_end fields may not match the address the page fault is occurring. This can only happens when the VMA is split but in that case, the anon_vma pointer of the new VM

[PATCH v7 23/24] x86/mm: Add speculative pagefault handling

From: Peter Zijlstra Try a speculative fault before acquiring mmap_sem, if it returns with VM_FAULT_RETRY continue with the mmap_sem acquisition and do the traditional fault. Signed-off-by: Peter Zijlstra (Intel) [Clearing of FAULT_FLAG_ALLOW_RETRY is now done in handle_speculative_fault()] [

[PATCH v7 22/24] mm: Speculative page fault handler return VMA

When the speculative page fault handler is returning VM_RETRY, there is a chance that VMA fetched without grabbing the mmap_sem can be reused by the legacy page fault handler. By reusing it, we avoid calling find_vma() again. To achieve, that we must ensure that the VMA structure will not be freed

[PATCH v7 24/24] powerpc/mm: Add speculative page fault

This patch enable the speculative page fault on the PowerPC architecture. This will try a speculative page fault without holding the mmap_sem, if it returns with VM_FAULT_RETRY, the mmap_sem is acquired and the traditional page fault processing is done. The speculative path is only tried for mult

[PATCH v7 21/24] perf tools: Add support for the SPF perf event

Add support for the new speculative faults event. Signed-off-by: Laurent Dufour --- tools/include/uapi/linux/perf_event.h | 1 + tools/perf/util/evsel.c | 1 + tools/perf/util/parse-events.c| 4 tools/perf/util/parse-events.l| 1 + tools/perf/util/python.c

[PATCH v7 19/24] mm: Adding speculative page fault failure trace events

This patch a set of new trace events to collect the speculative page fault event failures. Signed-off-by: Laurent Dufour --- include/trace/events/pagefault.h | 87 mm/memory.c | 62 ++-- 2 files changed, 136 in

[PATCH v7 20/24] perf: Add a speculative page fault sw event

Add a new software event to count succeeded speculative page faults. Signed-off-by: Laurent Dufour --- include/uapi/linux/perf_event.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h index e0739a1aa4b2..164383273147 100644 ---

[PATCH v7 18/24] mm: Provide speculative fault infrastructure

From: Peter Zijlstra Provide infrastructure to do a speculative fault (not holding mmap_sem). The not holding of mmap_sem means we can race against VMA change/removal and page-table destruction. We use the SRCU VMA freeing to keep the VMA around. We use the VMA seqcount to detect change (includi

[PATCH v7 17/24] mm: Protect mm_rb tree with a rwlock

This change is inspired by the Peter's proposal patch [1] which was protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in that particular case, and it is introducing major performance degradation due to excessive scheduling operations. To allow access to the mm_rb tree without

[PATCH] Documentation/process: tweak pgp maintainer guide

From: Konstantin Ryabitsev Based on the feedback provided: - Uniformly use lowercase k in "Linux kernel" - Give a one-sentence explanation of what subkeys are - Explain what signed commits might be useful for even if upstream developers do not use them for much of anything - Admonish to set up

[PATCH v3 7/8] platform: sh_veu: use 64-bit arithmetic instead of 32-bit

Cast left and top to dma_addr_t in order to give the compiler complete information about the proper arithmetic to use. Notice that these variables are being used in contexts that expect expressions of type dma_addr_t (64 bit, unsigned). Such expressions are currently being evaluated using 32-bit a

[PATCH 04/21] perf mmap: Cleanup perf_mmap__push()

From: Kan Liang The first assignment for 'start' and 'end' is redundant. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1516310792-208685-4-git-send-email-kan.li...@intel.com Signed-o

[PATCH v3 8/8] platform: vivid-cec: use 64-bit arithmetic instead of 32-bit

Add suffix ULL to constant 10 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type u64 (64 bits, unsigned). The expression len * 10 * CEC_TIM_DATA_BIT_TOTAL is currently being evalua

[PATCH 03/21] perf mmap: Recalculate size for overwrite mode

From: Kan Liang In perf_mmap__push(), the 'size' need to be recalculated, otherwise the invalid data might be pushed to the record in overwrite mode. The issue is introduced by commit 7fb4b407a124 ("perf mmap: Don't discard prev in backward mode"). When the ring buffer is full in overwrite mode

[PATCH 05/21] perf mmap: Introduce perf_mmap__read_init()

From: Kan Liang The new function perf_mmap__read_init() is factored out from perf_mmap__push(). It is to calculate the 'start' and 'end' of the available data in ringbuffer. No functional change. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc:

[PATCH 08/21] perf mmap: Introduce perf_mmap__read_done()

From: Kan Liang The direction of overwrite mode is backward. The last perf_mmap__read() will set tail to map->prev. Need to correct the map->prev to head which is the end of next read. It will be used later. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyun

[PATCH 13/21] perf evsel: Expose the perf_missing_features struct

From: Arnaldo Carvalho de Melo As tools may need to adjust to missing features, as 'perf top' will, in the next csets, to cope with a missing 'write_backward' feature. Cc: Andi Kleen Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: https://lkm

[PATCH 09/21] perf mmap: Introduce perf_mmap__read_event()

From: Kan Liang Except for 'perf record', the other perf tools read events one by one from the ring buffer using perf_mmap__read_forward(). But it only supports non-overwrite mode. Introduce perf_mmap__read_event() to support both non-overwrite and overwrite mode. Usage: perf_mmap__read_init()

[PATCH 12/21] perf top: Check per-event overwrite term

From: Kan Liang Per-event overwrite term is not forbidden in 'perf top', which can bring problems. Because 'perf top' only support non-overwrite mode now. Add new rules and check regarding to overwrite term for 'perf top'. - All events either have same per-event term or don't have per-event mo

[PATCH 11/21] perf mmap: Discard legacy interface for mmap read

From: Kan Liang Discards perf_mmap__read_backward() and perf_mmap__read_catchup(). No tools use them. There are tools still use perf_mmap__read_forward(). Keep it, but add comments to point to the new interface for future use. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: J

[PATCH 17/21] perf top: Switch default mode to overwrite mode

From: Kan Liang perf_top__mmap_read() has a severe performance issue in the Knights Landing/Mill platform, when monitoring heavy load systems. It costs several minutes to finish, which is unacceptable. Currently, 'perf top' uses the non overwrite mode. For non overwrite mode, it tries to read ev

[PATCH 19/21] perf tools: Substitute yet another strtoull()

From: Andy Shevchenko Instead of home grown function let's use what library provides us. Signed-off-by: Andriy Shevchenko Acked-by: Jiri Olsa Link: http://lkml.kernel.org/r/20180129130359.1490-1-andriy.shevche...@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/util/ut

[PATCH 2/9] perf utils: add support for pmu events vendor sub-directory

For some architectures (like arm), it is required to support a vendor sub-directory and not locate all the JSONs for a specific vendor in the same folder. This is because all the events for the same vendor will be placed in the same pmu events table, which may cause conflict. This conflict would b

[PATCH 1/9] perf vendor events: drop incomplete multiple mapfile support

Currently jevents supports multiple mapfiles, but this is only in the form where mapfile basename starts with 'mapfile.csv' At the moment, no architectures actually use multiple mapfiles, so drop the support for now. This patch also solves a nuisance where, when the mapfile is edited and the text

[PATCH 6/9] perf utils: add armv8-recommended.json

Add JSON for ARMv8 IMPLEMENTATION DEFINED recommended events. The JSON is copied from ARMv8 architecture reference manual, available here: https://static.docs.arm.com/ddi0487/ca/DDI0487C_a_armv8_arm.pdf Signed-off-by: John Garry Signed-off-by: Shaokun Zhang --- .../pmu-events/arch/arm64/armv8-

[PATCH 8/9] perf utils: fixup ARM Cortex A53 JSONs to use ARMv8 recommended events

This patch fixes the ARM Cortex-A53 json to use event definitions from the ARMv8 recommended events. The brief description is kept for readability for arch standard events, but is not strictly required. In addition to this change, other changes were made: - remove stray ',' - remove mirrored even

Re: [PATCH v1 0/1] spi_ks8995: use regmap to access chip registers.

On Tue, Feb 6, 2018 at 11:50 AM, Andrew Lunn wrote: > And a DSA driver does not need to be complex. You can start simple, > and add more features later. I see. Would it be possible/practical to start with just phy_read/write, port_enable/disable in dsa_switch_ops ? And just add a sysfs bin file f

Re: [RFC PATCH] membarrier-sync-core: Document architecture support

- On Feb 6, 2018, at 11:51 AM, efficios effic...@ubuntu.efficios.com wrote: > Ensure we gather architecture requirements about each architecture supporting > the "sync_core" membarrier command in a single file under > Documentation/features. > > [ This patch applies on top of tip sched/core.

Re: [PATCH] KVM: nVMX: Fix CR4 after VMLAUNCH/VMRESUME failure

On Mon, Feb 5, 2018 at 4:57 PM, Wanpeng Li wrote: > This is effective one, what I restore in this patch is > achitectural/guest visible. This patch doesn't "restore" the guest visible CR4 to its value at the time of VMLAUNCH/VMRESUME. It loads a new CR4 value from the vmcs12. That behavior is in

Re: [RFC 1/2] softirq: Defer net rx/tx processing to ksoftirqd context

On 2018-01-17 17:24:47 [-0500], David Miller wrote: > From: Eric Dumazet > Date: Wed, 17 Jan 2018 14:02:43 -0800 > > There is also the netif_rx_ni() stuff. > > > > Can't remember right now why it is not using > > local_bh_{diable,enable}() pair instead > > of preempt_disable() ... if (local_softi

[PATCH 9/9] perf utils: add HiSilicon hip08 JSON file

This patch adds the HiSilicon hip08 JSON file. This platform follows the ARMv8 recommended IMPLEMENTATION DEFINED events, where applicable. The brief description is kept for readability for arch defined events, but is not strictly required. Signed-off-by: John Garry --- .../arch/arm64/hisilicon

[PATCH 3/9] perf vendor events arm64: Relocate ThunderX2 JSON

Since jevents now supports vendor subdirectory, relocate the ThunderX2 JSON to Cavium subdirectory. Signed-off-by: John Garry --- .../arch/arm64/cavium/thunderx2-imp-def.json | 62 -- .../arch/arm64/cavium/thunderx2/core-imp-def.json | 62 ++ tools/

[PATCH 7/9] perf utils: fixup Cavium ThunderX2 JSON to use ARMv8 recommended events

This patch fixes the Cavium ThunderX2 JSON to use event definitions from the ARMv8 recommended events. The brief description is kept for readability for arch standard events, but is not strictly required. Signed-off-by: John Garry --- .../arch/arm64/cavium/thunderx2/core-imp-def.json | 60

[PATCH 0/9] perf events patches for improved ARM64 support

This patchset adds support for some perf events features, targeted at ARM64, implemented in a generic fashion. The two main features are as follows: - support for arch/vendor/platform pmu events directory structure - support for parsing standard architecture pmu events On the back of these, the C

[PATCH 4/9] perf vendor events arm64: Relocate Cortex A53 JSONs

The arm64 pmu-events folder structure has become disorganised, since now we have core and also vendor folders at the same level folder. Since jevents now supports vendor subdirectory, relocate the Cortex-A53 JSONs to arm vendor subdirectory. Signed-off-by: John Garry --- .../arch/arm64/arm/cort

[PATCH 5/9] perf utils: add support for arch standard events

For some architectures (like arm), there are architecture- defined events. Sometimes these events may be "recommended" according to the architecture standard, in that the implementer is free ignore the "recommendation" and create its custom event. This patch adds support for parsing standard event

[RFC PATCH] membarrier-sync-core: Document architecture support

Ensure we gather architecture requirements about each architecture supporting the "sync_core" membarrier command in a single file under Documentation/features. [ This patch applies on top of tip sched/core. ] Signed-off-by: Mathieu Desnoyers Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Peter Zijls

Re: [PATCH 3.18 00/36] 3.18.94-stable review

On Tue, Feb 06, 2018 at 06:29:16AM -0800, Guenter Roeck wrote: > On 02/05/2018 10:23 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.18.94 release. > > There are 36 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.15 00/60] 4.15.2-stable review

On Tue, Feb 06, 2018 at 06:32:43AM -0800, Guenter Roeck wrote: > On 02/05/2018 10:22 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.15.2 release. > > There are 60 patches in this series, all will be posted as a response > > to this one. If anyone has any i

Re: [PATCH v2 8/8] platform: vivid-cec: use 64-bit arithmetic instead of 32-bit

Quoting Hans Verkuil : On 02/05/18 22:54, Gustavo A. R. Silva wrote: Hi Hans, Quoting Hans Verkuil : On 02/05/2018 09:36 PM, Gustavo A. R. Silva wrote: Add suffix ULL to constant 10 in order to give the compiler complete information about the proper arithmetic to use. Notice that this cons

[PATCH 21/21] perf test: Fix test trace+probe_libc_inet_pton.sh for s390x

From: Thomas Richter On Intel test case trace+probe_libc_inet_pton.sh succeeds and the output is: [root@f27 perf]# ./perf trace --no-syscalls -e probe_libc:inet_pton/max-stack=3/ ping -6 -c 1 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.037 ms -

[PATCH v3 6/8] rockchip/rga: use 64-bit arithmetic instead of 32-bit

Cast p to dma_addr_t in order to avoid a potential integer overflow. This variable is being used in a context that expects an expression of type dma_addr_t (u64). The expression p << PAGE_SHIFT is currently being evaluated using 32-bit arithmetic. Addresses-Coverity-ID: 1458347 ("Unintentional in

[PATCH 20/21] perf data: Document missing --force option

From: Sangwon Hong Add the --force option to the man page. Signed-off-by: Sangwon Hong Cc: Jiri Olsa Cc: Namhyung Kim Cc: Taeung Song Link: http://lkml.kernel.org/r/1517831315-31490-1-git-send-email-qpa...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Documentation/perf

[PATCH 18/21] perf top: Check the latency of perf_top__mmap_read()

From: Kan Liang The latency of perf_top__mmap_read() should be lower than refresh time. If not, give some hints to reduce the latency. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan Link: http://lkml.kernel.org/r/1

[PATCH 16/21] perf top: Remove lost events checking

From: Kan Liang There would be some records lost in overwrite mode because of pausing the ringbuffer. It has little impact for the accuracy of the snapshot and could be tolerated by 'perf top'. Remove the lost events checking. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: J

[PATCH 15/21] perf hists browser: Add parameter to disable lost event warning

From: Kan Liang For overwrite mode, the ringbuffer will be paused. The event lost is expected. It needs a way to notify the browser not print the warning. It will be used later for perf top to disable lost event warning in overwrite mode. There is no behavior change for now. Signed-off-by: Kan

[PATCH 14/21] perf top: Add overwrite fall back

From: Kan Liang Switch to non-overwrite mode if kernel doesnot support overwrite ringbuffer. It's only effect when overwrite mode is supported. No change to current behavior. Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Cc: W

[PATCH 10/21] perf test: Update mmap read functions for backward-ring-buffer test

From: Kan Liang Use the new perf_mmap__read_* interfaces for overwrite ringbuffer test. Commiter notes: Testing: [root@seventh ~]# perf test -v backward 48: Read backward ring buffer : --- start --- test child forked, pid 8309 Using CPUID GenuineIntel-6-9E

[PATCH 07/21] perf mmap: Discard 'prev' in perf_mmap__read()

From: Kan Liang The 'start' and 'prev' variables are duplicates in perf_mmap__read(). Use 'map->prev' to replace 'start' in perf_mmap__read_*(). Suggested-by: Wang Nan Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan

[PATCH 02/21] perf evlist: Remove stale mmap read for backward

From: Kan Liang perf_evlist__mmap_read_catchup() and perf_evlist__mmap_read_backward() are only for overwrite mode. But they read the evlist->mmap buffer which is for non-overwrite mode. It did not bring any serious problem yet, because there is no one use it. Remove the unused interfaces. Si

[GIT PULL 00/21] perf/core improvements and fixes

ository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.17-20180206 for you to fetch changes up to 52a37001d51a320c1019269fb3ba473a1363650d: perf test: Fix test trace+probe_libc_inet_pton.sh for s390x (2018-02-06 10:4

Re: linux-next: manual merge of the tip tree with Linus' tree

- On Feb 6, 2018, at 9:11 AM, Will Deacon will.dea...@arm.com wrote: > On Tue, Feb 06, 2018 at 02:06:50PM +, Mathieu Desnoyers wrote: >> - On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote: >> > On Tue, Feb 06, 2018 at 12:52:34PM +, Mathieu Desnoyers wrote: >> >> On

[PATCH 01/21] perf vendor events aarch64: Add JSON metrics for ARM Cortex-A53 Processor

From: William Cohen Add JSON metrics for ARM Cortex-A53 Processor. Unlike the Intel processors there isn't a script that automatically generated these files. The patch was manually generated from the documentation and the previous oprofile ARM Cortex ac53 event file patch I made. The relevant d

[PATCH 06/21] perf mmap: Add new return value logic for perf_mmap__read_init()

From: Kan Liang Improve the readability by using meaningful enum (-EAGAIN, -EINVAL and 0) to replace the three returning states (0, -1 and 1). Suggested-by: Wang Nan Signed-off-by: Kan Liang Acked-by: Jiri Olsa Cc: Andi Kleen Cc: Jin Yao Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Wang Nan L

Re: [PATCH] Carrier detect ok, don't turn off negotiation

Ok, I submit it  again. In drivers/net/wan/hdlc_ppp.c, some noise on physical line can cause the carrier detect still ok, but the protocol will fail. So if carrier detect ok, don't turn off protocol negotiation This patch is against the kernel version Linux 4.15-rc8 On Tuesday, February

[PATCH v7 13/24] mm: Introduce __lru_cache_add_active_or_unevictable

The speculative page fault handler which is run without holding the mmap_sem is calling lru_cache_add_active_or_unevictable() but the vm_flags is not guaranteed to remain constant. Introducing __lru_cache_add_active_or_unevictable() which has the vma flags value parameter instead of the vma pointer

[PATCH v7 09/24] mm: protect mremap() against SPF hanlder

If a thread is remapping an area while another one is faulting on the destination area, the SPF handler may fetch the vma from the RB tree before the pte has been moved by the other thread. This means that the moved ptes will overwrite those create by the page fault handler leading to page leaked.

[PATCH] Fix a misspelling in kernel/cpu.c

From: Kangmin Park Signed-off-by: Kangmin Park Sorry for sending duplicate. A trivial path to fix a typo in kernel/cpu.c Fix 'synchronsization' to 'synchronization' --- kernel/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index 53f7dc6.

RE: [PATCH 06/14] kbuild: define PYTHON2 and PYTHON3 variables instead of PYTHON

> That's true, and who knows if python3 is running on ia64 :) $ python3 -bash: python3: command not found So I don't have it installed on my ia64 test/build machine. -Tony

[PATCH v7 08/24] mm: Protect VMA modifications using VMA sequence count

The VMA sequence count has been introduced to allow fast detection of VMA modification when running a page fault handler without holding the mmap_sem. This patch provides protection against the VMA modification done in : - madvise() - mpol_rebind_policy() - vma_replace_poli

Re: [PATCH v7 7/7] livepatch: Atomic replace and cumulative patches documentation

On Tue, Feb 06, 2018 at 11:34:24AM +0100, Petr Mladek wrote: > User documentation for the atomic replace feature. It makes it easier > to maintain livepatches using so-called cumulative patches. Thanks for adding this doc. A few minor wording suggestions and typos below... > > Signed-off-by: Pe

Re: [PATCHv2 2/3] ARM: imx53: add SoC specific PMU setup

On Tue, Feb 6, 2018 at 12:26 PM, Sebastian Reichel wrote: > From: Peter Senna Tschudin Looking at http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/277931.html this patch seems to be originally from Martin Fuzzey. In this case I would expect to see his name in the From field.

Re: [PATCH] crypto: s5p-sss.c: Fix kernel Oops in AES-ECB mode

On 06.02.2018 17:48, Anand Moon wrote: > Hi Kamil, > > Thanks for providing the fix to this issue. > > On 5 February 2018 at 23:10, Kamil Konieczny > wrote: >> >> In AES-ECB mode crypt is done with key only, so any use of IV >> can cause kernel Oops, as reported by Anand Moon. > > If possible

Re: [PATCH 1/2] char_dev: Fix off-by-one bugs in find_dynamic_major()

Thanks! On 05/02/18 07:25 PM, Srivatsa S. Bhat wrote: From: Srivatsa S. Bhat CHRDEV_MAJOR_DYN_END and CHRDEV_MAJOR_DYN_EXT_END are valid major numbers. So fix the loop iteration to include them in the search for free major numbers. While at it, also remove a redundant if condition ("cd->major

Re: [PATCH 2/2] block, char_dev: Use correct format specifier for unsigned ints

On 05/02/18 07:25 PM, Srivatsa S. Bhat wrote: From: Srivatsa S. Bhat register_blkdev() and __register_chrdev_region() treat the major number as an unsigned int. So print it the same way to avoid absurd error statements such as: "... major requested (-1) is greater than the maximum (511) ..."

Re: linux-next: manual merge of the tip tree with Linus' tree

On Tue, Feb 06, 2018 at 05:05:52PM +, Mathieu Desnoyers wrote: > - On Feb 6, 2018, at 9:11 AM, Will Deacon will.dea...@arm.com wrote: > > > On Tue, Feb 06, 2018 at 02:06:50PM +, Mathieu Desnoyers wrote: > >> - On Feb 6, 2018, at 8:55 AM, Will Deacon will.dea...@arm.com wrote: > >>

Re: [PATCH] mm: Always print RLIMIT_DATA warning

On Tue, Feb 06, 2018 at 04:45:05PM +, David Woodhouse wrote: > The documentation for ignore_rlimit_data says that it will print a warning > at first misuse. Yet it doesn't seem to do that. Fix the code to print > the warning even when we allow the process to continue. > > Signed-off-by: David

[PATCH 0/2] HID-Asus: Adjustments for two function implementations

From: Markus Elfring Date: Tue, 6 Feb 2018 18:24:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation in two functions Return an error code only as a constant in asus_start_multito

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