Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Fri, Nov 10, 2017 at 10:07:56AM +0800, Wanpeng Li wrote: > >> Also, you should not put cpumask_t on stack, that's 'broken'. > > Thanks pointing out this. I found a useful comments in arch/x86/kernel/irq.c: > > /* These two declarations are only used in check_irq_vectors_for_cpu_disable() >

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Fri, Nov 10, 2017 at 10:07:56AM +0800, Wanpeng Li wrote: > >> Also, you should not put cpumask_t on stack, that's 'broken'. > > Thanks pointing out this. I found a useful comments in arch/x86/kernel/irq.c: > > /* These two declarations are only used in check_irq_vectors_for_cpu_disable() >

[PATCH 0/4] i2c: mpc: Clean up clock selection

This series cleans up I2C clock selection for Freescale/NXP MPC SoCs during the controller initialization for cases when clock settings are not to be preserved from the bootloader. Patch 1/4 fixes division by zero which happens during controller initialization when (1) clock frequency is not

[PATCH 3/4] i2c: mpc: fix PORDEVSR2 mask for MPC8533/44

According to the reference manuals for the corresponding SoCs, SEC frequency ratio configuration is indicated by bit 26 of the POR Device Status Register 2. Consequently, SEC_CFG bit should be tested by mask 0x20, not 0x80. Testing the wrong bit leads to selection of wrong I2C clock prescaler on

[PATCH 0/4] i2c: mpc: Clean up clock selection

This series cleans up I2C clock selection for Freescale/NXP MPC SoCs during the controller initialization for cases when clock settings are not to be preserved from the bootloader. Patch 1/4 fixes division by zero which happens during controller initialization when (1) clock frequency is not

[PATCH 3/4] i2c: mpc: fix PORDEVSR2 mask for MPC8533/44

According to the reference manuals for the corresponding SoCs, SEC frequency ratio configuration is indicated by bit 26 of the POR Device Status Register 2. Consequently, SEC_CFG bit should be tested by mask 0x20, not 0x80. Testing the wrong bit leads to selection of wrong I2C clock prescaler on

[PATCH 2/4] i2c: mpc: unify obtaining the MPC8533/44 I2C clock prescaler w/ MPC8xxx

Commit 8ce795cb0c6b ("i2c: mpc: assign the correct prescaler from SVR") introduced the common helper function for obtaining the actual clock prescaler value for MPC85xx. However, getting the prescaler for MPC8544 which depends on the SEC frequency ratio on this platform, has been always performed

[PATCH 4/4] i2c: mpc: always determine I2C clock prescaler at runtime

Remove the facility for setting the prescaler value at compile time entirely. It was only used for two SoCs, duplicating the actual value for one of them and setting sometimes bogus value for another. Make all MPC8xxx SoCs obtain their actual I2C clock prescaler from a single place in the code.

[PATCH 2/4] i2c: mpc: unify obtaining the MPC8533/44 I2C clock prescaler w/ MPC8xxx

Commit 8ce795cb0c6b ("i2c: mpc: assign the correct prescaler from SVR") introduced the common helper function for obtaining the actual clock prescaler value for MPC85xx. However, getting the prescaler for MPC8544 which depends on the SEC frequency ratio on this platform, has been always performed

[PATCH 4/4] i2c: mpc: always determine I2C clock prescaler at runtime

Remove the facility for setting the prescaler value at compile time entirely. It was only used for two SoCs, duplicating the actual value for one of them and setting sometimes bogus value for another. Make all MPC8xxx SoCs obtain their actual I2C clock prescaler from a single place in the code.

Re: [PATCH] perf evsel: Fix incorrect precise_ip in default event name

Hi Namhyung, Yeah, you are right. I'll send a new patch later. Thanks, Mengting Zhang On 2017/11/10 14:30, Namhyung Kim wrote: Hello, On Fri, Nov 10, 2017 at 01:49:06PM +0800, Mengting Zhang wrote: When no event is specified with -e option, perf will specify a "cycles" event with the

