Re: [PATCH 3.18 32/32] mm: larger stack guard gap, between vmas

On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Hugh Dickins > > > > commit

Re: [PATCH 3.18 32/32] mm: larger stack guard gap, between vmas

On Tue, Jun 20, 2017 at 10:49:16PM -0700, Hugh Dickins wrote: > On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > > > 3.18-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Hugh Dickins > > > > commit

[PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

The ELF_ET_DYN_BASE position was originally intended to keep loaders away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2 /bin/cat" might cause the subsequent load of /bin/cat into where the loader had been loaded.) With the advent of PIE (ET_DYN binaries with an INTERP Program

[PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

The ELF_ET_DYN_BASE position was originally intended to keep loaders away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2 /bin/cat" might cause the subsequent load of /bin/cat into where the loader had been loaded.) With the advent of PIE (ET_DYN binaries with an INTERP Program

linux-next: manual merge of the scsi tree with the block tree

Hi all, Today's linux-next merge of the scsi tree got a conflict in: drivers/scsi/scsi_lib.c between commit: ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit") from the block tree and commit: 2dd6fb5957a7 ("scsi: Only add commands to the device command list if required

linux-next: manual merge of the scsi tree with the block tree

Hi all, Today's linux-next merge of the scsi tree got a conflict in: drivers/scsi/scsi_lib.c between commit: ca18d6f769d2 ("block: Make most scsi_req_init() calls implicit") from the block tree and commit: 2dd6fb5957a7 ("scsi: Only add commands to the device command list if required

Re: [PATCH 3.18 32/32] mm: larger stack guard gap, between vmas

On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Hugh Dickins > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. Here's a few adjustments to the 3.18

Re: [PATCH 3.18 32/32] mm: larger stack guard gap, between vmas

On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > 3.18-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Hugh Dickins > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. Here's a few adjustments to the 3.18 patch: no doubt

[PATCH v2] brcmfmac: Fix a memory leak in error handling path in 'brcmf_cfg80211_attach'

If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error handling path to free it in such a case. Cc: sta...@vger.kernel.org Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload support") Signed-off-by: Christophe JAILLET --- v2: Add CC tag

[PATCH v2] brcmfmac: Fix a memory leak in error handling path in 'brcmf_cfg80211_attach'

If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error handling path to free it in such a case. Cc: sta...@vger.kernel.org Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload support") Signed-off-by: Christophe JAILLET --- v2: Add CC tag Change prefix ---

Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Hugh Dickins > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. The 4.11 and 4.9 patches are fine, but I

Re: [PATCH 4.4 30/30] mm: larger stack guard gap, between vmas

On Mon, 19 Jun 2017, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Hugh Dickins > > commit 1be7107fbe18eed3e319a6c3e83c78254b693acb upstream. The 4.11 and 4.9 patches are fine, but I noticed a couple

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

On 20-06-17, 17:31, Saravana Kannan wrote: > On 06/19/2017 11:17 PM, Viresh Kumar wrote: > >On Thu, Jun 8, 2017 at 1:25 PM, Dietmar Eggemann > > wrote: > > > >>diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > > > >> static int __init

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

On 20-06-17, 17:31, Saravana Kannan wrote: > On 06/19/2017 11:17 PM, Viresh Kumar wrote: > >On Thu, Jun 8, 2017 at 1:25 PM, Dietmar Eggemann > > wrote: > > > >>diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c > > > >> static int __init register_cpufreq_notifier(void) > >>

Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages.

On 06/21/2017 04:53 AM, Ram Pai wrote: > On Tue, Jun 20, 2017 at 03:50:25PM +0530, Anshuman Khandual wrote: >> On 06/17/2017 09:22 AM, Ram Pai wrote: >>> Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 >>> in the 4K backed hpte pages. These bits continue to be used >>> for 64K backed

Re: [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages.

On 06/21/2017 04:53 AM, Ram Pai wrote: > On Tue, Jun 20, 2017 at 03:50:25PM +0530, Anshuman Khandual wrote: >> On 06/17/2017 09:22 AM, Ram Pai wrote: >>> Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 >>> in the 4K backed hpte pages. These bits continue to be used >>> for 64K backed

[PATCH v2] backlight: lm3630a: bump REG_MAX value to 0x50 instead of 0x1F

In the lm3630a_chip_init we try to write to 0x50 register, which is higher value then the max_register value, this resulted in regmap_write return -EIO. Fix this by bumping REG_MAX value to 0x50. Signed-off-by: Bhushan Shah Suggested-by: Bjorn Andersson

[PATCH v2] backlight: lm3630a: bump REG_MAX value to 0x50 instead of 0x1F

In the lm3630a_chip_init we try to write to 0x50 register, which is higher value then the max_register value, this resulted in regmap_write return -EIO. Fix this by bumping REG_MAX value to 0x50. Signed-off-by: Bhushan Shah Suggested-by: Bjorn Andersson --- Changes since v1: - Fix the

[PATCH] backlight: lm3630a: bump REG_MAX value to 0x50 instead of 0x1F

In the lm3630a_chip_init we try to write to 0x50 register, which is higher value then the max_register value, this resulted in regmap_write return -EIO. Fix this by bumping REG_MAX value to 0x50. Signed-off-by: Bhushan Shah Suggested-by: Bjorn Andersson

[PATCH] backlight: lm3630a: bump REG_MAX value to 0x50 instead of 0x1F

In the lm3630a_chip_init we try to write to 0x50 register, which is higher value then the max_register value, this resulted in regmap_write return -EIO. Fix this by bumping REG_MAX value to 0x50. Signed-off-by: Bhushan Shah Suggested-by: Bjorn Andersson ---

[PATCH] MAINTAINERS: Add Qualcomm pinctrl drivers section

Document the maintainership of the Qualcomm pinctrl drivers to improve the hitrate. Signed-off-by: Bjorn Andersson --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 75cd0dc8e93f..c2e3a349ca7c

[PATCH] MAINTAINERS: Add Qualcomm pinctrl drivers section

Document the maintainership of the Qualcomm pinctrl drivers to improve the hitrate. Signed-off-by: Bjorn Andersson --- MAINTAINERS | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 75cd0dc8e93f..c2e3a349ca7c 100644 --- a/MAINTAINERS +++

[PATCH v3 02/11] x86/ldt: Simplify LDT switching logic

Originally, Linux reloaded the LDT whenever the prev mm or the next mm had an LDT. It was changed in 0bbed3beb4f2 ("[PATCH] Thread-Local Storage (TLS) support") (from the historical tree) like this: - /* load_LDT, if either the previous or next thread -* has a

[PATCH 2/4] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago to allow a transition from the old vsyscall implementations to the new method (which simplified internal accounting and made timekeeping more precise). However, PPC and IA64 have yet to make the transition, despite in some cases me

[PATCH v3 02/11] x86/ldt: Simplify LDT switching logic

Originally, Linux reloaded the LDT whenever the prev mm or the next mm had an LDT. It was changed in 0bbed3beb4f2 ("[PATCH] Thread-Local Storage (TLS) support") (from the historical tree) like this: - /* load_LDT, if either the previous or next thread -* has a

[PATCH 2/4] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago to allow a transition from the old vsyscall implementations to the new method (which simplified internal accounting and made timekeeping more precise). However, PPC and IA64 have yet to make the transition, despite in some cases me

[PATCH v3 05/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm

There are two kernel features that would benefit from tracking how up-to-date each CPU's TLB is in the case where IPIs aren't keeping it up to date in real time: - Lazy mm switching currently works by switching to init_mm when it would otherwise flush. This is wasteful: there isn't

[PATCH v3 05/11] x86/mm: Track the TLB's tlb_gen and update the flushing algorithm

There are two kernel features that would benefit from tracking how up-to-date each CPU's TLB is in the case where IPIs aren't keeping it up to date in real time: - Lazy mm switching currently works by switching to init_mm when it would otherwise flush. This is wasteful: there isn't

[PATCH v3 03/11] x86/mm: Remove reset_lazy_tlbstate()

The only call site also calls idle_task_exit(), and idle_task_exit() puts us into a clean state by explicitly switching to init_mm. Reviewed-by: Rik van Riel Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/tlbflush.h | 8

[PATCH v3 09/11] x86/mm: Add nopcid to turn off PCID

The parameter is only present on x86_64 systems to save a few bytes, as PCID is always disabled on x86_32. Signed-off-by: Andy Lutomirski --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/kernel/cpu/common.c| 18 ++ 2

[PATCH v3 09/11] x86/mm: Add nopcid to turn off PCID

The parameter is only present on x86_64 systems to save a few bytes, as PCID is always disabled on x86_32. Signed-off-by: Andy Lutomirski --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/kernel/cpu/common.c| 18 ++ 2 files changed, 20

[PATCH v3 03/11] x86/mm: Remove reset_lazy_tlbstate()

The only call site also calls idle_task_exit(), and idle_task_exit() puts us into a clean state by explicitly switching to init_mm. Reviewed-by: Rik van Riel Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/tlbflush.h | 8 arch/x86/kernel/smpboot.c | 1 - 2 files changed,

[PATCH v3 11/11] x86/mm: Try to preserve old TLB entries using PCID

PCID is a "process context ID" -- it's what other architectures call an address space ID. Every non-global TLB entry is tagged with a PCID, only TLB entries that match the currently selected PCID are used, and we can switch PGDs without flushing the TLB. x86's PCID is 12 bits. This is an

Re: [GIT PULL][PATCH 0/4] Timekeeping items for 4.13

On Tue, Jun 20, 2017 at 10:21 PM, John Stultz wrote: > Just a small set of changes, the biggest changes being the > MONOTONIC_RAW handling cleanup, and a new kselftest from > Miroslav. Also a a clear warning deprecating > CONFIG_GENERIC_TIME_VSYSCALL_OLD, which affects ppc

[PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems

We can use PCID if the CPU has PCID and PGE and we're not on Xen. By itself, this has no effect. The next patch will start using PCID. Cc: Juergen Gross Cc: Boris Ostrovsky Signed-off-by: Andy Lutomirski ---

[PATCH v3 11/11] x86/mm: Try to preserve old TLB entries using PCID

PCID is a "process context ID" -- it's what other architectures call an address space ID. Every non-global TLB entry is tagged with a PCID, only TLB entries that match the currently selected PCID are used, and we can switch PGDs without flushing the TLB. x86's PCID is 12 bits. This is an

Re: [GIT PULL][PATCH 0/4] Timekeeping items for 4.13

On Tue, Jun 20, 2017 at 10:21 PM, John Stultz wrote: > Just a small set of changes, the biggest changes being the > MONOTONIC_RAW handling cleanup, and a new kselftest from > Miroslav. Also a a clear warning deprecating > CONFIG_GENERIC_TIME_VSYSCALL_OLD, which affects ppc and ia64. I forgot to

[PATCH v3 10/11] x86/mm: Enable CR4.PCIDE on supported systems

We can use PCID if the CPU has PCID and PGE and we're not on Xen. By itself, this has no effect. The next patch will start using PCID. Cc: Juergen Gross Cc: Boris Ostrovsky Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/tlbflush.h | 8 arch/x86/kernel/cpu/common.c| 15

[PATCH v3 06/11] x86/mm: Rework lazy TLB mode and TLB freshness tracking

x86's lazy TLB mode used to be fairly weak -- it would switch to init_mm the first time it tried to flush a lazy TLB. This meant an unnecessary CR3 write and, if the flush was remote, an unnecessary IPI. Rewrite it entirely. When we enter lazy mode, we simply remove the cpu from mm_cpumask.

[PATCH v3 06/11] x86/mm: Rework lazy TLB mode and TLB freshness tracking

x86's lazy TLB mode used to be fairly weak -- it would switch to init_mm the first time it tried to flush a lazy TLB. This meant an unnecessary CR3 write and, if the flush was remote, an unnecessary IPI. Rewrite it entirely. When we enter lazy mode, we simply remove the cpu from mm_cpumask.

[PATCH v3 01/11] x86/mm: Don't reenter flush_tlb_func_common()

It was historically possible to have two concurrent TLB flushes targetting the same CPU: one initiated locally and one initiated remotely. This can now cause an OOPS in leave_mm() at arch/x86/mm/tlb.c:47: if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) BUG(); with

[PATCH 3/4] kselftests: timers: Fix inconsistency-check to not ignore first timestamp

From: Miroslav Lichvar When the first timestamp in the list of clock readings was later than the second timestamp and all other timestamps were in order, the inconsistency was not reported because the index of the out-of-order timestamp was equal to the default value. Cc:

[PATCH v3 07/11] x86/mm: Stop calling leave_mm() in idle code

Now that lazy TLB suppresses all flush IPIs (as opposed to all but the first), there's no need to leave_mm() when going idle. This means we can get rid of the rcuidle hack in switch_mm_irqs_off() and we can unexport leave_mm(). This also removes acpi_unlazy_tlb() from the x86 and ia64 headers,

[PATCH v3 01/11] x86/mm: Don't reenter flush_tlb_func_common()

It was historically possible to have two concurrent TLB flushes targetting the same CPU: one initiated locally and one initiated remotely. This can now cause an OOPS in leave_mm() at arch/x86/mm/tlb.c:47: if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) BUG(); with

[PATCH 3/4] kselftests: timers: Fix inconsistency-check to not ignore first timestamp

From: Miroslav Lichvar When the first timestamp in the list of clock readings was later than the second timestamp and all other timestamps were in order, the inconsistency was not reported because the index of the out-of-order timestamp was equal to the default value. Cc: Thomas Gleixner Cc:

[PATCH v3 07/11] x86/mm: Stop calling leave_mm() in idle code

Now that lazy TLB suppresses all flush IPIs (as opposed to all but the first), there's no need to leave_mm() when going idle. This means we can get rid of the rcuidle hack in switch_mm_irqs_off() and we can unexport leave_mm(). This also removes acpi_unlazy_tlb() from the x86 and ia64 headers,

[PATCH v3 00/11] PCID and improved laziness

There are three performance benefits here: 1. TLB flushing is slow. (I.e. the flush itself takes a while.) This avoids many of them when switching tasks by using PCID. In a stupid little benchmark I did, it saves about 100ns on my laptop per context switch. I'll try to improve that

[GIT PULL][PATCH 0/4] Timekeeping items for 4.13

Just a small set of changes, the biggest changes being the MONOTONIC_RAW handling cleanup, and a new kselftest from Miroslav. Also a a clear warning deprecating CONFIG_GENERIC_TIME_VSYSCALL_OLD, which affects ppc and ia64. Let me know if you have any thoughts or objections! thanks -john Cc:

[PATCH v3 00/11] PCID and improved laziness

There are three performance benefits here: 1. TLB flushing is slow. (I.e. the flush itself takes a while.) This avoids many of them when switching tasks by using PCID. In a stupid little benchmark I did, it saves about 100ns on my laptop per context switch. I'll try to improve that

[GIT PULL][PATCH 0/4] Timekeeping items for 4.13

Just a small set of changes, the biggest changes being the MONOTONIC_RAW handling cleanup, and a new kselftest from Miroslav. Also a a clear warning deprecating CONFIG_GENERIC_TIME_VSYSCALL_OLD, which affects ppc and ia64. Let me know if you have any thoughts or objections! thanks -john Cc:

[PATCH v3 04/11] x86/mm: Give each mm TLB flush generation a unique ID

This adds two new variables to mmu_context_t: ctx_id and tlb_gen. ctx_id uniquely identifies the mm_struct and will never be reused. For a given mm_struct (and hence ctx_id), tlb_gen is a monotonic count of the number of times that a TLB flush has been requested. The pair (ctx_id, tlb_gen) can be

[PATCH v3 08/11] x86/mm: Disable PCID on 32-bit kernels

32-bit kernels on new hardware will see PCID in CPUID, but PCID can only be used in 64-bit mode. Rather than making all PCID code conditional, just disable the feature on 32-bit builds. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/disabled-features.h | 4 +++-

[PATCH v3 04/11] x86/mm: Give each mm TLB flush generation a unique ID

This adds two new variables to mmu_context_t: ctx_id and tlb_gen. ctx_id uniquely identifies the mm_struct and will never be reused. For a given mm_struct (and hence ctx_id), tlb_gen is a monotonic count of the number of times that a TLB flush has been requested. The pair (ctx_id, tlb_gen) can be

[PATCH v3 08/11] x86/mm: Disable PCID on 32-bit kernels

32-bit kernels on new hardware will see PCID in CPUID, but PCID can only be used in 64-bit mode. Rather than making all PCID code conditional, just disable the feature on 32-bit builds. Signed-off-by: Andy Lutomirski --- arch/x86/include/asm/disabled-features.h | 4 +++-

[PATCH 4/4] kselftests: timers: Add test for frequency step

From: Miroslav Lichvar This test checks the response of the system clock to frequency steps made with adjtimex(). The frequency error and stability of the CLOCK_MONOTONIC clock relative to the CLOCK_MONOTONIC_RAW clock is measured in two intervals following the step. The

[PATCH 1/4] time: Clean up CLOCK_MONOTONIC_RAW time handling

Now that we fixed the sub-ns handling for CLOCK_MONOTONIC_RAW, remove the duplicitive tk->raw_time.tv_nsec, which can be stored in tk->tkr_raw.xtime_nsec (similarly to how its handled for monotonic time). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Miroslav

[PATCH 4/4] kselftests: timers: Add test for frequency step

From: Miroslav Lichvar This test checks the response of the system clock to frequency steps made with adjtimex(). The frequency error and stability of the CLOCK_MONOTONIC clock relative to the CLOCK_MONOTONIC_RAW clock is measured in two intervals following the step. The test fails if values

[PATCH 1/4] time: Clean up CLOCK_MONOTONIC_RAW time handling

Now that we fixed the sub-ns handling for CLOCK_MONOTONIC_RAW, remove the duplicitive tk->raw_time.tv_nsec, which can be stored in tk->tkr_raw.xtime_nsec (similarly to how its handled for monotonic time). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Miroslav Lichvar Cc: Richard Cochran Cc: Prarit

linux-next: build warning after merge of the percpu tree

Hi all, After merging the percpu tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/linux/kernel.h:13:0, from include/linux/bitmap.h:9, from mm/percpu.c:58: mm/percpu.c: In function 'pcpu_alloc':

linux-next: build warning after merge of the percpu tree

Hi all, After merging the percpu tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/linux/kernel.h:13:0, from include/linux/bitmap.h:9, from mm/percpu.c:58: mm/percpu.c: In function 'pcpu_alloc':

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 6:40 PM, Dave Chinner wrote: > Your mangling terminology here. We don't "break COW" - we *use* > copy-on-write to break *extent sharing*. We can break extent sharing > in page_mkwrite - that's exactly what we do for normal pagecache > based mmap

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 6:40 PM, Dave Chinner wrote: > Your mangling terminology here. We don't "break COW" - we *use* > copy-on-write to break *extent sharing*. We can break extent sharing > in page_mkwrite - that's exactly what we do for normal pagecache > based mmap writes, and it's done in

Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

Re: [Ksummit-discuss] Next steps and plans for the 2017 Maintainer and Kernel Summits

On Wed, Jun 14, 2017 at 09:29:20AM -0400, Theodore Ts'o wrote: > We will use the rest of names that Linus had mentioned as being part > of his secondary list to preseed the list of people to be considered. > People who suggest topics that should be discussed on the Maintainer's > summit will be

Re: [Ksummit-discuss] Next steps and plans for the 2017 Maintainer and Kernel Summits

On Wed, Jun 14, 2017 at 09:29:20AM -0400, Theodore Ts'o wrote: > We will use the rest of names that Linus had mentioned as being part > of his secondary list to preseed the list of people to be considered. > People who suggest topics that should be discussed on the Maintainer's > summit will be

Re: [PATCH V1 09/15] spmi: pmic-arb: check apid enabled before calling the handler

On 2017-06-17 02:41, Stephen Boyd wrote: On 06/14, kgu...@codeaurora.org wrote: On 2017-06-01 02:09, Stephen Boyd wrote: >On 05/30, Kiran Gunda wrote: >>From: Abhijeet Dharmapurikar >> >>The driver currently invokes the apid handler (periph_handler()) > >You mean

Re: [PATCH V1 09/15] spmi: pmic-arb: check apid enabled before calling the handler

On 2017-06-17 02:41, Stephen Boyd wrote: On 06/14, kgu...@codeaurora.org wrote: On 2017-06-01 02:09, Stephen Boyd wrote: >On 05/30, Kiran Gunda wrote: >>From: Abhijeet Dharmapurikar >> >>The driver currently invokes the apid handler (periph_handler()) > >You mean periph_interrupt()? > Yes.

[GVT-g] [Intel-gfx] [ANNOUNCE] 2017-Q2 release of XenGT (Intel GVT-g for Xen)

Hi all, We are pleased to announce an update of Intel GVT-g for Xen. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel processor graphics. A virtual GPU instance is maintained for each VM, with part

[GVT-g] [Intel-gfx] [ANNOUNCE] 2017-Q2 release of XenGT (Intel GVT-g for Xen)

Hi all, We are pleased to announce an update of Intel GVT-g for Xen. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel processor graphics. A virtual GPU instance is maintained for each VM, with part

[GVT-g] [Intel-gfx] [ANNOUNCE] 2017-Q2 release of KVMGT (Intel GVT-g for KVM)

Hi all, We are pleased to announce an update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 5th generation Intel Core(TM) processors with Intel processor graphics. A virtual GPU instance is maintained

[GVT-g] [Intel-gfx] [ANNOUNCE] 2017-Q2 release of KVMGT (Intel GVT-g for KVM)

Hi all, We are pleased to announce an update of Intel GVT-g for KVM. Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with mediated pass-through, starting from 5th generation Intel Core(TM) processors with Intel processor graphics. A virtual GPU instance is maintained

Re: [PATCH] PM / OPP: Add dev_pm_opp_{set|put}_clkname()

On 20-06-17, 14:08, Stephen Boyd wrote: > On 06/20, Viresh Kumar wrote: > > + */ > > +struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char > > *name) > > +{ > > + struct opp_table *opp_table; > > + int ret; > > + > > + opp_table = dev_pm_opp_get_opp_table(dev); > > + if

Re: [PATCH] PM / OPP: Add dev_pm_opp_{set|put}_clkname()

On 20-06-17, 14:08, Stephen Boyd wrote: > On 06/20, Viresh Kumar wrote: > > + */ > > +struct opp_table *dev_pm_opp_set_clkname(struct device *dev, const char > > *name) > > +{ > > + struct opp_table *opp_table; > > + int ret; > > + > > + opp_table = dev_pm_opp_get_opp_table(dev); > > + if

[PATCH V2] PM / OPP: Add dev_pm_opp_{set|put}_clkname()

In order to support OPP switching, OPP layer needs to get pointer to the clock for the device. Simple cases work fine without using the routines added by this patch (i.e. by passing connection-id as NULL), but for a device with multiple clocks available, the OPP core needs to know the exact name

[PATCH V2] PM / OPP: Add dev_pm_opp_{set|put}_clkname()

In order to support OPP switching, OPP layer needs to get pointer to the clock for the device. Simple cases work fine without using the routines added by this patch (i.e. by passing connection-id as NULL), but for a device with multiple clocks available, the OPP core needs to know the exact name

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

Hi Frank, frowand.l...@gmail.com writes: > From: Frank Rowand > > Remove "phandle", "linux,phandle", and "ibm,phandle" properties from > the internal device tree. The phandle will still be in the struct > device_node phandle field and will still be displayed as if it is >

Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree

Hi Frank, frowand.l...@gmail.com writes: > From: Frank Rowand > > Remove "phandle", "linux,phandle", and "ibm,phandle" properties from > the internal device tree. The phandle will still be in the struct > device_node phandle field and will still be displayed as if it is > a property in

Re: [PATCH v3 28/31] quota: add get_inode_usage callback to transfer multi-inode charges

Tahsin, when you think we've closed on the reviews, could you send out a complete set of all of the patches on a new mail thread, using git send-email so I can make sure I'm grabbing the final version of all of the patches in this patch series? It's great that you are using separate versions for

Re: [PATCH v3 28/31] quota: add get_inode_usage callback to transfer multi-inode charges

Tahsin, when you think we've closed on the reviews, could you send out a complete set of all of the patches on a new mail thread, using git send-email so I can make sure I'm grabbing the final version of all of the patches in this patch series? It's great that you are using separate versions for

[PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

We can reuse "cap_parsing_failed" instead of keeping an additional variable here. Signed-off-by: Viresh Kumar --- drivers/base/arch_topology.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/base/arch_topology.c

[PATCH V2 0/5] arch_topology: Minor cleanups

Hi Greg, You weren't included in the first [1] version of this series, as it was targeting arch/arm*/ directories then. Here are some cleanups for the arch_topology core. Tested on ARM64 Hikey board by setting following in cpu nodes in DT: capacity-dmips-mhz = <1000>; V1->V2: - based

[PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

We can reuse "cap_parsing_failed" instead of keeping an additional variable here. Signed-off-by: Viresh Kumar --- drivers/base/arch_topology.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index

[PATCH V2 0/5] arch_topology: Minor cleanups

Hi Greg, You weren't included in the first [1] version of this series, as it was targeting arch/arm*/ directories then. Here are some cleanups for the arch_topology core. Tested on ARM64 Hikey board by setting following in cpu nodes in DT: capacity-dmips-mhz = <1000>; V1->V2: - based

[PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

Use the standard way of returning errors instead of returning 0(failure) OR 1(success) and making it hard to read. Signed-off-by: Viresh Kumar --- arch/arm/kernel/topology.c | 2 +- drivers/base/arch_topology.c | 8 2 files changed, 5 insertions(+), 5

[PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

Use the standard way of returning errors instead of returning 0(failure) OR 1(success) and making it hard to read. Signed-off-by: Viresh Kumar --- arch/arm/kernel/topology.c | 2 +- drivers/base/arch_topology.c | 8 2 files changed, 5 insertions(+), 5 deletions(-) diff --git

[PATCH V2 3/5] arch_topology: Covert switch block to if block

We only need to take care of one case here (CPUFREQ_NOTIFY) and there is no need to add an extra level of indentation to the case specific code by using a switch block. Use an if block instead. Also add some blank lines to make the code look better. Signed-off-by: Viresh Kumar

[PATCH V2 5/5] arch_topology: Localize cap_parsing_failed to topology_parse_cpu_capacity()

cap_parsing_failed is only required in topology_parse_cpu_capacity() to know if we have already tried to allocate raw_capacity and failed, or if at least one of the cpu_node didn't had the required "capacity-dmips-mhz" property. All other users can use raw_capacity instead of cap_parsing_failed.

[PATCH V2 2/5] arch_topology: Don't break lines unnecessarily

There is no need of line break at few places, avoid them. Signed-off-by: Viresh Kumar --- drivers/base/arch_topology.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index

[PATCH V2 3/5] arch_topology: Covert switch block to if block

We only need to take care of one case here (CPUFREQ_NOTIFY) and there is no need to add an extra level of indentation to the case specific code by using a switch block. Use an if block instead. Also add some blank lines to make the code look better. Signed-off-by: Viresh Kumar ---

[PATCH V2 5/5] arch_topology: Localize cap_parsing_failed to topology_parse_cpu_capacity()

cap_parsing_failed is only required in topology_parse_cpu_capacity() to know if we have already tried to allocate raw_capacity and failed, or if at least one of the cpu_node didn't had the required "capacity-dmips-mhz" property. All other users can use raw_capacity instead of cap_parsing_failed.

[PATCH V2 2/5] arch_topology: Don't break lines unnecessarily

There is no need of line break at few places, avoid them. Signed-off-by: Viresh Kumar --- drivers/base/arch_topology.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 8239a6232808..2f1d9921ee54 100644

Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

Re: [PATCH 32/51] rtc: pcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

Re: [PATCH 13/51] rtc: cpcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

Re: [PATCH 13/51] rtc: cpcap: stop using rtc deprecated functions

Hi Benjamin, [auto build test ERROR on abelloni/rtc-next] [also build test ERROR on v4.12-rc6 next-20170620] [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/Benjamin-Gaignard/rtc-stop-using-rtc

[PATCH 1/3] ASoC: fsl: mpc5200_dma: remove unused psc_dma

linux/sound/soc/fsl/mpc5200_dma.c:305:18: warning: unused variable \ psc_dma’ [-Wunused-variable] Signed-off-by: Kuninori Morimoto --- sound/soc/fsl/mpc5200_dma.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/mpc5200_dma.c

[PATCH 1/3] ASoC: fsl: mpc5200_dma: remove unused psc_dma

linux/sound/soc/fsl/mpc5200_dma.c:305:18: warning: unused variable \ psc_dma’ [-Wunused-variable] Signed-off-by: Kuninori Morimoto --- sound/soc/fsl/mpc5200_dma.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c index

Re: [PATCH] acer-wmi: Using zero as the first WMI instance number

On Tue, Jun 20, 2017 at 02:45:56PM -0700, Darren Hart wrote: > On Tue, Jun 20, 2017 at 10:46:12PM +0200, Pali Rohár wrote: > > On Tuesday 20 June 2017 19:22:46 Andy Shevchenko wrote: > > > On Tue, Jun 20, 2017 at 7:48 PM, Pali Rohár > > > wrote: > > > > On Tuesday 20 June

Re: [PATCH] acer-wmi: Using zero as the first WMI instance number

On Tue, Jun 20, 2017 at 02:45:56PM -0700, Darren Hart wrote: > On Tue, Jun 20, 2017 at 10:46:12PM +0200, Pali Rohár wrote: > > On Tuesday 20 June 2017 19:22:46 Andy Shevchenko wrote: > > > On Tue, Jun 20, 2017 at 7:48 PM, Pali Rohár > > > wrote: > > > > On Tuesday 20 June 2017 17:06:23 Lee,

  1   2   3   4   5   6   7   8   9   10   >