Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support

On Mon, Aug 22, 2016 at 05:35:50PM -0500, Tom Lendacky wrote: > For processors that support PAT, set the write-protect cache mode > (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). > > Signed-off-by: Tom Lendacky > --- > arch/x86/mm/pat.c |4 ++--

Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support

On Mon, Aug 22, 2016 at 05:35:50PM -0500, Tom Lendacky wrote: > For processors that support PAT, set the write-protect cache mode > (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). > > Signed-off-by: Tom Lendacky > --- > arch/x86/mm/pat.c |4 ++-- > 1 file changed, 2

[PATCH] [IA64] MCA: Use kmalloc_array() in init_record_index_pools()

From: Markus Elfring Date: Thu, 25 Aug 2016 07:37:46 +0200 * A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kmalloc_array". This issue was

Re: [patch 1/2] i2c: add master driver for mellanox systems

Hi Vadim, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.8-rc3 next-20160824] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

[PATCH] [IA64] MCA: Use kmalloc_array() in init_record_index_pools()

From: Markus Elfring Date: Thu, 25 Aug 2016 07:37:46 +0200 * A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kmalloc_array". This issue was detected by using the

Re: [patch 1/2] i2c: add master driver for mellanox systems

Hi Vadim, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.8-rc3 next-20160824] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for convenience) to rec

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

On Thu, Aug 25, 2016 at 1:54 AM, Bjorn Helgaas wrote: > [+cc Ray, Scott, Jon, bcm-kernel-feedback-list] > > On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote: >> On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas wrote: >> > On Fri, Aug 19, 2016 at

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

On Thu, Aug 25, 2016 at 1:54 AM, Bjorn Helgaas wrote: > [+cc Ray, Scott, Jon, bcm-kernel-feedback-list] > > On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote: >> On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas wrote: >> > On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:

Re: [PATCH 21/34] clk: nspire: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Daniel Tang

Re: [PATCH 21/34] clk: nspire: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Daniel Tang > Signed-off-by:

Re: [PATCH 06/34] clk: bcm: kona: Migrate to clk_hw based registration and OF APIs

On 06/01, Stephen Boyd wrote: > Now that we can use clk_hw pointers we don't need to have two > duplicate arrays holding the same mapping of clk index to clk_hw > pointer. Implement a custom clk_hw provider function to map the > OF specifier to the clk_hw instance for it. > > Cc: Alex Elder

Re: [PATCH 2/3] docs: split up the driver book

Em Wed, 24 Aug 2016 16:46:22 -0600 Jonathan Corbet escreveu: > On Tue, 23 Aug 2016 11:30:16 -0300 > Mauro Carvalho Chehab wrote: > > > On the output text, you'll see two places with "@:c:func:threadfn()". > > > > The problem here is that threadfn() is

Re: [PATCH 06/34] clk: bcm: kona: Migrate to clk_hw based registration and OF APIs

On 06/01, Stephen Boyd wrote: > Now that we can use clk_hw pointers we don't need to have two > duplicate arrays holding the same mapping of clk index to clk_hw > pointer. Implement a custom clk_hw provider function to map the > OF specifier to the clk_hw instance for it. > > Cc: Alex Elder >

Re: [PATCH 2/3] docs: split up the driver book

Em Wed, 24 Aug 2016 16:46:22 -0600 Jonathan Corbet escreveu: > On Tue, 23 Aug 2016 11:30:16 -0300 > Mauro Carvalho Chehab wrote: > > > On the output text, you'll see two places with "@:c:func:threadfn()". > > > > The problem here is that threadfn() is a function argument. While this > > used

Re: [PATCH v2] clk: qcom: Migrate to clk_hw based registration and OF APIs

On 08/16, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers in this driver, allowing us to > move closer to a clear split of consumer and provider clk APIs. > > Signed-off-by: Stephen Boyd > ---

Re: [PATCH v2] clk: qcom: Migrate to clk_hw based registration and OF APIs

On 08/16, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers in this driver, allowing us to > move closer to a clear split of consumer and provider clk APIs. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next --

Re: linux-next: Tree for Aug 25

Hi all, On Thu, 25 Aug 2016 14:54:59 +1000 Stephen Rothwell <s...@canb.auug.org.au> wrote: > > Changes since 20160824: Just a reminder that I will not doing a linux-next release until next-20160905 (i.e. Monday week my time). -- Cheers, Stephen Rothwell

Re: linux-next: Tree for Aug 25

Hi all, On Thu, 25 Aug 2016 14:54:59 +1000 Stephen Rothwell wrote: > > Changes since 20160824: Just a reminder that I will not doing a linux-next release until next-20160905 (i.e. Monday week my time). -- Cheers, Stephen Rothwell

Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***