Re: [PATCH] perf evsel: Fix incorrect precise_ip in default event name

Hi Namhyung, Yeah, you are right. I'll send a new patch later. Thanks, Mengting Zhang On 2017/11/10 14:30, Namhyung Kim wrote: Hello, On Fri, Nov 10, 2017 at 01:49:06PM +0800, Mengting Zhang wrote: When no event is specified with -e option, perf will specify a "cycles" event with the

[PATCH 1/4] i2c: mpc: get MPC8xxx I2C clock prescaler before using it in calculations

Obtaining the actual I2C clock prescaler value in mpc_i2c_setup_8xxx() only happens when the clock parameter is set to something other than MPC_I2C_CLOCK_LEGACY. When the clock parameter is exactly MPC_I2C_CLOCK_LEGACY, the prescaler parameter is used in arithmetic division as provided by the

[PATCH 1/4] i2c: mpc: get MPC8xxx I2C clock prescaler before using it in calculations

Obtaining the actual I2C clock prescaler value in mpc_i2c_setup_8xxx() only happens when the clock parameter is set to something other than MPC_I2C_CLOCK_LEGACY. When the clock parameter is exactly MPC_I2C_CLOCK_LEGACY, the prescaler parameter is used in arithmetic division as provided by the

Re: [PATCH v3 1/2] PM / domains: Rework governor code to be more consistent

On 7 November 2017 at 02:23, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently.

Re: [PATCH v3 1/2] PM / domains: Rework governor code to be more consistent

On 7 November 2017 at 02:23, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The genpd governor currently uses negative PM QoS values to indicate > the "no suspend" condition and 0 as "no restriction", but it doesn't > use them consistently. Moreover, it tries to refresh QoS values for >

Re: [PATCH v4 2/2] PM / QoS: Fix device resume latency framework

On 7 November 2017 at 11:33, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The special value of 0 for device resume latency PM QoS means > "no restriction", but there are two problems with that. > > First, device resume latency PM QoS

Re: [PATCH v4 2/2] PM / QoS: Fix device resume latency framework

On 7 November 2017 at 11:33, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The special value of 0 for device resume latency PM QoS means > "no restriction", but there are two problems with that. > > First, device resume latency PM QoS requests with 0 as the > value are always put in

[PATCH] fixup! kvm: arm debug: introduce helper for single-step

--- arch/arm/include/asm/kvm_host.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index a2e881d6108e..26a1ea6c6542 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@

[PATCH] fixup! kvm: arm debug: introduce helper for single-step

--- arch/arm/include/asm/kvm_host.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index a2e881d6108e..26a1ea6c6542 100644 --- a/arch/arm/include/asm/kvm_host.h +++ b/arch/arm/include/asm/kvm_host.h @@

[git pull] Input updates for v4.14-rc8

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a new ACPI ID for Elan touchpad found in yet another Ideapad model; - Synaptics RMI4 will allow binding to controllers

[git pull] Input updates for v4.14-rc8

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - a new ACPI ID for Elan touchpad found in yet another Ideapad model; - Synaptics RMI4 will allow binding to controllers

[f2fs-dev] [PATCH] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increaced regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

[f2fs-dev] [PATCH] f2fs: validate before set/clear free nat bitmap

In flush_nat_entries, all dirty nats will be flushed and if their new address isn't NULL_ADDR, their bitmaps will be updated, the free_nid_count of the bitmaps will be increaced regardless of whether the nats have already been occupied before. This could lead to wrong free_nid_count. So this patch

Re: [PATCH v2] locking/lockdep: Revise Documentation/locking/crossrelease.txt

On 11/10/2017 4:30 PM, Ingo Molnar wrote: * Byungchul Park wrote: Event C depends on event A. Event A depends on event B. Event B depends on event C. - NOTE: Precisely speaking, a dependency is one between whether a - waiter for an event can be

Re: [PATCH v2] locking/lockdep: Revise Documentation/locking/crossrelease.txt

