Re: [PATCH net v2] sfc: report supported link speeds on SFP connections

2016-06-07 Thread Jarod Wilson
On Mon, Jun 06, 2016 at 02:55:29PM -0400, Jarod Wilson wrote: > On Mon, Jun 06, 2016 at 05:29:30PM +0100, Bert Kenward wrote: > > 7000-series SFC NICs connected with an SFP+ module currently fail to > > report any supported link speeds. > > > > Reported-by: Jarod Wilson > >

Re: [PATCH net v2] sfc: report supported link speeds on SFP connections

2016-06-07 Thread Jarod Wilson
On Mon, Jun 06, 2016 at 02:55:29PM -0400, Jarod Wilson wrote: > On Mon, Jun 06, 2016 at 05:29:30PM +0100, Bert Kenward wrote: > > 7000-series SFC NICs connected with an SFP+ module currently fail to > > report any supported link speeds. > > > > Reported-by: Jarod Wilson > > Signed-off-by: Bert

[PATCH] crypto: qat: Remove deprecated create_workqueue

2016-06-07 Thread Bhaktipriya Shridhar
alloc_workqueue replaces deprecated create_workqueue(). The workqueue device_reset_wq has workitem _data->reset_work per adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for PF2VF responses has workitem _resp->pf2vf_resp_work per pf2vf_resp. The workqueue adf_vf_stop_wq is used to

[PATCH] crypto: qat: Remove deprecated create_workqueue

2016-06-07 Thread Bhaktipriya Shridhar
alloc_workqueue replaces deprecated create_workqueue(). The workqueue device_reset_wq has workitem _data->reset_work per adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for PF2VF responses has workitem _resp->pf2vf_resp_work per pf2vf_resp. The workqueue adf_vf_stop_wq is used to

Re: [PATCH] selftests/vm/compaction_test: fix write to restore nr_hugepages

2016-06-07 Thread Jayaramappa, Srilakshmi
On 6/7/16, 4:26 PM, "Mike Kravetz" wrote: >The write at the end of the test to restore nr_hugepages to its previous >value is failing. This is because it is trying to write the number of >bytes in the char array as opposed to the number of bytes in the string. >

Re: [PATCH] selftests/vm/compaction_test: fix write to restore nr_hugepages

2016-06-07 Thread Jayaramappa, Srilakshmi
On 6/7/16, 4:26 PM, "Mike Kravetz" wrote: >The write at the end of the test to restore nr_hugepages to its previous >value is failing. This is because it is trying to write the number of >bytes in the char array as opposed to the number of bytes in the string. > >Signed-off-by: Mike Kravetz

Re: NVMe over Fabrics target implementation

2016-06-07 Thread Ming Lin
On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote: > On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: >> >> Hi HCH & Co, >> >> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: >>> >>> This patch set adds a generic NVMe over Fabrics target. The >>> implementation

Re: NVMe over Fabrics target implementation

2016-06-07 Thread Ming Lin
On Tue, Jun 7, 2016 at 2:02 PM, Andy Grover wrote: > On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: >> >> Hi HCH & Co, >> >> On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: >>> >>> This patch set adds a generic NVMe over Fabrics target. The >>> implementation conforms to the

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for HKEY version 0x200

2016-06-07 Thread Lyude Paul
Managed to find someone in the office with one of these laptops and it looks like the adaptive keyboard works perfectly with this patch, so I can give my t- b: Tested-by: Lyude Paul Cheers, Lyude On Tue, 2016-06-07 at 13:02 -0400, Lyude Paul wrote: > Since

Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add support for HKEY version 0x200

2016-06-07 Thread Lyude Paul
Managed to find someone in the office with one of these laptops and it looks like the adaptive keyboard works perfectly with this patch, so I can give my t- b: Tested-by: Lyude Paul Cheers, Lyude On Tue, 2016-06-07 at 13:02 -0400, Lyude Paul wrote: > Since nothing's really

[RFC 0/1] ARM: print MHz in /proc/cpuinfo

2016-06-07 Thread Jon Mason
Many users (and some applications) are expecting the CPU clock speed to be output in /proc/cpuinfo (as is done in x86, avr32, c6x, tile, parisc, ia64, and xtensa). This can be trivially added by simply querying the clock described in the CPU node of the device tree. It appears that many of the

[RFC 1/1] ARM: print MHz in /proc/cpuinfo