Hi Binoy, On 08/24/2016 01:17 PM, Binoy Jayan wrote: Histogram output: cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist cat

Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***

Hi Binoy, On 08/24/2016 01:17 PM, Binoy Jayan wrote: Histogram output: cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist cat

Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms

Quoting Gabriel Fernandez (2016-08-22 09:06:20) > Hi Mike, > > you forgot me ? > > Best Regards > > Gabriel > > > On 07/11/2016 08:58 AM, Gabriel Fernandez wrote: > > > > > > On 07/08/2016 06:08 PM, Michael Turquette wrote: > >> Quoting Gabriel Fernandez (2016-07-08 02:12:35) > >>> Hi Mike, >

Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms

Quoting Gabriel Fernandez (2016-08-22 09:06:20) > Hi Mike, > > you forgot me ? > > Best Regards > > Gabriel > > > On 07/11/2016 08:58 AM, Gabriel Fernandez wrote: > > > > > > On 07/08/2016 06:08 PM, Michael Turquette wrote: > >> Quoting Gabriel Fernandez (2016-07-08 02:12:35) > >>> Hi Mike, >

Re: [PATCH 33/34] clk: vt8500: Migrate to clk_hw based registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth

Re: [PATCH 34/34] clk: wm831x: Migrate to clk_hw based registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Mark Brown

Re: [PATCH 33/34] clk: vt8500: Migrate to clk_hw based registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc:

Re: [PATCH 34/34] clk: wm831x: Migrate to clk_hw based registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Mark Brown > Signed-off-by:

[PATCH] PCI: Export pci_enable_ptm

Export symbol so device drivers outside of the core pci subsystem can use it. Signed-off-by: Yong, Jonathan --- drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c index 3b83024..bab8ac6 100644 ---

[PATCH] Allow pci_enable_ptm to be called outside of the pci subsystem

Allow external drivers to enable PTM bits on their respective devices. Please CC me when replying, thanks. Yong, Jonathan (1): PCI: Export pci_enable_ptm drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) -- 2.7.3

[PATCH] PCI: Export pci_enable_ptm

Export symbol so device drivers outside of the core pci subsystem can use it. Signed-off-by: Yong, Jonathan --- drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c index 3b83024..bab8ac6 100644 --- a/drivers/pci/pcie/ptm.c

[PATCH] Allow pci_enable_ptm to be called outside of the pci subsystem

Allow external drivers to enable PTM bits on their respective devices. Please CC me when replying, thanks. Yong, Jonathan (1): PCI: Export pci_enable_ptm drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) -- 2.7.3

Re: [PATCH 29/34] clk: si570: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Guenter Roeck

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 23:04, Greg KH wrote: > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote: >> On 24 August 2016 at 11:22, Greg KH wrote: >> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote: >> >> +static

Re: [PATCH 27/34] clk: si514: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth

Re: [PATCH 26/34] clk: scpi: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sudeep Holla