On 11/10/2017 4:30 PM, Ingo Molnar wrote: * Byungchul Park wrote: Event C depends on event A. Event A depends on event B. Event B depends on event C. - NOTE: Precisely speaking, a dependency is one between whether a - waiter for an event can be woken up and whether

[PATCH RFC] kbuild: fixes in Makefile.lib

commit cf4f21938e13e ("kbuild: Allow to specify composite modules with modname-m") add modname-m support, but miss to update the corresponding multi-objs-m defination. commit 551559e13af1c ("kbuild: implement modules.order") miss to filter the subdir listed in obj-m. Except that the subdirs

[PATCH RFC] kbuild: fixes in Makefile.lib

commit cf4f21938e13e ("kbuild: Allow to specify composite modules with modname-m") add modname-m support, but miss to update the corresponding multi-objs-m defination. commit 551559e13af1c ("kbuild: implement modules.order") miss to filter the subdir listed in obj-m. Except that the subdirs

Re: [PATCH v5 15/37] tracing: Add variable support to hist triggers

Hi Tom, On Thu, Nov 09, 2017 at 02:33:46PM -0600, Tom Zanussi wrote: > Add support for saving the value of a current event's event field by > assigning it to a variable that can be read by a subsequent event. > > The basic syntax for saving a variable is to simply prefix a unique > variable name

Re: [PATCH v5 15/37] tracing: Add variable support to hist triggers

Hi Tom, On Thu, Nov 09, 2017 at 02:33:46PM -0600, Tom Zanussi wrote: > Add support for saving the value of a current event's event field by > assigning it to a variable that can be read by a subsequent event. > > The basic syntax for saving a variable is to simply prefix a unique > variable name

[RFC PATCH] mm: fix device-dax pud write-faults triggered by get_user_pages()

Currently only get_user_pages_fast() can safely handle the writable gup case due to its use of pud_access_permitted() to check whether the pud entry is writable. In the gup slow path pud_write() is used instead of pud_access_permitted() and to date it has been unimplemented, just calls BUG_ON().

[RFC PATCH] mm: fix device-dax pud write-faults triggered by get_user_pages()

Currently only get_user_pages_fast() can safely handle the writable gup case due to its use of pud_access_permitted() to check whether the pud entry is writable. In the gup slow path pud_write() is used instead of pud_access_permitted() and to date it has been unimplemented, just calls BUG_ON().

Re: [PATCH v2] locking/lockdep: Revise Documentation/locking/crossrelease.txt

* Byungchul Park wrote: > Event C depends on event A. > Event A depends on event B. > Event B depends on event C. > > - NOTE: Precisely speaking, a dependency is one between whether a > - waiter for an event can be woken up and whether another waiter

Re: [PATCH v2] locking/lockdep: Revise Documentation/locking/crossrelease.txt

* Byungchul Park wrote: > Event C depends on event A. > Event A depends on event B. > Event B depends on event C. > > - NOTE: Precisely speaking, a dependency is one between whether a > - waiter for an event can be woken up and whether another waiter for > - another event

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

* Rafael J. Wysocki wrote: > Hi Linus, > > On 11/9/2017 11:38 AM, WANG Chao wrote: > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused > > a serious performance issue when reading from /proc/cpuinfo on system > > with aperfmperf. > > > >

Re: [PATCH] x86: use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" again

* Rafael J. Wysocki wrote: > Hi Linus, > > On 11/9/2017 11:38 AM, WANG Chao wrote: > > Commit 941f5f0f6ef5 (x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo) caused > > a serious performance issue when reading from /proc/cpuinfo on system > > with aperfmperf. > > > > For each cpu,

Re: [alsa-devel] [RFC PATCH v2 7/7] sound: core: Avoid using timespec for struct snd_timer_tread

On Fri, 10 Nov 2017 00:20:10 +0100, Arnd Bergmann wrote: > > On Thu, Nov 9, 2017 at 7:11 PM, Takashi Iwai wrote: > > On Thu, 09 Nov 2017 18:01:47 +0100, > > Arnd Bergmann wrote: > >> > >> On Thu, Nov 9, 2017 at 5:52 PM, Takashi Iwai wrote: > >> > > >> > IOW, is