2016-06-07 Thread Jon Mason
Query the CPU core clock in the device tree to determine the core clock speed. Output this clock rate in /proc/cpuinfo to match the output from other architectures. The output is intentionally patterned after the x86 output, to match existing (and possibly expected) convention. If any errors

[RFC 1/1] ARM: print MHz in /proc/cpuinfo

2016-06-07 Thread Jon Mason
Query the CPU core clock in the device tree to determine the core clock speed. Output this clock rate in /proc/cpuinfo to match the output from other architectures. The output is intentionally patterned after the x86 output, to match existing (and possibly expected) convention. If any errors

[RFC 0/1] ARM: print MHz in /proc/cpuinfo

2016-06-07 Thread Jon Mason
Many users (and some applications) are expecting the CPU clock speed to be output in /proc/cpuinfo (as is done in x86, avr32, c6x, tile, parisc, ia64, and xtensa). This can be trivially added by simply querying the clock described in the CPU node of the device tree. It appears that many of the

Re: [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

2016-06-07 Thread Geert Uytterhoeven
Hi Magnus, On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote: > iommu/ipmmu-vmsa: IPMMU multi-arch update V3 > > [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling > [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for > context >

Re: [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

2016-06-07 Thread Geert Uytterhoeven
Hi Magnus, On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm wrote: > iommu/ipmmu-vmsa: IPMMU multi-arch update V3 > > [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling > [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for > context > [PATCH v3 03/06]

Re: [PATCH 2/2] sched/debug: fix deadlock when enabling sched events

2016-06-07 Thread Josh Poimboeuf
On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote: > @@ -403,9 +402,10 @@ DECLARE_EVENT_CLASS(sched_stat_runtime, > (unsigned long long)__entry->vruntime) > ); > > -DEFINE_EVENT(sched_stat_runtime, sched_stat_runtime, > - TP_PROTO(struct task_struct

Re: [PATCH 2/2] sched/debug: fix deadlock when enabling sched events

2016-06-07 Thread Josh Poimboeuf
On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote: > @@ -403,9 +402,10 @@ DECLARE_EVENT_CLASS(sched_stat_runtime, > (unsigned long long)__entry->vruntime) > ); > > -DEFINE_EVENT(sched_stat_runtime, sched_stat_runtime, > - TP_PROTO(struct task_struct

Re: [RFC PATCH 1/4] RAS: Add a Corrected Errors Collector

2016-06-07 Thread Borislav Petkov
On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote: > Is there a reason that we need to call the ce_add_elem() inline > here instead of having it just register on the mce_notifier chain? > This series just cleaned out all the /dev/mcelog special code from > here, and you are adding

Re: [RFC PATCH 1/4] RAS: Add a Corrected Errors Collector

2016-06-07 Thread Borislav Petkov
On Tue, Jun 07, 2016 at 11:11:09AM -0700, Luck, Tony wrote: > Is there a reason that we need to call the ce_add_elem() inline > here instead of having it just register on the mce_notifier chain? > This series just cleaned out all the /dev/mcelog special code from > here, and you are adding

Re: [PATCH 2/2] sched/debug: fix deadlock when enabling sched events

2016-06-07 Thread Josh Poimboeuf
On Tue, Jun 07, 2016 at 09:54:48PM +0200, Peter Zijlstra wrote: > On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote: > > 1. Instead of just warning and allowing the tracepoints to be broken, > >I'd argue that it would be better to make them work by forcing > >schedstats

Re: [PATCH 2/2] sched/debug: fix deadlock when enabling sched events

2016-06-07 Thread Josh Poimboeuf
On Tue, Jun 07, 2016 at 09:54:48PM +0200, Peter Zijlstra wrote: > On Tue, Jun 07, 2016 at 02:43:17PM -0500, Josh Poimboeuf wrote: > > 1. Instead of just warning and allowing the tracepoints to be broken, > >I'd argue that it would be better to make them work by forcing > >schedstats

Re: [PATCH] ext4: mballoc.c: fix ac_g_ex and ac_f_ex misuse bug in EXT4_MB_HINT_TRY_GOAL path

2016-06-07 Thread Andreas Dilger
On Jun 2, 2016, at 6:01 AM, Lin Feng wrote: > > Descriptions: > ext4 block allocation core stack: > ext4_mb_new_blocks > ext4_mb_normalize_request > ext4_mb_regular_allocator >ext4_mb_find_by_goal > mb_find_extent(e4b, ac->ac_g_ex.fe_start, ac->ac_g_ex.fe_len,

Re: [PATCH] ext4: mballoc.c: fix ac_g_ex and ac_f_ex misuse bug in EXT4_MB_HINT_TRY_GOAL path

2016-06-07 Thread Andreas Dilger
On Jun 2, 2016, at 6:01 AM, Lin Feng wrote: > > Descriptions: > ext4 block allocation core stack: > ext4_mb_new_blocks > ext4_mb_normalize_request > ext4_mb_regular_allocator >ext4_mb_find_by_goal > mb_find_extent(e4b, ac->ac_g_ex.fe_start, ac->ac_g_ex.fe_len, ); > > The start block

Re: NVMe over Fabrics target implementation

2016-06-07 Thread Andy Grover
On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over

Re: NVMe over Fabrics target implementation

2016-06-07 Thread Andy Grover
On 06/06/2016 11:23 PM, Nicholas A. Bellinger wrote: Hi HCH & Co, On Mon, 2016-06-06 at 23:22 +0200, Christoph Hellwig wrote: This patch set adds a generic NVMe over Fabrics target. The implementation conforms to the NVMe 1.2b specification (which includes Fabrics) and provides the NVMe over

Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF

2016-06-07 Thread Rob Herring
+Mark R On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou wrote: > In certain cases it makes sense to create cascaded GPIO which > are not real GPIOs, merely point to the real backend GPIO chip. In what cases? Make it clear what this is for. Connectors of course,

Re: [PATCH 2/2] gpio: Support cascaded GPIO chip lookup for OF

2016-06-07 Thread Rob Herring
+Mark R On Fri, Jun 3, 2016 at 3:26 PM, Pantelis Antoniou wrote: > In certain cases it makes sense to create cascaded GPIO which > are not real GPIOs, merely point to the real backend GPIO chip. In what cases? Make it clear what this is for. Connectors of course, but are there any other use

Re: [PATCH v9 0/4] Introduce GCC plugin infrastructure

2016-06-07 Thread Kees Cook
On Tue, Jun 7, 2016 at 1:58 PM, Michal Marek wrote: > Dne 25.5.2016 v 19:12 Kees Cook napsal(a): >> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote: >>> On 2016-05-24 19:04, Kees Cook wrote: On Mon, May 23, 2016 at 3:07 PM, Emese Revfy

Re: [PATCH v9 0/4] Introduce GCC plugin infrastructure

2016-06-07 Thread Kees Cook
On Tue, Jun 7, 2016 at 1:58 PM, Michal Marek wrote: > Dne 25.5.2016 v 19:12 Kees Cook napsal(a): >> On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote: >>> On 2016-05-24 19:04, Kees Cook wrote: On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote: > This patch set introduce the GCC

Re: [PATCH v9 0/4] Introduce GCC plugin infrastructure

2016-06-07 Thread Michal Marek
Dne 25.5.2016 v 19:12 Kees Cook napsal(a): > On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote: >> On 2016-05-24 19:04, Kees Cook wrote: >>> On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote: This patch set introduce the GCC plugin infrastructure with

Re: [PATCH v9 0/4] Introduce GCC plugin infrastructure

2016-06-07 Thread Michal Marek
Dne 25.5.2016 v 19:12 Kees Cook napsal(a): > On Wed, May 25, 2016 at 3:46 AM, Michal Marek wrote: >> On 2016-05-24 19:04, Kees Cook wrote: >>> On Mon, May 23, 2016 at 3:07 PM, Emese Revfy wrote: This patch set introduce the GCC plugin infrastructure with examples for testing and

[PATCH] tile: allow disabling CONFIG_EARLY_PRINTK

2016-06-07 Thread Chris Metcalf
In that case, any users of early_panic() end up calling panic(). Signed-off-by: Chris Metcalf --- I don't think this is a recent breakage, and it doesn't feel too critical, so I'll just push it in the next merge window. arch/tile/include/asm/setup.h | 5 + 1 file

[PATCH] tile: allow disabling CONFIG_EARLY_PRINTK

2016-06-07 Thread Chris Metcalf
In that case, any users of early_panic() end up calling panic(). Signed-off-by: Chris Metcalf --- I don't think this is a recent breakage, and it doesn't feel too critical, so I'll just push it in the next merge window. arch/tile/include/asm/setup.h | 5 + 1 file changed, 5 insertions(+)

Re: [PATCH] dmaengine: bcm2835: Fix polling for completion of DMA with interrupts masked.

2016-06-07 Thread Eric Anholt
Vinod Koul writes: > On Mon, Jun 06, 2016 at 11:10:38PM -0700, Eric Anholt wrote: >> >> >> - if (ret == DMA_COMPLETE || !txstate) >> >> >> + if (ret == DMA_COMPLETE) >> >> > >> >> > Why do you change this? txstate can be NULL, so no point calculating >> >> >

Re: [PATCH] dmaengine: bcm2835: Fix polling for completion of DMA with interrupts masked.

2016-06-07 Thread Eric Anholt
Vinod Koul writes: > On Mon, Jun 06, 2016 at 11:10:38PM -0700, Eric Anholt wrote: >> >> >> - if (ret == DMA_COMPLETE || !txstate) >> >> >> + if (ret == DMA_COMPLETE) >> >> > >> >> > Why do you change this? txstate can be NULL, so no point calculating >> >> > reside >> >> > for those

Re: [PATCH v3 0/2] ARM: dts: sun9i: drop sunxi-common-regulators.dtsi

2016-06-07 Thread Maxime Ripard
On Fri, Jun 03, 2016 at 02:50:49PM +0800, Chen-Yu Tsai wrote: > Hi Maxime, > > These are the remaining 2 patches from the AXP809 series. > > Changes since v2: > > - Drop sunxi-common-regulators.dtsi instead of disabling dummy regulators. Applied both, thanks! Maxime -- Maxime Ripard, Free

[PATCH 3/9] x86, pkeys: make mprotect_key() mask off additional vm_flags

2016-06-07 Thread Dave Hansen
From: Dave Hansen Today, mprotect() takes 4 bits of data: PROT_READ/WRITE/EXEC/NONE. Three of those bits: READ/WRITE/EXEC get translated directly in to vma->vm_flags by calc_vm_prot_bits(). If a bit is unset in mprotect()'s 'prot' argument then it must be cleared

Re: [PATCH v3 0/2] ARM: dts: sun9i: drop sunxi-common-regulators.dtsi

2016-06-07 Thread Maxime Ripard
On Fri, Jun 03, 2016 at 02:50:49PM +0800, Chen-Yu Tsai wrote: > Hi Maxime, > > These are the remaining 2 patches from the AXP809 series. > > Changes since v2: > > - Drop sunxi-common-regulators.dtsi instead of disabling dummy regulators. Applied both, thanks! Maxime -- Maxime Ripard, Free

[PATCH 3/9] x86, pkeys: make mprotect_key() mask off additional vm_flags

2016-06-07 Thread Dave Hansen
From: Dave Hansen Today, mprotect() takes 4 bits of data: PROT_READ/WRITE/EXEC/NONE. Three of those bits: READ/WRITE/EXEC get translated directly in to vma->vm_flags by calc_vm_prot_bits(). If a bit is unset in mprotect()'s 'prot' argument then it must be cleared in vma->vm_flags during the

[PATCH 4/9] x86: wire up mprotect_key() system call

2016-06-07 Thread Dave Hansen
From: Dave Hansen This is all that we need to get the new system call itself working on x86. Signed-off-by: Dave Hansen Cc: linux-...@vger.kernel.org Cc: linux...@kvack.org Cc: x...@kernel.org Cc: torva...@linux-foundation.org Cc:

[PATCH 4/9] x86: wire up mprotect_key() system call

2016-06-07 Thread Dave Hansen
From: Dave Hansen This is all that we need to get the new system call itself working on x86. Signed-off-by: Dave Hansen Cc: linux-...@vger.kernel.org Cc: linux...@kvack.org Cc: x...@kernel.org Cc: torva...@linux-foundation.org Cc: a...@linux-foundation.org ---

[PATCH 2/9] mm: implement new pkey_mprotect() system call

2016-06-07 Thread Dave Hansen
From: Dave Hansen pkey_mprotect() is just like mprotect, except it also takes a protection key as an argument. On systems that do not support protection keys, it still works, but requires that key=0. Otherwise it does exactly what mprotect does. I expect it to get

[PATCH 2/9] mm: implement new pkey_mprotect() system call

2016-06-07 Thread Dave Hansen
From: Dave Hansen pkey_mprotect() is just like mprotect, except it also takes a protection key as an argument. On systems that do not support protection keys, it still works, but requires that key=0. Otherwise it does exactly what mprotect does. I expect it to get used like this, if you want

[PATCH 1/9] x86, pkeys: add fault handling for PF_PK page fault bit

2016-06-07 Thread Dave Hansen
From: Dave Hansen PF_PK means that a memory access violated the protection key access restrictions. It is unconditionally an access_error() because the permissions set on the VMA don't matter (the PKRU value overrides it), and we never "resolve" PK faults (like how

[PATCH 1/9] x86, pkeys: add fault handling for PF_PK page fault bit

2016-06-07 Thread Dave Hansen
From: Dave Hansen PF_PK means that a memory access violated the protection key access restrictions. It is unconditionally an access_error() because the permissions set on the VMA don't matter (the PKRU value overrides it), and we never "resolve" PK faults (like how a COW can "resolve write

[PATCH 5/9] x86, pkeys: allocation/free syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen This patch adds two new system calls: int pkey_alloc(unsigned long flags, unsigned long init_access_rights) int pkey_free(int pkey); These implement an "allocator" for the protection keys themselves, which can be thought of as

[PATCH 6/9] x86, pkeys: add pkey set/get syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen This establishes two more system calls for protection key management: unsigned long pkey_get(int pkey); int pkey_set(int pkey, unsigned long access_rights); The return value from pkey_get() and the 'access_rights' passed to

[PATCH 6/9] x86, pkeys: add pkey set/get syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen This establishes two more system calls for protection key management: unsigned long pkey_get(int pkey); int pkey_set(int pkey, unsigned long access_rights); The return value from pkey_get() and the 'access_rights' passed to pkey_set() are the same format: a

[PATCH 5/9] x86, pkeys: allocation/free syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen This patch adds two new system calls: int pkey_alloc(unsigned long flags, unsigned long init_access_rights) int pkey_free(int pkey); These implement an "allocator" for the protection keys themselves, which can be thought of as analogous to the allocator that

[PATCH 7/9] generic syscalls: wire up memory protection keys syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen These new syscalls are implemented as generic code, so enable them for architectures like arm64 which use the generic syscall table. According to Arnd: Even if the support is x86 specific for the forseeable future, it may be good

[PATCH 7/9] generic syscalls: wire up memory protection keys syscalls

2016-06-07 Thread Dave Hansen
From: Dave Hansen These new syscalls are implemented as generic code, so enable them for architectures like arm64 which use the generic syscall table. According to Arnd: Even if the support is x86 specific for the forseeable future, it may be good to reserve the number just in

[PATCH 9/9] x86, pkeys: add self-tests

2016-06-07 Thread Dave Hansen
From: Dave Hansen This code should be a good demonstration of how to use the new system calls as well as how to use protection keys in general. This code shows how to: 1. Manipulate the Protection Keys Rights User (PKRU) register with sys_pkey_get/set() 2. Set a

[PATCH 9/9] x86, pkeys: add self-tests

2016-06-07 Thread Dave Hansen
From: Dave Hansen This code should be a good demonstration of how to use the new system calls as well as how to use protection keys in general. This code shows how to: 1. Manipulate the Protection Keys Rights User (PKRU) register with sys_pkey_get/set() 2. Set a protection key on memory 3.

[PATCH 0/9] [v2] System Calls for Memory Protection Keys

2016-06-07 Thread Dave Hansen
Are there any concerns with merging these into the x86 tree so that they go upstream for 4.8? The updates here are pretty minor. Changes from v1: * updates to alloc/free patch description calling out that "in-use" pkeys may still be pkey_free()'d successfully. * Fixed a bug in the selftest

[PATCH 8/9] pkeys: add details of system call use to Documentation/

2016-06-07 Thread Dave Hansen
From: Dave Hansen This spells out all of the pkey-related system calls that we have and provides some example code fragments to demonstrate how we expect them to be used. Signed-off-by: Dave Hansen Cc: linux-...@vger.kernel.org Cc:

[PATCH 0/9] [v2] System Calls for Memory Protection Keys

2016-06-07 Thread Dave Hansen
Are there any concerns with merging these into the x86 tree so that they go upstream for 4.8? The updates here are pretty minor. Changes from v1: * updates to alloc/free patch description calling out that "in-use" pkeys may still be pkey_free()'d successfully. * Fixed a bug in the selftest

[PATCH 8/9] pkeys: add details of system call use to Documentation/

2016-06-07 Thread Dave Hansen
From: Dave Hansen This spells out all of the pkey-related system calls that we have and provides some example code fragments to demonstrate how we expect them to be used. Signed-off-by: Dave Hansen Cc: linux-...@vger.kernel.org Cc: linux...@kvack.org Cc: x...@kernel.org Cc:

[PATCH v2 05/15] clk: sunxi-ng: Add gate clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clocks unit are just simple gates. Add support for those clocks. Since it's a feature that can also be found in more complex clocks, provide a bunch of helpers that can be reused later on. Signed-off-by: Maxime Ripard ---

[PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

2016-06-07 Thread Maxime Ripard
Hi, This is an attempt at introducing clock support for the Allwinner SoCs following the current model used by pretty much all the other SoCs. Such a conversion has been suggested on a regular basis by Mike and Stephen, and here is a first implementation. This new approach has a good number of

[PATCH v2 05/15] clk: sunxi-ng: Add gate clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clocks unit are just simple gates. Add support for those clocks. Since it's a feature that can also be found in more complex clocks, provide a bunch of helpers that can be reused later on. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 +

[PATCH v2 00/15] clk: sunxi: introduce "modern" clock support

2016-06-07 Thread Maxime Ripard
Hi, This is an attempt at introducing clock support for the Allwinner SoCs following the current model used by pretty much all the other SoCs. Such a conversion has been suggested on a regular basis by Mike and Stephen, and here is a first implementation. This new approach has a good number of

[PATCH v2 03/15] clk: sunxi-ng: Add fractional lib

2016-06-07 Thread Maxime Ripard
Some clocks can be switched to a mode called fractional that have two fixed output rate you can choose from. Add a small library to deal with those clocks. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 2 +

[PATCH v2 03/15] clk: sunxi-ng: Add fractional lib

2016-06-07 Thread Maxime Ripard
Some clocks can be switched to a mode called fractional that have two fixed output rate you can choose from. Add a small library to deal with those clocks. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 2 + drivers/clk/sunxi-ng/ccu_frac.c | 110

[PATCH v2 04/15] clk: sunxi-ng: Add fixed factor clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clock units are direct, fixed, multipliers or dividers from their parent. Add support for such clocks. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 2 ++ drivers/clk/sunxi-ng/ccu_fixed_factor.c |

[PATCH v2 04/15] clk: sunxi-ng: Add fixed factor clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clock units are direct, fixed, multipliers or dividers from their parent. Add support for such clocks. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 2 ++ drivers/clk/sunxi-ng/ccu_fixed_factor.c | 50

[PATCH v2 02/15] clk: sunxi-ng: Add common infrastructure

2016-06-07 Thread Maxime Ripard
Start our new clock infrastructure by adding the registration code, common structure and common code. Signed-off-by: Maxime Ripard --- Changes from v1: - Moved from of_iomap to of_io_request_and_map - Change lock bit feature name to PLL_LOCK - Fixed bug

[PATCH v2 02/15] clk: sunxi-ng: Add common infrastructure

2016-06-07 Thread Maxime Ripard
Start our new clock infrastructure by adding the registration code, common structure and common code. Signed-off-by: Maxime Ripard --- Changes from v1: - Moved from of_iomap to of_io_request_and_map - Change lock bit feature name to PLL_LOCK - Fixed bug in clocks description array

[PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks

2016-06-07 Thread Maxime Ripard
Add the list of clocks and resets found in the H3 CCU. Signed-off-by: Maxime Ripard --- Changes from v1: - Only build the H3 clocks description when MACH_SUN8I is set --- drivers/clk/sunxi-ng/Makefile| 2 + drivers/clk/sunxi-ng/ccu-sun8i-h3.c |

[PATCH v2 14/15] clk: sunxi-ng: Add H3 clocks

2016-06-07 Thread Maxime Ripard
Add the list of clocks and resets found in the H3 CCU. Signed-off-by: Maxime Ripard --- Changes from v1: - Only build the H3 clocks description when MACH_SUN8I is set --- drivers/clk/sunxi-ng/Makefile| 2 + drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 703

[PATCH v2 15/15] ARM: dt: sun8i: switch the H3 to the new CCU driver

2016-06-07 Thread Maxime Ripard
Now that we have a different clock representation, switch to it. Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun8i-h3.dtsi | 312 1 file changed, 60 insertions(+), 252 deletions(-) diff --git

[PATCH v2 15/15] ARM: dt: sun8i: switch the H3 to the new CCU driver

2016-06-07 Thread Maxime Ripard
Now that we have a different clock representation, switch to it. Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun8i-h3.dtsi | 312 1 file changed, 60 insertions(+), 252 deletions(-) diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi

Re: [PATCH 3/3] ARM: dts: sun8i-h3: Add dts file for Sinovoip BPI-M2+

2016-06-07 Thread Maxime Ripard
On Thu, Jun 02, 2016 at 03:50:11PM +0800, Chen-Yu Tsai wrote: > The BPI-M2+ is an H3 development board. It is a smaller form factor than > the original BPI-M2, with the new H3 SoC. > > It has 1GB DRAM, 8GB eMMC, a micro SD card slot, HDMI output, 2 USB > host connector and 1 USB OTG connector, an

[PATCH v2 10/15] clk: sunxi-ng: Add N-K-factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that use a combination of two linear multipliers. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_nk.c | 147 ++ drivers/clk/sunxi-ng/ccu_nk.h

[PATCH v2 11/15] clk: sunxi-ng: Add N-M-factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that multiply and divide using linear factors. Signed-off-by: Maxime Ripard --- Changes from v1: - Fixed the maximums for both factors passed to the rational factor computation. --- drivers/clk/sunxi-ng/Makefile | 1 +

[PATCH v2 10/15] clk: sunxi-ng: Add N-K-factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that use a combination of two linear multipliers. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_nk.c | 147 ++ drivers/clk/sunxi-ng/ccu_nk.h | 73 + 3

[PATCH v2 11/15] clk: sunxi-ng: Add N-M-factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that multiply and divide using linear factors. Signed-off-by: Maxime Ripard --- Changes from v1: - Fixed the maximums for both factors passed to the rational factor computation. --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_nm.c | 114

Re: [PATCH 3/3] ARM: dts: sun8i-h3: Add dts file for Sinovoip BPI-M2+

2016-06-07 Thread Maxime Ripard
On Thu, Jun 02, 2016 at 03:50:11PM +0800, Chen-Yu Tsai wrote: > The BPI-M2+ is an H3 development board. It is a smaller form factor than > the original BPI-M2, with the new H3 SoC. > > It has 1GB DRAM, 8GB eMMC, a micro SD card slot, HDMI output, 2 USB > host connector and 1 USB OTG connector, an

[PATCH v2 06/15] clk: sunxi-ng: Add mux clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clocks unit are just muxes. However, those muxes might also be found in some other complicated clocks that would benefit from the code in there to deal with "advanced" features, like pre-dividers. Introduce a set of helpers to reduce the code duplication in such

[PATCH v2 13/15] clk: sunxi-ng: Add N-K-M-P factor clock

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that use a combination of two linear multipliers (N and K factors), one linear divider (M) and one power of two divider (P). Signed-off-by: Maxime Ripard --- Changes from v1: - Declared our find_best function static - Fixed our

[PATCH v2 08/15] clk: sunxi-ng: Add divider

2016-06-07 Thread Maxime Ripard
Add support for the various dividers (linear, table or pow-of-two based) found in the CCU. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_div.c | 136 +

[PATCH v2 07/15] clk: sunxi-ng: Add phase clock support

2016-06-07 Thread Maxime Ripard
Add support for the clocks in the CCU that introduce a phase shift from their parent clock. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile| 1 + drivers/clk/sunxi-ng/ccu_phase.c | 126 +++

[PATCH v2 06/15] clk: sunxi-ng: Add mux clock support

2016-06-07 Thread Maxime Ripard
Some clocks in the Allwinner SoCs clocks unit are just muxes. However, those muxes might also be found in some other complicated clocks that would benefit from the code in there to deal with "advanced" features, like pre-dividers. Introduce a set of helpers to reduce the code duplication in such

[PATCH v2 13/15] clk: sunxi-ng: Add N-K-M-P factor clock

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that use a combination of two linear multipliers (N and K factors), one linear divider (M) and one power of two divider (P). Signed-off-by: Maxime Ripard --- Changes from v1: - Declared our find_best function static - Fixed our set_rate function that was always

[PATCH v2 08/15] clk: sunxi-ng: Add divider

2016-06-07 Thread Maxime Ripard
Add support for the various dividers (linear, table or pow-of-two based) found in the CCU. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_div.c | 136 + drivers/clk/sunxi-ng/ccu_div.h | 135

[PATCH v2 07/15] clk: sunxi-ng: Add phase clock support

2016-06-07 Thread Maxime Ripard
Add support for the clocks in the CCU that introduce a phase shift from their parent clock. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile| 1 + drivers/clk/sunxi-ng/ccu_phase.c | 126 +++ drivers/clk/sunxi-ng/ccu_phase.h | 50

[PATCH v2 09/15] clk: sunxi-ng: Add M-P factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for the clocks that combine a linear divider and a power-of-two based one. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_mp.c | 158 ++

Re: [PATCH] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions

2016-06-07 Thread Tim Chen
On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote: > On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote: > > > > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote: > > > > > >   > > > Hi Tim, > > > > > > To me, this reorganization is too limited and not good for me, > > > frankly

[PATCH v2 09/15] clk: sunxi-ng: Add M-P factor clock support

2016-06-07 Thread Maxime Ripard
Introduce support for the clocks that combine a linear divider and a power-of-two based one. Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu_mp.c | 158 ++ drivers/clk/sunxi-ng/ccu_mp.h | 78

Re: [PATCH] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions

2016-06-07 Thread Tim Chen
On Tue, 2016-06-07 at 17:21 +0900, Minchan Kim wrote: > On Wed, Jun 01, 2016 at 11:23:53AM -0700, Tim Chen wrote: > > > > On Wed, 2016-06-01 at 16:12 +0900, Minchan Kim wrote: > > > > > >   > > > Hi Tim, > > > > > > To me, this reorganization is too limited and not good for me, > > > frankly

[PATCH v2 01/15] dt-bindings: sunxi: Add CCU binding documentation

2016-06-07 Thread Maxime Ripard
Introduce a new binding with its documentation for the brand new clock sub-framework. Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644

[PATCH v2 01/15] dt-bindings: sunxi: Add CCU binding documentation

2016-06-07 Thread Maxime Ripard
Introduce a new binding with its documentation for the brand new clock sub-framework. Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 17 + 1 file changed, 17 insertions(+) create mode 100644

[PATCH v2 12/15] clk: sunxi-ng: Add N-K-M Factor clock

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that multiply and divide using two linear multipliers and one linear divider. Signed-off-by: Maxime Ripard --- Changes from v1: - Declared the find_best function static - Fixed the set_rate function that was always writing the

[PATCH v2 12/15] clk: sunxi-ng: Add N-K-M Factor clock

2016-06-07 Thread Maxime Ripard
Introduce support for clocks that multiply and divide using two linear multipliers and one linear divider. Signed-off-by: Maxime Ripard --- Changes from v1: - Declared the find_best function static - Fixed the set_rate function that was always writing the various factors at the same

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Rob Herring
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei wrote: > v3 -> v4: > 1. Packed three patches of Kefeng Wang, patch6-8. > 2. Add 6 new patches(9-15) to enhance the numa on arm64. > > v2 -> v3: > 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make > the

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-07 Thread Rob Herring
On Tue, Jun 7, 2016 at 3:08 AM, Zhen Lei wrote: > v3 -> v4: > 1. Packed three patches of Kefeng Wang, patch6-8. > 2. Add 6 new patches(9-15) to enhance the numa on arm64. > > v2 -> v3: > 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make > the >patches looks more

Re: [PATCH v3 1/6] watchdog: add set_pretimeout interface

2016-06-07 Thread Guenter Roeck
On Tue, Jun 07, 2016 at 08:38:42PM +0300, Vladimir Zapolskiy wrote: > From: Robin Gong > > Add set_pretimeout since our watchdog driver has those interfaces and > obviously, the new common watchdog framework didn't implement this > interface. > > Signed-off-by: Robin Gong

Re: [PATCH v3 1/6] watchdog: add set_pretimeout interface

2016-06-07 Thread Guenter Roeck
On Tue, Jun 07, 2016 at 08:38:42PM +0300, Vladimir Zapolskiy wrote: > From: Robin Gong > > Add set_pretimeout since our watchdog driver has those interfaces and > obviously, the new common watchdog framework didn't implement this > interface. > > Signed-off-by: Robin Gong > [vzapolskiy:

Re: [PATCH] RDS: IB: Remove deprecated create_workqueue

2016-06-07 Thread Santosh Shilimkar
Hi, On 6/7/2016 12:33 PM, Bhaktipriya Shridhar wrote: alloc_workqueue replaces deprecated create_workqueue(). Since the driver is infiniband which can be used as block device and the workqueue seems involved in regular operation of the device, so a dedicated workqueue has been used with

Re: [PATCH] RDS: IB: Remove deprecated create_workqueue

2016-06-07 Thread Santosh Shilimkar
Hi, On 6/7/2016 12:33 PM, Bhaktipriya Shridhar wrote: alloc_workqueue replaces deprecated create_workqueue(). Since the driver is infiniband which can be used as block device and the workqueue seems involved in regular operation of the device, so a dedicated workqueue has been used with

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