Re: [PATCH 29/34] clk: si570: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Guenter Roeck > Cc: Sören

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On 24 August 2016 at 23:04, Greg KH wrote: > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote: >> On 24 August 2016 at 11:22, Greg KH wrote: >> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote: >> >> +static ssize_t ports_show(struct device *dev, struct

Re: [PATCH 27/34] clk: si514: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc:

Re: [PATCH 26/34] clk: scpi: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sudeep Holla > Signed-off-by:

Re: [PATCH 24/34] clk: rk808: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Chris Zhong

Re: [PATCH 24/34] clk: rk808: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Chris Zhong > Signed-off-by:

Re: [PATCH 28/34] clk: si5351: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth

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

Hi Herbert, After merging the crypto tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: crypto/xor.c: In function 'calibrate_xor_blocks': crypto/xor.c:156:1: warning: label 'out' defined but not used [-Wunused-label] out: ^ Introduced by commit 39457acda913

Re: [PATCH] kexec: Fix double-free when failing to relocate the purgatory.

It's reasonable. Ack. Acked-by: Baoquan He On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote: > If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs > and pi->purgatory_buf. This is redundant, because in case of error > kimage_file_prepare_segments calls

Re: [PATCH 28/34] clk: si5351: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc:

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

Hi Herbert, After merging the crypto tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: crypto/xor.c: In function 'calibrate_xor_blocks': crypto/xor.c:156:1: warning: label 'out' defined but not used [-Wunused-label] out: ^ Introduced by commit 39457acda913

Re: [PATCH] kexec: Fix double-free when failing to relocate the purgatory.

It's reasonable. Ack. Acked-by: Baoquan He On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote: > If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs > and pi->purgatory_buf. This is redundant, because in case of error > kimage_file_prepare_segments calls

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote: > Hi Rob, > > On 08/23/2016 08:32 PM, Rob Herring wrote: > > On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote: > >> Add devicetree binding document for Venus remote processor. > >> > >> Signed-off-by: Stanimir Varbanov

Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document

On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote: > Hi Rob, > > On 08/23/2016 08:32 PM, Rob Herring wrote: > > On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote: > >> Add devicetree binding document for Venus remote processor. > >> > >> Signed-off-by: Stanimir Varbanov > >>

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On 24 August 2016 at 22:13, Bjorn Andersson wrote: > On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote: > >> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote: >> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: >> > > Hey Andy, >> > > >> > >

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On 24 August 2016 at 22:13, Bjorn Andersson wrote: > On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote: > >> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote: >> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: >> > > Hey Andy, >> > > >> > > This is a respin of v2 with

Re: [PATCH 15/34] clk: efm32gg: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Uwe Kleine-König

Re: [PATCH 1/2] clk: mvebu: set flags in CP110 gate clock

On 08/23, Marcin Wojtas wrote: > Armada CP110 system controller comprise its own routine responsble > for registering gate clocks. Among others 'flags' field in > struct clk_init_data was not set, using a random values, which > may cause an unpredicted behavior. > > This patch fixes the problem

Re: [PATCH 14/34] clk: cs2000: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Kuninori Morimoto

Re: [PATCH 15/34] clk: efm32gg: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Uwe Kleine-König >

Re: [PATCH 1/2] clk: mvebu: set flags in CP110 gate clock

On 08/23, Marcin Wojtas wrote: > Armada CP110 system controller comprise its own routine responsble > for registering gate clocks. Among others 'flags' field in > struct clk_init_data was not set, using a random values, which > may cause an unpredicted behavior. > > This patch fixes the problem

Re: [PATCH 14/34] clk: cs2000: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Kuninori Morimoto >

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote: > On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote: > > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: > > > Hey Andy, > > > > > > This is a respin of v2 with some minor fixes pointed out by Rob. > > > Please pull these

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

On 07/04, Jongsung Kim wrote: > On 2016년 07월 02일 09:20, Stephen Boyd wrote: > > Do you actually have an IC on the board that is doing some fixed > > factor calculation? Or is this a clk driver design where we are > > listing out each piece of an SoC's clk controller in DT? > > > The SoC has

Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags

On 07/04, Jongsung Kim wrote: > On 2016년 07월 02일 09:20, Stephen Boyd wrote: > > Do you actually have an IC on the board that is doing some fixed > > factor calculation? Or is this a clk driver design where we are > > listing out each piece of an SoC's clk controller in DT? > > > The SoC has

Re: [PATCH v3 0/5] dts patches for qcom tsens support

On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote: > On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote: > > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote: > > > Hey Andy, > > > > > > This is a respin of v2 with some minor fixes pointed out by Rob. > > > Please pull these

Re: [PATCH 13/34] clk: clps711x: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Alexander Shiyan

linux-next: Tree for Aug 25

Hi all, Changes since 20160824: The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit. Non-merge commits (relative to Linus' tree): 3682 3689 files changed, 170524 insertions(+), 63738 deletions

Re: [PATCH 13/34] clk: clps711x: Migrate to clk_hw based OF and registration APIs

On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Alexander Shiyan >

linux-next: Tree for Aug 25

Hi all, Changes since 20160824: The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit. Non-merge commits (relative to Linus' tree): 3682 3689 files changed, 170524 insertions(+), 63738 deletions

MAINTAINERS without commits in the last 3 years

Many email addresses in MAINTAINERS no longer work so many sections in MAINTAINERS could likely be considered either obsolete or unmaintained. Marking these sections appropriately or simply removing the sections would make MAINTAINERS and get_maintainer.pl more useful. These M: entries in

Re: MAINTAINERS without commits in the last 3 years

> Am 24.08.2016 um 19:33 schrieb Joe Perches : > > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections

MAINTAINERS without commits in the last 3 years

Many email addresses in MAINTAINERS no longer work so many sections in MAINTAINERS could likely be considered either obsolete or unmaintained. Marking these sections appropriately or simply removing the sections would make MAINTAINERS and get_maintainer.pl more useful. These M: entries in

Re: MAINTAINERS without commits in the last 3 years

> Am 24.08.2016 um 19:33 schrieb Joe Perches : > > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections would make

Re: [PATCH] arm64: dts: hikey: extend default cma size to 128MB

On 24 August 2016 at 23:10, Rob Herring wrote: > On Wed, Aug 24, 2016 at 8:35 AM, Guodong Xu wrote: >> To support display in Debian on HiKey, cma heap is used to allocate >> graphic buffers. The default size of CMA is 16 MB which is not enought. > >

Re: [PATCH 2/2] clk: mvebu: dynamically allocate resources in Armada CP110 system controller

On 08/23, Marcin Wojtas wrote: > Original commit, which added support for Armada CP110 system controller > used global variables for storing all clock information. It worked > fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k > was introduced, the data got overwritten and

Re: + stackdepot-fix-mempolicy-use-after-free.patch added to -mm tree

On Fri, 19 Aug 2016, a...@linux-foundation.org wrote: > From: Vegard Nossum > Subject: stackdepot: fix mempolicy use-after-free > > This patch fixes the following: > > BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr > 88010b48102c >

Re: [PATCH] arm64: dts: hikey: extend default cma size to 128MB

On 24 August 2016 at 23:10, Rob Herring wrote: > On Wed, Aug 24, 2016 at 8:35 AM, Guodong Xu wrote: >> To support display in Debian on HiKey, cma heap is used to allocate >> graphic buffers. The default size of CMA is 16 MB which is not enought. > > s/enought/enough/ > >> >> Increase the default

Re: [PATCH 2/2] clk: mvebu: dynamically allocate resources in Armada CP110 system controller

On 08/23, Marcin Wojtas wrote: > Original commit, which added support for Armada CP110 system controller > used global variables for storing all clock information. It worked > fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k > was introduced, the data got overwritten and

Re: + stackdepot-fix-mempolicy-use-after-free.patch added to -mm tree

On Fri, 19 Aug 2016, a...@linux-foundation.org wrote: > From: Vegard Nossum > Subject: stackdepot: fix mempolicy use-after-free > > This patch fixes the following: > > BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr > 88010b48102c > Read of size 2 by task

Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote: > On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote: > > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote: > > > The driver name is displayed each time differently. > > > This patch make use of the same name

Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote: > On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote: > > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote: > > > The driver name is displayed each time differently. > > > This patch make use of the same name

[PATCH v2 1/2] arm64: dts: hikey: extend default cma size to 128MB

To support display in Debian on HiKey, cma heap is used to allocate graphic buffers. The default size of CMA is 16 MB which is not enough. Increase the default CMA size to 128 MB. cc: Fathi Boudra cc: John Stultz cc: Xinliang Liu

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

On 08/23/16 13:42, Mikko Rapeli wrote: > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: >> On 08/23/16 06:57, Bart Van Assche wrote: >>> On 08/22/16 11:32, Mikko Rapeli wrote: - * uint32_t (*get_region_size)(struct dm_dirty_log *log); + * __u32 (*get_region_size)(struct

[PATCH v2 1/2] arm64: dts: hikey: extend default cma size to 128MB

To support display in Debian on HiKey, cma heap is used to allocate graphic buffers. The default size of CMA is 16 MB which is not enough. Increase the default CMA size to 128 MB. cc: Fathi Boudra cc: John Stultz cc: Xinliang Liu Signed-off-by: Guodong Xu Acked-by: Rob Herring ---

Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h

On 08/23/16 13:42, Mikko Rapeli wrote: > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: >> On 08/23/16 06:57, Bart Van Assche wrote: >>> On 08/22/16 11:32, Mikko Rapeli wrote: - * uint32_t (*get_region_size)(struct dm_dirty_log *log); + * __u32 (*get_region_size)(struct

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

On 08/24, Chanwoo Choi wrote: > On 2016년 08월 24일 13:43, Stephen Boyd wrote: > > On 08/23, Sylwester Nawrocki wrote: > >> So the saving is rather insignificant but the patch doesn't make > >> things worse and I'd say it might be worth applying. > >> > > > > Sounds good. This sort of information

Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section

On 08/24, Chanwoo Choi wrote: > On 2016년 08월 24일 13:43, Stephen Boyd wrote: > > On 08/23, Sylwester Nawrocki wrote: > >> So the saving is rather insignificant but the patch doesn't make > >> things worse and I'd say it might be worth applying. > >> > > > > Sounds good. This sort of information

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

Hi Maxime, thanks for your answer, much appreciated! On 23/08/16 20:31, Maxime Ripard wrote: > Hi Andre, > > On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote: >> Hi Maxime, >> >> On 26/07/16 21:30, Maxime Ripard wrote: >>> Hi, >>> >>> Here is the previous A64 patches made by Andre

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/24 18:30, Catalin Marinas wrote: > On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/24 1:28, Catalin Marinas wrote: >>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: On 2016/7/20 17:19, Catalin Marinas wrote: >

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

On 2016/8/24 18:30, Catalin Marinas wrote: > On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/24 1:28, Catalin Marinas wrote: >>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: On 2016/7/20 17:19, Catalin Marinas wrote: >

Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng

Hi Maxime, thanks for your answer, much appreciated! On 23/08/16 20:31, Maxime Ripard wrote: > Hi Andre, > > On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote: >> Hi Maxime, >> >> On 26/07/16 21:30, Maxime Ripard wrote: >>> Hi, >>> >>> Here is the previous A64 patches made by Andre

[PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220 Code and documentation to this property were confirmed by maintainers. See: [1] https://patchwork.kernel.org/patch/9276607/ [2] https://patchwork.kernel.org/patch/8487151/ [3] https://lkml.org/lkml/2016/8/12/91 cc: Jaehoon Chung

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

Hi, On 17 June 2016 at 15:46, Pramod Gurav wrote: > Add runtime pm and suspend/resume callback support to serial msm > driver so that clock resources are managed runtime to save power. > Any comments on this patch? > Signed-off-by: Pramod Gurav

[PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes

Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220 Code and documentation to this property were confirmed by maintainers. See: [1] https://patchwork.kernel.org/patch/9276607/ [2] https://patchwork.kernel.org/patch/8487151/ [3] https://lkml.org/lkml/2016/8/12/91 cc: Jaehoon Chung

Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support

Hi, On 17 June 2016 at 15:46, Pramod Gurav wrote: > Add runtime pm and suspend/resume callback support to serial msm > driver so that clock resources are managed runtime to save power. > Any comments on this patch? > Signed-off-by: Pramod Gurav > --- > drivers/tty/serial/msm_serial.c | 183

Re: [PATCH 2/5] Drivers: hv: balloon: account for gaps in hot add regions

Hi, kys! > On Wed, 24 Aug 2016 16:23:10 -0700, kys wrote: [...] > -static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt) > +static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt) > { > struct list_head *cur; > struct hv_hotadd_state *has;

Re: [PATCH 2/5] Drivers: hv: balloon: account for gaps in hot add regions

Hi, kys! > On Wed, 24 Aug 2016 16:23:10 -0700, kys wrote: [...] > -static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt) > +static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt) > { > struct list_head *cur; > struct hv_hotadd_state *has;

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

From: Salil Mehta Date: Wed, 24 Aug 2016 04:44:48 +0800 > This patch is meant to add support of ACPI to the Hisilicon RoCE driver. > Following changes have been made in the driver(s): > > Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in >the

Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver

From: Salil Mehta Date: Wed, 24 Aug 2016 04:44:48 +0800 > This patch is meant to add support of ACPI to the Hisilicon RoCE driver. > Following changes have been made in the driver(s): > > Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in >the RoCE reset function part

Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

On Thu, Aug 25, 2016 at 7:58 AM, Icenowy Zheng wrote: > > > 25.08.2016, 03:36, "Maxime Ripard" : >> Hi, >> >> On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote: >>> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo

Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

On Thu, Aug 25, 2016 at 7:58 AM, Icenowy Zheng wrote: > > > 25.08.2016, 03:36, "Maxime Ripard" : >> Hi, >> >> On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote: >>> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card >>> on iNet D978 Rev2 board. >>> >>> Enable

Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.

On Wed, Aug 24, 2016 at 07:59:05AM -0700, Dan Williams wrote: On Tue, Aug 23, 2016 at 7:47 PM, Fengguang Wu wrote: On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote: I was not able to reproduce this, I tried on Fedora 23 and Fedora 24 and both attempts

Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.

On Wed, Aug 24, 2016 at 07:59:05AM -0700, Dan Williams wrote: On Tue, Aug 23, 2016 at 7:47 PM, Fengguang Wu wrote: On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote: I was not able to reproduce this, I tried on Fedora 23 and Fedora 24 and both attempts succeeded. Hi Dan, it

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

On 13 January 2016 at 19:18, Nishanth Menon wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary

Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific

On Wed, 24 Aug 2016, Josh Poimboeuf wrote: > There's no reliable way to determine which module tainted the kernel > with CONFIG_LIVEPATCH. For example, /sys/module//taint > doesn't report it. Neither does the "mod -t" command in the crash tool. > > Make it crystal clear who the guilty party is

  1   2   3   4   5   6   7   8   9   10   >