Re: [PATCH v12 0/5] Fix issues with huge mapping in ioremap for ARM64
Hi Will, Just curious to know, is there anything that I should be addressing in these patches ? For now, I don't see anything from my side that requires modification, unless one has some more review comments on this. Status so far on and around this: - Status of Toshi's series of patches is still not clear to me. However, if this series can get through first, there won't be conflicting scenarios as far as arm64 is concerned. - I've rebased these patches on tip - Also re-tested these patches for long duration tests with 1 GB mapping case also exercised enough. Test ended positively. Thanks, On 6/1/2018 6:09 PM, Chintan Pandya wrote: This series of patches re-bring huge vmap back for arm64. Patch 1/4 has been taken by Toshi in his series of patches by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86" to avoid merge conflict with this series. These patches are tested on 4.16 kernel with Cortex-A75 based SoC. The test used for verifying these patches is a stress test on ioremap/unmap which tries to re-use same io-address but changes size of mapping randomly i.e. 4K to 2M to 1G etc. The same test used to reproduce 3rd level translation fault without these fixes (and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP mappings" being part of the tree). These patches can also go into '-stable' branch (if accepted) for 4.6 onwards. From V11->V12: - Introduced p*d_page_vaddr helper macros and using them - Rebased over current tip From V10->V11: - Updated pud_free_pmd_page & pmd_free_pte_page to use consistent conding style - Fixed few bugs by using pmd_page_paddr & pud_page_paddr From V9->V10: - Updated commit log for patch 1/4 by Toshi - Addressed review comments by Will on patch 3/4 From V8->V9: - Used __TLBI_VADDR macros in new TLB flush API From V7->V8: - Properly fixed compilation issue in x86 file From V6->V7: - Fixed compilation issue in x86 case - V6 patches were not properly enumarated From V5->V6: - Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove "bool tlb_inv" based variance as it is not need now - Re-naming for consistency From V4->V5: - Add new API __flush_tlb_kernel_pgtable(unsigned long addr) for kernel addresses From V3->V4: - Add header for 'addr' in x86 implementation - Re-order pmd/pud clear and table free - Avoid redundant TLB invalidatation in one perticular case From V2->V3: - Use the exisiting page table free interface to do arm64 specific things From V1->V2: - Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc: Add interfaces to free unmapped page table" - Honored BBM for ARM64 Chintan Pandya (5): ioremap: Update pgtable free interfaces with addr arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable arm64: pgtable: Add p*d_page_vaddr helper macros arm64: Implement page table free interfaces arm64: Re-enable huge io mappings arch/arm64/include/asm/pgtable.h | 3 +++ arch/arm64/include/asm/tlbflush.h | 7 + arch/arm64/mm/mmu.c | 56 +-- arch/x86/mm/pgtable.c | 8 +++--- include/asm-generic/pgtable.h | 8 +++--- lib/ioremap.c | 4 +-- 6 files changed, 57 insertions(+), 29 deletions(-) Chintan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v12 0/5] Fix issues with huge mapping in ioremap for ARM64
Hi Will, Just curious to know, is there anything that I should be addressing in these patches ? For now, I don't see anything from my side that requires modification, unless one has some more review comments on this. Status so far on and around this: - Status of Toshi's series of patches is still not clear to me. However, if this series can get through first, there won't be conflicting scenarios as far as arm64 is concerned. - I've rebased these patches on tip - Also re-tested these patches for long duration tests with 1 GB mapping case also exercised enough. Test ended positively. Thanks, On 6/1/2018 6:09 PM, Chintan Pandya wrote: This series of patches re-bring huge vmap back for arm64. Patch 1/4 has been taken by Toshi in his series of patches by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86" to avoid merge conflict with this series. These patches are tested on 4.16 kernel with Cortex-A75 based SoC. The test used for verifying these patches is a stress test on ioremap/unmap which tries to re-use same io-address but changes size of mapping randomly i.e. 4K to 2M to 1G etc. The same test used to reproduce 3rd level translation fault without these fixes (and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP mappings" being part of the tree). These patches can also go into '-stable' branch (if accepted) for 4.6 onwards. From V11->V12: - Introduced p*d_page_vaddr helper macros and using them - Rebased over current tip From V10->V11: - Updated pud_free_pmd_page & pmd_free_pte_page to use consistent conding style - Fixed few bugs by using pmd_page_paddr & pud_page_paddr From V9->V10: - Updated commit log for patch 1/4 by Toshi - Addressed review comments by Will on patch 3/4 From V8->V9: - Used __TLBI_VADDR macros in new TLB flush API From V7->V8: - Properly fixed compilation issue in x86 file From V6->V7: - Fixed compilation issue in x86 case - V6 patches were not properly enumarated From V5->V6: - Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove "bool tlb_inv" based variance as it is not need now - Re-naming for consistency From V4->V5: - Add new API __flush_tlb_kernel_pgtable(unsigned long addr) for kernel addresses From V3->V4: - Add header for 'addr' in x86 implementation - Re-order pmd/pud clear and table free - Avoid redundant TLB invalidatation in one perticular case From V2->V3: - Use the exisiting page table free interface to do arm64 specific things From V1->V2: - Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc: Add interfaces to free unmapped page table" - Honored BBM for ARM64 Chintan Pandya (5): ioremap: Update pgtable free interfaces with addr arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable arm64: pgtable: Add p*d_page_vaddr helper macros arm64: Implement page table free interfaces arm64: Re-enable huge io mappings arch/arm64/include/asm/pgtable.h | 3 +++ arch/arm64/include/asm/tlbflush.h | 7 + arch/arm64/mm/mmu.c | 56 +-- arch/x86/mm/pgtable.c | 8 +++--- include/asm-generic/pgtable.h | 8 +++--- lib/ioremap.c | 4 +-- 6 files changed, 57 insertions(+), 29 deletions(-) Chintan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[lkp-robot] [mm, oom] 2d251ff6e6: BUG:unable_to_handle_kernel
FYI, we noticed the following commit (built with gcc-7):
commit: 2d251ff6e66d7978b3e7a9c69e99b7150de26926 ("mm, oom: fix unnecessary
killing of additional processes")
url:
https://github.com/0day-ci/linux/commits/David-Rientjes/mm-oom-fix-unnecessary-killing-of-additional-processes/20180527-033815
base: git://git.cmpxchg.org/linux-mmotm.git master
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 0b018d19da
| 2d251ff6e6 |
+--+++
| boot_successes | 4
| 0 |
| boot_failures| 4
| 4 |
| invoked_oom-killer:gfp_mask=0x | 4
| 2 |
| Mem-Info | 4
| 4 |
| Out_of_memory:Kill_process | 4
| 4 |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4
||
| BUG:unable_to_handle_kernel | 0
| 4 |
| Oops:#[##] | 0
| 4 |
| EIP:oom_reaper | 0
| 4 |
| Kernel_panic-not_syncing:Fatal_exception | 0
| 4 |
+--+++
[ 11.063029] BUG: unable to handle kernel NULL pointer dereference at 0204
[ 11.064104] *pde =
[ 11.064548] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 11.065328] CPU: 0 PID: 21 Comm: oom_reaper Not tainted
4.17.0-rc5-mm1-00218-g2d251ff #1
[ 11.066537] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 11.067786] EIP: oom_reaper+0x115/0x296
[ 11.068374] Code: 01 00 00 bb 54 92 65 7e c7 05 ac a8 65 7e 00 02 00 00 b8
80 a8 65 7e e8 9c a2 63 00 85 db 0f 84 fa fe ff ff 8b 83 ac 04 00 00 <8b> b0 04
02 00 00 8b 86 c8 02 00 00 0f ba e0 15 0f 82 55 01 00 00
[ 11.071210] EAX: EBX: 7e659254 ECX: 0001 EDX:
[ 11.072142] ESI: 78090960 EDI: 7816b500 EBP: 78167f8c ESP: 78167f68
[ 11.073073] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010202
[ 11.074075] CR0: 80050033 CR2: 0204 CR3: 033d7000 CR4: 00040690
[ 11.074994] Call Trace:
[ 11.075380] ? wait_woken+0x75/0x75
[ 11.075911] ? kthread+0xef/0xf4
[ 11.076413] ? __oom_reap_task_mm+0x6f/0x6f
[ 11.077036] ? kthread_create_on_node+0x1a/0x1a
[ 11.077718] ? ret_from_fork+0x19/0x24
[ 11.078286] Modules linked in:
[ 11.078747] CR2: 0204
[ 11.079253] ---[ end trace 881b7ebfce401a98 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc5-mm1 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
[lkp-robot] [mm, oom] 2d251ff6e6: BUG:unable_to_handle_kernel
FYI, we noticed the following commit (built with gcc-7):
commit: 2d251ff6e66d7978b3e7a9c69e99b7150de26926 ("mm, oom: fix unnecessary
killing of additional processes")
url:
https://github.com/0day-ci/linux/commits/David-Rientjes/mm-oom-fix-unnecessary-killing-of-additional-processes/20180527-033815
base: git://git.cmpxchg.org/linux-mmotm.git master
in testcase: boot
on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | 0b018d19da
| 2d251ff6e6 |
+--+++
| boot_successes | 4
| 0 |
| boot_failures| 4
| 4 |
| invoked_oom-killer:gfp_mask=0x | 4
| 2 |
| Mem-Info | 4
| 4 |
| Out_of_memory:Kill_process | 4
| 4 |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4
||
| BUG:unable_to_handle_kernel | 0
| 4 |
| Oops:#[##] | 0
| 4 |
| EIP:oom_reaper | 0
| 4 |
| Kernel_panic-not_syncing:Fatal_exception | 0
| 4 |
+--+++
[ 11.063029] BUG: unable to handle kernel NULL pointer dereference at 0204
[ 11.064104] *pde =
[ 11.064548] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 11.065328] CPU: 0 PID: 21 Comm: oom_reaper Not tainted
4.17.0-rc5-mm1-00218-g2d251ff #1
[ 11.066537] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 11.067786] EIP: oom_reaper+0x115/0x296
[ 11.068374] Code: 01 00 00 bb 54 92 65 7e c7 05 ac a8 65 7e 00 02 00 00 b8
80 a8 65 7e e8 9c a2 63 00 85 db 0f 84 fa fe ff ff 8b 83 ac 04 00 00 <8b> b0 04
02 00 00 8b 86 c8 02 00 00 0f ba e0 15 0f 82 55 01 00 00
[ 11.071210] EAX: EBX: 7e659254 ECX: 0001 EDX:
[ 11.072142] ESI: 78090960 EDI: 7816b500 EBP: 78167f8c ESP: 78167f68
[ 11.073073] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010202
[ 11.074075] CR0: 80050033 CR2: 0204 CR3: 033d7000 CR4: 00040690
[ 11.074994] Call Trace:
[ 11.075380] ? wait_woken+0x75/0x75
[ 11.075911] ? kthread+0xef/0xf4
[ 11.076413] ? __oom_reap_task_mm+0x6f/0x6f
[ 11.077036] ? kthread_create_on_node+0x1a/0x1a
[ 11.077718] ? ret_from_fork+0x19/0x24
[ 11.078286] Modules linked in:
[ 11.078747] CR2: 0204
[ 11.079253] ---[ end trace 881b7ebfce401a98 ]---
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc5-mm1 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
Hi,
On Saturday 02 June 2018 12:02 PM, Stephen Boyd wrote:
> Quoting Faiz Abbas (2018-05-30 07:11:32)
>> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
>> index bfc82636999c..57b8dc0fe719 100644
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>> / {
>> compatible = "ti,dra762", "ti,dra7";
>>
>> + ocp {
>> +
>> + target-module@0x42c0 {
>
> Drop the 0x on unit address. Also, it should match the first register
> property. And what is a "target-module"?
>
Will fix it. And please see
Documentation/devicetree/bindings/bus/ti-sysc.txt
Thanks,
Faiz
Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN
Hi,
On Saturday 02 June 2018 12:02 PM, Stephen Boyd wrote:
> Quoting Faiz Abbas (2018-05-30 07:11:32)
>> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
>> index bfc82636999c..57b8dc0fe719 100644
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>> / {
>> compatible = "ti,dra762", "ti,dra7";
>>
>> + ocp {
>> +
>> + target-module@0x42c0 {
>
> Drop the 0x on unit address. Also, it should match the first register
> property. And what is a "target-module"?
>
Will fix it. And please see
Documentation/devicetree/bindings/bus/ti-sysc.txt
Thanks,
Faiz
[PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks
From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq enabled (using spin_lock()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock()) if "oops_in_progress" is equal or greater than 1 to avoid deadlocks. There is a case ocurring a deadlock related to the lock and oops_in_progress. A CPU could be stopped by smp_send_stop() while it was holding the port lock because irq was enabled. Once a CPU stops, it doesn't respond interrupts anymore and the lock stays locked forever. console_flush_on_panic() is called during panic() and it eventually holds the uart lock but the lock is held by another stopped CPU and it is a deadlock. By moving bust_spinlocks(0) after console_flush_on_panic(), let the console device drivers think the Oops is still in progress to call spin_trylock() instead of spin_lock() to avoid the deadlock. Signed-off-by: Hoeun Ryu --- kernel/panic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/panic.c b/kernel/panic.c index 42e4874..b4063b6 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -233,8 +233,6 @@ void panic(const char *fmt, ...) if (_crash_kexec_post_notifiers) __crash_kexec(NULL); - bust_spinlocks(0); - /* * We may have ended up stopping the CPU holding the lock (in * smp_send_stop()) while still having some valuable data in the console @@ -246,6 +244,8 @@ void panic(const char *fmt, ...) debug_locks_off(); console_flush_on_panic(); + bust_spinlocks(0); + if (!panic_blink) panic_blink = no_blink; -- 2.1.4
[PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks
From: Hoeun Ryu Many console device drivers hold the uart_port->lock spinlock with irq enabled (using spin_lock()) while the device drivers are writing characters to their devices, but the device drivers just try to hold the spin lock (using spin_trylock()) if "oops_in_progress" is equal or greater than 1 to avoid deadlocks. There is a case ocurring a deadlock related to the lock and oops_in_progress. A CPU could be stopped by smp_send_stop() while it was holding the port lock because irq was enabled. Once a CPU stops, it doesn't respond interrupts anymore and the lock stays locked forever. console_flush_on_panic() is called during panic() and it eventually holds the uart lock but the lock is held by another stopped CPU and it is a deadlock. By moving bust_spinlocks(0) after console_flush_on_panic(), let the console device drivers think the Oops is still in progress to call spin_trylock() instead of spin_lock() to avoid the deadlock. Signed-off-by: Hoeun Ryu --- kernel/panic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/panic.c b/kernel/panic.c index 42e4874..b4063b6 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -233,8 +233,6 @@ void panic(const char *fmt, ...) if (_crash_kexec_post_notifiers) __crash_kexec(NULL); - bust_spinlocks(0); - /* * We may have ended up stopping the CPU holding the lock (in * smp_send_stop()) while still having some valuable data in the console @@ -246,6 +244,8 @@ void panic(const char *fmt, ...) debug_locks_off(); console_flush_on_panic(); + bust_spinlocks(0); + if (!panic_blink) panic_blink = no_blink; -- 2.1.4
Re: [PATCH] mfd: arizona: Don't use regmap_read_poll_timeout
On Fri, 11 May 2018, Charles Keepax wrote:
> Some Arizona CODECs have a small timing window where they will
> NAK an I2C transaction if it happens before the boot done bit is
> set. This can cause the read of the register containing the boot
> done bit to fail until it is set. Since regmap_read_poll_timeout
> will abort polling if a read fails it can't be reliably used to
> poll the boot done bit over I2C.
>
> Do a partial revert of ef84f885e037 ("mfd: arizona: Refactor
> arizona_poll_reg"), removing the regmap_read_poll_timeout but
> leaving the refactoring to make the arizona_poll_reg take more
> sensible arguments.
>
> Fixes: ef84f885e037 ("mfd: arizona: Refactor arizona_poll_reg")
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/arizona-core.c | 29 +
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 83f1c5a516d9..2ed29ce08dac 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -240,18 +240,31 @@ static int arizona_poll_reg(struct arizona *arizona,
> int timeout_ms, unsigned int reg,
> unsigned int mask, unsigned int target)
> {
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_ms * 1000);
USEC_PER_MSEC ?
> unsigned int val = 0;
> int ret;
>
> - ret = regmap_read_poll_timeout(arizona->regmap,
> -reg, val, ((val & mask) == target),
> -ARIZONA_REG_POLL_DELAY_US,
> -timeout_ms * 1000);
> - if (ret)
> - dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n",
> - reg, val);
> + while (true) {
> + ret = regmap_read(arizona->regmap, reg, );
>
> - return ret;
> + if ((val & mask) == target)
> + return 0;
> +
> + if (ktime_compare(ktime_get(), timeout) > 0)
> + break;
> +
> + usleep_range(ARIZONA_REG_POLL_DELAY_US / 2,
> + ARIZONA_REG_POLL_DELAY_US);
> + }
> +
> + if (ret) {
> + dev_err(arizona->dev, "Failed polling reg 0x%x: %d\n",
> + reg, ret);
> + return ret;
> + }
> +
> + dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n", reg, val);
> + return -ETIMEDOUT;
> }
>
> static int arizona_wait_for_boot(struct arizona *arizona)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mfd: arizona: Don't use regmap_read_poll_timeout
On Fri, 11 May 2018, Charles Keepax wrote:
> Some Arizona CODECs have a small timing window where they will
> NAK an I2C transaction if it happens before the boot done bit is
> set. This can cause the read of the register containing the boot
> done bit to fail until it is set. Since regmap_read_poll_timeout
> will abort polling if a read fails it can't be reliably used to
> poll the boot done bit over I2C.
>
> Do a partial revert of ef84f885e037 ("mfd: arizona: Refactor
> arizona_poll_reg"), removing the regmap_read_poll_timeout but
> leaving the refactoring to make the arizona_poll_reg take more
> sensible arguments.
>
> Fixes: ef84f885e037 ("mfd: arizona: Refactor arizona_poll_reg")
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/arizona-core.c | 29 +
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 83f1c5a516d9..2ed29ce08dac 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -240,18 +240,31 @@ static int arizona_poll_reg(struct arizona *arizona,
> int timeout_ms, unsigned int reg,
> unsigned int mask, unsigned int target)
> {
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_ms * 1000);
USEC_PER_MSEC ?
> unsigned int val = 0;
> int ret;
>
> - ret = regmap_read_poll_timeout(arizona->regmap,
> -reg, val, ((val & mask) == target),
> -ARIZONA_REG_POLL_DELAY_US,
> -timeout_ms * 1000);
> - if (ret)
> - dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n",
> - reg, val);
> + while (true) {
> + ret = regmap_read(arizona->regmap, reg, );
>
> - return ret;
> + if ((val & mask) == target)
> + return 0;
> +
> + if (ktime_compare(ktime_get(), timeout) > 0)
> + break;
> +
> + usleep_range(ARIZONA_REG_POLL_DELAY_US / 2,
> + ARIZONA_REG_POLL_DELAY_US);
> + }
> +
> + if (ret) {
> + dev_err(arizona->dev, "Failed polling reg 0x%x: %d\n",
> + reg, ret);
> + return ret;
> + }
> +
> + dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n", reg, val);
> + return -ETIMEDOUT;
> }
>
> static int arizona_wait_for_boot(struct arizona *arizona)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH] clk-si514, clk-si544: Implement prepare/unprepare/is_prepared operations
This adds prepare/unprepare/is_prepared functionality to the drivers for
the SI544 and SI514 chips, allowing the clock output to be disabled when
the clock is not in use.
Signed-off-by: Mike Looijmans
---
drivers/clk/clk-si514.c | 38 +-
drivers/clk/clk-si544.c | 39 ++-
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-si514.c b/drivers/clk/clk-si514.c
index 09b6718..153b3a2 100644
--- a/drivers/clk/clk-si514.c
+++ b/drivers/clk/clk-si514.c
@@ -74,6 +74,33 @@ static int si514_enable_output(struct clk_si514 *data, bool
enable)
SI514_CONTROL_OE, enable ? SI514_CONTROL_OE : 0);
}
+static int si514_prepare(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+
+ return si514_enable_output(data, true);
+}
+
+static void si514_unprepare(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+
+ si514_enable_output(data, false);
+}
+
+static int si514_is_prepared(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+ unsigned int val;
+ int err;
+
+ err = regmap_read(data->regmap, SI514_REG_CONTROL, );
+ if (err < 0)
+ return err;
+
+ return !!(val & SI514_CONTROL_OE);
+}
+
/* Retrieve clock multiplier and dividers from hardware */
static int si514_get_muldiv(struct clk_si514 *data,
struct clk_si514_muldiv *settings)
@@ -235,12 +262,17 @@ static int si514_set_rate(struct clk_hw *hw, unsigned
long rate,
{
struct clk_si514 *data = to_clk_si514(hw);
struct clk_si514_muldiv settings;
+ unsigned int old_oe_state;
int err;
err = si514_calc_muldiv(, rate);
if (err)
return err;
+ err = regmap_read(data->regmap, SI514_REG_CONTROL, _oe_state);
+ if (err)
+ return err;
+
si514_enable_output(data, false);
err = si514_set_muldiv(data, );
@@ -255,12 +287,16 @@ static int si514_set_rate(struct clk_hw *hw, unsigned
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
- si514_enable_output(data, true);
+ if (old_oe_state & SI514_CONTROL_OE)
+ si514_enable_output(data, true);
return err;
}
static const struct clk_ops si514_clk_ops = {
+ .prepare = si514_prepare,
+ .unprepare = si514_unprepare,
+ .is_prepared = si514_is_prepared,
.recalc_rate = si514_recalc_rate,
.round_rate = si514_round_rate,
.set_rate = si514_set_rate,
diff --git a/drivers/clk/clk-si544.c b/drivers/clk/clk-si544.c
index e972ffb..f8ed9d9 100644
--- a/drivers/clk/clk-si544.c
+++ b/drivers/clk/clk-si544.c
@@ -86,6 +86,34 @@ static int si544_enable_output(struct clk_si544 *data, bool
enable)
SI544_OE_STATE_ODC_OE, enable ? SI544_OE_STATE_ODC_OE : 0);
}
+static int si544_prepare(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+
+ return si544_enable_output(data, true);
+}
+
+static void si544_unprepare(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+
+ si544_enable_output(data, false);
+}
+
+static int si544_is_prepared(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+ unsigned int val;
+ int err;
+
+ err = regmap_read(data->regmap, SI544_REG_OE_STATE, );
+ if (err < 0)
+ return err;
+
+ return !!(val & SI544_OE_STATE_ODC_OE);
+}
+
+
/* Retrieve clock multiplier and dividers from hardware */
static int si544_get_muldiv(struct clk_si544 *data,
struct clk_si544_muldiv *settings)
@@ -273,6 +301,7 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long
rate,
{
struct clk_si544 *data = to_clk_si544(hw);
struct clk_si544_muldiv settings;
+ unsigned int old_oe_state;
int err;
if (!is_valid_frequency(data, rate))
@@ -282,6 +311,10 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long
rate,
if (err)
return err;
+ err = regmap_read(data->regmap, SI544_REG_OE_STATE, _oe_state);
+ if (err)
+ return err;
+
si544_enable_output(data, false);
/* Allow FCAL for this frequency update */
@@ -303,12 +336,16 @@ static int si544_set_rate(struct clk_hw *hw, unsigned
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
- si544_enable_output(data, true);
+ if (old_oe_state & SI544_OE_STATE_ODC_OE)
+ si544_enable_output(data, true);
return err;
}
static const struct clk_ops si544_clk_ops = {
+ .prepare = si544_prepare,
+ .unprepare = si544_unprepare,
+ .is_prepared = si544_is_prepared,
.recalc_rate = si544_recalc_rate,
.round_rate = si544_round_rate,
.set_rate = si544_set_rate,
--
[PATCH] clk-si514, clk-si544: Implement prepare/unprepare/is_prepared operations
This adds prepare/unprepare/is_prepared functionality to the drivers for
the SI544 and SI514 chips, allowing the clock output to be disabled when
the clock is not in use.
Signed-off-by: Mike Looijmans
---
drivers/clk/clk-si514.c | 38 +-
drivers/clk/clk-si544.c | 39 ++-
2 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-si514.c b/drivers/clk/clk-si514.c
index 09b6718..153b3a2 100644
--- a/drivers/clk/clk-si514.c
+++ b/drivers/clk/clk-si514.c
@@ -74,6 +74,33 @@ static int si514_enable_output(struct clk_si514 *data, bool
enable)
SI514_CONTROL_OE, enable ? SI514_CONTROL_OE : 0);
}
+static int si514_prepare(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+
+ return si514_enable_output(data, true);
+}
+
+static void si514_unprepare(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+
+ si514_enable_output(data, false);
+}
+
+static int si514_is_prepared(struct clk_hw *hw)
+{
+ struct clk_si514 *data = to_clk_si514(hw);
+ unsigned int val;
+ int err;
+
+ err = regmap_read(data->regmap, SI514_REG_CONTROL, );
+ if (err < 0)
+ return err;
+
+ return !!(val & SI514_CONTROL_OE);
+}
+
/* Retrieve clock multiplier and dividers from hardware */
static int si514_get_muldiv(struct clk_si514 *data,
struct clk_si514_muldiv *settings)
@@ -235,12 +262,17 @@ static int si514_set_rate(struct clk_hw *hw, unsigned
long rate,
{
struct clk_si514 *data = to_clk_si514(hw);
struct clk_si514_muldiv settings;
+ unsigned int old_oe_state;
int err;
err = si514_calc_muldiv(, rate);
if (err)
return err;
+ err = regmap_read(data->regmap, SI514_REG_CONTROL, _oe_state);
+ if (err)
+ return err;
+
si514_enable_output(data, false);
err = si514_set_muldiv(data, );
@@ -255,12 +287,16 @@ static int si514_set_rate(struct clk_hw *hw, unsigned
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
- si514_enable_output(data, true);
+ if (old_oe_state & SI514_CONTROL_OE)
+ si514_enable_output(data, true);
return err;
}
static const struct clk_ops si514_clk_ops = {
+ .prepare = si514_prepare,
+ .unprepare = si514_unprepare,
+ .is_prepared = si514_is_prepared,
.recalc_rate = si514_recalc_rate,
.round_rate = si514_round_rate,
.set_rate = si514_set_rate,
diff --git a/drivers/clk/clk-si544.c b/drivers/clk/clk-si544.c
index e972ffb..f8ed9d9 100644
--- a/drivers/clk/clk-si544.c
+++ b/drivers/clk/clk-si544.c
@@ -86,6 +86,34 @@ static int si544_enable_output(struct clk_si544 *data, bool
enable)
SI544_OE_STATE_ODC_OE, enable ? SI544_OE_STATE_ODC_OE : 0);
}
+static int si544_prepare(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+
+ return si544_enable_output(data, true);
+}
+
+static void si544_unprepare(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+
+ si544_enable_output(data, false);
+}
+
+static int si544_is_prepared(struct clk_hw *hw)
+{
+ struct clk_si544 *data = to_clk_si544(hw);
+ unsigned int val;
+ int err;
+
+ err = regmap_read(data->regmap, SI544_REG_OE_STATE, );
+ if (err < 0)
+ return err;
+
+ return !!(val & SI544_OE_STATE_ODC_OE);
+}
+
+
/* Retrieve clock multiplier and dividers from hardware */
static int si544_get_muldiv(struct clk_si544 *data,
struct clk_si544_muldiv *settings)
@@ -273,6 +301,7 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long
rate,
{
struct clk_si544 *data = to_clk_si544(hw);
struct clk_si544_muldiv settings;
+ unsigned int old_oe_state;
int err;
if (!is_valid_frequency(data, rate))
@@ -282,6 +311,10 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long
rate,
if (err)
return err;
+ err = regmap_read(data->regmap, SI544_REG_OE_STATE, _oe_state);
+ if (err)
+ return err;
+
si544_enable_output(data, false);
/* Allow FCAL for this frequency update */
@@ -303,12 +336,16 @@ static int si544_set_rate(struct clk_hw *hw, unsigned
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
- si544_enable_output(data, true);
+ if (old_oe_state & SI544_OE_STATE_ODC_OE)
+ si544_enable_output(data, true);
return err;
}
static const struct clk_ops si544_clk_ops = {
+ .prepare = si544_prepare,
+ .unprepare = si544_unprepare,
+ .is_prepared = si544_is_prepared,
.recalc_rate = si544_recalc_rate,
.round_rate = si544_round_rate,
.set_rate = si544_set_rate,
--
Re: [PATCH v1] mfd: intel-lpss: Program REMAP register in PIO mode
On Fri, 01 Jun 2018, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 14:51 +0100, Lee Jones wrote:
> > On Tue, 24 Apr 2018, Andy Shevchenko wrote:
> >
> > > According to documentation REMAP register has to be programmed in
> > > either DMA or PIO mode of the slice.
> > >
> > > Move the DMA capability check below to let REMAP register be
> > > programmed
> > > in PIO mode.
> > >
> > > Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS
> > > devices")
> > > Cc: Mika Westerberg
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > drivers/mfd/intel-lpss.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Applied and tagged for -stable # 4.3+
>
> Thanks!
>
> Though can not see it in Linus' tree still.
Why would it be in Linus' tree?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: intel-lpss: Program REMAP register in PIO mode
On Fri, 01 Jun 2018, Andy Shevchenko wrote:
> On Fri, 2018-05-18 at 14:51 +0100, Lee Jones wrote:
> > On Tue, 24 Apr 2018, Andy Shevchenko wrote:
> >
> > > According to documentation REMAP register has to be programmed in
> > > either DMA or PIO mode of the slice.
> > >
> > > Move the DMA capability check below to let REMAP register be
> > > programmed
> > > in PIO mode.
> > >
> > > Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS
> > > devices")
> > > Cc: Mika Westerberg
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > drivers/mfd/intel-lpss.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Applied and tagged for -stable # 4.3+
>
> Thanks!
>
> Though can not see it in Linus' tree still.
Why would it be in Linus' tree?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: intel-lpss: Correct names of RESETS register bits
On Tue, 24 Apr 2018, Andy Shevchenko wrote: > According to documentation the function has 2 bits for reset > while iDMA 64-bit has only one. > > Rename it accordingly. Note, there is no functional change since > we always handle them together. > > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel-lpss.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1] mfd: intel-lpss: Correct names of RESETS register bits
On Tue, 24 Apr 2018, Andy Shevchenko wrote: > According to documentation the function has 2 bits for reset > while iDMA 64-bit has only one. > > Rename it accordingly. Note, there is no functional change since > we always handle them together. > > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel-lpss.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
BUG: soft lockup in shrink_dcache_parent (2)
Hello, syzbot found the following crash on: HEAD commit:325e14f97e0c Merge branch 'fixes' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=166329d780 kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b dashboard link: https://syzkaller.appspot.com/bug?extid=be3179e6006280aaf174 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+be3179e6006280aaf...@syzkaller.appspotmail.com watchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor4:4588] Modules linked in: irq event stamp: 76609500 hardirqs last enabled at (76609499): [] seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline] hardirqs last enabled at (76609499): [] read_seqcount_begin include/linux/seqlock.h:164 [inline] hardirqs last enabled at (76609499): [] read_seqbegin include/linux/seqlock.h:433 [inline] hardirqs last enabled at (76609499): [] read_seqbegin_or_lock include/linux/seqlock.h:529 [inline] hardirqs last enabled at (76609499): [] d_walk+0x80f/0xc80 fs/dcache.c:1248 hardirqs last disabled at (76609500): [] interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625 softirqs last enabled at (468244): [] __do_softirq+0x778/0xaf5 kernel/softirq.c:311 softirqs last disabled at (468177): [] invoke_softirq kernel/softirq.c:365 [inline] softirqs last disabled at (468177): [] irq_exit+0x1d1/0x200 kernel/softirq.c:405 CPU: 1 PID: 4588 Comm: syz-executor4 Not tainted 4.17.0-rc7+ #81 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline] RIP: 0010:read_seqcount_begin include/linux/seqlock.h:164 [inline] RIP: 0010:read_seqbegin include/linux/seqlock.h:433 [inline] RIP: 0010:read_seqbegin_or_lock include/linux/seqlock.h:529 [inline] RIP: 0010:d_walk+0x840/0xc80 fs/dcache.c:1248 RSP: 0018:880183f5f9f8 EFLAGS: 0293 ORIG_RAX: ff13 RAX: 8801b0d3c680 RBX: 0293 RCX: 1100361a79e5 RDX: RSI: 81c66cfb RDI: 0293 RBP: 880183f5fb78 R08: 8801b0d3ceb8 R09: 0006 R10: 8801b0d3c680 R11: R12: 0200 R13: dc00 R14: 1100307ebf82 R15: 880183f5fb50 FS: 0217c940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ffca8309eac CR3: 000183eb2000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486 vfs_rmdir+0x202/0x470 fs/namei.c:3855 do_rmdir+0x523/0x610 fs/namei.c:3916 __do_sys_rmdir fs/namei.c:3934 [inline] __se_sys_rmdir fs/namei.c:3932 [inline] __x64_sys_rmdir+0x36/0x40 fs/namei.c:3932 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x455777 RSP: 002b:7ffca830a5b8 EFLAGS: 0206 ORIG_RAX: 0054 RAX: ffda RBX: 0065 RCX: 00455777 RDX: RSI: 7ffca830c360 RDI: 7ffca830c360 RBP: 7ffca830c360 R08: R09: 0001 R10: 0006 R11: 0206 R12: 0217d940 R13: R14: 0198 R15: 0001f12d Code: 88 48 89 f8 48 c1 e8 03 42 80 3c 28 00 0f 85 1e 04 00 00 48 83 3d 78 20 0b 07 00 0f 84 29 02 00 00 e8 e5 d7 b2 ff 48 89 df 57 9d <0f> 1f 44 00 00 e8 d6 d7 b2 ff 49 8d 5f 80 48 c1 eb 03 4c 01 eb Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 4581 Comm: syz-executor6 Not tainted 4.17.0-rc7+ #81 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:select_collect+0x249/0x5f0 fs/dcache.c:1443 RSP: 0018:880189947908 EFLAGS: 0286 RAX: RBX: ed0031328f24 RCX: 81c5c3b4 RDX: RSI: 81c5c4fa RDI: 880189947c28 RBP: 8801899479e8 R08: 88018993e5c0 R09: ed0039dde7a4 R10: ed0039dde7a4 R11: 8801ceef3d23 R12: R13: 110031328f28 R14: 880189947c18 R15: dc00 FS: 01790940() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ffebea69e9c CR3: 00018989f000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: d_walk+0x3c3/0xc80 fs/dcache.c:1276 shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486 vfs_rmdir+0x202/0x470 fs/namei.c:3855 do_rmdir+0x523/0x610
BUG: soft lockup in shrink_dcache_parent (2)
Hello, syzbot found the following crash on: HEAD commit:325e14f97e0c Merge branch 'fixes' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=166329d780 kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b dashboard link: https://syzkaller.appspot.com/bug?extid=be3179e6006280aaf174 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+be3179e6006280aaf...@syzkaller.appspotmail.com watchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor4:4588] Modules linked in: irq event stamp: 76609500 hardirqs last enabled at (76609499): [] seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline] hardirqs last enabled at (76609499): [] read_seqcount_begin include/linux/seqlock.h:164 [inline] hardirqs last enabled at (76609499): [] read_seqbegin include/linux/seqlock.h:433 [inline] hardirqs last enabled at (76609499): [] read_seqbegin_or_lock include/linux/seqlock.h:529 [inline] hardirqs last enabled at (76609499): [] d_walk+0x80f/0xc80 fs/dcache.c:1248 hardirqs last disabled at (76609500): [] interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625 softirqs last enabled at (468244): [] __do_softirq+0x778/0xaf5 kernel/softirq.c:311 softirqs last disabled at (468177): [] invoke_softirq kernel/softirq.c:365 [inline] softirqs last disabled at (468177): [] irq_exit+0x1d1/0x200 kernel/softirq.c:405 CPU: 1 PID: 4588 Comm: syz-executor4 Not tainted 4.17.0-rc7+ #81 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline] RIP: 0010:read_seqcount_begin include/linux/seqlock.h:164 [inline] RIP: 0010:read_seqbegin include/linux/seqlock.h:433 [inline] RIP: 0010:read_seqbegin_or_lock include/linux/seqlock.h:529 [inline] RIP: 0010:d_walk+0x840/0xc80 fs/dcache.c:1248 RSP: 0018:880183f5f9f8 EFLAGS: 0293 ORIG_RAX: ff13 RAX: 8801b0d3c680 RBX: 0293 RCX: 1100361a79e5 RDX: RSI: 81c66cfb RDI: 0293 RBP: 880183f5fb78 R08: 8801b0d3ceb8 R09: 0006 R10: 8801b0d3c680 R11: R12: 0200 R13: dc00 R14: 1100307ebf82 R15: 880183f5fb50 FS: 0217c940() GS:8801daf0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ffca8309eac CR3: 000183eb2000 CR4: 001406e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486 vfs_rmdir+0x202/0x470 fs/namei.c:3855 do_rmdir+0x523/0x610 fs/namei.c:3916 __do_sys_rmdir fs/namei.c:3934 [inline] __se_sys_rmdir fs/namei.c:3932 [inline] __x64_sys_rmdir+0x36/0x40 fs/namei.c:3932 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x455777 RSP: 002b:7ffca830a5b8 EFLAGS: 0206 ORIG_RAX: 0054 RAX: ffda RBX: 0065 RCX: 00455777 RDX: RSI: 7ffca830c360 RDI: 7ffca830c360 RBP: 7ffca830c360 R08: R09: 0001 R10: 0006 R11: 0206 R12: 0217d940 R13: R14: 0198 R15: 0001f12d Code: 88 48 89 f8 48 c1 e8 03 42 80 3c 28 00 0f 85 1e 04 00 00 48 83 3d 78 20 0b 07 00 0f 84 29 02 00 00 e8 e5 d7 b2 ff 48 89 df 57 9d <0f> 1f 44 00 00 e8 d6 d7 b2 ff 49 8d 5f 80 48 c1 eb 03 4c 01 eb Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 4581 Comm: syz-executor6 Not tainted 4.17.0-rc7+ #81 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:select_collect+0x249/0x5f0 fs/dcache.c:1443 RSP: 0018:880189947908 EFLAGS: 0286 RAX: RBX: ed0031328f24 RCX: 81c5c3b4 RDX: RSI: 81c5c4fa RDI: 880189947c28 RBP: 8801899479e8 R08: 88018993e5c0 R09: ed0039dde7a4 R10: ed0039dde7a4 R11: 8801ceef3d23 R12: R13: 110031328f28 R14: 880189947c18 R15: dc00 FS: 01790940() GS:8801dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ffebea69e9c CR3: 00018989f000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: d_walk+0x3c3/0xc80 fs/dcache.c:1276 shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486 vfs_rmdir+0x202/0x470 fs/namei.c:3855 do_rmdir+0x523/0x610
Re: [PATCH v2] kernel: event: core: Change return type to vm_fault_t
On Mon, May 21, 2018 at 11:55 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Signed-off-by: Souptick Joarder
> Acked-by: Peter Zijlstra (Intel)
> Reviewed-by: Matthew Wilcox
> ---
> v2: Updated the change log.
> Acked by Peter Zijlstra.
>
> kernel/events/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 96db9ae..d09f1c4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event
> *event)
> }
> EXPORT_SYMBOL_GPL(perf_event_update_userpage);
>
> -static int perf_mmap_fault(struct vm_fault *vmf)
> +static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)
> {
> struct perf_event *event = vmf->vma->vm_file->private_data;
> struct ring_buffer *rb;
> - int ret = VM_FAULT_SIGBUS;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> if (vmf->flags & FAULT_FLAG_MKWRITE) {
> if (vmf->pgoff == 0)
> --
> 1.9.1
>
Any further comment on this patch ?
Re: [PATCH v2] kernel: event: core: Change return type to vm_fault_t
On Mon, May 21, 2018 at 11:55 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Signed-off-by: Souptick Joarder
> Acked-by: Peter Zijlstra (Intel)
> Reviewed-by: Matthew Wilcox
> ---
> v2: Updated the change log.
> Acked by Peter Zijlstra.
>
> kernel/events/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 96db9ae..d09f1c4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event
> *event)
> }
> EXPORT_SYMBOL_GPL(perf_event_update_userpage);
>
> -static int perf_mmap_fault(struct vm_fault *vmf)
> +static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)
> {
> struct perf_event *event = vmf->vma->vm_file->private_data;
> struct ring_buffer *rb;
> - int ret = VM_FAULT_SIGBUS;
> + vm_fault_t ret = VM_FAULT_SIGBUS;
>
> if (vmf->flags & FAULT_FLAG_MKWRITE) {
> if (vmf->pgoff == 0)
> --
> 1.9.1
>
Any further comment on this patch ?
Testing RCU boosting with rcutorture
Hi Paul,
I was testing RCU boosting behavior with rcutorture on rcu/dev and I had some
issues getting it to fail when no RCU boost is done (CONFIG_RCU_BOOST is
disabled and rcutorture is forced to test it using test_boost parameter).
It appears I need to disable RT throttling so that the readers can get
starved by the RT thread. I also noticed some problems in rcutorture where we
are not checking for failure correctly. Below is an RFC patch fixing these
issues, could you let me know your thoughts about it? Thanks a lot,
- Joel
---8<---
From: "Joel Fernandes (Google)"
Date: Sun, 3 Jun 2018 21:30:26 -0700
Subject: [RFC] rcutorture: Make boost test more robust
Currently, with RCU_BOOST disabled, I get no failures when forcing
rcutorture to test RCU boost priority inversion. The reason seems to be
that we don't check for failures if the callback never ran at all for
the duration of the boost-test loop.
Further, the 'rtb' and 'rtbf' counters seem to be used inconsistently.
'rtb' is incremented at the start of each test and 'rtbf' is incremented
per-cpu on each failure of call_rcu. So its possible 'rtbf' > 'rtb'.
To test the boost with rcutorture, I did following on a 4-CPU x86 machine:
# Disable RT throttling
echo 100 > /proc/sys/kernel/sched_rt_period_us
echo 100 > /proc/sys/kernel/sched_rt_runtime_us
modprobe rcutorture test_boost=2
sleep 20
rmmod rcutorture
With patch:
rtbf: 8 rtb: 12
Without patch:
rtbf: 0 rtb: 2
In summary this patch:
- Increments failed and total test counters once per boost-test.
- Checks for failure cases correctly.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 773d6f1b4abf..1d26f9c27d36 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -769,6 +769,18 @@ static void rcu_torture_boost_cb(struct rcu_head *head)
smp_store_release(>inflight, 0);
}
+static bool rcu_torture_boost_failed(unsigned long start, unsigned long end)
+{
+ if (end - start > test_boost_duration * HZ - HZ / 2) {
+ VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
+ n_rcu_torture_boost_failure++;
+
+ return true; /* failed */
+ }
+
+ return false; /* passed */
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -789,6 +801,21 @@ static int rcu_torture_boost(void *arg)
init_rcu_head_on_stack();
/* Each pass through the following loop does one boost-test cycle. */
do {
+ /* Track if the test failed already in this test interval? */
+ bool failed = false;
+
+ /* Increment n_rcu_torture_boosts once per boost-test */
+ while (!kthread_should_stop()) {
+ if (mutex_trylock(_mutex)) {
+ n_rcu_torture_boosts++;
+ mutex_unlock(_mutex);
+ break;
+ }
+ schedule_timeout_uninterruptible(1);
+ }
+ if (kthread_should_stop())
+ goto checkwait;
+
/* Wait for the next test interval. */
oldstarttime = boost_starttime;
while (ULONG_CMP_LT(jiffies, oldstarttime)) {
@@ -807,11 +834,10 @@ static int rcu_torture_boost(void *arg)
/* RCU core before ->inflight = 1. */
smp_store_release(, 1);
call_rcu(, rcu_torture_boost_cb);
- if (jiffies - call_rcu_time >
-test_boost_duration * HZ - HZ / 2) {
-
VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
- n_rcu_torture_boost_failure++;
- }
+ /* Check if the boost test failed */
+ failed = failed ||
+rcu_torture_boost_failed(call_rcu_time,
+jiffies);
call_rcu_time = jiffies;
}
stutter_wait("rcu_torture_boost");
@@ -819,6 +845,14 @@ static int rcu_torture_boost(void *arg)
goto checkwait;
}
+ /*
+* If boost never happened, then inflight will always be 1, in
+* this case the boost check would never happen in the above
+* loop so do another one here.
+*/
+ if (!failed && smp_load_acquire())
+ rcu_torture_boost_failed(call_rcu_time,
Testing RCU boosting with rcutorture
Hi Paul,
I was testing RCU boosting behavior with rcutorture on rcu/dev and I had some
issues getting it to fail when no RCU boost is done (CONFIG_RCU_BOOST is
disabled and rcutorture is forced to test it using test_boost parameter).
It appears I need to disable RT throttling so that the readers can get
starved by the RT thread. I also noticed some problems in rcutorture where we
are not checking for failure correctly. Below is an RFC patch fixing these
issues, could you let me know your thoughts about it? Thanks a lot,
- Joel
---8<---
From: "Joel Fernandes (Google)"
Date: Sun, 3 Jun 2018 21:30:26 -0700
Subject: [RFC] rcutorture: Make boost test more robust
Currently, with RCU_BOOST disabled, I get no failures when forcing
rcutorture to test RCU boost priority inversion. The reason seems to be
that we don't check for failures if the callback never ran at all for
the duration of the boost-test loop.
Further, the 'rtb' and 'rtbf' counters seem to be used inconsistently.
'rtb' is incremented at the start of each test and 'rtbf' is incremented
per-cpu on each failure of call_rcu. So its possible 'rtbf' > 'rtb'.
To test the boost with rcutorture, I did following on a 4-CPU x86 machine:
# Disable RT throttling
echo 100 > /proc/sys/kernel/sched_rt_period_us
echo 100 > /proc/sys/kernel/sched_rt_runtime_us
modprobe rcutorture test_boost=2
sleep 20
rmmod rcutorture
With patch:
rtbf: 8 rtb: 12
Without patch:
rtbf: 0 rtb: 2
In summary this patch:
- Increments failed and total test counters once per boost-test.
- Checks for failure cases correctly.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 773d6f1b4abf..1d26f9c27d36 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -769,6 +769,18 @@ static void rcu_torture_boost_cb(struct rcu_head *head)
smp_store_release(>inflight, 0);
}
+static bool rcu_torture_boost_failed(unsigned long start, unsigned long end)
+{
+ if (end - start > test_boost_duration * HZ - HZ / 2) {
+ VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
+ n_rcu_torture_boost_failure++;
+
+ return true; /* failed */
+ }
+
+ return false; /* passed */
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -789,6 +801,21 @@ static int rcu_torture_boost(void *arg)
init_rcu_head_on_stack();
/* Each pass through the following loop does one boost-test cycle. */
do {
+ /* Track if the test failed already in this test interval? */
+ bool failed = false;
+
+ /* Increment n_rcu_torture_boosts once per boost-test */
+ while (!kthread_should_stop()) {
+ if (mutex_trylock(_mutex)) {
+ n_rcu_torture_boosts++;
+ mutex_unlock(_mutex);
+ break;
+ }
+ schedule_timeout_uninterruptible(1);
+ }
+ if (kthread_should_stop())
+ goto checkwait;
+
/* Wait for the next test interval. */
oldstarttime = boost_starttime;
while (ULONG_CMP_LT(jiffies, oldstarttime)) {
@@ -807,11 +834,10 @@ static int rcu_torture_boost(void *arg)
/* RCU core before ->inflight = 1. */
smp_store_release(, 1);
call_rcu(, rcu_torture_boost_cb);
- if (jiffies - call_rcu_time >
-test_boost_duration * HZ - HZ / 2) {
-
VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
- n_rcu_torture_boost_failure++;
- }
+ /* Check if the boost test failed */
+ failed = failed ||
+rcu_torture_boost_failed(call_rcu_time,
+jiffies);
call_rcu_time = jiffies;
}
stutter_wait("rcu_torture_boost");
@@ -819,6 +845,14 @@ static int rcu_torture_boost(void *arg)
goto checkwait;
}
+ /*
+* If boost never happened, then inflight will always be 1, in
+* this case the boost check would never happen in the above
+* loop so do another one here.
+*/
+ if (!failed && smp_load_acquire())
+ rcu_torture_boost_failed(call_rcu_time,
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
On Mon, Jun 04, 2018 at 10:41:10AM +0800, 禹舟键 wrote: > Hi Tetsuo > > Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is > > strange that origin_memcg_name is updated only when memcg != NULL. Have you > > really tested !memcg OOM case? > > if memcg == NULL , origin_memcg_name will also be NULL, so the length > of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM > case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. > > Thanks > Wind > 禹舟键 于2018年6月4日周一 上午9:58写道： > > > > Hi Mike > > > Please keep the brief description of the function actually brief and move > > > the detailed explanation after the parameters description. > > Thanks for your advice. > > > > > The allocation constraint is detected by the dump_header() callers, why > > > not just use it here? > > David suggest that constraint need to be printed in the oom report, so > > I add the enum variable in this function. My question was why do you call to alloc_constrained in the dump_header() function rather than pass the constraint that was detected a bit earlier to that function? Sorry if wasn't clear enough. > > Thanks > > Wind > -- Sincerely yours, Mike.
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
On Mon, Jun 04, 2018 at 10:41:10AM +0800, 禹舟键 wrote: > Hi Tetsuo > > Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is > > strange that origin_memcg_name is updated only when memcg != NULL. Have you > > really tested !memcg OOM case? > > if memcg == NULL , origin_memcg_name will also be NULL, so the length > of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM > case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. > > Thanks > Wind > 禹舟键 于2018年6月4日周一 上午9:58写道： > > > > Hi Mike > > > Please keep the brief description of the function actually brief and move > > > the detailed explanation after the parameters description. > > Thanks for your advice. > > > > > The allocation constraint is detected by the dump_header() callers, why > > > not just use it here? > > David suggest that constraint need to be printed in the oom report, so > > I add the enum variable in this function. My question was why do you call to alloc_constrained in the dump_header() function rather than pass the constraint that was detected a bit earlier to that function? Sorry if wasn't clear enough. > > Thanks > > Wind > -- Sincerely yours, Mike.
[GIT PULL] rslib updates for v4.18-rc1
Hi Linus, Please pull these rslib changes for v4.18-rc1. Thomas asked me to carry this series since I've been coordinating VLA removal, and he's got enough trees to worry about. :) This has been in -next for a while now. Thanks! -Kees The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: Linux 4.17-rc2 (2018-04-22 19:20:09 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/rslib-v4.18-rc1 for you to fetch changes up to 45888b40d2a6221d46bb69959e2600ddba71cc1f: rslib: Allocate decoder buffers to avoid VLAs (2018-04-24 19:50:10 -0700) Refactors rslib and callers to provide a per-instance allocation area instead of performing VLAs on the stack. Thomas Gleixner (10): rslib: Add GFP aware init function dm/verity_fec: Use GFP aware reed solomon init rslib: Cleanup whitespace damage rslib: Cleanup top level comments rslib: Add SPDX identifiers rslib: Remove GPL boilerplate rslib: Simplify error path rslib: Split rs control struct mtd: rawnand: diskonchip: Allocate rs control per instance rslib: Allocate decoder buffers to avoid VLAs drivers/md/dm-verity-fec.c| 2 +- drivers/mtd/nand/raw/cafe_nand.c | 7 +- drivers/mtd/nand/raw/diskonchip.c | 67 +-- include/linux/rslib.h | 74 +++- lib/reed_solomon/decode_rs.c | 34 +++--- lib/reed_solomon/encode_rs.c | 15 +-- lib/reed_solomon/reed_solomon.c | 240 ++ 7 files changed, 243 insertions(+), 196 deletions(-) -- Kees Cook Pixel Security
[GIT PULL] rslib updates for v4.18-rc1
Hi Linus, Please pull these rslib changes for v4.18-rc1. Thomas asked me to carry this series since I've been coordinating VLA removal, and he's got enough trees to worry about. :) This has been in -next for a while now. Thanks! -Kees The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e: Linux 4.17-rc2 (2018-04-22 19:20:09 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git tags/rslib-v4.18-rc1 for you to fetch changes up to 45888b40d2a6221d46bb69959e2600ddba71cc1f: rslib: Allocate decoder buffers to avoid VLAs (2018-04-24 19:50:10 -0700) Refactors rslib and callers to provide a per-instance allocation area instead of performing VLAs on the stack. Thomas Gleixner (10): rslib: Add GFP aware init function dm/verity_fec: Use GFP aware reed solomon init rslib: Cleanup whitespace damage rslib: Cleanup top level comments rslib: Add SPDX identifiers rslib: Remove GPL boilerplate rslib: Simplify error path rslib: Split rs control struct mtd: rawnand: diskonchip: Allocate rs control per instance rslib: Allocate decoder buffers to avoid VLAs drivers/md/dm-verity-fec.c| 2 +- drivers/mtd/nand/raw/cafe_nand.c | 7 +- drivers/mtd/nand/raw/diskonchip.c | 67 +-- include/linux/rslib.h | 74 +++- lib/reed_solomon/decode_rs.c | 34 +++--- lib/reed_solomon/encode_rs.c | 15 +-- lib/reed_solomon/reed_solomon.c | 240 ++ 7 files changed, 243 insertions(+), 196 deletions(-) -- Kees Cook Pixel Security
Re: [PATCH v2] mm: Change return type int to vm_fault_t for fault handlers
On Sun, Jun 3, 2018 at 3:31 AM, Matthew Wilcox wrote: > On Sun, Jun 03, 2018 at 01:34:07AM +0530, Souptick Joarder wrote: >> @@ -3570,9 +3571,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct >> vm_area_struct *vma, >> return 0; >> } >> >> - ret = (PTR_ERR(new_page) == -ENOMEM) ? >> - VM_FAULT_OOM : VM_FAULT_SIGBUS; >> - goto out_release_old; >> + ret = vmf_error(PTR_ERR(new_page)); >> + goto out_release_old; >> } >> >> /* > > Something weird happened to the goto here Didn't get it ? Do you refer to wrong indent in goto ?
Re: [PATCH v2] mm: Change return type int to vm_fault_t for fault handlers
On Sun, Jun 3, 2018 at 3:31 AM, Matthew Wilcox wrote: > On Sun, Jun 03, 2018 at 01:34:07AM +0530, Souptick Joarder wrote: >> @@ -3570,9 +3571,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct >> vm_area_struct *vma, >> return 0; >> } >> >> - ret = (PTR_ERR(new_page) == -ENOMEM) ? >> - VM_FAULT_OOM : VM_FAULT_SIGBUS; >> - goto out_release_old; >> + ret = vmf_error(PTR_ERR(new_page)); >> + goto out_release_old; >> } >> >> /* > > Something weird happened to the goto here Didn't get it ? Do you refer to wrong indent in goto ?
Re: [PATCH 2/2] tsens: Get rid of unused fields in structure
On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> status_field and trdy are unused in any of the tsens drivers. Remove them.
>
> Signed-off-by: Amit Kucheria
Acked-by: Rajendra Nayak
> ---
> drivers/thermal/qcom/tsens.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
> index f15660d..77ed8dc 100644
> --- a/drivers/thermal/qcom/tsens.h
> +++ b/drivers/thermal/qcom/tsens.h
> @@ -77,9 +77,7 @@ struct tsens_device {
> struct device *dev;
> u32 num_sensors;
> struct regmap *map;
> - struct regmap_field *status_field;
> struct tsens_contextctx;
> - booltrdy;
> const struct tsens_ops *ops;
> struct tsens_sensor sensor[0];
> };
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH 2/2] tsens: Get rid of unused fields in structure
On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> status_field and trdy are unused in any of the tsens drivers. Remove them.
>
> Signed-off-by: Amit Kucheria
Acked-by: Rajendra Nayak
> ---
> drivers/thermal/qcom/tsens.h | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
> index f15660d..77ed8dc 100644
> --- a/drivers/thermal/qcom/tsens.h
> +++ b/drivers/thermal/qcom/tsens.h
> @@ -77,9 +77,7 @@ struct tsens_device {
> struct device *dev;
> u32 num_sensors;
> struct regmap *map;
> - struct regmap_field *status_field;
> struct tsens_contextctx;
> - booltrdy;
> const struct tsens_ops *ops;
> struct tsens_sensor sensor[0];
> };
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
Re: [PATCH 1/2] thermal: tsens: Add support for SDM845 platform
On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> There are two tsens blocks on the SDM845. These will be configured through
> the devicetree.
>
> Signed-off-by: Amit Kucheria
> ---
> .../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
> drivers/thermal/qcom/Makefile | 2 +-
> drivers/thermal/qcom/tsens-sdm845.c| 98
> ++
> drivers/thermal/qcom/tsens.c | 3 +
> drivers/thermal/qcom/tsens.h | 1 +
> 5 files changed, 104 insertions(+), 1 deletion(-)
> create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89..8652499 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
> - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,sdm845-tsens" : For SDM845 Family of SoCs
>
> - reg: Address range of the thermal registers
> - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 2cc2193..dc9f169 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> -qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o
> +qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o tsens-sdm845.o
> diff --git a/drivers/thermal/qcom/tsens-sdm845.c
> b/drivers/thermal/qcom/tsens-sdm845.c
> new file mode 100644
> index 000..5d78f0b
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-sdm845.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include "tsens.h"
> +
> +#define CNTL_OFFSET 4
> +/* CNTL_OFFSET bitmasks */
> +#define EN BIT(0)
> +#define SW_RST BIT(1)
> +
> +#define SENSOR0_SHIFT3
> +
> +#define TRDY_OFFSET 0xe4
> +#define TRDY_READY_BIT BIT(1)
> +
> +#define STATUS_OFFSET0xa0
> +#define LAST_TEMP_MASK 0xfff
> +#define STATUS_VALID_BIT BIT(21)
> +#define CODE_SIGN_BITBIT(11)
> +
> +static int get_temp_sdm845(struct tsens_device *tmdev, int id, int *temp)
> +{
> + struct tsens_sensor *s = >sensor[id];
> + u32 code;
> + unsigned int sensor_addr;
> + int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> +
> + ret = regmap_read(tmdev->map, TRDY_OFFSET, );
> + if (ret)
> + return ret;
> + if (code & TRDY_READY_BIT)
> + return -ENODATA;
> +
> + sensor_addr = STATUS_OFFSET + s->hw_id * 4;
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + last_temp = code & LAST_TEMP_MASK;
> + if (code & STATUS_VALID_BIT)
> + goto done;
> +
> + /* Try a second time */
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp2 = code & LAST_TEMP_MASK;
> + }
> +
> + /* Try a third/last time */
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp3 = code & LAST_TEMP_MASK;
> + }
> +
> + if (last_temp == last_temp2)
> + last_temp = last_temp2;
> + else if (last_temp2 == last_temp3)
> + last_temp = last_temp3;
> +done:
> + /* Code sign bit is the sign extension for a negative value */
> + if (last_temp & CODE_SIGN_BIT)
> + last_temp |= ~CODE_SIGN_BIT;
> +
> + /* Temperatures are in deciCelicius */
> + *temp = last_temp * 100;
This looks the same as what we do for 8996. Does it make sense to move this
to tsens-common and reuse in both 8996 and 845?
> +
> + return 0;
> +}
> +
> +static const struct regmap_config tsens_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +
> +static const struct tsens_ops ops_sdm845 = {
> + .init = init_common,
> + .get_temp = get_temp_sdm845,
> +};
> +
> +const struct tsens_data data_sdm845 = {
> + .ops= _sdm845,
> +};
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3f9fe6a..314a20f 100644
> ---
Re: [PATCH 1/2] thermal: tsens: Add support for SDM845 platform
On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> There are two tsens blocks on the SDM845. These will be configured through
> the devicetree.
>
> Signed-off-by: Amit Kucheria
> ---
> .../devicetree/bindings/thermal/qcom-tsens.txt | 1 +
> drivers/thermal/qcom/Makefile | 2 +-
> drivers/thermal/qcom/tsens-sdm845.c| 98
> ++
> drivers/thermal/qcom/tsens.c | 3 +
> drivers/thermal/qcom/tsens.h | 1 +
> 5 files changed, 104 insertions(+), 1 deletion(-)
> create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89..8652499 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
> - "qcom,msm8916-tsens" : For 8916 Family of SoCs
> - "qcom,msm8974-tsens" : For 8974 Family of SoCs
> - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,sdm845-tsens" : For SDM845 Family of SoCs
>
> - reg: Address range of the thermal registers
> - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 2cc2193..dc9f169 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,2 +1,2 @@
> obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> -qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o
> +qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o
> tsens-8974.o tsens-8960.o tsens-8996.o tsens-sdm845.o
> diff --git a/drivers/thermal/qcom/tsens-sdm845.c
> b/drivers/thermal/qcom/tsens-sdm845.c
> new file mode 100644
> index 000..5d78f0b
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-sdm845.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include "tsens.h"
> +
> +#define CNTL_OFFSET 4
> +/* CNTL_OFFSET bitmasks */
> +#define EN BIT(0)
> +#define SW_RST BIT(1)
> +
> +#define SENSOR0_SHIFT3
> +
> +#define TRDY_OFFSET 0xe4
> +#define TRDY_READY_BIT BIT(1)
> +
> +#define STATUS_OFFSET0xa0
> +#define LAST_TEMP_MASK 0xfff
> +#define STATUS_VALID_BIT BIT(21)
> +#define CODE_SIGN_BITBIT(11)
> +
> +static int get_temp_sdm845(struct tsens_device *tmdev, int id, int *temp)
> +{
> + struct tsens_sensor *s = >sensor[id];
> + u32 code;
> + unsigned int sensor_addr;
> + int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> +
> + ret = regmap_read(tmdev->map, TRDY_OFFSET, );
> + if (ret)
> + return ret;
> + if (code & TRDY_READY_BIT)
> + return -ENODATA;
> +
> + sensor_addr = STATUS_OFFSET + s->hw_id * 4;
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + last_temp = code & LAST_TEMP_MASK;
> + if (code & STATUS_VALID_BIT)
> + goto done;
> +
> + /* Try a second time */
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp2 = code & LAST_TEMP_MASK;
> + }
> +
> + /* Try a third/last time */
> + ret = regmap_read(tmdev->map, sensor_addr, );
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp3 = code & LAST_TEMP_MASK;
> + }
> +
> + if (last_temp == last_temp2)
> + last_temp = last_temp2;
> + else if (last_temp2 == last_temp3)
> + last_temp = last_temp3;
> +done:
> + /* Code sign bit is the sign extension for a negative value */
> + if (last_temp & CODE_SIGN_BIT)
> + last_temp |= ~CODE_SIGN_BIT;
> +
> + /* Temperatures are in deciCelicius */
> + *temp = last_temp * 100;
This looks the same as what we do for 8996. Does it make sense to move this
to tsens-common and reuse in both 8996 and 845?
> +
> + return 0;
> +}
> +
> +static const struct regmap_config tsens_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +
> +static const struct tsens_ops ops_sdm845 = {
> + .init = init_common,
> + .get_temp = get_temp_sdm845,
> +};
> +
> +const struct tsens_data data_sdm845 = {
> + .ops= _sdm845,
> +};
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3f9fe6a..314a20f 100644
> ---
[GIT PULL] userns vfs bits for v4.18-rc1
Linus, Please pull the userns-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git userns-linus HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems Apologies for the resend I forgot the diffstat and the subject line. This is the last couple of vfs bits to enable root in a user namespace to mount and manipulate a filesystem with backing store (AKA not a virtual filesystem like proc, but a filesystem where the unprivileged user controls the content). The target filesystem for this work is fuse, and Miklos should be sending you the pull request for the fuse bits this merge window. The two key patches are " evm: Don't update hmacs in user ns mounts" and "vfs: Don't allow changing the link count of an inode with an invalid uid or gid". Those close small gaps in the vfs that would be a problem if an unprivileged fuse filesystem is mounted. The rest of the changes are things that are now safe to allow a root user in a user namespace to do with a filesystem they have mounted. The most interesting development is that remount is now safe. Eric W. Biederman (5): vfs: Don't allow changing the link count of an inode with an invalid uid or gid vfs: Allow userns root to call mknod on owned filesystems. fs: Allow superblock owner to replace invalid owners of inodes fs: Allow superblock owner to access do_remount_sb() capabilities: Allow privileged user in s_user_ns to set security.* xattrs Seth Forshee (2): evm: Don't update hmacs in user ns mounts fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems fs/attr.c | 36 fs/ioctl.c | 4 ++-- fs/namei.c | 16 fs/namespace.c | 4 ++-- security/commoncap.c| 8 ++-- security/integrity/evm/evm_crypto.c | 3 ++- 6 files changed, 52 insertions(+), 19 deletions(-) Eric
[GIT PULL] userns vfs bits for v4.18-rc1
Linus, Please pull the userns-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git userns-linus HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems Apologies for the resend I forgot the diffstat and the subject line. This is the last couple of vfs bits to enable root in a user namespace to mount and manipulate a filesystem with backing store (AKA not a virtual filesystem like proc, but a filesystem where the unprivileged user controls the content). The target filesystem for this work is fuse, and Miklos should be sending you the pull request for the fuse bits this merge window. The two key patches are " evm: Don't update hmacs in user ns mounts" and "vfs: Don't allow changing the link count of an inode with an invalid uid or gid". Those close small gaps in the vfs that would be a problem if an unprivileged fuse filesystem is mounted. The rest of the changes are things that are now safe to allow a root user in a user namespace to do with a filesystem they have mounted. The most interesting development is that remount is now safe. Eric W. Biederman (5): vfs: Don't allow changing the link count of an inode with an invalid uid or gid vfs: Allow userns root to call mknod on owned filesystems. fs: Allow superblock owner to replace invalid owners of inodes fs: Allow superblock owner to access do_remount_sb() capabilities: Allow privileged user in s_user_ns to set security.* xattrs Seth Forshee (2): evm: Don't update hmacs in user ns mounts fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems fs/attr.c | 36 fs/ioctl.c | 4 ++-- fs/namei.c | 16 fs/namespace.c | 4 ++-- security/commoncap.c| 8 ++-- security/integrity/evm/evm_crypto.c | 3 ++- 6 files changed, 52 insertions(+), 19 deletions(-) Eric
[GIT PULL] siginfo work for v4.18-rc1
Linus,
Please pull the siginfo-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
siginfo-linus
HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning
about an impossible case in do_divide_error
Apologies for the resend I spaced and forgot the diffstat earlier.
This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo. There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state. Most of that work involves refactoring the signal
handling code and thus careful code review.
Also not included is the work to shrink the in kernel version of struct
siginfo. That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.
Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.
Dmitry V. Levin (1):
sparc: fix compat siginfo ABI regression
Eric W. Biederman (44):
signal/alpha: Document a conflict with SI_USER for SIGFPE
signal/sh: Use force_sig_fault in hw_breakpoint_handler
signal/nds32: Use force_sig in unhandled_interruption and
unhandled_exceptions
signal/nds32: Use force_sig(SIGILL) in do_revisn
signal: Ensure every siginfo we send has all bits initialized
signal: Reduce copy_siginfo_to_user to just copy_to_user
signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
signal: Remove SEGV_BNDERR ifdefs
signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
signal/alpha: Replace TRAP_FIXME with TRAP_UNK
signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
signal/alpha: Use send_sig_fault where appropriate
signal/alpha: Use force_sig_fault where appropriate
signal/c6x: Use force_sig_fault where appropriate
signal/hexagon: Use force_sig_fault as appropriate
signal/m68k: Use force_sig_fault where appropriate
signal/microblaze: Remove the commented out force_sig_info in
do_page_fault
signal/microblaze: Use force_sig_fault where appropriate
signal/mips: Use force_sig_fault where appropriate
signal/nds32: Use force_sig_fault where appropriate
signal/nios2: Use force_sig_fault where appropriate
signal/openrisc: Use force_sig_fault where appropriate
signal/parisc: Use force_sig_mceerr where appropriate
signal/parisc: Use force_sig_fault where appropriate
signal/riscv: Use force_sig_fault where appropriate
signal/riscv: Replace do_trap_siginfo with force_sig_fault
signal/s390: Use force_sig_fault where appropriate
signal/sh: Use force_sig_fault where appropriate
signal/sparc: Use send_sig_fault where appropriate
signal/sparc: Use force_sig_fault where appropriate
signal/um: Use force_sig_fault where appropriate
signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
signal/xtensa: Use force_sig_fault where appropriate
signal/signalfd: Remove __put_user from signalfd_copyinfo
signal/signalfd: Add support for SIGSYS
signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
signal/um: More carefully relay signals in relay_signal.
signal/sh: Stop gcc warning about an impossible case in do_divide_error
Guenter Roeck (1):
signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions
arch/alpha/include/uapi/asm/siginfo.h | 14 ---
arch/alpha/kernel/osf_sys.c | 11 +-
arch/alpha/kernel/signal.c| 20 +---
arch/alpha/kernel/traps.c | 79 -
arch/alpha/mm/fault.c | 13 +--
arch/arc/mm/fault.c | 2 +
arch/arm/kernel/ptrace.c | 1 +
arch/arm/kernel/swp_emulate.c | 1 +
arch/arm/kernel/traps.c | 5 +
arch/arm/mm/alignment.c | 1 +
arch/arm/mm/fault.c | 4 +
arch/arm/vfp/vfpmodule.c | 3 +-
arch/arm64/kernel/fpsimd.c| 2 +-
arch/arm64/kernel/sys_compat.c| 1 +
arch/arm64/kernel/traps.c | 1 +
arch/arm64/mm/fault.c | 18 ++-
arch/c6x/kernel/traps.c | 9 +-
arch/hexagon/kernel/traps.c
Re: [PATCH] nfc: st21nfca: use setup_timer instead of init_timer
Hi Colin, On Fri, Nov 24, 2017 at 01:37:41PM +, Colin King wrote: > From: Colin Ian King > > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Colin Ian King > --- > drivers/nfc/st21nfca/se.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) Applied to nfc-next, thanks. Cheers, Samuel.
[GIT PULL] siginfo work for v4.18-rc1
Linus,
Please pull the siginfo-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
siginfo-linus
HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning
about an impossible case in do_divide_error
Apologies for the resend I spaced and forgot the diffstat earlier.
This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo. There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state. Most of that work involves refactoring the signal
handling code and thus careful code review.
Also not included is the work to shrink the in kernel version of struct
siginfo. That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.
Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.
Dmitry V. Levin (1):
sparc: fix compat siginfo ABI regression
Eric W. Biederman (44):
signal/alpha: Document a conflict with SI_USER for SIGFPE
signal/sh: Use force_sig_fault in hw_breakpoint_handler
signal/nds32: Use force_sig in unhandled_interruption and
unhandled_exceptions
signal/nds32: Use force_sig(SIGILL) in do_revisn
signal: Ensure every siginfo we send has all bits initialized
signal: Reduce copy_siginfo_to_user to just copy_to_user
signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
signal: Remove SEGV_BNDERR ifdefs
signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
signal/alpha: Replace TRAP_FIXME with TRAP_UNK
signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
signal/alpha: Use send_sig_fault where appropriate
signal/alpha: Use force_sig_fault where appropriate
signal/c6x: Use force_sig_fault where appropriate
signal/hexagon: Use force_sig_fault as appropriate
signal/m68k: Use force_sig_fault where appropriate
signal/microblaze: Remove the commented out force_sig_info in
do_page_fault
signal/microblaze: Use force_sig_fault where appropriate
signal/mips: Use force_sig_fault where appropriate
signal/nds32: Use force_sig_fault where appropriate
signal/nios2: Use force_sig_fault where appropriate
signal/openrisc: Use force_sig_fault where appropriate
signal/parisc: Use force_sig_mceerr where appropriate
signal/parisc: Use force_sig_fault where appropriate
signal/riscv: Use force_sig_fault where appropriate
signal/riscv: Replace do_trap_siginfo with force_sig_fault
signal/s390: Use force_sig_fault where appropriate
signal/sh: Use force_sig_fault where appropriate
signal/sparc: Use send_sig_fault where appropriate
signal/sparc: Use force_sig_fault where appropriate
signal/um: Use force_sig_fault where appropriate
signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
signal/xtensa: Use force_sig_fault where appropriate
signal/signalfd: Remove __put_user from signalfd_copyinfo
signal/signalfd: Add support for SIGSYS
signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
signal/um: More carefully relay signals in relay_signal.
signal/sh: Stop gcc warning about an impossible case in do_divide_error
Guenter Roeck (1):
signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions
arch/alpha/include/uapi/asm/siginfo.h | 14 ---
arch/alpha/kernel/osf_sys.c | 11 +-
arch/alpha/kernel/signal.c| 20 +---
arch/alpha/kernel/traps.c | 79 -
arch/alpha/mm/fault.c | 13 +--
arch/arc/mm/fault.c | 2 +
arch/arm/kernel/ptrace.c | 1 +
arch/arm/kernel/swp_emulate.c | 1 +
arch/arm/kernel/traps.c | 5 +
arch/arm/mm/alignment.c | 1 +
arch/arm/mm/fault.c | 4 +
arch/arm/vfp/vfpmodule.c | 3 +-
arch/arm64/kernel/fpsimd.c| 2 +-
arch/arm64/kernel/sys_compat.c| 1 +
arch/arm64/kernel/traps.c | 1 +
arch/arm64/mm/fault.c | 18 ++-
arch/c6x/kernel/traps.c | 9 +-
arch/hexagon/kernel/traps.c
Re: [PATCH] nfc: st21nfca: use setup_timer instead of init_timer
Hi Colin, On Fri, Nov 24, 2017 at 01:37:41PM +, Colin King wrote: > From: Colin Ian King > > Use setup_timer function instead of initializing timer with the > function and data fields. > > Signed-off-by: Colin Ian King > --- > drivers/nfc/st21nfca/se.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) Applied to nfc-next, thanks. Cheers, Samuel.
[GIT PULL] siginfo work for v4.18-rc1
Linus,
Please pull the siginfo-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
siginfo-linus
HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning
about an impossible case in do_divide_error
This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo. There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state. Most of that work involves refactoring the signal
handling code and thus careful code review.
Also not included is the work to shrink the in kernel version of struct
siginfo. That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.
Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.
Dmitry V. Levin (1):
sparc: fix compat siginfo ABI regression
Eric W. Biederman (44):
signal/alpha: Document a conflict with SI_USER for SIGFPE
signal/sh: Use force_sig_fault in hw_breakpoint_handler
signal/nds32: Use force_sig in unhandled_interruption and
unhandled_exceptions
signal/nds32: Use force_sig(SIGILL) in do_revisn
signal: Ensure every siginfo we send has all bits initialized
signal: Reduce copy_siginfo_to_user to just copy_to_user
signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
signal: Remove SEGV_BNDERR ifdefs
signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
signal/alpha: Replace TRAP_FIXME with TRAP_UNK
signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
signal/alpha: Use send_sig_fault where appropriate
signal/alpha: Use force_sig_fault where appropriate
signal/c6x: Use force_sig_fault where appropriate
signal/hexagon: Use force_sig_fault as appropriate
signal/m68k: Use force_sig_fault where appropriate
signal/microblaze: Remove the commented out force_sig_info in
do_page_fault
signal/microblaze: Use force_sig_fault where appropriate
signal/mips: Use force_sig_fault where appropriate
signal/nds32: Use force_sig_fault where appropriate
signal/nios2: Use force_sig_fault where appropriate
signal/openrisc: Use force_sig_fault where appropriate
signal/parisc: Use force_sig_mceerr where appropriate
signal/parisc: Use force_sig_fault where appropriate
signal/riscv: Use force_sig_fault where appropriate
signal/riscv: Replace do_trap_siginfo with force_sig_fault
signal/s390: Use force_sig_fault where appropriate
signal/sh: Use force_sig_fault where appropriate
signal/sparc: Use send_sig_fault where appropriate
signal/sparc: Use force_sig_fault where appropriate
signal/um: Use force_sig_fault where appropriate
signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
signal/xtensa: Use force_sig_fault where appropriate
signal/signalfd: Remove __put_user from signalfd_copyinfo
signal/signalfd: Add support for SIGSYS
signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
signal/um: More carefully relay signals in relay_signal.
signal/sh: Stop gcc warning about an impossible case in do_divide_error
Guenter Roeck (1):
signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions
Eric
[GIT PULL] siginfo work for v4.18-rc1
Linus,
Please pull the siginfo-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
siginfo-linus
HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning
about an impossible case in do_divide_error
This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo. There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state. Most of that work involves refactoring the signal
handling code and thus careful code review.
Also not included is the work to shrink the in kernel version of struct
siginfo. That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.
Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.
Dmitry V. Levin (1):
sparc: fix compat siginfo ABI regression
Eric W. Biederman (44):
signal/alpha: Document a conflict with SI_USER for SIGFPE
signal/sh: Use force_sig_fault in hw_breakpoint_handler
signal/nds32: Use force_sig in unhandled_interruption and
unhandled_exceptions
signal/nds32: Use force_sig(SIGILL) in do_revisn
signal: Ensure every siginfo we send has all bits initialized
signal: Reduce copy_siginfo_to_user to just copy_to_user
signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
signal: Remove SEGV_BNDERR ifdefs
signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
signal/alpha: Replace TRAP_FIXME with TRAP_UNK
signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
signal/alpha: Use send_sig_fault where appropriate
signal/alpha: Use force_sig_fault where appropriate
signal/c6x: Use force_sig_fault where appropriate
signal/hexagon: Use force_sig_fault as appropriate
signal/m68k: Use force_sig_fault where appropriate
signal/microblaze: Remove the commented out force_sig_info in
do_page_fault
signal/microblaze: Use force_sig_fault where appropriate
signal/mips: Use force_sig_fault where appropriate
signal/nds32: Use force_sig_fault where appropriate
signal/nios2: Use force_sig_fault where appropriate
signal/openrisc: Use force_sig_fault where appropriate
signal/parisc: Use force_sig_mceerr where appropriate
signal/parisc: Use force_sig_fault where appropriate
signal/riscv: Use force_sig_fault where appropriate
signal/riscv: Replace do_trap_siginfo with force_sig_fault
signal/s390: Use force_sig_fault where appropriate
signal/sh: Use force_sig_fault where appropriate
signal/sparc: Use send_sig_fault where appropriate
signal/sparc: Use force_sig_fault where appropriate
signal/um: Use force_sig_fault where appropriate
signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
signal/xtensa: Use force_sig_fault where appropriate
signal/signalfd: Remove __put_user from signalfd_copyinfo
signal/signalfd: Add support for SIGSYS
signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
signal/um: More carefully relay signals in relay_signal.
signal/sh: Stop gcc warning about an impossible case in do_divide_error
Guenter Roeck (1):
signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions
Eric
[GIT PULL] userns
Linus, Please pull the userns-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git userns-linus HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems This is the last couple of vfs bits to enable root in a user namespace to mount and manipulate a filesystem with backing store (AKA not a virtual filesystem like proc, but a filesystem where the unprivileged user controls the content). The target filesystem for this work is fuse, and Miklos should be sending you the pull request for the fuse bits this merge window. The two key patches are " evm: Don't update hmacs in user ns mounts" and "vfs: Don't allow changing the link count of an inode with an invalid uid or gid". Those close small gaps in the vfs that would be a problem if an unprivileged fuse filesystem is mounted. The rest of the changes are things that are now safe to allow a root user in a user namespace to do with a filesystem they have mounted. The most interesting development is that remount is now safe. Eric W. Biederman (5): vfs: Don't allow changing the link count of an inode with an invalid uid or gid vfs: Allow userns root to call mknod on owned filesystems. fs: Allow superblock owner to replace invalid owners of inodes fs: Allow superblock owner to access do_remount_sb() capabilities: Allow privileged user in s_user_ns to set security.* xattrs Seth Forshee (2): evm: Don't update hmacs in user ns mounts fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems Eric
[GIT PULL] userns
Linus, Please pull the userns-linus branch from the git tree: git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git userns-linus HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems This is the last couple of vfs bits to enable root in a user namespace to mount and manipulate a filesystem with backing store (AKA not a virtual filesystem like proc, but a filesystem where the unprivileged user controls the content). The target filesystem for this work is fuse, and Miklos should be sending you the pull request for the fuse bits this merge window. The two key patches are " evm: Don't update hmacs in user ns mounts" and "vfs: Don't allow changing the link count of an inode with an invalid uid or gid". Those close small gaps in the vfs that would be a problem if an unprivileged fuse filesystem is mounted. The rest of the changes are things that are now safe to allow a root user in a user namespace to do with a filesystem they have mounted. The most interesting development is that remount is now safe. Eric W. Biederman (5): vfs: Don't allow changing the link count of an inode with an invalid uid or gid vfs: Allow userns root to call mknod on owned filesystems. fs: Allow superblock owner to replace invalid owners of inodes fs: Allow superblock owner to access do_remount_sb() capabilities: Allow privileged user in s_user_ns to set security.* xattrs Seth Forshee (2): evm: Don't update hmacs in user ns mounts fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems Eric
[GIT PULL] chrome-platform updates for v4.18
Hi Linus, The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git tags/chrome-platform-for-linus-4.18 for you to fetch changes up to 79a3d60300fc28def9b58dc30d86274b47052422: platform/chrome: Use to_cros_ec_dev more broadly (2018-05-30 11:53:40 -0700) Changes to chrome-platform for v4.18 Further changes from Dmitry related to the removal of platform data from atmel_mxt_ts and chromeos_laptop. This time, we have some changes that teach chromeos_laptop how to supply acpi properties for some input devices so that the peripheral driver doesn't have to do dmi matching on some Chromebook platforms. Also adds the Chromebook Tablet switch driver, which is useful for x86 convertible Chromebooks. Other misc. cleanup. Thanks, Benson Arnd Bergmann (1): platform: chrome: Add input dependency for tablet switch driver Benson Leung (2): platform/chrome: chromeos_tbmc - add SPDX identifier Merge branch 'ib-chrome-platform-atmel-mxt-ts-device-properties' into working-branch-for-4.18 Dmitry Torokhov (3): platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found platform/chrome: chromeos_laptop - supply properties for ACPI devices platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes Gwendal Grignou (2): platform: chrome: Add Tablet Switch ACPI driver platform/chrome: Use to_cros_ec_dev more broadly drivers/platform/chrome/Kconfig| 11 + drivers/platform/chrome/Makefile | 1 + drivers/platform/chrome/chromeos_laptop.c | 315 ++--- drivers/platform/chrome/chromeos_tbmc.c| 111 ++ drivers/platform/chrome/cros_ec_lightbar.c | 21 +- drivers/platform/chrome/cros_ec_lpc.c | 13 +- drivers/platform/chrome/cros_ec_sysfs.c| 2 - drivers/platform/chrome/cros_ec_vbc.c | 9 +- include/linux/mfd/cros_ec.h| 2 + 9 files changed, 428 insertions(+), 57 deletions(-) create mode 100644 drivers/platform/chrome/chromeos_tbmc.c -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER
Hi Stephen,
Thanks for the reply.
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: 02 June 2018 12:11 PM
> To: Rajan Vaja
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> ; Michal Simek ;
> mturque...@baylibre.com
> Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> CLK_OF_DECLARE_DRIVER
>
> Quoting Rajan Vaja (2018-05-03 02:18:30)
> > Hi Stephen,
> >
> > > -Original Message-
> > > From: Rajan Vaja
> > > Sent: 16 March 2018 05:20 PM
> > > To: 'Stephen Boyd'
> > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > ; Michal Simek ;
> > > mturque...@baylibre.com
> > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > CLK_OF_DECLARE_DRIVER
> > >
> > > Hi Stephen,
> > >
> > > Thanks for the comment.
> > >
> > > > -Original Message-
> > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > Sent: 16 March 2018 12:17 AM
> > > > To: Rajan Vaja
> > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > > ; Michal Simek ;
> > > > mturque...@baylibre.com
> > > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > > CLK_OF_DECLARE_DRIVER
> > > >
> > > > Quoting Rajan Vaja (2018-03-09 11:27:40)
> > > > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > > >
> > > > > > Is the intent to register the clk twice? I believe things are
> > > > > > working as
> > > > > > intended without this patch, so maybe you can explain a little more
> what
> > > > > > you're trying to fix.
> > > > > [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> > > > > parent which is neither mentioned in output-clock-names of clock
> > > > > controller nor registered as clock provider, of_clk_init() will try to
> > > > > forcefully register in second loop.
> > > > >
> > > > > if (force || parent_ready(clk_provider->np)) {
> > > > >
> > > > > /* Don't populate platform devices */
> > > > > of_node_set_flag(clk_provider->np,
> > > > > OF_POPULATED);
> > > > >
> > > > > So registration of this DT fixed-factor clock would fail as parent
> > > > > would be NULL as below (called from _of_fixed_factor_clk_setup()):
> > > > > parent_name = of_clk_get_parent_name(node, 0);
> > > > >
> > > > > On the other hand, even if registration failed, that node will be
> > > > > marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> > > > > be called and that DT fixed-factor clock would never be registered.
> > > > >
> > > > > Same thing is discussed at https://lkml.org/lkml/2017/6/5/681 .
> > > >
> > > > Ok. I believe the answer is to fix the DT to describe the parent chain
> > > > properly with clock-output-names. Otherwise, we have no good way of
> > > > figuring out what the name should be.
> > > [Rajan] clock DT binding doc says that clock-output-names property
> > > is optional and sometimes not recommended.
> > > I think this patch fixes the issue we have which mandates to add clock-
> output-
> > > names
> > > property (for this particular case). Also, IIUC platform driver probe in
> > > clk-
> fixed-
> > > factor.c
> > > will never be called unless we use CLK_OF_DECLARE_DRIVER.
> > > I completely agree that proper solution would be to stop using strings to
> > > describe clock topology.
> > [Rajan] Any comments on this?
> > Unless we have proper solution ready, we need to have some mechanism to
> handle this scenario.
> > clock-output-names is optional and without this, it mandates to use clock-
> output-names.
> >
>
> I couldn't read your outlook sent email and I was too busy to go
> translate it. Some bug in my MUA it seems.
>
> Can you add the output-names property? In this case it's practically
> mandatory, so if you can't do it I'd like to hear why not.
[Rajan] In our case, we are firmware maintains clock database and driver query
clocks
from firmware and registers clock based on information received from firmware.
So
output clock names are not fixed.
https://patchwork.kernel.org/patch/10439893/ - dt-bindings: clock: Add bindings
for ZynqMP clock driver
https://patchwork.kernel.org/patch/10439891/ - drivers: clk: Add ZynqMP clock
driver
[GIT PULL] chrome-platform updates for v4.18
Hi Linus, The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git tags/chrome-platform-for-linus-4.18 for you to fetch changes up to 79a3d60300fc28def9b58dc30d86274b47052422: platform/chrome: Use to_cros_ec_dev more broadly (2018-05-30 11:53:40 -0700) Changes to chrome-platform for v4.18 Further changes from Dmitry related to the removal of platform data from atmel_mxt_ts and chromeos_laptop. This time, we have some changes that teach chromeos_laptop how to supply acpi properties for some input devices so that the peripheral driver doesn't have to do dmi matching on some Chromebook platforms. Also adds the Chromebook Tablet switch driver, which is useful for x86 convertible Chromebooks. Other misc. cleanup. Thanks, Benson Arnd Bergmann (1): platform: chrome: Add input dependency for tablet switch driver Benson Leung (2): platform/chrome: chromeos_tbmc - add SPDX identifier Merge branch 'ib-chrome-platform-atmel-mxt-ts-device-properties' into working-branch-for-4.18 Dmitry Torokhov (3): platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found platform/chrome: chromeos_laptop - supply properties for ACPI devices platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes Gwendal Grignou (2): platform: chrome: Add Tablet Switch ACPI driver platform/chrome: Use to_cros_ec_dev more broadly drivers/platform/chrome/Kconfig| 11 + drivers/platform/chrome/Makefile | 1 + drivers/platform/chrome/chromeos_laptop.c | 315 ++--- drivers/platform/chrome/chromeos_tbmc.c| 111 ++ drivers/platform/chrome/cros_ec_lightbar.c | 21 +- drivers/platform/chrome/cros_ec_lpc.c | 13 +- drivers/platform/chrome/cros_ec_sysfs.c| 2 - drivers/platform/chrome/cros_ec_vbc.c | 9 +- include/linux/mfd/cros_ec.h| 2 + 9 files changed, 428 insertions(+), 57 deletions(-) create mode 100644 drivers/platform/chrome/chromeos_tbmc.c -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER
Hi Stephen,
Thanks for the reply.
> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: 02 June 2018 12:11 PM
> To: Rajan Vaja
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> ; Michal Simek ;
> mturque...@baylibre.com
> Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> CLK_OF_DECLARE_DRIVER
>
> Quoting Rajan Vaja (2018-05-03 02:18:30)
> > Hi Stephen,
> >
> > > -Original Message-
> > > From: Rajan Vaja
> > > Sent: 16 March 2018 05:20 PM
> > > To: 'Stephen Boyd'
> > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > ; Michal Simek ;
> > > mturque...@baylibre.com
> > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > CLK_OF_DECLARE_DRIVER
> > >
> > > Hi Stephen,
> > >
> > > Thanks for the comment.
> > >
> > > > -Original Message-
> > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > Sent: 16 March 2018 12:17 AM
> > > > To: Rajan Vaja
> > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > > ; Michal Simek ;
> > > > mturque...@baylibre.com
> > > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > > CLK_OF_DECLARE_DRIVER
> > > >
> > > > Quoting Rajan Vaja (2018-03-09 11:27:40)
> > > > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > > >
> > > > > > Is the intent to register the clk twice? I believe things are
> > > > > > working as
> > > > > > intended without this patch, so maybe you can explain a little more
> what
> > > > > > you're trying to fix.
> > > > > [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> > > > > parent which is neither mentioned in output-clock-names of clock
> > > > > controller nor registered as clock provider, of_clk_init() will try to
> > > > > forcefully register in second loop.
> > > > >
> > > > > if (force || parent_ready(clk_provider->np)) {
> > > > >
> > > > > /* Don't populate platform devices */
> > > > > of_node_set_flag(clk_provider->np,
> > > > > OF_POPULATED);
> > > > >
> > > > > So registration of this DT fixed-factor clock would fail as parent
> > > > > would be NULL as below (called from _of_fixed_factor_clk_setup()):
> > > > > parent_name = of_clk_get_parent_name(node, 0);
> > > > >
> > > > > On the other hand, even if registration failed, that node will be
> > > > > marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> > > > > be called and that DT fixed-factor clock would never be registered.
> > > > >
> > > > > Same thing is discussed at https://lkml.org/lkml/2017/6/5/681 .
> > > >
> > > > Ok. I believe the answer is to fix the DT to describe the parent chain
> > > > properly with clock-output-names. Otherwise, we have no good way of
> > > > figuring out what the name should be.
> > > [Rajan] clock DT binding doc says that clock-output-names property
> > > is optional and sometimes not recommended.
> > > I think this patch fixes the issue we have which mandates to add clock-
> output-
> > > names
> > > property (for this particular case). Also, IIUC platform driver probe in
> > > clk-
> fixed-
> > > factor.c
> > > will never be called unless we use CLK_OF_DECLARE_DRIVER.
> > > I completely agree that proper solution would be to stop using strings to
> > > describe clock topology.
> > [Rajan] Any comments on this?
> > Unless we have proper solution ready, we need to have some mechanism to
> handle this scenario.
> > clock-output-names is optional and without this, it mandates to use clock-
> output-names.
> >
>
> I couldn't read your outlook sent email and I was too busy to go
> translate it. Some bug in my MUA it seems.
>
> Can you add the output-names property? In this case it's practically
> mandatory, so if you can't do it I'd like to hear why not.
[Rajan] In our case, we are firmware maintains clock database and driver query
clocks
from firmware and registers clock based on information received from firmware.
So
output clock names are not fixed.
https://patchwork.kernel.org/patch/10439893/ - dt-bindings: clock: Add bindings
for ZynqMP clock driver
https://patchwork.kernel.org/patch/10439891/ - drivers: clk: Add ZynqMP clock
driver
For help, whether to check the return value of sata_scr_read should be added in sata_print_link_status
Hello
I have trouble reading the code, I hope you can help guide
The function sata_print_link_status in the file drivers/ata/libata-core.c
checks the return value when the function sata_scr_read is called on line 3009,
but does not check the return value when calling sata_scr_read on line 3011.
Why are two calls handled differently?
Is there any other code logic that guarantees that the 3011 line will not
return an exception?
drivers/ata/libata-core.c :
3005 static void sata_print_link_status(struct ata_link *link)
3006 {
3007 u32 sstatus, scontrol, tmp;
3008
3009 if (sata_scr_read(link, SCR_STATUS, ))
3010 return;
3011 sata_scr_read(link, SCR_CONTROL, );
3012
3013 if (ata_phys_link_online(link)) {
Thanks
For help, whether to check the return value of sata_scr_read should be added in sata_print_link_status
Hello
I have trouble reading the code, I hope you can help guide
The function sata_print_link_status in the file drivers/ata/libata-core.c
checks the return value when the function sata_scr_read is called on line 3009,
but does not check the return value when calling sata_scr_read on line 3011.
Why are two calls handled differently?
Is there any other code logic that guarantees that the 3011 line will not
return an exception?
drivers/ata/libata-core.c :
3005 static void sata_print_link_status(struct ata_link *link)
3006 {
3007 u32 sstatus, scontrol, tmp;
3008
3009 if (sata_scr_read(link, SCR_STATUS, ))
3010 return;
3011 sata_scr_read(link, SCR_CONTROL, );
3012
3013 if (ata_phys_link_online(link)) {
Thanks
linux-next: build failure after merge of the drm-msm tree
Hi Rob,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_busy':
a5xx_gpu.c:(.text+0xcc): undefined reference to `__aeabi_uldivmod'
Caused by commit
dd4ff3063899 ("drm/msm: re-factor devfreq code")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpykALsubR93.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the drm-msm tree
Hi Rob,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_busy':
a5xx_gpu.c:(.text+0xcc): undefined reference to `__aeabi_uldivmod'
Caused by commit
dd4ff3063899 ("drm/msm: re-factor devfreq code")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpykALsubR93.pgp
Description: OpenPGP digital signature
[PATCH v3] kbuild: check for pkg-config on make {menu,n,g.x}config
From: Randy Dunlap
Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present and to determine build flags
settings, but none of these check that pkg-config itself is present.
Add a check for all 4 of these targets and update
Documentation/process/changes.rst to mention 'pkg-config'.
Fixes kernel bugzilla #77511:
https://bugzilla.kernel.org/show_bug.cgi?id=77511
Signed-off-by: Randy Dunlap
Cc: Bjørn Forsman
---
Strictly speaking, pkg-config is not required if someone is only
using 'make {menu,n}config' since there are fallbacks for those
two targets.
Documentation/process/changes.rst |8
scripts/kconfig/Makefile |6 ++
scripts/kconfig/check-pkgconfig.sh | 12
3 files changed, 26 insertions(+)
--- linux-next-20180601.orig/scripts/kconfig/Makefile
+++ linux-next-20180601/scripts/kconfig/Makefile
@@ -214,11 +214,17 @@ $(obj)/gconf.o: $(obj)/.gconf-cfg
$(obj)/zconf.tab.o: $(obj)/zconf.lex.c
# check if necessary packages are available, and configure build flags
+# pkg-config check
+define check_pkg_config
+ $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh FORCE
+endef
+
define filechk_conf_cfg
$(CONFIG_SHELL) $<
endef
$(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
+ $(call check_pkg_config)
$(call filechk,conf_cfg)
clean-files += .*conf-cfg
--- /dev/null
+++ linux-next-20180601/scripts/kconfig/check-pkgconfig.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# Check for pkg-config presence
+
+pkgcfg=`command -v pkg-config`
+
+if [ "$pkgcfg" = "" ]; then
+ echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
+ exit 1 # error
+fi
+
+exit 0
--- linux-next-20180601.orig/Documentation/process/changes.rst
+++ linux-next-20180601/Documentation/process/changes.rst
@@ -81,6 +81,14 @@ The build system has, as of 4.13, switch
rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
This requires binutils 2.20 or newer.
+pkg-config
+--
+
+The build system, as of 4.18, requires pkg-config to check for installed
+kconfig tools and to determine flags settings for use in
+'make {menu,n,g,x}config'. Previously pkg-config was being used but not
+verified or documented.
+
Flex
[PATCH v3] kbuild: check for pkg-config on make {menu,n,g.x}config
From: Randy Dunlap
Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present and to determine build flags
settings, but none of these check that pkg-config itself is present.
Add a check for all 4 of these targets and update
Documentation/process/changes.rst to mention 'pkg-config'.
Fixes kernel bugzilla #77511:
https://bugzilla.kernel.org/show_bug.cgi?id=77511
Signed-off-by: Randy Dunlap
Cc: Bjørn Forsman
---
Strictly speaking, pkg-config is not required if someone is only
using 'make {menu,n}config' since there are fallbacks for those
two targets.
Documentation/process/changes.rst |8
scripts/kconfig/Makefile |6 ++
scripts/kconfig/check-pkgconfig.sh | 12
3 files changed, 26 insertions(+)
--- linux-next-20180601.orig/scripts/kconfig/Makefile
+++ linux-next-20180601/scripts/kconfig/Makefile
@@ -214,11 +214,17 @@ $(obj)/gconf.o: $(obj)/.gconf-cfg
$(obj)/zconf.tab.o: $(obj)/zconf.lex.c
# check if necessary packages are available, and configure build flags
+# pkg-config check
+define check_pkg_config
+ $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh FORCE
+endef
+
define filechk_conf_cfg
$(CONFIG_SHELL) $<
endef
$(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
+ $(call check_pkg_config)
$(call filechk,conf_cfg)
clean-files += .*conf-cfg
--- /dev/null
+++ linux-next-20180601/scripts/kconfig/check-pkgconfig.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# Check for pkg-config presence
+
+pkgcfg=`command -v pkg-config`
+
+if [ "$pkgcfg" = "" ]; then
+ echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
+ exit 1 # error
+fi
+
+exit 0
--- linux-next-20180601.orig/Documentation/process/changes.rst
+++ linux-next-20180601/Documentation/process/changes.rst
@@ -81,6 +81,14 @@ The build system has, as of 4.13, switch
rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
This requires binutils 2.20 or newer.
+pkg-config
+--
+
+The build system, as of 4.18, requires pkg-config to check for installed
+kconfig tools and to determine flags settings for use in
+'make {menu,n,g,x}config'. Previously pkg-config was being used but not
+verified or documented.
+
Flex
[PATCH] rtc:ds1307:it assume 20xx not 19xx.
If we settime between 1970 and 2000. for example: $ date 052915571978 $ hwclock -w it will be wrong, this patch fix it. Signed-off-by: Linkui --- drivers/rtc/rtc-ds1307.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index a13e59edff53..8c218a16569d 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -425,7 +425,9 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t) t->tm_mday = bcd2bin(regs[DS1307_REG_MDAY] & 0x3f); tmp = regs[DS1307_REG_MONTH] & 0x1f; t->tm_mon = bcd2bin(tmp) - 1; - t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]) + 100; + t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]); + if (t->tm_year >= 0 && t->tm_year <= 69) + t->tm_year += 100; if (regs[chip->century_reg] & chip->century_bit && IS_ENABLED(CONFIG_RTC_DRV_DS1307_CENTURY)) @@ -454,7 +456,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t) t->tm_hour, t->tm_mday, t->tm_mon, t->tm_year, t->tm_wday); - if (t->tm_year < 100) + if (t->tm_year < 0) return -EINVAL; #ifdef CONFIG_RTC_DRV_DS1307_CENTURY @@ -472,8 +474,9 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t) regs[DS1307_REG_MDAY] = bin2bcd(t->tm_mday); regs[DS1307_REG_MONTH] = bin2bcd(t->tm_mon + 1); - /* assume 20YY not 19YY */ - tmp = t->tm_year - 100; + tmp = t->tm_year; + if (tmp >= 100 && tmp <= 169) + tmp -= 100; regs[DS1307_REG_YEAR] = bin2bcd(tmp); if (chip->century_enable_bit) -- 2.17.0
[PATCH] rtc:ds1307:it assume 20xx not 19xx.
If we settime between 1970 and 2000. for example: $ date 052915571978 $ hwclock -w it will be wrong, this patch fix it. Signed-off-by: Linkui --- drivers/rtc/rtc-ds1307.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c index a13e59edff53..8c218a16569d 100644 --- a/drivers/rtc/rtc-ds1307.c +++ b/drivers/rtc/rtc-ds1307.c @@ -425,7 +425,9 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t) t->tm_mday = bcd2bin(regs[DS1307_REG_MDAY] & 0x3f); tmp = regs[DS1307_REG_MONTH] & 0x1f; t->tm_mon = bcd2bin(tmp) - 1; - t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]) + 100; + t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]); + if (t->tm_year >= 0 && t->tm_year <= 69) + t->tm_year += 100; if (regs[chip->century_reg] & chip->century_bit && IS_ENABLED(CONFIG_RTC_DRV_DS1307_CENTURY)) @@ -454,7 +456,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t) t->tm_hour, t->tm_mday, t->tm_mon, t->tm_year, t->tm_wday); - if (t->tm_year < 100) + if (t->tm_year < 0) return -EINVAL; #ifdef CONFIG_RTC_DRV_DS1307_CENTURY @@ -472,8 +474,9 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t) regs[DS1307_REG_MDAY] = bin2bcd(t->tm_mday); regs[DS1307_REG_MONTH] = bin2bcd(t->tm_mon + 1); - /* assume 20YY not 19YY */ - tmp = t->tm_year - 100; + tmp = t->tm_year; + if (tmp >= 100 && tmp <= 169) + tmp -= 100; regs[DS1307_REG_YEAR] = bin2bcd(tmp); if (chip->century_enable_bit) -- 2.17.0
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
Hi Tetsuo > Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is > strange that origin_memcg_name is updated only when memcg != NULL. Have you > really tested !memcg OOM case? if memcg == NULL , origin_memcg_name will also be NULL, so the length of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. Thanks Wind 禹舟键 于2018年6月4日周一 上午9:58写道： > > Hi Mike > > Please keep the brief description of the function actually brief and move > > the detailed explanation after the parameters description. > Thanks for your advice. > > > The allocation constraint is detected by the dump_header() callers, why not > > just use it here? > David suggest that constraint need to be printed in the oom report, so > I add the enum variable in this function. > > Thanks > Wind
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
Hi Tetsuo > Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is > strange that origin_memcg_name is updated only when memcg != NULL. Have you > really tested !memcg OOM case? if memcg == NULL , origin_memcg_name will also be NULL, so the length of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong. Thanks Wind 禹舟键 于2018年6月4日周一 上午9:58写道： > > Hi Mike > > Please keep the brief description of the function actually brief and move > > the detailed explanation after the parameters description. > Thanks for your advice. > > > The allocation constraint is detected by the dump_header() callers, why not > > just use it here? > David suggest that constraint need to be printed in the oom report, so > I add the enum variable in this function. > > Thanks > Wind
[PATCH v2] x86/mce: add CMCI support for Centaur CPUs
New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI.
Signed-off-by: David Wang
Changes from v1 to v2:
*1, add vendor check for Centaur CPU in cmci_supported.
*2, Only call intel_init_cmci for Centaur CPU in mce_intel_feature_init
function.
---
arch/x86/Kconfig | 12
arch/x86/kernel/cpu/mcheck/mce.c | 6 ++
arch/x86/kernel/cpu/mcheck/mce_intel.c | 21 -
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
Additional support for AMD specific MCE features such as
the DRAM Error Threshold.
+config X86_MCE_CENTAUR
+ def_bool y
+ prompt "CENTAUR MCE features"
+ depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+ help
+ Additional support for Centaur specific MCE features such as
+ MCE broadcasting and CMCI support.
+ New Centaur CPU support MCE broadcasting.
+ New Centaur CPU support CMCI which is fully compliant with Intel
CMCI.
+
+ If unsure, say N here.
+
config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
}
+#ifdef CONFIG_X86_MCE_CENTAUR
static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
{
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+ mce_intel_feature_init(c);
+ mce_adjust_timer = cmci_intel_adjust_timer;
}
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
{
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index d05be30..5b1b68f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
* initialization is vendor keyed and this
* makes sure none of the backdoors are entered otherwise.
*/
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
@@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
- intel_init_thermal(c);
- intel_init_cmci();
- intel_init_lmce();
- intel_ppin_init(c);
+
+ switch (c->x86_vendor) {
+ case X86_VENDOR_INTEL:
+ intel_init_thermal(c);
+ intel_init_cmci();
+ intel_init_lmce();
+ intel_ppin_init(c);
+ break;
+ case X86_VENDOR_CENTAUR:
+ intel_init_cmci();
+ break;
+ default:
+ break;
+ }
}
void mce_intel_feature_clear(struct cpuinfo_x86 *c)
--
1.9.1
[PATCH v2] x86/mce: add CMCI support for Centaur CPUs
New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI.
Signed-off-by: David Wang
Changes from v1 to v2:
*1, add vendor check for Centaur CPU in cmci_supported.
*2, Only call intel_init_cmci for Centaur CPU in mce_intel_feature_init
function.
---
arch/x86/Kconfig | 12
arch/x86/kernel/cpu/mcheck/mce.c | 6 ++
arch/x86/kernel/cpu/mcheck/mce_intel.c | 21 -
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
Additional support for AMD specific MCE features such as
the DRAM Error Threshold.
+config X86_MCE_CENTAUR
+ def_bool y
+ prompt "CENTAUR MCE features"
+ depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+ help
+ Additional support for Centaur specific MCE features such as
+ MCE broadcasting and CMCI support.
+ New Centaur CPU support MCE broadcasting.
+ New Centaur CPU support CMCI which is fully compliant with Intel
CMCI.
+
+ If unsure, say N here.
+
config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
}
+#ifdef CONFIG_X86_MCE_CENTAUR
static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
{
struct mca_config *cfg = _cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+ mce_intel_feature_init(c);
+ mce_adjust_timer = cmci_intel_adjust_timer;
}
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
{
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index d05be30..5b1b68f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
* initialization is vendor keyed and this
* makes sure none of the backdoors are entered otherwise.
*/
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
@@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
- intel_init_thermal(c);
- intel_init_cmci();
- intel_init_lmce();
- intel_ppin_init(c);
+
+ switch (c->x86_vendor) {
+ case X86_VENDOR_INTEL:
+ intel_init_thermal(c);
+ intel_init_cmci();
+ intel_init_lmce();
+ intel_ppin_init(c);
+ break;
+ case X86_VENDOR_CENTAUR:
+ intel_init_cmci();
+ break;
+ default:
+ break;
+ }
}
void mce_intel_feature_clear(struct cpuinfo_x86 *c)
--
1.9.1
Re: About GPL license compliance of Tesla Model S, Linux kernel 4.4
FYI, https://sfconservancy.org/blog/2018/may/18/tesla-incomplete-ccs/ On Sun, Nov 26, 2017 at 8:23 PM, Geunsik Lim wrote: > Here is my next activity. > > After reading http://gpl-violations.org/helping/, > I have reported this issue to solve a potential GPL misuse about the > Linux kernel open source code > that is used to deploy Tesla Model S (Linux kernel based commercial product). > > > > > BRs, > Geunsik Lim. > > > On Sat, Nov 25, 2017 at 4:48 PM, Geunsik Lim wrote: >> Hi All, >> >> I want to talk about a potential GPL misuse of the Linux open source >> that is used by Tesla Model S. Some months ago, I have read that a >> version information of Linux kernel that is deployed into the >> commercial self-driving car such as Tesla Model S via (1) the twitter >> web page of Tesla CEO Elon Musk and (2) the presentation material of >> the Blackhat 2017 presenter Sen Nie as follows. >> >> Oct-05-2016, Twitter, "When we upgrade the core Linux OS to 4.4, which >> is probably December" >> https://twitter.com/elonmusk/status/783759011724210176 >> >> Jul-22-2017, Blackhat 2017, "FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN >> BUS" >> https://www.blackhat.com/us-17/briefings.html#free-fall-hacking-tesla-from-wireless-to-can-bus >> >> >> In case of the embedded device vendors, it seems that the most of the >> global vendors have being uploaded related open source software that >> are used by commercial products via their open source release center >> to keep the GPL compliance as following: >> >> https://opensource.google.com/ >> https://opensource.microsoft.com/ >> https://opensource.apple.com >> https://opensource.samsung.com >> https://opensource.lge.com >> https://opensource.dell.com/ >> http://opensource.alibaba.com/ >> https://developer.sonymobile.com/knowledge-base/open-source/ >> http://consumer.huawei.com/en/opensource/ >> http://xiaomi.github.io/ >> https://software.intel.com/en-us/open-source >> >> >> Also, we can download related open sources such as Linux kernel, GCC, >> and so on from their official homepage in case of BMW, GM, Ford, and >> Toyota cars. >> >> BMW - http://www.bmw-carit.de/open-source/ >> GM - http://oss.bosch-cm.com/gm.html >> Ford - http://corporate.ford.com/ford-open-source.html >> Toyota - http://www.globaldenso.com/en/opensource/ivi/toyota/ >> >> >> BTW, in case of Tesla, where can we find an official open source >> release center to download their Linux kernel source that is deployed >> into a commercial self-driving car? I could not find an official web >> page of Tesla to download Linux Kernel 4.4 (GPLv2) and other open >> sources that are used by Tesla company. And, I can not find the >> related Linux kernel source code from https://github.com/teslamotors. >> Unfortunately, even though I asked a person in charging on this issue, >> they do not reply me any e-mail for 2 weeks. Anyone that already tried >> to get their Linux kernel source of Tesla Model S? >> >> As we all know, Linus Torvalds has released his Linux Kernel under >> GPLv2 license via https://www.kernel.org/. >> For more details, please visit the below web-pages. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.4 >> http://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic >> >> I wonder if they correctly keep the GPL compliance because I am not a lawyer. >> >> >> Thanks for reading. >> >> >> >> BRs, >> Geunsik Lim. >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > > > > -- > > Best regards, > Geunsik Lim, Samsung Electronics > http://leemgs.fedorapeople.org > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Best regards, Geunsik Lim, Samsung Electronics http://leemgs.fedorapeople.org To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: About GPL license compliance of Tesla Model S, Linux kernel 4.4
FYI, https://sfconservancy.org/blog/2018/may/18/tesla-incomplete-ccs/ On Sun, Nov 26, 2017 at 8:23 PM, Geunsik Lim wrote: > Here is my next activity. > > After reading http://gpl-violations.org/helping/, > I have reported this issue to solve a potential GPL misuse about the > Linux kernel open source code > that is used to deploy Tesla Model S (Linux kernel based commercial product). > > > > > BRs, > Geunsik Lim. > > > On Sat, Nov 25, 2017 at 4:48 PM, Geunsik Lim wrote: >> Hi All, >> >> I want to talk about a potential GPL misuse of the Linux open source >> that is used by Tesla Model S. Some months ago, I have read that a >> version information of Linux kernel that is deployed into the >> commercial self-driving car such as Tesla Model S via (1) the twitter >> web page of Tesla CEO Elon Musk and (2) the presentation material of >> the Blackhat 2017 presenter Sen Nie as follows. >> >> Oct-05-2016, Twitter, "When we upgrade the core Linux OS to 4.4, which >> is probably December" >> https://twitter.com/elonmusk/status/783759011724210176 >> >> Jul-22-2017, Blackhat 2017, "FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN >> BUS" >> https://www.blackhat.com/us-17/briefings.html#free-fall-hacking-tesla-from-wireless-to-can-bus >> >> >> In case of the embedded device vendors, it seems that the most of the >> global vendors have being uploaded related open source software that >> are used by commercial products via their open source release center >> to keep the GPL compliance as following: >> >> https://opensource.google.com/ >> https://opensource.microsoft.com/ >> https://opensource.apple.com >> https://opensource.samsung.com >> https://opensource.lge.com >> https://opensource.dell.com/ >> http://opensource.alibaba.com/ >> https://developer.sonymobile.com/knowledge-base/open-source/ >> http://consumer.huawei.com/en/opensource/ >> http://xiaomi.github.io/ >> https://software.intel.com/en-us/open-source >> >> >> Also, we can download related open sources such as Linux kernel, GCC, >> and so on from their official homepage in case of BMW, GM, Ford, and >> Toyota cars. >> >> BMW - http://www.bmw-carit.de/open-source/ >> GM - http://oss.bosch-cm.com/gm.html >> Ford - http://corporate.ford.com/ford-open-source.html >> Toyota - http://www.globaldenso.com/en/opensource/ivi/toyota/ >> >> >> BTW, in case of Tesla, where can we find an official open source >> release center to download their Linux kernel source that is deployed >> into a commercial self-driving car? I could not find an official web >> page of Tesla to download Linux Kernel 4.4 (GPLv2) and other open >> sources that are used by Tesla company. And, I can not find the >> related Linux kernel source code from https://github.com/teslamotors. >> Unfortunately, even though I asked a person in charging on this issue, >> they do not reply me any e-mail for 2 weeks. Anyone that already tried >> to get their Linux kernel source of Tesla Model S? >> >> As we all know, Linus Torvalds has released his Linux Kernel under >> GPLv2 license via https://www.kernel.org/. >> For more details, please visit the below web-pages. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.4 >> http://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic >> >> I wonder if they correctly keep the GPL compliance because I am not a lawyer. >> >> >> Thanks for reading. >> >> >> >> BRs, >> Geunsik Lim. >> >> >> >> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > > > > -- > > Best regards, > Geunsik Lim, Samsung Electronics > http://leemgs.fedorapeople.org > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Best regards, Geunsik Lim, Samsung Electronics http://leemgs.fedorapeople.org To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts/faddr2line: show the code context
On Tue, May 29, 2018 at 06:03:32PM +0200, Peter Zijlstra wrote:
> On Mon, Mar 19, 2018 at 03:23:25PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Inspired by gdb command 'list', show the code context of target lines.
> > Here is a example:
> >
> > $ scripts/faddr2line vmlinux native_write_msr+0x6
> > native_write_msr+0x6/0x20:
> > arch_static_branch at arch/x86/include/asm/msr.h:105
> > 100 return EAX_EDX_VAL(val, low, high);
> > 101 }
> > 102
> > 103 static inline void notrace __wrmsr(unsigned int msr, u32 low, u32
> > high)
> > 104 {
> > 105 asm volatile("1: wrmsr\n"
> > 106 "2:\n"
> > 107 _ASM_EXTABLE_HANDLE(1b, 2b,
> > ex_handler_wrmsr_unsafe)
> > 108 : : "c" (msr), "a"(low), "d" (high) :
> > "memory");
> > 109 }
> > 110
> > (inlined by) static_key_false at include/linux/jump_label.h:142
> > 137 #define JUMP_TYPE_LINKED2UL
> > 138 #define JUMP_TYPE_MASK 3UL
> > 139
> > 140 static __always_inline bool static_key_false(struct static_key *key)
> > 141 {
> > 142 return arch_static_branch(key, false);
> > 143 }
> > 144
> > 145 static __always_inline bool static_key_true(struct static_key *key)
> > 146 {
> > 147 return !arch_static_branch(key, true);
> > (inlined by) native_write_msr at arch/x86/include/asm/msr.h:150
> > 145 static inline void notrace
> > 146 native_write_msr(unsigned int msr, u32 low, u32 high)
> > 147 {
> > 148 __wrmsr(msr, low, high);
> > 149
> > 150 if (msr_tracepoint_active(__tracepoint_write_msr))
> > 151 do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
> > 152 }
> > 153
> > 154 /* Can be uninlined because referenced by paravirt */
> > 155 static inline int notrace
>
> Not a fan of this :-/ And you didn't even make it optional. Nor did you
> Cc the original author of the tool.
Yeah, understand your compatibility concern, and thanks for your improvment.
I only added people from 'scripts/get_maintainer.pl'.
--
Thanks,
Changbin Du
Re: [PATCH] scripts/faddr2line: show the code context
On Tue, May 29, 2018 at 06:03:32PM +0200, Peter Zijlstra wrote:
> On Mon, Mar 19, 2018 at 03:23:25PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > Inspired by gdb command 'list', show the code context of target lines.
> > Here is a example:
> >
> > $ scripts/faddr2line vmlinux native_write_msr+0x6
> > native_write_msr+0x6/0x20:
> > arch_static_branch at arch/x86/include/asm/msr.h:105
> > 100 return EAX_EDX_VAL(val, low, high);
> > 101 }
> > 102
> > 103 static inline void notrace __wrmsr(unsigned int msr, u32 low, u32
> > high)
> > 104 {
> > 105 asm volatile("1: wrmsr\n"
> > 106 "2:\n"
> > 107 _ASM_EXTABLE_HANDLE(1b, 2b,
> > ex_handler_wrmsr_unsafe)
> > 108 : : "c" (msr), "a"(low), "d" (high) :
> > "memory");
> > 109 }
> > 110
> > (inlined by) static_key_false at include/linux/jump_label.h:142
> > 137 #define JUMP_TYPE_LINKED2UL
> > 138 #define JUMP_TYPE_MASK 3UL
> > 139
> > 140 static __always_inline bool static_key_false(struct static_key *key)
> > 141 {
> > 142 return arch_static_branch(key, false);
> > 143 }
> > 144
> > 145 static __always_inline bool static_key_true(struct static_key *key)
> > 146 {
> > 147 return !arch_static_branch(key, true);
> > (inlined by) native_write_msr at arch/x86/include/asm/msr.h:150
> > 145 static inline void notrace
> > 146 native_write_msr(unsigned int msr, u32 low, u32 high)
> > 147 {
> > 148 __wrmsr(msr, low, high);
> > 149
> > 150 if (msr_tracepoint_active(__tracepoint_write_msr))
> > 151 do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
> > 152 }
> > 153
> > 154 /* Can be uninlined because referenced by paravirt */
> > 155 static inline int notrace
>
> Not a fan of this :-/ And you didn't even make it optional. Nor did you
> Cc the original author of the tool.
Yeah, understand your compatibility concern, and thanks for your improvment.
I only added people from 'scripts/get_maintainer.pl'.
--
Thanks,
Changbin Du
Re: [PATCH] scripts/faddr2line: show the code context
On Wed, May 30, 2018 at 08:01:48AM +1000, NeilBrown wrote:
> On Tue, May 29 2018, Peter Zijlstra wrote:
>
> > On Tue, May 29, 2018 at 12:07:10PM -0500, Josh Poimboeuf wrote:
> >> Yeah, this change really should have been an optional arg. It hurt the
> >> readability and compactness of the output. The above looks good to me.
> >>
> >> Care to send a proper patch? If you send it to Linus he might apply it
> >> directly as he did with my original patches.
> >
> > ---
> > From: Peter Zijlstra (Intel)
> >
> > Commit 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > radically altered the output format of the faddr2line tool. And while
> > the new list output format might have merrit it broke my vim usage and
> > was hard to read.
> >
> > Make the new format optional; using a '--list' argument and attempt to
> > make the output slightly easier to read by adding a little whitespace to
> > separate the different files and explicitly mark the line in question.
>
> Not commenting on your code but on the original patch.
> I've recently noticed that ADDR2LINE sometimes outputs
> (discriminator 2)
> or similar at the end of the line. This messes up the parsing.
>
> I hacked it to work so I could keep debugging with
>
> - local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s;
> $dir_prefix\(\./\)*; ;")
> + local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed -e
> "s; $dir_prefix\(\./\)*; ;" -e "s/(discriminator [0-9]*)//")
>
> but someone should probably find out exactly what sort of messages
> ADDR2LINE produces, and make sure they are all parsed correctly.
> (maybe that someone should be me, but not today).
>
Hi, I have fixed it by commit 78eb0c6356 ("scripts/faddr2line: fix error when
addr2line output contains discriminator") and it is already in the mainline now.
Thank you!
> Thanks,
> NeilBrown
>
>
> >
> > Cc: Changbin Du
> > Acked-by: Josh Poimboeuf
> > Fixes: 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > Signed-off-by: Peter Zijlstra (Intel)
> > ---
> > scripts/faddr2line | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/faddr2line b/scripts/faddr2line
> > index 1876a741087c..a0149db00be7 100755
> > --- a/scripts/faddr2line
> > +++ b/scripts/faddr2line
> > @@ -56,7 +56,7 @@ command -v ${SIZE} >/dev/null 2>&1 || die "size isn't
> > installed"
> > command -v ${NM} >/dev/null 2>&1 || die "nm isn't installed"
> >
> > usage() {
> > - echo "usage: faddr2line ..."
> > >&2
> > + echo "usage: faddr2line [--list]
> > ..." >&2
> > exit 1
> > }
> >
> > @@ -166,15 +166,25 @@ __faddr2line() {
> > local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s;
> > $dir_prefix\(\./\)*; ;")
> > [[ -z $file_lines ]] && return
> >
> > + if [[ $LIST = 0 ]]; then
> > + echo "$file_lines" | while read -r line
> > + do
> > + echo $line
> > + done
> > + DONE=1;
> > + return
> > + fi
> > +
> > # show each line with context
> > echo "$file_lines" | while read -r line
> > do
> > + echo
> > echo $line
> > n=$(echo $line | sed 's/.*:\([0-9]\+\).*/\1/g')
> > n1=$[$n-5]
> > n2=$[$n+5]
> > f=$(echo $line | sed 's/.*at \(.\+\):.*/\1/g')
> > - awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'")
> > {printf("%d\t%s\n", NR, $0)}' $f
> > + awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'") {
> > if (NR=='$n') printf(">%d<", NR); else printf(" %d ", NR); printf("\t%s\n",
> > $0)}' $f
> > done
> >
> > DONE=1
> > @@ -185,6 +195,10 @@ __faddr2line() {
> > [[ $# -lt 2 ]] && usage
> >
> > objfile=$1
> > +
> > +LIST=0
> > +[[ "$objfile" == "--list" ]] && LIST=1 && shift && objfile=$1
> > +
> > [[ ! -f $objfile ]] && die "can't find objfile $objfile"
> > shift
> >
--
Thanks,
Changbin Du
Re: [PATCH] scripts/faddr2line: show the code context
On Wed, May 30, 2018 at 08:01:48AM +1000, NeilBrown wrote:
> On Tue, May 29 2018, Peter Zijlstra wrote:
>
> > On Tue, May 29, 2018 at 12:07:10PM -0500, Josh Poimboeuf wrote:
> >> Yeah, this change really should have been an optional arg. It hurt the
> >> readability and compactness of the output. The above looks good to me.
> >>
> >> Care to send a proper patch? If you send it to Linus he might apply it
> >> directly as he did with my original patches.
> >
> > ---
> > From: Peter Zijlstra (Intel)
> >
> > Commit 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > radically altered the output format of the faddr2line tool. And while
> > the new list output format might have merrit it broke my vim usage and
> > was hard to read.
> >
> > Make the new format optional; using a '--list' argument and attempt to
> > make the output slightly easier to read by adding a little whitespace to
> > separate the different files and explicitly mark the line in question.
>
> Not commenting on your code but on the original patch.
> I've recently noticed that ADDR2LINE sometimes outputs
> (discriminator 2)
> or similar at the end of the line. This messes up the parsing.
>
> I hacked it to work so I could keep debugging with
>
> - local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s;
> $dir_prefix\(\./\)*; ;")
> + local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed -e
> "s; $dir_prefix\(\./\)*; ;" -e "s/(discriminator [0-9]*)//")
>
> but someone should probably find out exactly what sort of messages
> ADDR2LINE produces, and make sure they are all parsed correctly.
> (maybe that someone should be me, but not today).
>
Hi, I have fixed it by commit 78eb0c6356 ("scripts/faddr2line: fix error when
addr2line output contains discriminator") and it is already in the mainline now.
Thank you!
> Thanks,
> NeilBrown
>
>
> >
> > Cc: Changbin Du
> > Acked-by: Josh Poimboeuf
> > Fixes: 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > Signed-off-by: Peter Zijlstra (Intel)
> > ---
> > scripts/faddr2line | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/faddr2line b/scripts/faddr2line
> > index 1876a741087c..a0149db00be7 100755
> > --- a/scripts/faddr2line
> > +++ b/scripts/faddr2line
> > @@ -56,7 +56,7 @@ command -v ${SIZE} >/dev/null 2>&1 || die "size isn't
> > installed"
> > command -v ${NM} >/dev/null 2>&1 || die "nm isn't installed"
> >
> > usage() {
> > - echo "usage: faddr2line ..."
> > >&2
> > + echo "usage: faddr2line [--list]
> > ..." >&2
> > exit 1
> > }
> >
> > @@ -166,15 +166,25 @@ __faddr2line() {
> > local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s;
> > $dir_prefix\(\./\)*; ;")
> > [[ -z $file_lines ]] && return
> >
> > + if [[ $LIST = 0 ]]; then
> > + echo "$file_lines" | while read -r line
> > + do
> > + echo $line
> > + done
> > + DONE=1;
> > + return
> > + fi
> > +
> > # show each line with context
> > echo "$file_lines" | while read -r line
> > do
> > + echo
> > echo $line
> > n=$(echo $line | sed 's/.*:\([0-9]\+\).*/\1/g')
> > n1=$[$n-5]
> > n2=$[$n+5]
> > f=$(echo $line | sed 's/.*at \(.\+\):.*/\1/g')
> > - awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'")
> > {printf("%d\t%s\n", NR, $0)}' $f
> > + awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'") {
> > if (NR=='$n') printf(">%d<", NR); else printf(" %d ", NR); printf("\t%s\n",
> > $0)}' $f
> > done
> >
> > DONE=1
> > @@ -185,6 +195,10 @@ __faddr2line() {
> > [[ $# -lt 2 ]] && usage
> >
> > objfile=$1
> > +
> > +LIST=0
> > +[[ "$objfile" == "--list" ]] && LIST=1 && shift && objfile=$1
> > +
> > [[ ! -f $objfile ]] && die "can't find objfile $objfile"
> > shift
> >
--
Thanks,
Changbin Du
Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年6月1日 17:38
> Receiver: David Wang
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; gre...@linuxfoudation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
> brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com
> Topic : Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
>
> On Thu, May 31, 2018 at 11:28:58AM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechanism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang
> > ---
> > arch/x86/Kconfig | 12
> > arch/x86/kernel/cpu/mcheck/mce.c | 6 ++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > dda87a3..1adff5f 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1130,6 +1130,18 @@ config X86_MCE_AMD
> >Additional support for AMD specific MCE features such as
> >the DRAM Error Threshold.
> >
> > +config X86_MCE_CENTAUR
> > + def_bool y
> > + prompt "CENTAUR MCE features"
> > + depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
> > + help
> > + Additional support for Centaur specific MCE features such as
> > + MCE broadcasting and CMCI support.
> > + New Centaur CPU support MCE broadcasting.
> > + New Centaur CPU support CMCI which is fully compliant with Intel
> CMCI.
> > +
> > + If unsure, say N here.
> > +
> > config X86_ANCIENT_MCE
> > bool "Support for old Pentium 5 / WinChip machine checks"
> > depends on X86_32 && X86_MCE
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> > }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> > static void mce_centaur_feature_init(struct cpuinfo_x86 *c) {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > + mce_intel_feature_init(c);
> > + mce_adjust_timer = cmci_intel_adjust_timer;
>
> So far so good but above says "New Centaur CPU[s]" but you're calling
> mce_intel_feature_init() unconditionally here, for *all* centaur CPUs.
> Ditto for setting the CMCI handler.
There is a check for CMCI support or not In cmci_supported() function
which will be called by mce_intel_feature_init.
return !!(cap & MCG_CMCI_P);
So, I didn't add Family/Model/Stepping check.
But, I am sorry to add another patch just as following:
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
* initialization is vendor keyed and this
* makes sure none of the backdoors are entered otherwise.
*/
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
I will send patch v4 later to include this patch.
Thank you.
>
> Also mce_intel_feature_init() does more things than init CMCI so I think you
> wanna limit that to only intel_init_cmci(). IOW, something like the hunk
> below.
>
> And frankly I'm not crazy about adding centaur code to mce_intel.c but since
> it
> is copying functionality, I think we should copy the sw support in the kernel
> too
> instead of adding a mce_centaur.c duplicate. For now at least...
>
> Thx.
>
> ---
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index d05be307d081..77d8a9b996a6 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -506,8 +506,15 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
>
> void mce_intel_feature_init(struct cpuinfo_x86 *c) {
> - intel_init_thermal(c);
> intel_init_cmci();
> +
> + /*
> + * Some Centaur variants support CMCI.
> + */
> + if (c->x86_vendor == X86_VENDOR_CENTAUR)
> + return;
> +
> + intel_init_thermal(c);
> intel_init_lmce();
> intel_ppin_init(c);
> }
>
OK. I will send patch V4 to fix this problem, just like:
void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
- intel_init_thermal(c);
- intel_init_cmci();
- intel_init_lmce();
- intel_ppin_init(c);
+
+ switch (c->x86_vendor) {
+ case X86_VENDOR_INTEL:
+ intel_init_thermal(c);
+
Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年6月1日 17:38
> Receiver: David Wang
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; gre...@linuxfoudation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
> brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com
> Topic : Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
>
> On Thu, May 31, 2018 at 11:28:58AM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechanism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang
> > ---
> > arch/x86/Kconfig | 12
> > arch/x86/kernel/cpu/mcheck/mce.c | 6 ++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > dda87a3..1adff5f 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1130,6 +1130,18 @@ config X86_MCE_AMD
> >Additional support for AMD specific MCE features such as
> >the DRAM Error Threshold.
> >
> > +config X86_MCE_CENTAUR
> > + def_bool y
> > + prompt "CENTAUR MCE features"
> > + depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
> > + help
> > + Additional support for Centaur specific MCE features such as
> > + MCE broadcasting and CMCI support.
> > + New Centaur CPU support MCE broadcasting.
> > + New Centaur CPU support CMCI which is fully compliant with Intel
> CMCI.
> > +
> > + If unsure, say N here.
> > +
> > config X86_ANCIENT_MCE
> > bool "Support for old Pentium 5 / WinChip machine checks"
> > depends on X86_32 && X86_MCE
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> > }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> > static void mce_centaur_feature_init(struct cpuinfo_x86 *c) {
> > struct mca_config *cfg = _cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > + mce_intel_feature_init(c);
> > + mce_adjust_timer = cmci_intel_adjust_timer;
>
> So far so good but above says "New Centaur CPU[s]" but you're calling
> mce_intel_feature_init() unconditionally here, for *all* centaur CPUs.
> Ditto for setting the CMCI handler.
There is a check for CMCI support or not In cmci_supported() function
which will be called by mce_intel_feature_init.
return !!(cap & MCG_CMCI_P);
So, I didn't add Family/Model/Stepping check.
But, I am sorry to add another patch just as following:
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
* initialization is vendor keyed and this
* makes sure none of the backdoors are entered otherwise.
*/
- if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+ boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
I will send patch v4 later to include this patch.
Thank you.
>
> Also mce_intel_feature_init() does more things than init CMCI so I think you
> wanna limit that to only intel_init_cmci(). IOW, something like the hunk
> below.
>
> And frankly I'm not crazy about adding centaur code to mce_intel.c but since
> it
> is copying functionality, I think we should copy the sw support in the kernel
> too
> instead of adding a mce_centaur.c duplicate. For now at least...
>
> Thx.
>
> ---
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index d05be307d081..77d8a9b996a6 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -506,8 +506,15 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
>
> void mce_intel_feature_init(struct cpuinfo_x86 *c) {
> - intel_init_thermal(c);
> intel_init_cmci();
> +
> + /*
> + * Some Centaur variants support CMCI.
> + */
> + if (c->x86_vendor == X86_VENDOR_CENTAUR)
> + return;
> +
> + intel_init_thermal(c);
> intel_init_lmce();
> intel_ppin_init(c);
> }
>
OK. I will send patch V4 to fix this problem, just like:
void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
- intel_init_thermal(c);
- intel_init_cmci();
- intel_init_lmce();
- intel_ppin_init(c);
+
+ switch (c->x86_vendor) {
+ case X86_VENDOR_INTEL:
+ intel_init_thermal(c);
+
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
Hi Mike > Please keep the brief description of the function actually brief and move the > detailed explanation after the parameters description. Thanks for your advice. > The allocation constraint is detected by the dump_header() callers, why not > just use it here? David suggest that constraint need to be printed in the oom report, so I add the enum variable in this function. Thanks Wind
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
Hi Mike > Please keep the brief description of the function actually brief and move the > detailed explanation after the parameters description. Thanks for your advice. > The allocation constraint is detected by the dump_header() callers, why not > just use it here? David suggest that constraint need to be printed in the oom report, so I add the enum variable in this function. Thanks Wind
Re: [PATCH V2 4/4] clk: imx6ul: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 4/4] clk: imx6ul: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 3/4] clk: imx6sx: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > IPG clock has no clock gate and its parent AHB clock > is busy divider type, so no need to add CLK_IS_CRITICAL > flag for IPG clock. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 2/4] clk: imx6sl: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > IPG clock has no clock gate and its parent AHB clock > is busy divider type, so no need to add CLK_IS_CRITICAL > flag for IPG clock. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 3/4] clk: imx6sx: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > IPG clock has no clock gate and its parent AHB clock > is busy divider type, so no need to add CLK_IS_CRITICAL > flag for IPG clock. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 2/4] clk: imx6sl: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. > > IPG clock has no clock gate and its parent AHB clock > is busy divider type, so no need to add CLK_IS_CRITICAL > flag for IPG clock. > > Signed-off-by: Anson Huang Reviewed-by: Fabio Estevam
Re: [PATCH V2 1/4] clk: imx6q: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. Reviewed-by: Fabio Estevam
Re: [PATCH V2 1/4] clk: imx6q: remove clks_init_on array
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang wrote: > Clock framework will enable those clocks registered > with CLK_IS_CRITICAL flag, so no need to have > clks_init_on array during clock initialization now. > > ARM clock is busy divider type which has the > CLK_IS_CRITICAL flag set by default when registered. Reviewed-by: Fabio Estevam
Re: [PATCH] pci: qcom: include gpio/consumer.h
On Wed 30 May 14:53 PDT 2018, Arnd Bergmann wrote: > When CONFIG_GPIOLIB is disabled, we run into a build failure: > > drivers/pci/dwc/pcie-qcom.c: In function 'qcom_pcie_probe': > drivers/pci/dwc/pcie-qcom.c:1223:16: error: implicit declaration of function > 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? > [-Werror=implicit-function-declaration] > pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); > > Including gpio/consumer.h directly is the correct fix. > > Signed-off-by: Arnd Bergmann Reviewed-by: Bjorn Andersson Regards, Bjorn > --- > drivers/pci/dwc/pcie-qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c > index b65bbf7c284e..17df19db851e 100644 > --- a/drivers/pci/dwc/pcie-qcom.c > +++ b/drivers/pci/dwc/pcie-qcom.c > @@ -10,7 +10,7 @@ > > #include > #include > -#include > +#include > #include > #include > #include > -- > 2.9.0 >
Re: [PATCH] pci: qcom: include gpio/consumer.h
On Wed 30 May 14:53 PDT 2018, Arnd Bergmann wrote: > When CONFIG_GPIOLIB is disabled, we run into a build failure: > > drivers/pci/dwc/pcie-qcom.c: In function 'qcom_pcie_probe': > drivers/pci/dwc/pcie-qcom.c:1223:16: error: implicit declaration of function > 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? > [-Werror=implicit-function-declaration] > pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW); > > Including gpio/consumer.h directly is the correct fix. > > Signed-off-by: Arnd Bergmann Reviewed-by: Bjorn Andersson Regards, Bjorn > --- > drivers/pci/dwc/pcie-qcom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c > index b65bbf7c284e..17df19db851e 100644 > --- a/drivers/pci/dwc/pcie-qcom.c > +++ b/drivers/pci/dwc/pcie-qcom.c > @@ -10,7 +10,7 @@ > > #include > #include > -#include > +#include > #include > #include > #include > -- > 2.9.0 >
[git pull] vfs, pile 4
misc bits and pieces not fitting into anything more specific. That's probably it for tonight; more to follow tomorrow... The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you to fetch changes up to eb915375757cd32c5abf7aea4caa76fe7edf8ef4: vfs: delete unnecessary assignment in vfs_listxattr (2018-05-29 13:22:41 -0400) Al Viro (7): remove rpc_rmdir() msdos_rmdir(): kill BS comment it's SB_BORN, not MS_BORN... get rid of dead code in d_find_alias() vfat: simplify checks in vfat_lookup() make xattr_getsecurity() static __inode_security_revalidate() never gets NULL opt_dentry Chengguang Xu (1): vfs: delete unnecessary assignment in vfs_listxattr Danilo Krummrich (1): vfs: namei: use path_equal() in follow_dotdot() Li Qiang (1): fs.h: fix outdated comment about file flags Sean Anderson (1): Documentation: filesystems: update filesystem locking documentation Zev Weiss (1): fs: avoid fdput() after failed fdget() in vfs_dedupe_file_range() Documentation/filesystems/Locking | 43 +++- fs/dcache.c| 83 -- fs/fat/namei_msdos.c | 4 -- fs/fat/namei_vfat.c| 13 +- fs/namei.c | 4 +- fs/read_write.c| 6 +-- fs/super.c | 2 +- fs/xattr.c | 4 +- include/linux/fs.h | 2 +- include/linux/sunrpc/rpc_pipe_fs.h | 2 - include/linux/xattr.h | 1 - net/sunrpc/rpc_pipe.c | 16 security/selinux/hooks.c | 7 ++-- 13 files changed, 69 insertions(+), 118 deletions(-)
[git pull] vfs, pile 4
misc bits and pieces not fitting into anything more specific. That's probably it for tonight; more to follow tomorrow... The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc for you to fetch changes up to eb915375757cd32c5abf7aea4caa76fe7edf8ef4: vfs: delete unnecessary assignment in vfs_listxattr (2018-05-29 13:22:41 -0400) Al Viro (7): remove rpc_rmdir() msdos_rmdir(): kill BS comment it's SB_BORN, not MS_BORN... get rid of dead code in d_find_alias() vfat: simplify checks in vfat_lookup() make xattr_getsecurity() static __inode_security_revalidate() never gets NULL opt_dentry Chengguang Xu (1): vfs: delete unnecessary assignment in vfs_listxattr Danilo Krummrich (1): vfs: namei: use path_equal() in follow_dotdot() Li Qiang (1): fs.h: fix outdated comment about file flags Sean Anderson (1): Documentation: filesystems: update filesystem locking documentation Zev Weiss (1): fs: avoid fdput() after failed fdget() in vfs_dedupe_file_range() Documentation/filesystems/Locking | 43 +++- fs/dcache.c| 83 -- fs/fat/namei_msdos.c | 4 -- fs/fat/namei_vfat.c| 13 +- fs/namei.c | 4 +- fs/read_write.c| 6 +-- fs/super.c | 2 +- fs/xattr.c | 4 +- include/linux/fs.h | 2 +- include/linux/sunrpc/rpc_pipe_fs.h | 2 - include/linux/xattr.h | 1 - net/sunrpc/rpc_pipe.c | 16 security/selinux/hooks.c | 7 ++-- 13 files changed, 69 insertions(+), 118 deletions(-)
[git pull] vfs, pile 3
Christoph's proc_create_... cleanups series.
The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git hch.procfs
for you to fetch changes up to 5ef03dbd91855544cd4c7c1910c3ef5226ee87e8:
xfs, proc: hide unused xfs procfs helpers (2018-05-25 20:43:08 -0400)
Arnd Bergmann (1):
xfs, proc: hide unused xfs procfs helpers
Christoph Hellwig (43):
net/can: single_open_net needs to be paired with single_release_net
proc: introduce a proc_pid_ns helper
proc: don't detour through seq->private to get the inode
proc: simplify proc_register calling conventions
proc: add a proc_create_reg helper
proc: introduce proc_create_seq{,_data}
proc: introduce proc_create_seq_private
proc: introduce proc_create_single{,_data}
ipv{4,6}/udp{,lite}: simplify proc registration
ipv{4,6}/tcp: simplify procfs registration
ipv{4,6}/ping: simplify proc file creation
ipv{4,6}/raw: simplify ѕeq_file code
ipv6/flowlabel: simplify pid namespace lookup
net/kcm: simplify proc registration
netfilter/x_tables: simplify ѕeq_file code
net: move seq_file_single_net to
proc: introduce proc_create_net{,_data}
proc: introduce proc_create_net_single
acpi/battery: simplify procfs code
sgi-gru: simplify procfs code
megaraid: simplify procfs code
sg: simplify procfs code
afs: simplify procfs code
ext4: simplify procfs code
jfs: simplify procfs code
staging/rtl8192u: simplify procfs code
resource: switch to proc_create_seq_data
drbd: switch to proc_create_single
rtc/proc: switch to proc_create_single_data
bonding: switch to proc_create_seq_data
hostap: switch to proc_create_{seq,single}_data
neigh: switch to proc_create_seq_data
netfilter/xt_hashlimit: switch to proc_create_{seq,single}_data
netfilter/x_tables: switch to proc_create_seq_private
bluetooth: switch to proc_create_seq_data
atm: simplify procfs code
atm: switch to proc_create_seq_private
isdn: replace ->proc_fops with ->proc_show
ide: remove ide_driver_proc_write
ide: replace ->proc_fops with ->proc_show
tty: replace ->proc_fops with ->proc_show
proc: update SIZEOF_PDE_INLINE_NAME for the new pde fields
isdn/gigaset: add back gigaset_procinfo assignment
arch/arm/kernel/dma.c | 14 +-
arch/arm/kernel/swp_emulate.c | 15 +-
arch/arm/mach-rpc/ecard.c | 16 +-
arch/ia64/hp/common/sba_iommu.c| 15 +-
arch/ia64/hp/sim/simserial.c | 15 +-
arch/ia64/kernel/palinfo.c | 16 +-
arch/ia64/kernel/perfmon.c | 16 +-
arch/ia64/kernel/salinfo.c | 42 ++---
arch/ia64/sn/kernel/sn2/prominfo_proc.c| 32 +---
arch/ia64/sn/kernel/sn2/sn_proc_fs.c | 62 +--
arch/m68k/kernel/setup_mm.c| 14 +-
arch/mips/pci/ops-pmcmsp.c | 28 +---
arch/mips/sibyte/common/bus_watcher.c | 16 +-
arch/parisc/kernel/pci-dma.c | 17 +-
arch/parisc/kernel/pdc_chassis.c | 14 +-
arch/powerpc/kernel/eeh.c | 14 +-
arch/powerpc/kernel/rtas-proc.c| 32 +---
arch/powerpc/platforms/cell/spufs/sched.c | 14 +-
arch/s390/kernel/sysinfo.c | 28 +---
arch/sh/drivers/dma/dma-api.c | 14 +-
arch/sparc/kernel/ioport.c | 19 +--
arch/um/drivers/ubd_kern.c | 16 +-
arch/x86/kernel/apm_32.c | 15 +-
arch/xtensa/platforms/iss/console.c| 15 +-
block/genhd.c | 28 +---
crypto/proc.c | 14 +-
drivers/acpi/ac.c | 21 +--
drivers/acpi/battery.c | 121 +++---
drivers/acpi/button.c | 19 +--
drivers/block/DAC960.c | 49 +-
drivers/block/drbd/drbd_int.h | 2 +-
drivers/block/drbd/drbd_main.c | 3 +-
drivers/block/drbd/drbd_proc.c | 34 +---
drivers/block/pktcdvd.c| 14 +-
drivers/block/ps3vram.c| 17 +-
drivers/char/apm-emulation.c | 15 +-
drivers/char/ds1620.c | 14 +-
drivers/char/efirtc.c | 15 +-
drivers/char/misc.c
[git pull] vfs, pile 3
Christoph's proc_create_... cleanups series.
The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:
Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git hch.procfs
for you to fetch changes up to 5ef03dbd91855544cd4c7c1910c3ef5226ee87e8:
xfs, proc: hide unused xfs procfs helpers (2018-05-25 20:43:08 -0400)
Arnd Bergmann (1):
xfs, proc: hide unused xfs procfs helpers
Christoph Hellwig (43):
net/can: single_open_net needs to be paired with single_release_net
proc: introduce a proc_pid_ns helper
proc: don't detour through seq->private to get the inode
proc: simplify proc_register calling conventions
proc: add a proc_create_reg helper
proc: introduce proc_create_seq{,_data}
proc: introduce proc_create_seq_private
proc: introduce proc_create_single{,_data}
ipv{4,6}/udp{,lite}: simplify proc registration
ipv{4,6}/tcp: simplify procfs registration
ipv{4,6}/ping: simplify proc file creation
ipv{4,6}/raw: simplify ѕeq_file code
ipv6/flowlabel: simplify pid namespace lookup
net/kcm: simplify proc registration
netfilter/x_tables: simplify ѕeq_file code
net: move seq_file_single_net to
proc: introduce proc_create_net{,_data}
proc: introduce proc_create_net_single
acpi/battery: simplify procfs code
sgi-gru: simplify procfs code
megaraid: simplify procfs code
sg: simplify procfs code
afs: simplify procfs code
ext4: simplify procfs code
jfs: simplify procfs code
staging/rtl8192u: simplify procfs code
resource: switch to proc_create_seq_data
drbd: switch to proc_create_single
rtc/proc: switch to proc_create_single_data
bonding: switch to proc_create_seq_data
hostap: switch to proc_create_{seq,single}_data
neigh: switch to proc_create_seq_data
netfilter/xt_hashlimit: switch to proc_create_{seq,single}_data
netfilter/x_tables: switch to proc_create_seq_private
bluetooth: switch to proc_create_seq_data
atm: simplify procfs code
atm: switch to proc_create_seq_private
isdn: replace ->proc_fops with ->proc_show
ide: remove ide_driver_proc_write
ide: replace ->proc_fops with ->proc_show
tty: replace ->proc_fops with ->proc_show
proc: update SIZEOF_PDE_INLINE_NAME for the new pde fields
isdn/gigaset: add back gigaset_procinfo assignment
arch/arm/kernel/dma.c | 14 +-
arch/arm/kernel/swp_emulate.c | 15 +-
arch/arm/mach-rpc/ecard.c | 16 +-
arch/ia64/hp/common/sba_iommu.c| 15 +-
arch/ia64/hp/sim/simserial.c | 15 +-
arch/ia64/kernel/palinfo.c | 16 +-
arch/ia64/kernel/perfmon.c | 16 +-
arch/ia64/kernel/salinfo.c | 42 ++---
arch/ia64/sn/kernel/sn2/prominfo_proc.c| 32 +---
arch/ia64/sn/kernel/sn2/sn_proc_fs.c | 62 +--
arch/m68k/kernel/setup_mm.c| 14 +-
arch/mips/pci/ops-pmcmsp.c | 28 +---
arch/mips/sibyte/common/bus_watcher.c | 16 +-
arch/parisc/kernel/pci-dma.c | 17 +-
arch/parisc/kernel/pdc_chassis.c | 14 +-
arch/powerpc/kernel/eeh.c | 14 +-
arch/powerpc/kernel/rtas-proc.c| 32 +---
arch/powerpc/platforms/cell/spufs/sched.c | 14 +-
arch/s390/kernel/sysinfo.c | 28 +---
arch/sh/drivers/dma/dma-api.c | 14 +-
arch/sparc/kernel/ioport.c | 19 +--
arch/um/drivers/ubd_kern.c | 16 +-
arch/x86/kernel/apm_32.c | 15 +-
arch/xtensa/platforms/iss/console.c| 15 +-
block/genhd.c | 28 +---
crypto/proc.c | 14 +-
drivers/acpi/ac.c | 21 +--
drivers/acpi/battery.c | 121 +++---
drivers/acpi/button.c | 19 +--
drivers/block/DAC960.c | 49 +-
drivers/block/drbd/drbd_int.h | 2 +-
drivers/block/drbd/drbd_main.c | 3 +-
drivers/block/drbd/drbd_proc.c | 34 +---
drivers/block/pktcdvd.c| 14 +-
drivers/block/ps3vram.c| 17 +-
drivers/char/apm-emulation.c | 15 +-
drivers/char/ds1620.c | 14 +-
drivers/char/efirtc.c | 15 +-
drivers/char/misc.c
[PATCH V2 3/4] clk: imx6sx: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM and IPG clocks.
drivers/clk/imx/clk-imx6sx.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 10c771b..aed4391 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -92,14 +92,6 @@ static const char *pll7_bypass_sels[] = { "pll7",
"pll7_bypass_src", };
static struct clk *clks[IMX6SX_CLK_CLK_END];
static struct clk_onecell_data clk_data;
-static int const clks_init_on[] __initconst = {
- IMX6SX_CLK_AIPS_TZ1, IMX6SX_CLK_AIPS_TZ2, IMX6SX_CLK_AIPS_TZ3,
- IMX6SX_CLK_IPMUX1, IMX6SX_CLK_IPMUX2, IMX6SX_CLK_IPMUX3,
- IMX6SX_CLK_WAKEUP, IMX6SX_CLK_MMDC_P0_FAST, IMX6SX_CLK_MMDC_P0_IPG,
- IMX6SX_CLK_ROM, IMX6SX_CLK_ARM, IMX6SX_CLK_IPG, IMX6SX_CLK_OCRAM,
- IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_TZASC1,
-};
-
static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -142,7 +134,6 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX6SX_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -332,7 +323,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_QSPI1_PODF] = imx_clk_divider("qspi1_podf",
"qspi1_sel", base + 0x1c, 26, 3);
clks[IMX6SX_CLK_EIM_SLOW_PODF] = imx_clk_divider("eim_slow_podf",
"eim_slow_sel", base + 0x1c, 23, 3);
clks[IMX6SX_CLK_LCDIF2_PODF]= imx_clk_divider("lcdif2_podf",
"lcdif2_pred", base + 0x1c, 20, 3);
- clks[IMX6SX_CLK_PERCLK] = imx_clk_divider("perclk",
"perclk_sel",base + 0x1c, 0,6);
+ clks[IMX6SX_CLK_PERCLK] = imx_clk_divider_flags("perclk",
"perclk_sel", base + 0x1c, 0, 6, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_VID_PODF] = imx_clk_divider("vid_podf",
"vid_sel", base + 0x20, 24, 2);
clks[IMX6SX_CLK_CAN_PODF] = imx_clk_divider("can_podf",
"can_sel", base + 0x20, 2,6);
clks[IMX6SX_CLK_USDHC4_PODF]= imx_clk_divider("usdhc4_podf",
"usdhc4_sel",base + 0x24, 22, 3);
@@ -380,8 +371,8 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
/*name
parent_name reg shift */
/* CCGR0 */
- clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2("aips_tz1", "ahb",
base + 0x68, 0);
- clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2("aips_tz2", "ahb",
base + 0x68, 2);
+ clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2_flags("aips_tz1", "ahb",
base + 0x68, 0, CLK_IS_CRITICAL);
+ clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2_flags("aips_tz2", "ahb",
base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_APBH_DMA] = imx_clk_gate2("apbh_dma",
"usdhc3",base + 0x68, 4);
clks[IMX6SX_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem", "ahb",
base + 0x68, 6, _count_asrc);
clks[IMX6SX_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg", "ahb",
base + 0x68, 6, _count_asrc);
@@ -394,7 +385,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_CAN2_SERIAL] = imx_clk_gate2("can2_serial",
"can_podf", base + 0x68, 20);
clks[IMX6SX_CLK_DCIC1]= imx_clk_gate2("dcic1",
"display_podf", base + 0x68, 24);
clks[IMX6SX_CLK_DCIC2]= imx_clk_gate2("dcic2",
"display_podf", base + 0x68, 26);
- clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2("aips_tz3", "ahb",
base + 0x68, 30);
+ clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2_flags("aips_tz3", "ahb",
base + 0x68, 30, CLK_IS_CRITICAL);
/* CCGR1 */
clks[IMX6SX_CLK_ECSPI1] = imx_clk_gate2("ecspi1",
"ecspi_podf",base + 0x6c, 0);
@@ -407,7 +398,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_ESAI_EXTAL] = imx_clk_gate2_shared("esai_extal",
"esai_podf", base + 0x6c, 16, _count_esai);
clks[IMX6SX_CLK_ESAI_IPG] = imx_clk_gate2_shared("esai_ipg",
"ahb", base
[PATCH V2 3/4] clk: imx6sx: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM and IPG clocks.
drivers/clk/imx/clk-imx6sx.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 10c771b..aed4391 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -92,14 +92,6 @@ static const char *pll7_bypass_sels[] = { "pll7",
"pll7_bypass_src", };
static struct clk *clks[IMX6SX_CLK_CLK_END];
static struct clk_onecell_data clk_data;
-static int const clks_init_on[] __initconst = {
- IMX6SX_CLK_AIPS_TZ1, IMX6SX_CLK_AIPS_TZ2, IMX6SX_CLK_AIPS_TZ3,
- IMX6SX_CLK_IPMUX1, IMX6SX_CLK_IPMUX2, IMX6SX_CLK_IPMUX3,
- IMX6SX_CLK_WAKEUP, IMX6SX_CLK_MMDC_P0_FAST, IMX6SX_CLK_MMDC_P0_IPG,
- IMX6SX_CLK_ROM, IMX6SX_CLK_ARM, IMX6SX_CLK_IPG, IMX6SX_CLK_OCRAM,
- IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_TZASC1,
-};
-
static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -142,7 +134,6 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX6SX_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -332,7 +323,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_QSPI1_PODF] = imx_clk_divider("qspi1_podf",
"qspi1_sel", base + 0x1c, 26, 3);
clks[IMX6SX_CLK_EIM_SLOW_PODF] = imx_clk_divider("eim_slow_podf",
"eim_slow_sel", base + 0x1c, 23, 3);
clks[IMX6SX_CLK_LCDIF2_PODF]= imx_clk_divider("lcdif2_podf",
"lcdif2_pred", base + 0x1c, 20, 3);
- clks[IMX6SX_CLK_PERCLK] = imx_clk_divider("perclk",
"perclk_sel",base + 0x1c, 0,6);
+ clks[IMX6SX_CLK_PERCLK] = imx_clk_divider_flags("perclk",
"perclk_sel", base + 0x1c, 0, 6, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_VID_PODF] = imx_clk_divider("vid_podf",
"vid_sel", base + 0x20, 24, 2);
clks[IMX6SX_CLK_CAN_PODF] = imx_clk_divider("can_podf",
"can_sel", base + 0x20, 2,6);
clks[IMX6SX_CLK_USDHC4_PODF]= imx_clk_divider("usdhc4_podf",
"usdhc4_sel",base + 0x24, 22, 3);
@@ -380,8 +371,8 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
/*name
parent_name reg shift */
/* CCGR0 */
- clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2("aips_tz1", "ahb",
base + 0x68, 0);
- clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2("aips_tz2", "ahb",
base + 0x68, 2);
+ clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2_flags("aips_tz1", "ahb",
base + 0x68, 0, CLK_IS_CRITICAL);
+ clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2_flags("aips_tz2", "ahb",
base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_APBH_DMA] = imx_clk_gate2("apbh_dma",
"usdhc3",base + 0x68, 4);
clks[IMX6SX_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem", "ahb",
base + 0x68, 6, _count_asrc);
clks[IMX6SX_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg", "ahb",
base + 0x68, 6, _count_asrc);
@@ -394,7 +385,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_CAN2_SERIAL] = imx_clk_gate2("can2_serial",
"can_podf", base + 0x68, 20);
clks[IMX6SX_CLK_DCIC1]= imx_clk_gate2("dcic1",
"display_podf", base + 0x68, 24);
clks[IMX6SX_CLK_DCIC2]= imx_clk_gate2("dcic2",
"display_podf", base + 0x68, 26);
- clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2("aips_tz3", "ahb",
base + 0x68, 30);
+ clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2_flags("aips_tz3", "ahb",
base + 0x68, 30, CLK_IS_CRITICAL);
/* CCGR1 */
clks[IMX6SX_CLK_ECSPI1] = imx_clk_gate2("ecspi1",
"ecspi_podf",base + 0x6c, 0);
@@ -407,7 +398,7 @@ static void __init imx6sx_clocks_init(struct device_node
*ccm_node)
clks[IMX6SX_CLK_ESAI_EXTAL] = imx_clk_gate2_shared("esai_extal",
"esai_podf", base + 0x6c, 16, _count_esai);
clks[IMX6SX_CLK_ESAI_IPG] = imx_clk_gate2_shared("esai_ipg",
"ahb", base
RE: [PATCH 1/4] clk: imx6q: remove clks_init_on array
Hi, Fabio Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Sunday, June 3, 2018 8:54 PM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Michael > Turquette ; Stephen Boyd ; > dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC > ARM ARCHITECTURE ; linux-clk > ; linux-kernel > Subject: Re: [PATCH 1/4] clk: imx6q: remove clks_init_on array > > Hi Anson, > > On Sun, Jun 3, 2018 at 9:48 AM, Anson Huang > wrote: > > > As I explain in previous mail, busy divider clk type already include the > > flag > when registered. > > Ok, then please add this information in the commit log to make the review > process easier. Thanks for the comments, I improved the commit log in V2 patch set. Anson.
[PATCH V2 4/4] clk: imx6ul: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
Signed-off-by: Anson Huang
---
This patch is based on "[V2,1/2] clk: imx6ul: add GPIO clock gates".
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM clock.
drivers/clk/imx/clk-imx6ul.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 3ea2d97..d3f7f4d 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -79,12 +79,6 @@ static const char *cko_sels[] = { "cko1", "cko2", };
static struct clk *clks[IMX6UL_CLK_END];
static struct clk_onecell_data clk_data;
-static int const clks_init_on[] __initconst = {
- IMX6UL_CLK_AIPSTZ1, IMX6UL_CLK_AIPSTZ2,
- IMX6UL_CLK_AXI, IMX6UL_CLK_ARM, IMX6UL_CLK_ROM,
- IMX6UL_CLK_MMDC_P0_FAST, IMX6UL_CLK_MMDC_P0_IPG,
-};
-
static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -129,7 +123,6 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX6UL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -336,8 +329,8 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_AHB]= imx_clk_busy_divider("ahb",
"periph", base + 0x14, 10, 3, base + 0x48, 1);
/* CCGR0 */
- clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2("aips_tz1", "ahb",
base + 0x68,0);
- clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2("aips_tz2", "ahb",
base + 0x68,2);
+ clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2_flags("aips_tz1",
"ahb", base + 0x68, 0, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2_flags("aips_tz2",
"ahb", base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_APBHDMA]= imx_clk_gate2("apbh_dma",
"bch_podf", base + 0x68,4);
clks[IMX6UL_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg",
"ahb", base + 0x68,6, _count_asrc);
clks[IMX6UL_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem",
"ahb", base + 0x68,6, _count_asrc);
@@ -412,9 +405,9 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_GPIO4] = imx_clk_gate2("gpio4","ipg",
base + 0x74,12);
clks[IMX6UL_CLK_QSPI] = imx_clk_gate2("qspi1",
"qspi1_podf", base + 0x74,14);
clks[IMX6UL_CLK_WDOG1] = imx_clk_gate2("wdog1","ipg",
base + 0x74,16);
- clks[IMX6UL_CLK_MMDC_P0_FAST] = imx_clk_gate("mmdc_p0_fast",
"mmdc_podf", base + 0x74,20);
- clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2("mmdc_p0_ipg", "ipg",
base + 0x74,24);
- clks[IMX6UL_CLK_AXI]= imx_clk_gate("axi", "axi_podf",
base + 0x74,28);
+ clks[IMX6UL_CLK_MMDC_P0_FAST] = imx_clk_gate_flags("mmdc_p0_fast",
"mmdc_podf", base + 0x74, 20, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2_flags("mmdc_p0_ipg",
"ipg", base + 0x74,24, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_AXI]= imx_clk_gate_flags("axi",
"axi_podf", base + 0x74,28, CLK_IS_CRITICAL);
/* CCGR4 */
clks[IMX6UL_CLK_PER_BCH]= imx_clk_gate2("per_bch",
"bch_podf", base + 0x78,12);
@@ -428,7 +421,7 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_GPMI_APB] = imx_clk_gate2("gpmi_apb",
"bch_podf", base + 0x78,30);
/* CCGR5 */
- clks[IMX6UL_CLK_ROM]= imx_clk_gate2("rom", "ahb",
base + 0x7c,0);
+ clks[IMX6UL_CLK_ROM]= imx_clk_gate2_flags("rom","ahb",
base + 0x7c,0, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_SDMA] = imx_clk_gate2("sdma", "ahb",
base + 0x7c,6);
clks[IMX6UL_CLK_KPP]= imx_clk_gate2("kpp", "ipg",
base + 0x7c,8);
clks[IMX6UL_CLK_WDOG2] = imx_clk_gate2("wdog2","ipg",
base + 0x7c,10);
@@ -502,10 +495,6 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 5000);
clk_set_rate(clks[IMX6UL_CLK_CSI], 2400);
- /* keep all the clks on just for bringup */
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clks[clks_init_on[i]]);
-
if (clk_on_imx6ull())
[PATCH V2 4/4] clk: imx6ul: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
Signed-off-by: Anson Huang
---
This patch is based on "[V2,1/2] clk: imx6ul: add GPIO clock gates".
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM clock.
drivers/clk/imx/clk-imx6ul.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 3ea2d97..d3f7f4d 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -79,12 +79,6 @@ static const char *cko_sels[] = { "cko1", "cko2", };
static struct clk *clks[IMX6UL_CLK_END];
static struct clk_onecell_data clk_data;
-static int const clks_init_on[] __initconst = {
- IMX6UL_CLK_AIPSTZ1, IMX6UL_CLK_AIPSTZ2,
- IMX6UL_CLK_AXI, IMX6UL_CLK_ARM, IMX6UL_CLK_ROM,
- IMX6UL_CLK_MMDC_P0_FAST, IMX6UL_CLK_MMDC_P0_IPG,
-};
-
static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -129,7 +123,6 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
clks[IMX6UL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -336,8 +329,8 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_AHB]= imx_clk_busy_divider("ahb",
"periph", base + 0x14, 10, 3, base + 0x48, 1);
/* CCGR0 */
- clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2("aips_tz1", "ahb",
base + 0x68,0);
- clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2("aips_tz2", "ahb",
base + 0x68,2);
+ clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2_flags("aips_tz1",
"ahb", base + 0x68, 0, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2_flags("aips_tz2",
"ahb", base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_APBHDMA]= imx_clk_gate2("apbh_dma",
"bch_podf", base + 0x68,4);
clks[IMX6UL_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg",
"ahb", base + 0x68,6, _count_asrc);
clks[IMX6UL_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem",
"ahb", base + 0x68,6, _count_asrc);
@@ -412,9 +405,9 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_GPIO4] = imx_clk_gate2("gpio4","ipg",
base + 0x74,12);
clks[IMX6UL_CLK_QSPI] = imx_clk_gate2("qspi1",
"qspi1_podf", base + 0x74,14);
clks[IMX6UL_CLK_WDOG1] = imx_clk_gate2("wdog1","ipg",
base + 0x74,16);
- clks[IMX6UL_CLK_MMDC_P0_FAST] = imx_clk_gate("mmdc_p0_fast",
"mmdc_podf", base + 0x74,20);
- clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2("mmdc_p0_ipg", "ipg",
base + 0x74,24);
- clks[IMX6UL_CLK_AXI]= imx_clk_gate("axi", "axi_podf",
base + 0x74,28);
+ clks[IMX6UL_CLK_MMDC_P0_FAST] = imx_clk_gate_flags("mmdc_p0_fast",
"mmdc_podf", base + 0x74, 20, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2_flags("mmdc_p0_ipg",
"ipg", base + 0x74,24, CLK_IS_CRITICAL);
+ clks[IMX6UL_CLK_AXI]= imx_clk_gate_flags("axi",
"axi_podf", base + 0x74,28, CLK_IS_CRITICAL);
/* CCGR4 */
clks[IMX6UL_CLK_PER_BCH]= imx_clk_gate2("per_bch",
"bch_podf", base + 0x78,12);
@@ -428,7 +421,7 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clks[IMX6UL_CLK_GPMI_APB] = imx_clk_gate2("gpmi_apb",
"bch_podf", base + 0x78,30);
/* CCGR5 */
- clks[IMX6UL_CLK_ROM]= imx_clk_gate2("rom", "ahb",
base + 0x7c,0);
+ clks[IMX6UL_CLK_ROM]= imx_clk_gate2_flags("rom","ahb",
base + 0x7c,0, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_SDMA] = imx_clk_gate2("sdma", "ahb",
base + 0x7c,6);
clks[IMX6UL_CLK_KPP]= imx_clk_gate2("kpp", "ipg",
base + 0x7c,8);
clks[IMX6UL_CLK_WDOG2] = imx_clk_gate2("wdog2","ipg",
base + 0x7c,10);
@@ -502,10 +495,6 @@ static void __init imx6ul_clocks_init(struct device_node
*ccm_node)
clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 5000);
clk_set_rate(clks[IMX6UL_CLK_CSI], 2400);
- /* keep all the clks on just for bringup */
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clks[clks_init_on[i]]);
-
if (clk_on_imx6ull())
RE: [PATCH 1/4] clk: imx6q: remove clks_init_on array
Hi, Fabio Anson Huang Best Regards! > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: Sunday, June 3, 2018 8:54 PM > To: Anson Huang > Cc: Shawn Guo ; Sascha Hauer > ; Fabio Estevam ; Michael > Turquette ; Stephen Boyd ; > dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC > ARM ARCHITECTURE ; linux-clk > ; linux-kernel > Subject: Re: [PATCH 1/4] clk: imx6q: remove clks_init_on array > > Hi Anson, > > On Sun, Jun 3, 2018 at 9:48 AM, Anson Huang > wrote: > > > As I explain in previous mail, busy divider clk type already include the > > flag > when registered. > > Ok, then please add this information in the commit log to make the review > process easier. Thanks for the comments, I improved the commit log in V2 patch set. Anson.
[PATCH V2 1/4] clk: imx6q: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for IMX6QDL_CLK_ARM.
drivers/clk/imx/clk-imx6q.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index b9ea703..8754c61 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -96,12 +96,6 @@ static const char *pll7_bypass_sels[] = { "pll7",
"pll7_bypass_src", };
static struct clk *clk[IMX6QDL_CLK_END];
static struct clk_onecell_data clk_data;
-static unsigned int const clks_init_on[] __initconst = {
- IMX6QDL_CLK_MMDC_CH0_AXI,
- IMX6QDL_CLK_ROM,
- IMX6QDL_CLK_ARM,
-};
-
static struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -417,7 +411,6 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *anatop_base, *base;
- int i;
int ret;
clk[IMX6QDL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -794,7 +787,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb",
"mlb_podf", base + 0x74, 18);
else
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb","axi",
base + 0x74, 18);
- clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2("mmdc_ch0_axi",
"mmdc_ch0_axi_podf", base + 0x74, 20);
+ clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2_flags("mmdc_ch0_axi",
"mmdc_ch0_axi_podf", base + 0x74, 20, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_MMDC_CH1_AXI] = imx_clk_gate2("mmdc_ch1_axi",
"mmdc_ch1_axi_podf", base + 0x74, 22);
clk[IMX6QDL_CLK_OCRAM]= imx_clk_gate2("ocram", "ahb",
base + 0x74, 28);
clk[IMX6QDL_CLK_OPENVG_AXI] = imx_clk_gate2("openvg_axi","axi",
base + 0x74, 30);
@@ -808,7 +801,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_GPMI_BCH] = imx_clk_gate2("gpmi_bch",
"usdhc4",base + 0x78, 26);
clk[IMX6QDL_CLK_GPMI_IO] = imx_clk_gate2("gpmi_io", "enfc",
base + 0x78, 28);
clk[IMX6QDL_CLK_GPMI_APB] = imx_clk_gate2("gpmi_apb",
"usdhc3",base + 0x78, 30);
- clk[IMX6QDL_CLK_ROM] = imx_clk_gate2("rom", "ahb",
base + 0x7c, 0);
+ clk[IMX6QDL_CLK_ROM] = imx_clk_gate2_flags("rom", "ahb",
base + 0x7c, 0, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_SATA] = imx_clk_gate2("sata", "ahb",
base + 0x7c, 4);
clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma", "ahb",
base + 0x7c, 6);
clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba", "ipg",
base + 0x7c, 12);
@@ -878,9 +871,6 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
*/
clk_set_parent(clk[IMX6QDL_CLK_ENFC_SEL],
clk[IMX6QDL_CLK_PLL2_PFD2_396M]);
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clk[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY2_GATE]);
--
2.7.4
[PATCH V2 1/4] clk: imx6q: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for IMX6QDL_CLK_ARM.
drivers/clk/imx/clk-imx6q.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index b9ea703..8754c61 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -96,12 +96,6 @@ static const char *pll7_bypass_sels[] = { "pll7",
"pll7_bypass_src", };
static struct clk *clk[IMX6QDL_CLK_END];
static struct clk_onecell_data clk_data;
-static unsigned int const clks_init_on[] __initconst = {
- IMX6QDL_CLK_MMDC_CH0_AXI,
- IMX6QDL_CLK_ROM,
- IMX6QDL_CLK_ARM,
-};
-
static struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -417,7 +411,6 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *anatop_base, *base;
- int i;
int ret;
clk[IMX6QDL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -794,7 +787,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb",
"mlb_podf", base + 0x74, 18);
else
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb","axi",
base + 0x74, 18);
- clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2("mmdc_ch0_axi",
"mmdc_ch0_axi_podf", base + 0x74, 20);
+ clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2_flags("mmdc_ch0_axi",
"mmdc_ch0_axi_podf", base + 0x74, 20, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_MMDC_CH1_AXI] = imx_clk_gate2("mmdc_ch1_axi",
"mmdc_ch1_axi_podf", base + 0x74, 22);
clk[IMX6QDL_CLK_OCRAM]= imx_clk_gate2("ocram", "ahb",
base + 0x74, 28);
clk[IMX6QDL_CLK_OPENVG_AXI] = imx_clk_gate2("openvg_axi","axi",
base + 0x74, 30);
@@ -808,7 +801,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_GPMI_BCH] = imx_clk_gate2("gpmi_bch",
"usdhc4",base + 0x78, 26);
clk[IMX6QDL_CLK_GPMI_IO] = imx_clk_gate2("gpmi_io", "enfc",
base + 0x78, 28);
clk[IMX6QDL_CLK_GPMI_APB] = imx_clk_gate2("gpmi_apb",
"usdhc3",base + 0x78, 30);
- clk[IMX6QDL_CLK_ROM] = imx_clk_gate2("rom", "ahb",
base + 0x7c, 0);
+ clk[IMX6QDL_CLK_ROM] = imx_clk_gate2_flags("rom", "ahb",
base + 0x7c, 0, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_SATA] = imx_clk_gate2("sata", "ahb",
base + 0x7c, 4);
clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma", "ahb",
base + 0x7c, 6);
clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba", "ipg",
base + 0x7c, 12);
@@ -878,9 +871,6 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
*/
clk_set_parent(clk[IMX6QDL_CLK_ENFC_SEL],
clk[IMX6QDL_CLK_PLL2_PFD2_396M]);
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clk[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY2_GATE]);
--
2.7.4
[PATCH V2 2/4] clk: imx6sl: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM and IPG clocks.
drivers/clk/imx/clk-imx6sl.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index 66b1dd1..eb6bcbf 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -104,10 +104,6 @@ static struct clk_onecell_data clk_data;
static void __iomem *ccm_base;
static void __iomem *anatop_base;
-static const u32 clks_init_on[] __initconst = {
- IMX6SL_CLK_IPG, IMX6SL_CLK_ARM, IMX6SL_CLK_MMDC_ROOT,
-};
-
/*
* ERR005311 CCM: After exit from WAIT mode, unwanted interrupt(s) taken
* during WAIT mode entry process could cause cache memory
@@ -195,7 +191,6 @@ static void __init imx6sl_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
int ret;
clks[IMX6SL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -426,13 +421,6 @@ static void __init imx6sl_clocks_init(struct device_node
*ccm_node)
pr_warn("%s: failed to set AHB clock rate %d!\n",
__func__, ret);
- /*
-* Make sure those always on clocks are enabled to maintain the correct
-* usecount and enabling/disabling of parent PLLs.
-*/
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clks[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY2_GATE]);
--
2.7.4
[PATCH V2 2/4] clk: imx6sl: remove clks_init_on array
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.
ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.
IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.
Signed-off-by: Anson Huang
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag
for ARM and IPG clocks.
drivers/clk/imx/clk-imx6sl.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index 66b1dd1..eb6bcbf 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -104,10 +104,6 @@ static struct clk_onecell_data clk_data;
static void __iomem *ccm_base;
static void __iomem *anatop_base;
-static const u32 clks_init_on[] __initconst = {
- IMX6SL_CLK_IPG, IMX6SL_CLK_ARM, IMX6SL_CLK_MMDC_ROOT,
-};
-
/*
* ERR005311 CCM: After exit from WAIT mode, unwanted interrupt(s) taken
* during WAIT mode entry process could cause cache memory
@@ -195,7 +191,6 @@ static void __init imx6sl_clocks_init(struct device_node
*ccm_node)
{
struct device_node *np;
void __iomem *base;
- int i;
int ret;
clks[IMX6SL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -426,13 +421,6 @@ static void __init imx6sl_clocks_init(struct device_node
*ccm_node)
pr_warn("%s: failed to set AHB clock rate %d!\n",
__func__, ret);
- /*
-* Make sure those always on clocks are enabled to maintain the correct
-* usecount and enabling/disabling of parent PLLs.
-*/
- for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
- clk_prepare_enable(clks[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY2_GATE]);
--
2.7.4
Re: [PATCH v2 21/21] sparc64: use match_string() helper
Hi Andy,
On 2018/6/1 19:34, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie wrote:
>> match_string() returns the index of an array for a matching string,
>> which can be used instead of open coded variant.
>
>> @@ -512,10 +512,9 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
>> break;
>> }
>> }
>
> It seems previous loop also can be replaced.
No, because the there is an NULL in the middle of the array hwcaps:
static const char *hwcaps[] = {
"flush", "stbar", "swap", "muldiv", "v9",
"ultra3", "blkinit", "n2",
/* These strings are as they appear in the machine description
* 'hwcap-list' property for cpu nodes.
*/
"mul32", "div32", "fsmuld", "v8plus", "popc", "vis", "vis2",
"ASIBlkInit", "fmaf", "vis3", "hpc", "random", "trans", "fjfmau",
"ima", "cspare", "pause", "cbcond", NULL /*reserved for crypto */,
"adp",
};
Thanks
Yisheng
>
>> - for (i = 0; i < ARRAY_SIZE(crypto_hwcaps); i++) {
>> - if (!strcmp(prop, crypto_hwcaps[i]))
>> - caps |= HWCAP_SPARC_CRYPTO;
>> - }
>> + i = match_string(crypto_hwcaps, ARRAY_SIZE(crypto_hwcaps),
>> prop);
>> + if (i >= 0)
>> + caps |= HWCAP_SPARC_CRYPTO;
>>
>> plen = strlen(prop) + 1;
>> prop += plen;
>> --
>> 1.7.12.4
>>
>
>
>
Re: [PATCH v2 21/21] sparc64: use match_string() helper
Hi Andy,
On 2018/6/1 19:34, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie wrote:
>> match_string() returns the index of an array for a matching string,
>> which can be used instead of open coded variant.
>
>> @@ -512,10 +512,9 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
>> break;
>> }
>> }
>
> It seems previous loop also can be replaced.
No, because the there is an NULL in the middle of the array hwcaps:
static const char *hwcaps[] = {
"flush", "stbar", "swap", "muldiv", "v9",
"ultra3", "blkinit", "n2",
/* These strings are as they appear in the machine description
* 'hwcap-list' property for cpu nodes.
*/
"mul32", "div32", "fsmuld", "v8plus", "popc", "vis", "vis2",
"ASIBlkInit", "fmaf", "vis3", "hpc", "random", "trans", "fjfmau",
"ima", "cspare", "pause", "cbcond", NULL /*reserved for crypto */,
"adp",
};
Thanks
Yisheng
>
>> - for (i = 0; i < ARRAY_SIZE(crypto_hwcaps); i++) {
>> - if (!strcmp(prop, crypto_hwcaps[i]))
>> - caps |= HWCAP_SPARC_CRYPTO;
>> - }
>> + i = match_string(crypto_hwcaps, ARRAY_SIZE(crypto_hwcaps),
>> prop);
>> + if (i >= 0)
>> + caps |= HWCAP_SPARC_CRYPTO;
>>
>> plen = strlen(prop) + 1;
>> prop += plen;
>> --
>> 1.7.12.4
>>
>
>
>
[git pull] vfs, pile 2
More shrink_dcache_parent()-related stuff - killing the main source of potentially contended calls of that on large subtrees. The following changes since commit 4faa99965e027cc057c5145ce45fa772caa04e8d: fix io_destroy()/aio_complete() race (2018-05-23 22:53:22 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.rmdir for you to fetch changes up to 8767712f26d18ac4541e2d0d7be17c40a5911ce4: rmdir(),rename(): do shrink_dcache_parent() only on success (2018-05-27 16:23:51 -0400) Al Viro (1): rmdir(),rename(): do shrink_dcache_parent() only on success fs/namei.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
[git pull] vfs, pile 2
More shrink_dcache_parent()-related stuff - killing the main source of potentially contended calls of that on large subtrees. The following changes since commit 4faa99965e027cc057c5145ce45fa772caa04e8d: fix io_destroy()/aio_complete() race (2018-05-23 22:53:22 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.rmdir for you to fetch changes up to 8767712f26d18ac4541e2d0d7be17c40a5911ce4: rmdir(),rename(): do shrink_dcache_parent() only on success (2018-05-27 16:23:51 -0400) Al Viro (1): rmdir(),rename(): do shrink_dcache_parent() only on success fs/namei.c | 8 1 file changed, 4 insertions(+), 4 deletions(-)
[git pull] vfs, pile 1
That pile is the first part of dealing with livelocks, etc. around shrink_dcache_parent(). The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache for you to fetch changes up to 4fb48871409e2fcd375087d526d07f7600c88f94: restore cond_resched() in shrink_dcache_parent() (2018-04-19 23:58:48 -0400) Al Viro (5): d_invalidate(): unhash immediately d_walk(): kill 'finish' callback dcache: move cond_resched() into the end of __dentry_kill() dput(): turn into explicit while() loop restore cond_resched() in shrink_dcache_parent() fs/dcache.c | 122 +--- 1 file changed, 43 insertions(+), 79 deletions(-)
[git pull] vfs, pile 1
That pile is the first part of dealing with livelocks, etc. around shrink_dcache_parent(). The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache for you to fetch changes up to 4fb48871409e2fcd375087d526d07f7600c88f94: restore cond_resched() in shrink_dcache_parent() (2018-04-19 23:58:48 -0400) Al Viro (5): d_invalidate(): unhash immediately d_walk(): kill 'finish' callback dcache: move cond_resched() into the end of __dentry_kill() dput(): turn into explicit while() loop restore cond_resched() in shrink_dcache_parent() fs/dcache.c | 122 +--- 1 file changed, 43 insertions(+), 79 deletions(-)
Re: [PATCH] rpmsg: smd: do not use mananged resources for endpoints and channels
On Fri 01 Jun 16:32 PDT 2018, Srinivas Kandagatla wrote:
> @@ -1380,11 +1380,13 @@ static void qcom_smd_edge_release(struct device *dev)
> {
> struct qcom_smd_channel *channel;
> struct qcom_smd_edge *edge = to_smd_edge(dev);
> + struct list_head *this, *tmp;
>
> - list_for_each_entry(channel, >channels, list) {
> - SET_RX_CHANNEL_INFO(channel, state, SMD_CHANNEL_CLOSED);
> - SET_RX_CHANNEL_INFO(channel, head, 0);
> - SET_RX_CHANNEL_INFO(channel, tail, 0);
> + list_for_each_safe(this, tmp, >channels) {
> + channel = list_entry(this, struct qcom_smd_channel, list);
Is there a reason not to use list_for_each_entry_safe()?
> + list_del(>list);
> + kfree(channel->name);
> + kfree(channel);
Regards,
Bjorn
Re: [PATCH] rpmsg: smd: do not use mananged resources for endpoints and channels
On Fri 01 Jun 16:32 PDT 2018, Srinivas Kandagatla wrote:
> @@ -1380,11 +1380,13 @@ static void qcom_smd_edge_release(struct device *dev)
> {
> struct qcom_smd_channel *channel;
> struct qcom_smd_edge *edge = to_smd_edge(dev);
> + struct list_head *this, *tmp;
>
> - list_for_each_entry(channel, >channels, list) {
> - SET_RX_CHANNEL_INFO(channel, state, SMD_CHANNEL_CLOSED);
> - SET_RX_CHANNEL_INFO(channel, head, 0);
> - SET_RX_CHANNEL_INFO(channel, tail, 0);
> + list_for_each_safe(this, tmp, >channels) {
> + channel = list_entry(this, struct qcom_smd_channel, list);
Is there a reason not to use list_for_each_entry_safe()?
> + list_del(>list);
> + kfree(channel->name);
> + kfree(channel);
Regards,
Bjorn