Re: [alsa-devel] [RFC PATCH v2 7/7] sound: core: Avoid using timespec for struct snd_timer_tread

On Fri, 10 Nov 2017 00:20:10 +0100, Arnd Bergmann wrote: > > On Thu, Nov 9, 2017 at 7:11 PM, Takashi Iwai wrote: > > On Thu, 09 Nov 2017 18:01:47 +0100, > > Arnd Bergmann wrote: > >> > >> On Thu, Nov 9, 2017 at 5:52 PM, Takashi Iwai wrote: > >> > > >> > IOW, is there any macro indicating the

Re: [PATCH] x86, pkeys: update documentation about availability

* Dave Hansen wrote: > On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > > > * Dave Hansen wrote: > > > >> > >> From: Dave Hansen > >> > >> Now that CPUs that implement Memory Protection Keys are publicly >

Re: [PATCH] x86, pkeys: update documentation about availability

* Dave Hansen wrote: > On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > > > * Dave Hansen wrote: > > > >> > >> From: Dave Hansen > >> > >> Now that CPUs that implement Memory Protection Keys are publicly > >> available we can be a bit less oblique about where it is available. > >> > >>

Re: [PATCH 1/2] sched/swait: allow swake_up() to return

On Thu, Nov 09, 2017 at 11:06:53AM +0100, Paolo Bonzini wrote: > On 09/11/2017 10:18, Peter Xu wrote: > > Let swake_up() to return whether any of the waiters is waked up. One use > > case of it would be: > > > > if (swait_active(wq)) { > > swake_up(wq); > > // do something when waiter

Re: [PATCH 1/2] sched/swait: allow swake_up() to return

On Thu, Nov 09, 2017 at 11:06:53AM +0100, Paolo Bonzini wrote: > On 09/11/2017 10:18, Peter Xu wrote: > > Let swake_up() to return whether any of the waiters is waked up. One use > > case of it would be: > > > > if (swait_active(wq)) { > > swake_up(wq); > > // do something when waiter

Re: [PATCH v2 0/4] KVM: Paravirt remote TLB flush

2017-11-10 15:04 GMT+08:00 Wanpeng Li : > Remote flushing api's does a busy wait which is fine in bare-metal > scenario. But with-in the guest, the vcpus might have been pre-empted > or blocked. In this scenario, the initator vcpu would end up > busy-waiting for a long amount

Re: [PATCH v2 0/4] KVM: Paravirt remote TLB flush

2017-11-10 15:04 GMT+08:00 Wanpeng Li : > Remote flushing api's does a busy wait which is fine in bare-metal > scenario. But with-in the guest, the vcpus might have been pre-empted > or blocked. In this scenario, the initator vcpu would end up > busy-waiting for a long amount of time. > > This

Re: [PATCH 1/2] sched/swait: allow swake_up() to return

On Thu, Nov 09, 2017 at 11:23:03AM +0100, Peter Zijlstra wrote: > On Thu, Nov 09, 2017 at 05:18:53PM +0800, Peter Xu wrote: > > Let swake_up() to return whether any of the waiters is waked up. One use > > case of it would be: > > > > if (swait_active(wq)) { > > swake_up(wq); > > // do

Re: [PATCH 1/2] sched/swait: allow swake_up() to return

On Thu, Nov 09, 2017 at 11:23:03AM +0100, Peter Zijlstra wrote: > On Thu, Nov 09, 2017 at 05:18:53PM +0800, Peter Xu wrote: > > Let swake_up() to return whether any of the waiters is waked up. One use > > case of it would be: > > > > if (swait_active(wq)) { > > swake_up(wq); > > // do

[PATCH v2 3/4] KVM: X86: introduce invalidate_gpa argument to tlb flush

From: Wanpeng Li Introduce a new bool invalidate_gpa argument to kvm_x86_ops->tlb_flush, it will be used by later patches to just flush guest tlb. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li

[PATCH v2 1/4] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will prevent

[PATCH v2 2/4] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set

[PATCH v2 1/4] KVM: Add vCPU running/preempted state

From: Wanpeng Li This patch reuses the preempted field in kvm_steal_time, and will export the vcpu running/pre-empted information to the guest from host. This will enable guest to intelligently send ipi to running vcpus and set flag for pre-empted vcpus. This will prevent waiting for vcpus that

[PATCH v2 2/4] KVM: Add paravirt remote TLB flush

From: Wanpeng Li Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt

[PATCH v2 3/4] KVM: X86: introduce invalidate_gpa argument to tlb flush

From: Wanpeng Li Introduce a new bool invalidate_gpa argument to kvm_x86_ops->tlb_flush, it will be used by later patches to just flush guest tlb. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/include/asm/kvm_host.h | 2 +- arch/x86/kvm/svm.c | 14

[PATCH v2 0/4] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH v2 0/4] KVM: Paravirt remote TLB flush

Remote flushing api's does a busy wait which is fine in bare-metal scenario. But with-in the guest, the vcpus might have been pre-empted or blocked. In this scenario, the initator vcpu would end up busy-waiting for a long amount of time. This patch set implements para-virt flush tlbs making sure

[PATCH v2 4/4] KVM: Add flush_on_enter before guest enter

PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/x86.c | 22

[PATCH v2 4/4] KVM: Add flush_on_enter before guest enter

PV-Flush guest would indicate to flush on enter, flush the TLB before entering and exiting the guest. Cc: Paolo Bonzini Cc: Radim Krčmář Signed-off-by: Wanpeng Li --- arch/x86/kvm/cpuid.c | 3 ++- arch/x86/kvm/x86.c | 22 ++ 2 files changed, 16 insertions(+), 9

Re: [PATCH] pstore: use ktime_get_real_fast_ns() instead of __getnstimeofday()

On Thu, 9 Nov 2017, Kees Cook wrote: > On Thu, Nov 9, 2017 at 4:46 PM, Thomas Gleixner wrote: > > On Fri, 10 Nov 2017, Arnd Bergmann wrote: > >> On Fri, Nov 10, 2017 at 12:00 AM, Thomas Gleixner > >> wrote: > >> > Hmm, no. None of the regular accessor

Re: [PATCH] pstore: use ktime_get_real_fast_ns() instead of __getnstimeofday()

On Thu, 9 Nov 2017, Kees Cook wrote: > On Thu, Nov 9, 2017 at 4:46 PM, Thomas Gleixner wrote: > > On Fri, 10 Nov 2017, Arnd Bergmann wrote: > >> On Fri, Nov 10, 2017 at 12:00 AM, Thomas Gleixner > >> wrote: > >> > Hmm, no. None of the regular accessor functions can be called from NMI > >> >

Re: [PATCH v17 5/6] vfio: ABI for mdev display dma-buf operation

On Thu, Nov 09, 2017 at 01:54:57PM -0700, Alex Williamson wrote: > On Thu, 9 Nov 2017 19:35:14 +0100 > Gerd Hoffmann wrote: > > > Hi, > > > > > struct vfio_device_gfx_plane_info lacks the head field we've been > > > discussing. Thanks, > > > > Adding multihead support

Re: [PATCH v17 5/6] vfio: ABI for mdev display dma-buf operation

On Thu, Nov 09, 2017 at 01:54:57PM -0700, Alex Williamson wrote: > On Thu, 9 Nov 2017 19:35:14 +0100 > Gerd Hoffmann wrote: > > > Hi, > > > > > struct vfio_device_gfx_plane_info lacks the head field we've been > > > discussing. Thanks, > > > > Adding multihead support turned out to not be

[PATCH V4 06/12] clk: sprd: add divider clock support

This is a feature that can also be found in sprd composite clocks, provide a bunch of helpers that can be reused in that. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/div.c| 100

[PATCH V4 06/12] clk: sprd: add divider clock support

This is a feature that can also be found in sprd composite clocks, provide a bunch of helpers that can be reused in that. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/div.c| 100 ++ drivers/clk/sprd/div.h

[PATCH V4 12/12] arm64: dts: add clocks for SC9860

Some clocks on SC9860 are in the same address area with syscon devices, those are what have a property of 'sprd,syscon' which would refer to syscon devices, others would have a reg property indicated their address ranges. Signed-off-by: Chunyan Zhang ---

[PATCH V4 12/12] arm64: dts: add clocks for SC9860

Some clocks on SC9860 are in the same address area with syscon devices, those are what have a property of 'sprd,syscon' which would refer to syscon devices, others would have a reg property indicated their address ranges. Signed-off-by: Chunyan Zhang --- arch/arm64/boot/dts/sprd/sc9860.dtsi |

[PATCH V4 10/12] clk: sprd: add clocks support for SC9860

This patch added the list of clocks for Spreadtrum's SC9860 SoC, together with clock initialization code. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Kconfig | 10 + drivers/clk/sprd/Makefile |3 + drivers/clk/sprd/sc9860-clk.c | 1987

[PATCH V4 10/12] clk: sprd: add clocks support for SC9860

This patch added the list of clocks for Spreadtrum's SC9860 SoC, together with clock initialization code. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Kconfig | 10 + drivers/clk/sprd/Makefile |3 + drivers/clk/sprd/sc9860-clk.c | 1987

[PATCH V4 09/12] clk: sprd: Add dt-bindings include file for SC9860

This file defines all SC9860 clock indexes, it should be included in the device tree in which there's device using the clocks. Signed-off-by: Chunyan Zhang --- include/dt-bindings/clock/sprd,sc9860-clk.h | 408 1 file changed, 408

[PATCH V4 09/12] clk: sprd: Add dt-bindings include file for SC9860

This file defines all SC9860 clock indexes, it should be included in the device tree in which there's device using the clocks. Signed-off-by: Chunyan Zhang --- include/dt-bindings/clock/sprd,sc9860-clk.h | 408 1 file changed, 408 insertions(+) create mode 100644

Re: [RFC PATCH 0/2] apply write hints to select the type of segments

On 2017/11/10 8:23, Hyunchul Lee wrote: > Hello, Chao > > On 11/09/2017 06:12 PM, Chao Yu wrote: >> On 2017/11/9 13:51, Hyunchul Lee wrote: >>> From: Hyunchul Lee >>> >>> Using write hints[1], applications can inform the life time of the data >>> written to devices. and

[PATCH V4 11/12] arm64: dts: add syscon for whale2 platform

Some clocks on SC9860 are in the same address area with syscon devices, the proper syscon node will be quoted under the definitions of those clocks in DT. Signed-off-by: Chunyan Zhang --- arch/arm64/boot/dts/sprd/whale2.dtsi | 46

Re: [RFC PATCH 0/2] apply write hints to select the type of segments

On 2017/11/10 8:23, Hyunchul Lee wrote: > Hello, Chao > > On 11/09/2017 06:12 PM, Chao Yu wrote: >> On 2017/11/9 13:51, Hyunchul Lee wrote: >>> From: Hyunchul Lee >>> >>> Using write hints[1], applications can inform the life time of the data >>> written to devices. and this[2] reported that the

[PATCH V4 11/12] arm64: dts: add syscon for whale2 platform

Some clocks on SC9860 are in the same address area with syscon devices, the proper syscon node will be quoted under the definitions of those clocks in DT. Signed-off-by: Chunyan Zhang --- arch/arm64/boot/dts/sprd/whale2.dtsi | 46 +++- 1 file changed, 45

[PATCH v2] checkpatch: Fix checks for Kconfig help text

If one patch has Kconfig section, the check script variable '$is_start' will be set by first 'config' line and the variable '$is_end' is to be set by the second 'config' line. But patches often only has one 'config' line so we have no chance to set '$is_end', as result below condition is invalid

[PATCH V4 07/12] clk: sprd: add composite clock support

This patch introduced composite clock driver for Spreadtrum's SoCs. The functions of this composite clock simply consists of divider and mux clocks. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile| 1 + drivers/clk/sprd/composite.c | 65

[PATCH V4 02/12] dt-bindings: Add Spreadtrum clock binding documentation

Introduce a new binding with its documentation for Spreadtrum clock sub-framework. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/clock/sprd.txt | 63 1 file changed, 63 insertions(+) create mode 100644

[PATCH v2] checkpatch: Fix checks for Kconfig help text

If one patch has Kconfig section, the check script variable '$is_start' will be set by first 'config' line and the variable '$is_end' is to be set by the second 'config' line. But patches often only has one 'config' line so we have no chance to set '$is_end', as result below condition is invalid

[PATCH V4 07/12] clk: sprd: add composite clock support

This patch introduced composite clock driver for Spreadtrum's SoCs. The functions of this composite clock simply consists of divider and mux clocks. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile| 1 + drivers/clk/sprd/composite.c | 65

[PATCH V4 02/12] dt-bindings: Add Spreadtrum clock binding documentation

Introduce a new binding with its documentation for Spreadtrum clock sub-framework. Signed-off-by: Chunyan Zhang --- Documentation/devicetree/bindings/clock/sprd.txt | 63 1 file changed, 63 insertions(+) create mode 100644

[PATCH V4 03/12] clk: sprd: Add common infrastructure

Added Spreadtrum's clock driver framework together with common structures and interface functions. Signed-off-by: Chunyan Zhang --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/sprd/Kconfig | 4 ++ drivers/clk/sprd/Makefile |

[PATCH V4 03/12] clk: sprd: Add common infrastructure

Added Spreadtrum's clock driver framework together with common structures and interface functions. Signed-off-by: Chunyan Zhang --- drivers/clk/Kconfig | 1 + drivers/clk/Makefile | 1 + drivers/clk/sprd/Kconfig | 4 ++ drivers/clk/sprd/Makefile | 3 ++

[PATCH V4 08/12] clk: sprd: add adjustable pll support

Introduced a common adjustable pll clock driver for Spreadtrum SoCs. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/pll.c| 268 ++ drivers/clk/sprd/pll.h| 110

[PATCH V4 08/12] clk: sprd: add adjustable pll support

Introduced a common adjustable pll clock driver for Spreadtrum SoCs. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/pll.c| 268 ++ drivers/clk/sprd/pll.h| 110 +++ 3 files changed, 379

[PATCH V4 05/12] clk: sprd: add mux clock support

This patch adds clock multiplexor support for Spreadtrum platforms, the mux clocks also can be found in sprd composite clocks, so provides two helpers that can be reused later on. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 +

[PATCH V4 05/12] clk: sprd: add mux clock support

This patch adds clock multiplexor support for Spreadtrum platforms, the mux clocks also can be found in sprd composite clocks, so provides two helpers that can be reused later on. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/mux.c| 86

[PATCH V4 01/12] drivers: move clock common macros out from vendor directories

These macros are used by more than one SoC vendor platforms, avoid to have many copies of these code, this patch moves them to the common clock directory which every clock drivers can access to. Signed-off-by: Chunyan Zhang --- This patchset also added a few common

[PATCH V4 04/12] clk: sprd: add gate clock support

Some clocks on the Spreadtrum's SoCs are just simple gates. Add support for those clocks. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/gate.c | 124 ++ drivers/clk/sprd/gate.h |

[PATCH V4 01/12] drivers: move clock common macros out from vendor directories

These macros are used by more than one SoC vendor platforms, avoid to have many copies of these code, this patch moves them to the common clock directory which every clock drivers can access to. Signed-off-by: Chunyan Zhang --- This patchset also added a few common clock mactos into

[PATCH V4 04/12] clk: sprd: add gate clock support

Some clocks on the Spreadtrum's SoCs are just simple gates. Add support for those clocks. Signed-off-by: Chunyan Zhang --- drivers/clk/sprd/Makefile | 1 + drivers/clk/sprd/gate.c | 124 ++ drivers/clk/sprd/gate.h | 63 +++

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171109 22:19]: > > * Tony Lindgren [171110 03:28]: > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > Here's a better version, the static mapping

[PATCH V4 00/12] add clock driver for Spreadtrum platforms

This series adds Spreadtrum clock support together with its binding documentation and devicetree data. Any comments would be greatly appreciated. This patchset also added a few common clock mactos into drivers/clk/clk_common.h, which are generally useful for all vendors' clock driver, sunxi-ng,

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171109 22:19]: > > * Tony Lindgren [171110 03:28]: > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > Here's a better version, the static mapping did not get used.. It > > just moved

[PATCH V4 00/12] add clock driver for Spreadtrum platforms

This series adds Spreadtrum clock support together with its binding documentation and devicetree data. Any comments would be greatly appreciated. This patchset also added a few common clock mactos into drivers/clk/clk_common.h, which are generally useful for all vendors' clock driver, sunxi-ng,

Re: [PATCH] x86, pkeys: update documentation about availability

On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > * Dave Hansen wrote: > >> >> From: Dave Hansen >> >> Now that CPUs that implement Memory Protection Keys are publicly >> available we can be a bit less oblique about where it is available.

Re: [PATCH] x86, pkeys: update documentation about availability

On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > * Dave Hansen wrote: > >> >> From: Dave Hansen >> >> Now that CPUs that implement Memory Protection Keys are publicly >> available we can be a bit less oblique about where it is available. >> >> Signed-off-by: Dave Hansen >> --- >> >>

Re: [PATCH] checkpatch: Fix checks for Kconfig help text

On Fri, Nov 10, 2017 at 02:32:37PM +0800, Leo Yan wrote: > If one patch has Kconfig section with only one 'config', then variable > '$is_start' will be set by first 'config' line and '$is_end' set by the > second 'config' line. But patches often has only one 'config' line so > we have no chance to

[tip:x86/urgent] x86/debug: Handle warnings before the notifier chain, to fix KGDB crash

Commit-ID: a8d6c1bd62ffefb075c9d3570f07659e2a36ecb3 Gitweb: https://git.kernel.org/tip/a8d6c1bd62ffefb075c9d3570f07659e2a36ecb3 Author: Alexander Shishkin AuthorDate: Mon, 24 Jul 2017 13:04:28 +0300 Committer: Ingo Molnar

Re: [PATCH] checkpatch: Fix checks for Kconfig help text

On Fri, Nov 10, 2017 at 02:32:37PM +0800, Leo Yan wrote: > If one patch has Kconfig section with only one 'config', then variable > '$is_start' will be set by first 'config' line and '$is_end' set by the > second 'config' line. But patches often has only one 'config' line so > we have no chance to

[tip:x86/urgent] x86/debug: Handle warnings before the notifier chain, to fix KGDB crash

Commit-ID: a8d6c1bd62ffefb075c9d3570f07659e2a36ecb3 Gitweb: https://git.kernel.org/tip/a8d6c1bd62ffefb075c9d3570f07659e2a36ecb3 Author: Alexander Shishkin AuthorDate: Mon, 24 Jul 2017 13:04:28 +0300 Committer: Ingo Molnar CommitDate: Fri, 10 Nov 2017 07:16:23 +0100 x86/debug: Handle

Re: [PATCHv4 2/3] ARMv8: layerscape: add the pcie ep function support

Hi, On Friday 10 November 2017 09:18 AM, Bao Xiaowei wrote: > Add the pcie controller ep function support of layerscape base on > pcie ep framework. > > Signed-off-by: Bao Xiaowei > --- > v2: > - fix the ioremap function used but no ioumap issue > - optimize the code

Re: [PATCHv4 2/3] ARMv8: layerscape: add the pcie ep function support

Hi, On Friday 10 November 2017 09:18 AM, Bao Xiaowei wrote: > Add the pcie controller ep function support of layerscape base on > pcie ep framework. > > Signed-off-by: Bao Xiaowei > --- > v2: > - fix the ioremap function used but no ioumap issue > - optimize the code structure > - add code

  1   2   3   4   5   6   7   8   9   10   >