* Re: [PATCH 1/6] mm: change locked_vm's type from unsigned long to atomic64_t
From: Daniel Jordan @ 2019-04-22 15:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Rutland, Davidlohr Bueso, kvm, Alan Tull,
Alexey Kardashevskiy, linux-fpga, linux-kernel, kvm-ppc,
Daniel Jordan, linux-mm, Alex Williamson, Moritz Fischer,
Christoph Lameter, linuxppc-dev, Wu Hao
In-Reply-To: <20190416163351.5e4e075ddfad0677239fc23a@linux-foundation.org>
On Tue, Apr 16, 2019 at 04:33:51PM -0700, Andrew Morton wrote:
Sorry for the delay, I was on vacation all last week.
> What's the status of this patchset, btw?
>
> I have a note here that
> powerpc-mmu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch is to be
> updated.
Yes, the series needs a few updates. v2 should appear in the next day or two.
^ permalink raw reply
* Re: [PATCH v12 09/31] mm: VMA sequence count
From: Jerome Glisse @ 2019-04-22 15:51 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
David Rientjes, paulmck, Haiyan Song, npiggin, sj38.park, dave,
kemi.wang, kirill, Thomas Gleixner, zhong jiang, Ganesh Mahendran,
Yang Shi, Mike Rapoport, linuxppc-dev, linux-kernel,
Sergey Senozhatsky, vinayak menon, akpm, Tim Chen, haren
In-Reply-To: <d217e71c-7d55-ce1a-6461-ce1de732fb57@linux.ibm.com>
On Fri, Apr 19, 2019 at 05:45:57PM +0200, Laurent Dufour wrote:
> Hi Jerome,
>
> Thanks a lot for reviewing this series.
>
> Le 19/04/2019 à 00:48, Jerome Glisse a écrit :
> > On Tue, Apr 16, 2019 at 03:45:00PM +0200, Laurent Dufour wrote:
> > > From: Peter Zijlstra <peterz@infradead.org>
> > >
> > > Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
> > > counts such that we can easily test if a VMA is changed.
> > >
> > > The calls to vm_write_begin/end() in unmap_page_range() are
> > > used to detect when a VMA is being unmap and thus that new page fault
> > > should not be satisfied for this VMA. If the seqcount hasn't changed when
> > > the page table are locked, this means we are safe to satisfy the page
> > > fault.
> > >
> > > The flip side is that we cannot distinguish between a vma_adjust() and
> > > the unmap_page_range() -- where with the former we could have
> > > re-checked the vma bounds against the address.
> > >
> > > The VMA's sequence counter is also used to detect change to various VMA's
> > > fields used during the page fault handling, such as:
> > > - vm_start, vm_end
> > > - vm_pgoff
> > > - vm_flags, vm_page_prot
> > > - vm_policy
> >
> > ^ All above are under mmap write lock ?
>
> Yes, changes are still made under the protection of the mmap_sem.
>
> >
> > > - anon_vma
> >
> > ^ This is either under mmap write lock or under page table lock
> >
> > So my question is do we need the complexity of seqcount_t for this ?
>
> The sequence counter is used to detect write operation done while readers
> (SPF handler) is running.
>
> The implementation is quite simple (here without the lockdep checks):
>
> static inline void raw_write_seqcount_begin(seqcount_t *s)
> {
> s->sequence++;
> smp_wmb();
> }
>
> I can't see why this is too complex here, would you elaborate on this ?
>
> >
> > It seems that using regular int as counter and also relying on vm_flags
> > when vma is unmap should do the trick.
>
> vm_flags is not enough I guess an some operation are not impacting the
> vm_flags at all (resizing for instance).
> Am I missing something ?
>
> >
> > vma_delete(struct vm_area_struct *vma)
> > {
> > ...
> > /*
> > * Make sure the vma is mark as invalid ie neither read nor write
> > * so that speculative fault back off. A racing speculative fault
> > * will either see the flags as 0 or the new seqcount.
> > */
> > vma->vm_flags = 0;
> > smp_wmb();
> > vma->seqcount++;
> > ...
> > }
>
> Well I don't think we can safely clear the vm_flags this way when the VMA is
> unmap, I think it is used later when cleaning is doen.
>
> Later in this series, the VMA deletion is managed when the VMA is unlinked
> from the RB Tree. That is checked using the vm_rb field's value, and managed
> using RCU.
>
> > Then:
> > speculative_fault_begin(struct vm_area_struct *vma,
> > struct spec_vmf *spvmf)
> > {
> > ...
> > spvmf->seqcount = vma->seqcount;
> > smp_rmb();
> > spvmf->vm_flags = vma->vm_flags;
> > if (!spvmf->vm_flags) {
> > // Back off the vma is dying ...
> > ...
> > }
> > }
> >
> > bool speculative_fault_commit(struct vm_area_struct *vma,
> > struct spec_vmf *spvmf)
> > {
> > ...
> > seqcount = vma->seqcount;
> > smp_rmb();
> > vm_flags = vma->vm_flags;
> >
> > if (spvmf->vm_flags != vm_flags || seqcount != spvmf->seqcount) {
> > // Something did change for the vma
> > return false;
> > }
> > return true;
> > }
> >
> > This would also avoid the lockdep issue described below. But maybe what
> > i propose is stupid and i will see it after further reviewing thing.
>
> That's true that the lockdep is quite annoying here. But it is still
> interesting to keep in the loop to avoid 2 subsequent write_seqcount_begin()
> call being made in the same context (which would lead to an even sequence
> counter value while write operation is in progress). So I think this is
> still a good thing to have lockdep available here.
Ok so i had to read everything and i should have read everything before
asking all of the above. It does look good in fact, what worried my in
this patch is all the lockdep avoidance as it is usualy a red flags.
But after thinking long and hard i do not see how to easily solve that
one as unmap_page_range() is in so many different path... So what is done
in this patch is the most sane thing. Sorry for the noise.
So for this patch:
Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
^ permalink raw reply
* Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4
From: Diana Madalina Craciun @ 2019-04-22 15:32 UTC (permalink / raw)
To: Michael Ellerman, stable@vger.kernel.org,
gregkh@linuxfoundation.org
Cc: linuxppc-dev@ozlabs.org, msuchanek@suse.de, npiggin@gmail.com
In-Reply-To: <20190421142037.21881-1-mpe@ellerman.id.au>
Hi Michael,
There are some missing NXP Spectre v2 patches. I can send them
separately if the series will be accepted. I have merged them, but I did
not test them, I was sick today and incapable of doing that.
Thanks,
Diana
On 4/21/2019 5:21 PM, Michael Ellerman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Greg/Sasha,
>
> Please queue up these powerpc patches for 4.4 if you have no objections.
>
> cheers
>
>
> Christophe Leroy (1):
> powerpc/fsl: Fix the flush of branch predictor.
>
> Diana Craciun (10):
> powerpc/64: Disable the speculation barrier from the command line
> powerpc/64: Make stf barrier PPC_BOOK3S_64 specific.
> powerpc/64: Make meltdown reporting Book3S 64 specific
> powerpc/fsl: Add barrier_nospec implementation for NXP PowerPC Book3E
> powerpc/fsl: Add infrastructure to fixup branch predictor flush
> powerpc/fsl: Add macro to flush the branch predictor
> powerpc/fsl: Fix spectre_v2 mitigations reporting
> powerpc/fsl: Add nospectre_v2 command line argument
> powerpc/fsl: Flush the branch predictor at each kernel entry (64bit)
> powerpc/fsl: Update Spectre v2 reporting
>
> Mauricio Faria de Oliveira (4):
> powerpc/rfi-flush: Differentiate enabled and patched flush types
> powerpc/pseries: Fix clearing of security feature flags
> powerpc: Move default security feature flags
> powerpc/pseries: Restore default security feature flags on setup
>
> Michael Ellerman (29):
> powerpc/xmon: Add RFI flush related fields to paca dump
> powerpc/pseries: Support firmware disable of RFI flush
> powerpc/powernv: Support firmware disable of RFI flush
> powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs
> code
> powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
> powerpc/rfi-flush: Always enable fallback flush on pseries
> powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
> powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
> powerpc: Add security feature flags for Spectre/Meltdown
> powerpc/pseries: Set or clear security feature flags
> powerpc/powernv: Set or clear security feature flags
> powerpc/64s: Move cpu_show_meltdown()
> powerpc/64s: Enhance the information in cpu_show_meltdown()
> powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
> powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
> powerpc/64s: Wire up cpu_show_spectre_v1()
> powerpc/64s: Wire up cpu_show_spectre_v2()
> powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
> powerpc/64: Use barrier_nospec in syscall entry
> powerpc: Use barrier_nospec in copy_from_user()
> powerpc64s: Show ori31 availability in spectre_v1 sysfs file not v2
> powerpc/64: Add CONFIG_PPC_BARRIER_NOSPEC
> powerpc/64: Call setup_barrier_nospec() from setup_arch()
> powerpc/asm: Add a patch_site macro & helpers for patching
> instructions
> powerpc/64s: Add new security feature flags for count cache flush
> powerpc/64s: Add support for software count cache flush
> powerpc/pseries: Query hypervisor for count cache flush settings
> powerpc/powernv: Query firmware for count cache flush settings
> powerpc/security: Fix spectre_v2 reporting
>
> Michael Neuling (1):
> powerpc: Avoid code patching freed init sections
>
> Michal Suchanek (5):
> powerpc/64s: Add barrier_nospec
> powerpc/64s: Add support for ori barrier_nospec patching
> powerpc/64s: Patch barrier_nospec in modules
> powerpc/64s: Enable barrier_nospec based on firmware settings
> powerpc/64s: Enhance the information in cpu_show_spectre_v1()
>
> Nicholas Piggin (2):
> powerpc/64s: Improve RFI L1-D cache flush fallback
> powerpc/64s: Add support for a store forwarding barrier at kernel
> entry/exit
>
> arch/powerpc/Kconfig | 7 +-
> arch/powerpc/include/asm/asm-prototypes.h | 21 +
> arch/powerpc/include/asm/barrier.h | 21 +
> arch/powerpc/include/asm/code-patching-asm.h | 18 +
> arch/powerpc/include/asm/code-patching.h | 2 +
> arch/powerpc/include/asm/exception-64s.h | 35 ++
> arch/powerpc/include/asm/feature-fixups.h | 40 ++
> arch/powerpc/include/asm/hvcall.h | 5 +
> arch/powerpc/include/asm/paca.h | 3 +-
> arch/powerpc/include/asm/ppc-opcode.h | 1 +
> arch/powerpc/include/asm/ppc_asm.h | 11 +
> arch/powerpc/include/asm/security_features.h | 92 ++++
> arch/powerpc/include/asm/setup.h | 23 +-
> arch/powerpc/include/asm/uaccess.h | 18 +-
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/asm-offsets.c | 3 +-
> arch/powerpc/kernel/entry_64.S | 69 +++
> arch/powerpc/kernel/exceptions-64e.S | 27 +-
> arch/powerpc/kernel/exceptions-64s.S | 98 +++--
> arch/powerpc/kernel/module.c | 10 +-
> arch/powerpc/kernel/security.c | 433 +++++++++++++++++++
> arch/powerpc/kernel/setup_32.c | 2 +
> arch/powerpc/kernel/setup_64.c | 50 +--
> arch/powerpc/kernel/vmlinux.lds.S | 33 +-
> arch/powerpc/lib/code-patching.c | 29 ++
> arch/powerpc/lib/feature-fixups.c | 218 +++++++++-
> arch/powerpc/mm/mem.c | 2 +
> arch/powerpc/mm/tlb_low_64e.S | 7 +
> arch/powerpc/platforms/powernv/setup.c | 99 +++--
> arch/powerpc/platforms/pseries/mobility.c | 3 +
> arch/powerpc/platforms/pseries/pseries.h | 2 +
> arch/powerpc/platforms/pseries/setup.c | 88 +++-
> arch/powerpc/xmon/xmon.c | 2 +
> 33 files changed, 1345 insertions(+), 128 deletions(-)
> create mode 100644 arch/powerpc/include/asm/asm-prototypes.h
> create mode 100644 arch/powerpc/include/asm/code-patching-asm.h
> create mode 100644 arch/powerpc/include/asm/security_features.h
> create mode 100644 arch/powerpc/kernel/security.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 58a1fa979655..01b6c00a7060 100644
> - --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -136,7 +136,7 @@ config PPC
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_CMOS_UPDATE
> select GENERIC_TIME_VSYSCALL_OLD
> - - select GENERIC_CPU_VULNERABILITIES if PPC_BOOK3S_64
> + select GENERIC_CPU_VULNERABILITIES if PPC_BARRIER_NOSPEC
> select GENERIC_CLOCKEVENTS
> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> @@ -162,6 +162,11 @@ config PPC
> select ARCH_HAS_DMA_SET_COHERENT_MASK
> select HAVE_ARCH_SECCOMP_FILTER
>
> +config PPC_BARRIER_NOSPEC
> + bool
> + default y
> + depends on PPC_BOOK3S_64 || PPC_FSL_BOOK3E
> +
> config GENERIC_CSUM
> def_bool CPU_LITTLE_ENDIAN
>
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
> new file mode 100644
> index 000000000000..8944c55591cf
> - --- /dev/null
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -0,0 +1,21 @@
> +#ifndef _ASM_POWERPC_ASM_PROTOTYPES_H
> +#define _ASM_POWERPC_ASM_PROTOTYPES_H
> +/*
> + * This file is for prototypes of C functions that are only called
> + * from asm, and any associated variables.
> + *
> + * Copyright 2016, Daniel Axtens, IBM Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +/* Patch sites */
> +extern s32 patch__call_flush_count_cache;
> +extern s32 patch__flush_count_cache_return;
> +
> +extern long flush_count_cache;
> +
> +#endif /* _ASM_POWERPC_ASM_PROTOTYPES_H */
> diff --git a/arch/powerpc/include/asm/barrier.h b/arch/powerpc/include/asm/barrier.h
> index b9e16855a037..e7cb72cdb2ba 100644
> - --- a/arch/powerpc/include/asm/barrier.h
> +++ b/arch/powerpc/include/asm/barrier.h
> @@ -92,4 +92,25 @@ do { \
> #define smp_mb__after_atomic() smp_mb()
> #define smp_mb__before_spinlock() smp_mb()
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +#define NOSPEC_BARRIER_SLOT nop
> +#elif defined(CONFIG_PPC_FSL_BOOK3E)
> +#define NOSPEC_BARRIER_SLOT nop; nop
> +#endif
> +
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> +/*
> + * Prevent execution of subsequent instructions until preceding branches have
> + * been fully resolved and are no longer executing speculatively.
> + */
> +#define barrier_nospec_asm NOSPEC_BARRIER_FIXUP_SECTION; NOSPEC_BARRIER_SLOT
> +
> +// This also acts as a compiler barrier due to the memory clobber.
> +#define barrier_nospec() asm (stringify_in_c(barrier_nospec_asm) ::: "memory")
> +
> +#else /* !CONFIG_PPC_BARRIER_NOSPEC */
> +#define barrier_nospec_asm
> +#define barrier_nospec()
> +#endif /* CONFIG_PPC_BARRIER_NOSPEC */
> +
> #endif /* _ASM_POWERPC_BARRIER_H */
> diff --git a/arch/powerpc/include/asm/code-patching-asm.h b/arch/powerpc/include/asm/code-patching-asm.h
> new file mode 100644
> index 000000000000..ed7b1448493a
> - --- /dev/null
> +++ b/arch/powerpc/include/asm/code-patching-asm.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2018, Michael Ellerman, IBM Corporation.
> + */
> +#ifndef _ASM_POWERPC_CODE_PATCHING_ASM_H
> +#define _ASM_POWERPC_CODE_PATCHING_ASM_H
> +
> +/* Define a "site" that can be patched */
> +.macro patch_site label name
> + .pushsection ".rodata"
> + .balign 4
> + .global \name
> +\name:
> + .4byte \label - .
> + .popsection
> +.endm
> +
> +#endif /* _ASM_POWERPC_CODE_PATCHING_ASM_H */
> diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
> index 840a5509b3f1..a734b4b34d26 100644
> - --- a/arch/powerpc/include/asm/code-patching.h
> +++ b/arch/powerpc/include/asm/code-patching.h
> @@ -28,6 +28,8 @@ unsigned int create_cond_branch(const unsigned int *addr,
> unsigned long target, int flags);
> int patch_branch(unsigned int *addr, unsigned long target, int flags);
> int patch_instruction(unsigned int *addr, unsigned int instr);
> +int patch_instruction_site(s32 *addr, unsigned int instr);
> +int patch_branch_site(s32 *site, unsigned long target, int flags);
>
> int instr_is_relative_branch(unsigned int instr);
> int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
> diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
> index 9bddbec441b8..3ed536bec462 100644
> - --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -50,6 +50,27 @@
> #define EX_PPR 88 /* SMT thread status register (priority) */
> #define EX_CTR 96
>
> +#define STF_ENTRY_BARRIER_SLOT \
> + STF_ENTRY_BARRIER_FIXUP_SECTION; \
> + nop; \
> + nop; \
> + nop
> +
> +#define STF_EXIT_BARRIER_SLOT \
> + STF_EXIT_BARRIER_FIXUP_SECTION; \
> + nop; \
> + nop; \
> + nop; \
> + nop; \
> + nop; \
> + nop
> +
> +/*
> + * r10 must be free to use, r13 must be paca
> + */
> +#define INTERRUPT_TO_KERNEL \
> + STF_ENTRY_BARRIER_SLOT
> +
> /*
> * Macros for annotating the expected destination of (h)rfid
> *
> @@ -66,16 +87,19 @@
> rfid
>
> #define RFI_TO_USER \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> rfid; \
> b rfi_flush_fallback
>
> #define RFI_TO_USER_OR_KERNEL \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> rfid; \
> b rfi_flush_fallback
>
> #define RFI_TO_GUEST \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> rfid; \
> b rfi_flush_fallback
> @@ -84,21 +108,25 @@
> hrfid
>
> #define HRFI_TO_USER \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> hrfid; \
> b hrfi_flush_fallback
>
> #define HRFI_TO_USER_OR_KERNEL \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> hrfid; \
> b hrfi_flush_fallback
>
> #define HRFI_TO_GUEST \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> hrfid; \
> b hrfi_flush_fallback
>
> #define HRFI_TO_UNKNOWN \
> + STF_EXIT_BARRIER_SLOT; \
> RFI_FLUSH_SLOT; \
> hrfid; \
> b hrfi_flush_fallback
> @@ -226,6 +254,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
> #define __EXCEPTION_PROLOG_1(area, extra, vec) \
> OPT_SAVE_REG_TO_PACA(area+EX_PPR, r9, CPU_FTR_HAS_PPR); \
> OPT_SAVE_REG_TO_PACA(area+EX_CFAR, r10, CPU_FTR_CFAR); \
> + INTERRUPT_TO_KERNEL; \
> SAVE_CTR(r10, area); \
> mfcr r9; \
> extra(vec); \
> @@ -512,6 +541,12 @@ label##_relon_hv: \
> #define _MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
> __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra)
>
> +#define MASKABLE_EXCEPTION_OOL(vec, label) \
> + .globl label##_ool; \
> +label##_ool: \
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, vec); \
> + EXCEPTION_PROLOG_PSERIES_1(label##_common, EXC_STD);
> +
> #define MASKABLE_EXCEPTION_PSERIES(loc, vec, label) \
> . = loc; \
> .globl label##_pSeries; \
> diff --git a/arch/powerpc/include/asm/feature-fixups.h b/arch/powerpc/include/asm/feature-fixups.h
> index 7068bafbb2d6..145a37ab2d3e 100644
> - --- a/arch/powerpc/include/asm/feature-fixups.h
> +++ b/arch/powerpc/include/asm/feature-fixups.h
> @@ -184,6 +184,22 @@ label##3: \
> FTR_ENTRY_OFFSET label##1b-label##3b; \
> .popsection;
>
> +#define STF_ENTRY_BARRIER_FIXUP_SECTION \
> +953: \
> + .pushsection __stf_entry_barrier_fixup,"a"; \
> + .align 2; \
> +954: \
> + FTR_ENTRY_OFFSET 953b-954b; \
> + .popsection;
> +
> +#define STF_EXIT_BARRIER_FIXUP_SECTION \
> +955: \
> + .pushsection __stf_exit_barrier_fixup,"a"; \
> + .align 2; \
> +956: \
> + FTR_ENTRY_OFFSET 955b-956b; \
> + .popsection;
> +
> #define RFI_FLUSH_FIXUP_SECTION \
> 951: \
> .pushsection __rfi_flush_fixup,"a"; \
> @@ -192,10 +208,34 @@ label##3: \
> FTR_ENTRY_OFFSET 951b-952b; \
> .popsection;
>
> +#define NOSPEC_BARRIER_FIXUP_SECTION \
> +953: \
> + .pushsection __barrier_nospec_fixup,"a"; \
> + .align 2; \
> +954: \
> + FTR_ENTRY_OFFSET 953b-954b; \
> + .popsection;
> +
> +#define START_BTB_FLUSH_SECTION \
> +955: \
> +
> +#define END_BTB_FLUSH_SECTION \
> +956: \
> + .pushsection __btb_flush_fixup,"a"; \
> + .align 2; \
> +957: \
> + FTR_ENTRY_OFFSET 955b-957b; \
> + FTR_ENTRY_OFFSET 956b-957b; \
> + .popsection;
>
> #ifndef __ASSEMBLY__
>
> +extern long stf_barrier_fallback;
> +extern long __start___stf_entry_barrier_fixup, __stop___stf_entry_barrier_fixup;
> +extern long __start___stf_exit_barrier_fixup, __stop___stf_exit_barrier_fixup;
> extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;
> +extern long __start___barrier_nospec_fixup, __stop___barrier_nospec_fixup;
> +extern long __start__btb_flush_fixup, __stop__btb_flush_fixup;
>
> #endif
>
> diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
> index 449bbb87c257..b57db9d09db9 100644
> - --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -292,10 +292,15 @@
> #define H_CPU_CHAR_L1D_FLUSH_ORI30 (1ull << 61) // IBM bit 2
> #define H_CPU_CHAR_L1D_FLUSH_TRIG2 (1ull << 60) // IBM bit 3
> #define H_CPU_CHAR_L1D_THREAD_PRIV (1ull << 59) // IBM bit 4
> +#define H_CPU_CHAR_BRANCH_HINTS_HONORED (1ull << 58) // IBM bit 5
> +#define H_CPU_CHAR_THREAD_RECONFIG_CTRL (1ull << 57) // IBM bit 6
> +#define H_CPU_CHAR_COUNT_CACHE_DISABLED (1ull << 56) // IBM bit 7
> +#define H_CPU_CHAR_BCCTR_FLUSH_ASSIST (1ull << 54) // IBM bit 9
>
> #define H_CPU_BEHAV_FAVOUR_SECURITY (1ull << 63) // IBM bit 0
> #define H_CPU_BEHAV_L1D_FLUSH_PR (1ull << 62) // IBM bit 1
> #define H_CPU_BEHAV_BNDS_CHK_SPEC_BAR (1ull << 61) // IBM bit 2
> +#define H_CPU_BEHAV_FLUSH_COUNT_CACHE (1ull << 58) // IBM bit 5
>
> #ifndef __ASSEMBLY__
> #include <linux/types.h>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 45e2aefece16..08e5df3395fa 100644
> - --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -199,8 +199,7 @@ struct paca_struct {
> */
> u64 exrfi[13] __aligned(0x80);
> void *rfi_flush_fallback_area;
> - - u64 l1d_flush_congruence;
> - - u64 l1d_flush_sets;
> + u64 l1d_flush_size;
> #endif
> };
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 7ab04fc59e24..faf1bb045dee 100644
> - --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -147,6 +147,7 @@
> #define PPC_INST_LWSYNC 0x7c2004ac
> #define PPC_INST_SYNC 0x7c0004ac
> #define PPC_INST_SYNC_MASK 0xfc0007fe
> +#define PPC_INST_ISYNC 0x4c00012c
> #define PPC_INST_LXVD2X 0x7c000698
> #define PPC_INST_MCRXR 0x7c000400
> #define PPC_INST_MCRXR_MASK 0xfc0007fe
> diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
> index 160bb2311bbb..d219816b3e19 100644
> - --- a/arch/powerpc/include/asm/ppc_asm.h
> +++ b/arch/powerpc/include/asm/ppc_asm.h
> @@ -821,4 +821,15 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,945)
> .long 0x2400004c /* rfid */
> #endif /* !CONFIG_PPC_BOOK3E */
> #endif /* __ASSEMBLY__ */
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +#define BTB_FLUSH(reg) \
> + lis reg,BUCSR_INIT@h; \
> + ori reg,reg,BUCSR_INIT@l; \
> + mtspr SPRN_BUCSR,reg; \
> + isync;
> +#else
> +#define BTB_FLUSH(reg)
> +#endif /* CONFIG_PPC_FSL_BOOK3E */
> +
> #endif /* _ASM_POWERPC_PPC_ASM_H */
> diff --git a/arch/powerpc/include/asm/security_features.h b/arch/powerpc/include/asm/security_features.h
> new file mode 100644
> index 000000000000..759597bf0fd8
> - --- /dev/null
> +++ b/arch/powerpc/include/asm/security_features.h
> @@ -0,0 +1,92 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Security related feature bit definitions.
> + *
> + * Copyright 2018, Michael Ellerman, IBM Corporation.
> + */
> +
> +#ifndef _ASM_POWERPC_SECURITY_FEATURES_H
> +#define _ASM_POWERPC_SECURITY_FEATURES_H
> +
> +
> +extern unsigned long powerpc_security_features;
> +extern bool rfi_flush;
> +
> +/* These are bit flags */
> +enum stf_barrier_type {
> + STF_BARRIER_NONE = 0x1,
> + STF_BARRIER_FALLBACK = 0x2,
> + STF_BARRIER_EIEIO = 0x4,
> + STF_BARRIER_SYNC_ORI = 0x8,
> +};
> +
> +void setup_stf_barrier(void);
> +void do_stf_barrier_fixups(enum stf_barrier_type types);
> +void setup_count_cache_flush(void);
> +
> +static inline void security_ftr_set(unsigned long feature)
> +{
> + powerpc_security_features |= feature;
> +}
> +
> +static inline void security_ftr_clear(unsigned long feature)
> +{
> + powerpc_security_features &= ~feature;
> +}
> +
> +static inline bool security_ftr_enabled(unsigned long feature)
> +{
> + return !!(powerpc_security_features & feature);
> +}
> +
> +
> +// Features indicating support for Spectre/Meltdown mitigations
> +
> +// The L1-D cache can be flushed with ori r30,r30,0
> +#define SEC_FTR_L1D_FLUSH_ORI30 0x0000000000000001ull
> +
> +// The L1-D cache can be flushed with mtspr 882,r0 (aka SPRN_TRIG2)
> +#define SEC_FTR_L1D_FLUSH_TRIG2 0x0000000000000002ull
> +
> +// ori r31,r31,0 acts as a speculation barrier
> +#define SEC_FTR_SPEC_BAR_ORI31 0x0000000000000004ull
> +
> +// Speculation past bctr is disabled
> +#define SEC_FTR_BCCTRL_SERIALISED 0x0000000000000008ull
> +
> +// Entries in L1-D are private to a SMT thread
> +#define SEC_FTR_L1D_THREAD_PRIV 0x0000000000000010ull
> +
> +// Indirect branch prediction cache disabled
> +#define SEC_FTR_COUNT_CACHE_DISABLED 0x0000000000000020ull
> +
> +// bcctr 2,0,0 triggers a hardware assisted count cache flush
> +#define SEC_FTR_BCCTR_FLUSH_ASSIST 0x0000000000000800ull
> +
> +
> +// Features indicating need for Spectre/Meltdown mitigations
> +
> +// The L1-D cache should be flushed on MSR[HV] 1->0 transition (hypervisor to guest)
> +#define SEC_FTR_L1D_FLUSH_HV 0x0000000000000040ull
> +
> +// The L1-D cache should be flushed on MSR[PR] 0->1 transition (kernel to userspace)
> +#define SEC_FTR_L1D_FLUSH_PR 0x0000000000000080ull
> +
> +// A speculation barrier should be used for bounds checks (Spectre variant 1)
> +#define SEC_FTR_BNDS_CHK_SPEC_BAR 0x0000000000000100ull
> +
> +// Firmware configuration indicates user favours security over performance
> +#define SEC_FTR_FAVOUR_SECURITY 0x0000000000000200ull
> +
> +// Software required to flush count cache on context switch
> +#define SEC_FTR_FLUSH_COUNT_CACHE 0x0000000000000400ull
> +
> +
> +// Features enabled by default
> +#define SEC_FTR_DEFAULT \
> + (SEC_FTR_L1D_FLUSH_HV | \
> + SEC_FTR_L1D_FLUSH_PR | \
> + SEC_FTR_BNDS_CHK_SPEC_BAR | \
> + SEC_FTR_FAVOUR_SECURITY)
> +
> +#endif /* _ASM_POWERPC_SECURITY_FEATURES_H */
> diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
> index 7916b56f2e60..d299479c770b 100644
> - --- a/arch/powerpc/include/asm/setup.h
> +++ b/arch/powerpc/include/asm/setup.h
> @@ -8,6 +8,7 @@ extern void ppc_printk_progress(char *s, unsigned short hex);
>
> extern unsigned int rtas_data;
> extern unsigned long long memory_limit;
> +extern bool init_mem_is_free;
> extern unsigned long klimit;
> extern void *zalloc_maybe_bootmem(size_t size, gfp_t mask);
>
> @@ -36,8 +37,28 @@ enum l1d_flush_type {
> L1D_FLUSH_MTTRIG = 0x8,
> };
>
> - -void __init setup_rfi_flush(enum l1d_flush_type, bool enable);
> +void setup_rfi_flush(enum l1d_flush_type, bool enable);
> void do_rfi_flush_fixups(enum l1d_flush_type types);
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> +void setup_barrier_nospec(void);
> +#else
> +static inline void setup_barrier_nospec(void) { };
> +#endif
> +void do_barrier_nospec_fixups(bool enable);
> +extern bool barrier_nospec_enabled;
> +
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> +void do_barrier_nospec_fixups_range(bool enable, void *start, void *end);
> +#else
> +static inline void do_barrier_nospec_fixups_range(bool enable, void *start, void *end) { };
> +#endif
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +void setup_spectre_v2(void);
> +#else
> +static inline void setup_spectre_v2(void) {};
> +#endif
> +void do_btb_flush_fixups(void);
>
> #endif /* !__ASSEMBLY__ */
>
> diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
> index 05f1389228d2..e51ce5a0e221 100644
> - --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -269,6 +269,7 @@ do { \
> __chk_user_ptr(ptr); \
> if (!is_kernel_addr((unsigned long)__gu_addr)) \
> might_fault(); \
> + barrier_nospec(); \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> (x) = (__typeof__(*(ptr)))__gu_val; \
> __gu_err; \
> @@ -283,6 +284,7 @@ do { \
> __chk_user_ptr(ptr); \
> if (!is_kernel_addr((unsigned long)__gu_addr)) \
> might_fault(); \
> + barrier_nospec(); \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> (x) = (__force __typeof__(*(ptr)))__gu_val; \
> __gu_err; \
> @@ -295,8 +297,10 @@ do { \
> unsigned long __gu_val = 0; \
> __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> might_fault(); \
> - - if (access_ok(VERIFY_READ, __gu_addr, (size))) \
> + if (access_ok(VERIFY_READ, __gu_addr, (size))) { \
> + barrier_nospec(); \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> + } \
> (x) = (__force __typeof__(*(ptr)))__gu_val; \
> __gu_err; \
> })
> @@ -307,6 +311,7 @@ do { \
> unsigned long __gu_val; \
> __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> __chk_user_ptr(ptr); \
> + barrier_nospec(); \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> (x) = (__force __typeof__(*(ptr)))__gu_val; \
> __gu_err; \
> @@ -323,8 +328,10 @@ extern unsigned long __copy_tofrom_user(void __user *to,
> static inline unsigned long copy_from_user(void *to,
> const void __user *from, unsigned long n)
> {
> - - if (likely(access_ok(VERIFY_READ, from, n)))
> + if (likely(access_ok(VERIFY_READ, from, n))) {
> + barrier_nospec();
> return __copy_tofrom_user((__force void __user *)to, from, n);
> + }
> memset(to, 0, n);
> return n;
> }
> @@ -359,21 +366,27 @@ static inline unsigned long __copy_from_user_inatomic(void *to,
>
> switch (n) {
> case 1:
> + barrier_nospec();
> __get_user_size(*(u8 *)to, from, 1, ret);
> break;
> case 2:
> + barrier_nospec();
> __get_user_size(*(u16 *)to, from, 2, ret);
> break;
> case 4:
> + barrier_nospec();
> __get_user_size(*(u32 *)to, from, 4, ret);
> break;
> case 8:
> + barrier_nospec();
> __get_user_size(*(u64 *)to, from, 8, ret);
> break;
> }
> if (ret == 0)
> return 0;
> }
> +
> + barrier_nospec();
> return __copy_tofrom_user((__force void __user *)to, from, n);
> }
>
> @@ -400,6 +413,7 @@ static inline unsigned long __copy_to_user_inatomic(void __user *to,
> if (ret == 0)
> return 0;
> }
> +
> return __copy_tofrom_user(to, (__force const void __user *)from, n);
> }
>
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index ba336930d448..22ed3c32fca8 100644
> - --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_power.o
> obj-$(CONFIG_PPC_BOOK3S_64) += mce.o mce_power.o
> obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
> obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o idle_book3e.o
> +obj-$(CONFIG_PPC_BARRIER_NOSPEC) += security.o
> obj-$(CONFIG_PPC64) += vdso64/
> obj-$(CONFIG_ALTIVEC) += vecemu.o
> obj-$(CONFIG_PPC_970_NAP) += idle_power4.o
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index d92705e3a0c1..de3c29c51503 100644
> - --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -245,8 +245,7 @@ int main(void)
> DEFINE(PACA_IN_MCE, offsetof(struct paca_struct, in_mce));
> DEFINE(PACA_RFI_FLUSH_FALLBACK_AREA, offsetof(struct paca_struct, rfi_flush_fallback_area));
> DEFINE(PACA_EXRFI, offsetof(struct paca_struct, exrfi));
> - - DEFINE(PACA_L1D_FLUSH_CONGRUENCE, offsetof(struct paca_struct, l1d_flush_congruence));
> - - DEFINE(PACA_L1D_FLUSH_SETS, offsetof(struct paca_struct, l1d_flush_sets));
> + DEFINE(PACA_L1D_FLUSH_SIZE, offsetof(struct paca_struct, l1d_flush_size));
> #endif
> DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
> DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 59be96917369..6d36a4fb4acf 100644
> - --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -25,6 +25,7 @@
> #include <asm/page.h>
> #include <asm/mmu.h>
> #include <asm/thread_info.h>
> +#include <asm/code-patching-asm.h>
> #include <asm/ppc_asm.h>
> #include <asm/asm-offsets.h>
> #include <asm/cputable.h>
> @@ -36,6 +37,7 @@
> #include <asm/hw_irq.h>
> #include <asm/context_tracking.h>
> #include <asm/tm.h>
> +#include <asm/barrier.h>
> #ifdef CONFIG_PPC_BOOK3S
> #include <asm/exception-64s.h>
> #else
> @@ -75,6 +77,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_TM)
> std r0,GPR0(r1)
> std r10,GPR1(r1)
> beq 2f /* if from kernel mode */
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +START_BTB_FLUSH_SECTION
> + BTB_FLUSH(r10)
> +END_BTB_FLUSH_SECTION
> +#endif
> ACCOUNT_CPU_USER_ENTRY(r10, r11)
> 2: std r2,GPR2(r1)
> std r3,GPR3(r1)
> @@ -177,6 +184,15 @@ system_call: /* label this so stack traces look sane */
> clrldi r8,r8,32
> 15:
> slwi r0,r0,4
> +
> + barrier_nospec_asm
> + /*
> + * Prevent the load of the handler below (based on the user-passed
> + * system call number) being speculatively executed until the test
> + * against NR_syscalls and branch to .Lsyscall_enosys above has
> + * committed.
> + */
> +
> ldx r12,r11,r0 /* Fetch system call handler [ptr] */
> mtctr r12
> bctrl /* Call handler */
> @@ -440,6 +456,57 @@ _GLOBAL(ret_from_kernel_thread)
> li r3,0
> b .Lsyscall_exit
>
> +#ifdef CONFIG_PPC_BOOK3S_64
> +
> +#define FLUSH_COUNT_CACHE \
> +1: nop; \
> + patch_site 1b, patch__call_flush_count_cache
> +
> +
> +#define BCCTR_FLUSH .long 0x4c400420
> +
> +.macro nops number
> + .rept \number
> + nop
> + .endr
> +.endm
> +
> +.balign 32
> +.global flush_count_cache
> +flush_count_cache:
> + /* Save LR into r9 */
> + mflr r9
> +
> + .rept 64
> + bl .+4
> + .endr
> + b 1f
> + nops 6
> +
> + .balign 32
> + /* Restore LR */
> +1: mtlr r9
> + li r9,0x7fff
> + mtctr r9
> +
> + BCCTR_FLUSH
> +
> +2: nop
> + patch_site 2b patch__flush_count_cache_return
> +
> + nops 3
> +
> + .rept 278
> + .balign 32
> + BCCTR_FLUSH
> + nops 7
> + .endr
> +
> + blr
> +#else
> +#define FLUSH_COUNT_CACHE
> +#endif /* CONFIG_PPC_BOOK3S_64 */
> +
> /*
> * This routine switches between two different tasks. The process
> * state of one is saved on its kernel stack. Then the state
> @@ -503,6 +570,8 @@ BEGIN_FTR_SECTION
> END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
> #endif
>
> + FLUSH_COUNT_CACHE
> +
> #ifdef CONFIG_SMP
> /* We need a sync somewhere here to make sure that if the
> * previous task gets rescheduled on another CPU, it sees all
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index 5cc93f0b52ca..48ec841ea1bf 100644
> - --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -295,7 +295,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> andi. r10,r11,MSR_PR; /* save stack pointer */ \
> beq 1f; /* branch around if supervisor */ \
> ld r1,PACAKSAVE(r13); /* get kernel stack coming from usr */\
> - -1: cmpdi cr1,r1,0; /* check if SP makes sense */ \
> +1: type##_BTB_FLUSH \
> + cmpdi cr1,r1,0; /* check if SP makes sense */ \
> bge- cr1,exc_##n##_bad_stack;/* bad stack (TODO: out of line) */ \
> mfspr r10,SPRN_##type##_SRR0; /* read SRR0 before touching stack */
>
> @@ -327,6 +328,30 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> #define SPRN_MC_SRR0 SPRN_MCSRR0
> #define SPRN_MC_SRR1 SPRN_MCSRR1
>
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +#define GEN_BTB_FLUSH \
> + START_BTB_FLUSH_SECTION \
> + beq 1f; \
> + BTB_FLUSH(r10) \
> + 1: \
> + END_BTB_FLUSH_SECTION
> +
> +#define CRIT_BTB_FLUSH \
> + START_BTB_FLUSH_SECTION \
> + BTB_FLUSH(r10) \
> + END_BTB_FLUSH_SECTION
> +
> +#define DBG_BTB_FLUSH CRIT_BTB_FLUSH
> +#define MC_BTB_FLUSH CRIT_BTB_FLUSH
> +#define GDBELL_BTB_FLUSH GEN_BTB_FLUSH
> +#else
> +#define GEN_BTB_FLUSH
> +#define CRIT_BTB_FLUSH
> +#define DBG_BTB_FLUSH
> +#define MC_BTB_FLUSH
> +#define GDBELL_BTB_FLUSH
> +#endif
> +
> #define NORMAL_EXCEPTION_PROLOG(n, intnum, addition) \
> EXCEPTION_PROLOG(n, intnum, GEN, addition##_GEN(n))
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 938a30fef031..10e7cec9553d 100644
> - --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -36,6 +36,7 @@ BEGIN_FTR_SECTION \
> END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) \
> mr r9,r13 ; \
> GET_PACA(r13) ; \
> + INTERRUPT_TO_KERNEL ; \
> mfspr r11,SPRN_SRR0 ; \
> 0:
>
> @@ -292,7 +293,9 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
> . = 0x900
> .globl decrementer_pSeries
> decrementer_pSeries:
> - - _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer, EXC_STD, SOFTEN_TEST_PR)
> + SET_SCRATCH0(r13)
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + b decrementer_ool
>
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> @@ -319,6 +322,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
> OPT_GET_SPR(r9, SPRN_PPR, CPU_FTR_HAS_PPR);
> HMT_MEDIUM;
> std r10,PACA_EXGEN+EX_R10(r13)
> + INTERRUPT_TO_KERNEL
> OPT_SAVE_REG_TO_PACA(PACA_EXGEN+EX_PPR, r9, CPU_FTR_HAS_PPR);
> mfcr r9
> KVMTEST(0xc00)
> @@ -607,6 +611,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
>
> .align 7
> /* moved from 0xe00 */
> + MASKABLE_EXCEPTION_OOL(0x900, decrementer)
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
> STD_EXCEPTION_HV_OOL(0xe22, h_instr_storage)
> @@ -1564,6 +1569,21 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> blr
> #endif
>
> + .balign 16
> + .globl stf_barrier_fallback
> +stf_barrier_fallback:
> + std r9,PACA_EXRFI+EX_R9(r13)
> + std r10,PACA_EXRFI+EX_R10(r13)
> + sync
> + ld r9,PACA_EXRFI+EX_R9(r13)
> + ld r10,PACA_EXRFI+EX_R10(r13)
> + ori 31,31,0
> + .rept 14
> + b 1f
> +1:
> + .endr
> + blr
> +
> .globl rfi_flush_fallback
> rfi_flush_fallback:
> SET_SCRATCH0(r13);
> @@ -1571,39 +1591,37 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> std r9,PACA_EXRFI+EX_R9(r13)
> std r10,PACA_EXRFI+EX_R10(r13)
> std r11,PACA_EXRFI+EX_R11(r13)
> - - std r12,PACA_EXRFI+EX_R12(r13)
> - - std r8,PACA_EXRFI+EX_R13(r13)
> mfctr r9
> ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
> - - ld r11,PACA_L1D_FLUSH_SETS(r13)
> - - ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
> - - /*
> - - * The load adresses are at staggered offsets within cachelines,
> - - * which suits some pipelines better (on others it should not
> - - * hurt).
> - - */
> - - addi r12,r12,8
> + ld r11,PACA_L1D_FLUSH_SIZE(r13)
> + srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
> mtctr r11
> DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
>
> /* order ld/st prior to dcbt stop all streams with flushing */
> sync
> - -1: li r8,0
> - - .rept 8 /* 8-way set associative */
> - - ldx r11,r10,r8
> - - add r8,r8,r12
> - - xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
> - - add r8,r8,r11 // Add 0, this creates a dependency on the ldx
> - - .endr
> - - addi r10,r10,128 /* 128 byte cache line */
> +
> + /*
> + * The load adresses are at staggered offsets within cachelines,
> + * which suits some pipelines better (on others it should not
> + * hurt).
> + */
> +1:
> + ld r11,(0x80 + 8)*0(r10)
> + ld r11,(0x80 + 8)*1(r10)
> + ld r11,(0x80 + 8)*2(r10)
> + ld r11,(0x80 + 8)*3(r10)
> + ld r11,(0x80 + 8)*4(r10)
> + ld r11,(0x80 + 8)*5(r10)
> + ld r11,(0x80 + 8)*6(r10)
> + ld r11,(0x80 + 8)*7(r10)
> + addi r10,r10,0x80*8
> bdnz 1b
>
> mtctr r9
> ld r9,PACA_EXRFI+EX_R9(r13)
> ld r10,PACA_EXRFI+EX_R10(r13)
> ld r11,PACA_EXRFI+EX_R11(r13)
> - - ld r12,PACA_EXRFI+EX_R12(r13)
> - - ld r8,PACA_EXRFI+EX_R13(r13)
> GET_SCRATCH0(r13);
> rfid
>
> @@ -1614,39 +1632,37 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> std r9,PACA_EXRFI+EX_R9(r13)
> std r10,PACA_EXRFI+EX_R10(r13)
> std r11,PACA_EXRFI+EX_R11(r13)
> - - std r12,PACA_EXRFI+EX_R12(r13)
> - - std r8,PACA_EXRFI+EX_R13(r13)
> mfctr r9
> ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
> - - ld r11,PACA_L1D_FLUSH_SETS(r13)
> - - ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
> - - /*
> - - * The load adresses are at staggered offsets within cachelines,
> - - * which suits some pipelines better (on others it should not
> - - * hurt).
> - - */
> - - addi r12,r12,8
> + ld r11,PACA_L1D_FLUSH_SIZE(r13)
> + srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
> mtctr r11
> DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
>
> /* order ld/st prior to dcbt stop all streams with flushing */
> sync
> - -1: li r8,0
> - - .rept 8 /* 8-way set associative */
> - - ldx r11,r10,r8
> - - add r8,r8,r12
> - - xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
> - - add r8,r8,r11 // Add 0, this creates a dependency on the ldx
> - - .endr
> - - addi r10,r10,128 /* 128 byte cache line */
> +
> + /*
> + * The load adresses are at staggered offsets within cachelines,
> + * which suits some pipelines better (on others it should not
> + * hurt).
> + */
> +1:
> + ld r11,(0x80 + 8)*0(r10)
> + ld r11,(0x80 + 8)*1(r10)
> + ld r11,(0x80 + 8)*2(r10)
> + ld r11,(0x80 + 8)*3(r10)
> + ld r11,(0x80 + 8)*4(r10)
> + ld r11,(0x80 + 8)*5(r10)
> + ld r11,(0x80 + 8)*6(r10)
> + ld r11,(0x80 + 8)*7(r10)
> + addi r10,r10,0x80*8
> bdnz 1b
>
> mtctr r9
> ld r9,PACA_EXRFI+EX_R9(r13)
> ld r10,PACA_EXRFI+EX_R10(r13)
> ld r11,PACA_EXRFI+EX_R11(r13)
> - - ld r12,PACA_EXRFI+EX_R12(r13)
> - - ld r8,PACA_EXRFI+EX_R13(r13)
> GET_SCRATCH0(r13);
> hrfid
>
> diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
> index 9547381b631a..ff009be97a42 100644
> - --- a/arch/powerpc/kernel/module.c
> +++ b/arch/powerpc/kernel/module.c
> @@ -67,7 +67,15 @@ int module_finalize(const Elf_Ehdr *hdr,
> do_feature_fixups(powerpc_firmware_features,
> (void *)sect->sh_addr,
> (void *)sect->sh_addr + sect->sh_size);
> - -#endif
> +#endif /* CONFIG_PPC64 */
> +
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> + sect = find_section(hdr, sechdrs, "__spec_barrier_fixup");
> + if (sect != NULL)
> + do_barrier_nospec_fixups_range(barrier_nospec_enabled,
> + (void *)sect->sh_addr,
> + (void *)sect->sh_addr + sect->sh_size);
> +#endif /* CONFIG_PPC_BARRIER_NOSPEC */
>
> sect = find_section(hdr, sechdrs, "__lwsync_fixup");
> if (sect != NULL)
> diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
> new file mode 100644
> index 000000000000..58f0602a92b9
> - --- /dev/null
> +++ b/arch/powerpc/kernel/security.c
> @@ -0,0 +1,433 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Security related flags and so on.
> +//
> +// Copyright 2018, Michael Ellerman, IBM Corporation.
> +
> +#include <linux/kernel.h>
> +#include <linux/debugfs.h>
> +#include <linux/device.h>
> +#include <linux/seq_buf.h>
> +
> +#include <asm/debug.h>
> +#include <asm/asm-prototypes.h>
> +#include <asm/code-patching.h>
> +#include <asm/security_features.h>
> +#include <asm/setup.h>
> +
> +
> +unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
> +
> +enum count_cache_flush_type {
> + COUNT_CACHE_FLUSH_NONE = 0x1,
> + COUNT_CACHE_FLUSH_SW = 0x2,
> + COUNT_CACHE_FLUSH_HW = 0x4,
> +};
> +static enum count_cache_flush_type count_cache_flush_type = COUNT_CACHE_FLUSH_NONE;
> +
> +bool barrier_nospec_enabled;
> +static bool no_nospec;
> +static bool btb_flush_enabled;
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +static bool no_spectrev2;
> +#endif
> +
> +static void enable_barrier_nospec(bool enable)
> +{
> + barrier_nospec_enabled = enable;
> + do_barrier_nospec_fixups(enable);
> +}
> +
> +void setup_barrier_nospec(void)
> +{
> + bool enable;
> +
> + /*
> + * It would make sense to check SEC_FTR_SPEC_BAR_ORI31 below as well.
> + * But there's a good reason not to. The two flags we check below are
> + * both are enabled by default in the kernel, so if the hcall is not
> + * functional they will be enabled.
> + * On a system where the host firmware has been updated (so the ori
> + * functions as a barrier), but on which the hypervisor (KVM/Qemu) has
> + * not been updated, we would like to enable the barrier. Dropping the
> + * check for SEC_FTR_SPEC_BAR_ORI31 achieves that. The only downside is
> + * we potentially enable the barrier on systems where the host firmware
> + * is not updated, but that's harmless as it's a no-op.
> + */
> + enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
> + security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR);
> +
> + if (!no_nospec)
> + enable_barrier_nospec(enable);
> +}
> +
> +static int __init handle_nospectre_v1(char *p)
> +{
> + no_nospec = true;
> +
> + return 0;
> +}
> +early_param("nospectre_v1", handle_nospectre_v1);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int barrier_nospec_set(void *data, u64 val)
> +{
> + switch (val) {
> + case 0:
> + case 1:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (!!val == !!barrier_nospec_enabled)
> + return 0;
> +
> + enable_barrier_nospec(!!val);
> +
> + return 0;
> +}
> +
> +static int barrier_nospec_get(void *data, u64 *val)
> +{
> + *val = barrier_nospec_enabled ? 1 : 0;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(fops_barrier_nospec,
> + barrier_nospec_get, barrier_nospec_set, "%llu\n");
> +
> +static __init int barrier_nospec_debugfs_init(void)
> +{
> + debugfs_create_file("barrier_nospec", 0600, powerpc_debugfs_root, NULL,
> + &fops_barrier_nospec);
> + return 0;
> +}
> +device_initcall(barrier_nospec_debugfs_init);
> +#endif /* CONFIG_DEBUG_FS */
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +static int __init handle_nospectre_v2(char *p)
> +{
> + no_spectrev2 = true;
> +
> + return 0;
> +}
> +early_param("nospectre_v2", handle_nospectre_v2);
> +void setup_spectre_v2(void)
> +{
> + if (no_spectrev2)
> + do_btb_flush_fixups();
> + else
> + btb_flush_enabled = true;
> +}
> +#endif /* CONFIG_PPC_FSL_BOOK3E */
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
> +ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + bool thread_priv;
> +
> + thread_priv = security_ftr_enabled(SEC_FTR_L1D_THREAD_PRIV);
> +
> + if (rfi_flush || thread_priv) {
> + struct seq_buf s;
> + seq_buf_init(&s, buf, PAGE_SIZE - 1);
> +
> + seq_buf_printf(&s, "Mitigation: ");
> +
> + if (rfi_flush)
> + seq_buf_printf(&s, "RFI Flush");
> +
> + if (rfi_flush && thread_priv)
> + seq_buf_printf(&s, ", ");
> +
> + if (thread_priv)
> + seq_buf_printf(&s, "L1D private per thread");
> +
> + seq_buf_printf(&s, "\n");
> +
> + return s.len;
> + }
> +
> + if (!security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV) &&
> + !security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR))
> + return sprintf(buf, "Not affected\n");
> +
> + return sprintf(buf, "Vulnerable\n");
> +}
> +#endif
> +
> +ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct seq_buf s;
> +
> + seq_buf_init(&s, buf, PAGE_SIZE - 1);
> +
> + if (security_ftr_enabled(SEC_FTR_BNDS_CHK_SPEC_BAR)) {
> + if (barrier_nospec_enabled)
> + seq_buf_printf(&s, "Mitigation: __user pointer sanitization");
> + else
> + seq_buf_printf(&s, "Vulnerable");
> +
> + if (security_ftr_enabled(SEC_FTR_SPEC_BAR_ORI31))
> + seq_buf_printf(&s, ", ori31 speculation barrier enabled");
> +
> + seq_buf_printf(&s, "\n");
> + } else
> + seq_buf_printf(&s, "Not affected\n");
> +
> + return s.len;
> +}
> +
> +ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + struct seq_buf s;
> + bool bcs, ccd;
> +
> + seq_buf_init(&s, buf, PAGE_SIZE - 1);
> +
> + bcs = security_ftr_enabled(SEC_FTR_BCCTRL_SERIALISED);
> + ccd = security_ftr_enabled(SEC_FTR_COUNT_CACHE_DISABLED);
> +
> + if (bcs || ccd) {
> + seq_buf_printf(&s, "Mitigation: ");
> +
> + if (bcs)
> + seq_buf_printf(&s, "Indirect branch serialisation (kernel only)");
> +
> + if (bcs && ccd)
> + seq_buf_printf(&s, ", ");
> +
> + if (ccd)
> + seq_buf_printf(&s, "Indirect branch cache disabled");
> + } else if (count_cache_flush_type != COUNT_CACHE_FLUSH_NONE) {
> + seq_buf_printf(&s, "Mitigation: Software count cache flush");
> +
> + if (count_cache_flush_type == COUNT_CACHE_FLUSH_HW)
> + seq_buf_printf(&s, " (hardware accelerated)");
> + } else if (btb_flush_enabled) {
> + seq_buf_printf(&s, "Mitigation: Branch predictor state flush");
> + } else {
> + seq_buf_printf(&s, "Vulnerable");
> + }
> +
> + seq_buf_printf(&s, "\n");
> +
> + return s.len;
> +}
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * Store-forwarding barrier support.
> + */
> +
> +static enum stf_barrier_type stf_enabled_flush_types;
> +static bool no_stf_barrier;
> +bool stf_barrier;
> +
> +static int __init handle_no_stf_barrier(char *p)
> +{
> + pr_info("stf-barrier: disabled on command line.");
> + no_stf_barrier = true;
> + return 0;
> +}
> +
> +early_param("no_stf_barrier", handle_no_stf_barrier);
> +
> +/* This is the generic flag used by other architectures */
> +static int __init handle_ssbd(char *p)
> +{
> + if (!p || strncmp(p, "auto", 5) == 0 || strncmp(p, "on", 2) == 0 ) {
> + /* Until firmware tells us, we have the barrier with auto */
> + return 0;
> + } else if (strncmp(p, "off", 3) == 0) {
> + handle_no_stf_barrier(NULL);
> + return 0;
> + } else
> + return 1;
> +
> + return 0;
> +}
> +early_param("spec_store_bypass_disable", handle_ssbd);
> +
> +/* This is the generic flag used by other architectures */
> +static int __init handle_no_ssbd(char *p)
> +{
> + handle_no_stf_barrier(NULL);
> + return 0;
> +}
> +early_param("nospec_store_bypass_disable", handle_no_ssbd);
> +
> +static void stf_barrier_enable(bool enable)
> +{
> + if (enable)
> + do_stf_barrier_fixups(stf_enabled_flush_types);
> + else
> + do_stf_barrier_fixups(STF_BARRIER_NONE);
> +
> + stf_barrier = enable;
> +}
> +
> +void setup_stf_barrier(void)
> +{
> + enum stf_barrier_type type;
> + bool enable, hv;
> +
> + hv = cpu_has_feature(CPU_FTR_HVMODE);
> +
> + /* Default to fallback in case fw-features are not available */
> + if (cpu_has_feature(CPU_FTR_ARCH_207S))
> + type = STF_BARRIER_SYNC_ORI;
> + else if (cpu_has_feature(CPU_FTR_ARCH_206))
> + type = STF_BARRIER_FALLBACK;
> + else
> + type = STF_BARRIER_NONE;
> +
> + enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) &&
> + (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) ||
> + (security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV) && hv));
> +
> + if (type == STF_BARRIER_FALLBACK) {
> + pr_info("stf-barrier: fallback barrier available\n");
> + } else if (type == STF_BARRIER_SYNC_ORI) {
> + pr_info("stf-barrier: hwsync barrier available\n");
> + } else if (type == STF_BARRIER_EIEIO) {
> + pr_info("stf-barrier: eieio barrier available\n");
> + }
> +
> + stf_enabled_flush_types = type;
> +
> + if (!no_stf_barrier)
> + stf_barrier_enable(enable);
> +}
> +
> +ssize_t cpu_show_spec_store_bypass(struct device *dev, struct device_attribute *attr, char *buf)
> +{
> + if (stf_barrier && stf_enabled_flush_types != STF_BARRIER_NONE) {
> + const char *type;
> + switch (stf_enabled_flush_types) {
> + case STF_BARRIER_EIEIO:
> + type = "eieio";
> + break;
> + case STF_BARRIER_SYNC_ORI:
> + type = "hwsync";
> + break;
> + case STF_BARRIER_FALLBACK:
> + type = "fallback";
> + break;
> + default:
> + type = "unknown";
> + }
> + return sprintf(buf, "Mitigation: Kernel entry/exit barrier (%s)\n", type);
> + }
> +
> + if (!security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV) &&
> + !security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR))
> + return sprintf(buf, "Not affected\n");
> +
> + return sprintf(buf, "Vulnerable\n");
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int stf_barrier_set(void *data, u64 val)
> +{
> + bool enable;
> +
> + if (val == 1)
> + enable = true;
> + else if (val == 0)
> + enable = false;
> + else
> + return -EINVAL;
> +
> + /* Only do anything if we're changing state */
> + if (enable != stf_barrier)
> + stf_barrier_enable(enable);
> +
> + return 0;
> +}
> +
> +static int stf_barrier_get(void *data, u64 *val)
> +{
> + *val = stf_barrier ? 1 : 0;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(fops_stf_barrier, stf_barrier_get, stf_barrier_set, "%llu\n");
> +
> +static __init int stf_barrier_debugfs_init(void)
> +{
> + debugfs_create_file("stf_barrier", 0600, powerpc_debugfs_root, NULL, &fops_stf_barrier);
> + return 0;
> +}
> +device_initcall(stf_barrier_debugfs_init);
> +#endif /* CONFIG_DEBUG_FS */
> +
> +static void toggle_count_cache_flush(bool enable)
> +{
> + if (!enable || !security_ftr_enabled(SEC_FTR_FLUSH_COUNT_CACHE)) {
> + patch_instruction_site(&patch__call_flush_count_cache, PPC_INST_NOP);
> + count_cache_flush_type = COUNT_CACHE_FLUSH_NONE;
> + pr_info("count-cache-flush: software flush disabled.\n");
> + return;
> + }
> +
> + patch_branch_site(&patch__call_flush_count_cache,
> + (u64)&flush_count_cache, BRANCH_SET_LINK);
> +
> + if (!security_ftr_enabled(SEC_FTR_BCCTR_FLUSH_ASSIST)) {
> + count_cache_flush_type = COUNT_CACHE_FLUSH_SW;
> + pr_info("count-cache-flush: full software flush sequence enabled.\n");
> + return;
> + }
> +
> + patch_instruction_site(&patch__flush_count_cache_return, PPC_INST_BLR);
> + count_cache_flush_type = COUNT_CACHE_FLUSH_HW;
> + pr_info("count-cache-flush: hardware assisted flush sequence enabled\n");
> +}
> +
> +void setup_count_cache_flush(void)
> +{
> + toggle_count_cache_flush(true);
> +}
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int count_cache_flush_set(void *data, u64 val)
> +{
> + bool enable;
> +
> + if (val == 1)
> + enable = true;
> + else if (val == 0)
> + enable = false;
> + else
> + return -EINVAL;
> +
> + toggle_count_cache_flush(enable);
> +
> + return 0;
> +}
> +
> +static int count_cache_flush_get(void *data, u64 *val)
> +{
> + if (count_cache_flush_type == COUNT_CACHE_FLUSH_NONE)
> + *val = 0;
> + else
> + *val = 1;
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(fops_count_cache_flush, count_cache_flush_get,
> + count_cache_flush_set, "%llu\n");
> +
> +static __init int count_cache_flush_debugfs_init(void)
> +{
> + debugfs_create_file("count_cache_flush", 0600, powerpc_debugfs_root,
> + NULL, &fops_count_cache_flush);
> + return 0;
> +}
> +device_initcall(count_cache_flush_debugfs_init);
> +#endif /* CONFIG_DEBUG_FS */
> +#endif /* CONFIG_PPC_BOOK3S_64 */
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index ad8c9db61237..5a9f035bcd6b 100644
> - --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -322,6 +322,8 @@ void __init setup_arch(char **cmdline_p)
> ppc_md.setup_arch();
> if ( ppc_md.progress ) ppc_md.progress("arch: exit", 0x3eab);
>
> + setup_barrier_nospec();
> +
> paging_init();
>
> /* Initialize the MMU context management stuff */
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 9eb469bed22b..6bb731ababc6 100644
> - --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -736,6 +736,8 @@ void __init setup_arch(char **cmdline_p)
> if (ppc_md.setup_arch)
> ppc_md.setup_arch();
>
> + setup_barrier_nospec();
> +
> paging_init();
>
> /* Initialize the MMU context management stuff */
> @@ -873,9 +875,6 @@ static void do_nothing(void *unused)
>
> void rfi_flush_enable(bool enable)
> {
> - - if (rfi_flush == enable)
> - - return;
> - -
> if (enable) {
> do_rfi_flush_fixups(enabled_flush_types);
> on_each_cpu(do_nothing, NULL, 1);
> @@ -885,11 +884,15 @@ void rfi_flush_enable(bool enable)
> rfi_flush = enable;
> }
>
> - -static void init_fallback_flush(void)
> +static void __ref init_fallback_flush(void)
> {
> u64 l1d_size, limit;
> int cpu;
>
> + /* Only allocate the fallback flush area once (at boot time). */
> + if (l1d_flush_fallback_area)
> + return;
> +
> l1d_size = ppc64_caches.dsize;
> limit = min(safe_stack_limit(), ppc64_rma_size);
>
> @@ -902,34 +905,23 @@ static void init_fallback_flush(void)
> memset(l1d_flush_fallback_area, 0, l1d_size * 2);
>
> for_each_possible_cpu(cpu) {
> - - /*
> - - * The fallback flush is currently coded for 8-way
> - - * associativity. Different associativity is possible, but it
> - - * will be treated as 8-way and may not evict the lines as
> - - * effectively.
> - - *
> - - * 128 byte lines are mandatory.
> - - */
> - - u64 c = l1d_size / 8;
> - -
> paca[cpu].rfi_flush_fallback_area = l1d_flush_fallback_area;
> - - paca[cpu].l1d_flush_congruence = c;
> - - paca[cpu].l1d_flush_sets = c / 128;
> + paca[cpu].l1d_flush_size = l1d_size;
> }
> }
>
> - -void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
> +void setup_rfi_flush(enum l1d_flush_type types, bool enable)
> {
> if (types & L1D_FLUSH_FALLBACK) {
> - - pr_info("rfi-flush: Using fallback displacement flush\n");
> + pr_info("rfi-flush: fallback displacement flush available\n");
> init_fallback_flush();
> }
>
> if (types & L1D_FLUSH_ORI)
> - - pr_info("rfi-flush: Using ori type flush\n");
> + pr_info("rfi-flush: ori type flush available\n");
>
> if (types & L1D_FLUSH_MTTRIG)
> - - pr_info("rfi-flush: Using mttrig type flush\n");
> + pr_info("rfi-flush: mttrig type flush available\n");
>
> enabled_flush_types = types;
>
> @@ -940,13 +932,19 @@ void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
> #ifdef CONFIG_DEBUG_FS
> static int rfi_flush_set(void *data, u64 val)
> {
> + bool enable;
> +
> if (val == 1)
> - - rfi_flush_enable(true);
> + enable = true;
> else if (val == 0)
> - - rfi_flush_enable(false);
> + enable = false;
> else
> return -EINVAL;
>
> + /* Only do anything if we're changing state */
> + if (enable != rfi_flush)
> + rfi_flush_enable(enable);
> +
> return 0;
> }
>
> @@ -965,12 +963,4 @@ static __init int rfi_flush_debugfs_init(void)
> }
> device_initcall(rfi_flush_debugfs_init);
> #endif
> - -
> - -ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
> - -{
> - - if (rfi_flush)
> - - return sprintf(buf, "Mitigation: RFI Flush\n");
> - -
> - - return sprintf(buf, "Vulnerable\n");
> - -}
> #endif /* CONFIG_PPC_BOOK3S_64 */
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
> index 072a23a17350..876ac9d52afc 100644
> - --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -73,14 +73,45 @@ SECTIONS
> RODATA
>
> #ifdef CONFIG_PPC64
> + . = ALIGN(8);
> + __stf_entry_barrier_fixup : AT(ADDR(__stf_entry_barrier_fixup) - LOAD_OFFSET) {
> + __start___stf_entry_barrier_fixup = .;
> + *(__stf_entry_barrier_fixup)
> + __stop___stf_entry_barrier_fixup = .;
> + }
> +
> + . = ALIGN(8);
> + __stf_exit_barrier_fixup : AT(ADDR(__stf_exit_barrier_fixup) - LOAD_OFFSET) {
> + __start___stf_exit_barrier_fixup = .;
> + *(__stf_exit_barrier_fixup)
> + __stop___stf_exit_barrier_fixup = .;
> + }
> +
> . = ALIGN(8);
> __rfi_flush_fixup : AT(ADDR(__rfi_flush_fixup) - LOAD_OFFSET) {
> __start___rfi_flush_fixup = .;
> *(__rfi_flush_fixup)
> __stop___rfi_flush_fixup = .;
> }
> - -#endif
> +#endif /* CONFIG_PPC64 */
>
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> + . = ALIGN(8);
> + __spec_barrier_fixup : AT(ADDR(__spec_barrier_fixup) - LOAD_OFFSET) {
> + __start___barrier_nospec_fixup = .;
> + *(__barrier_nospec_fixup)
> + __stop___barrier_nospec_fixup = .;
> + }
> +#endif /* CONFIG_PPC_BARRIER_NOSPEC */
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> + . = ALIGN(8);
> + __spec_btb_flush_fixup : AT(ADDR(__spec_btb_flush_fixup) - LOAD_OFFSET) {
> + __start__btb_flush_fixup = .;
> + *(__btb_flush_fixup)
> + __stop__btb_flush_fixup = .;
> + }
> +#endif
> EXCEPTION_TABLE(0)
>
> NOTES :kernel :notes
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index d5edbeb8eb82..570c06a00db6 100644
> - --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -14,12 +14,25 @@
> #include <asm/page.h>
> #include <asm/code-patching.h>
> #include <asm/uaccess.h>
> +#include <asm/setup.h>
> +#include <asm/sections.h>
>
>
> +static inline bool is_init(unsigned int *addr)
> +{
> + return addr >= (unsigned int *)__init_begin && addr < (unsigned int *)__init_end;
> +}
> +
> int patch_instruction(unsigned int *addr, unsigned int instr)
> {
> int err;
>
> + /* Make sure we aren't patching a freed init section */
> + if (init_mem_is_free && is_init(addr)) {
> + pr_debug("Skipping init section patching addr: 0x%px\n", addr);
> + return 0;
> + }
> +
> __put_user_size(instr, addr, 4, err);
> if (err)
> return err;
> @@ -32,6 +45,22 @@ int patch_branch(unsigned int *addr, unsigned long target, int flags)
> return patch_instruction(addr, create_branch(addr, target, flags));
> }
>
> +int patch_branch_site(s32 *site, unsigned long target, int flags)
> +{
> + unsigned int *addr;
> +
> + addr = (unsigned int *)((unsigned long)site + *site);
> + return patch_instruction(addr, create_branch(addr, target, flags));
> +}
> +
> +int patch_instruction_site(s32 *site, unsigned int instr)
> +{
> + unsigned int *addr;
> +
> + addr = (unsigned int *)((unsigned long)site + *site);
> + return patch_instruction(addr, instr);
> +}
> +
> unsigned int create_branch(const unsigned int *addr,
> unsigned long target, int flags)
> {
> diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
> index 3af014684872..7bdfc19a491d 100644
> - --- a/arch/powerpc/lib/feature-fixups.c
> +++ b/arch/powerpc/lib/feature-fixups.c
> @@ -21,7 +21,7 @@
> #include <asm/page.h>
> #include <asm/sections.h>
> #include <asm/setup.h>
> - -
> +#include <asm/security_features.h>
>
> struct fixup_entry {
> unsigned long mask;
> @@ -115,6 +115,120 @@ void do_feature_fixups(unsigned long value, void *fixup_start, void *fixup_end)
> }
>
> #ifdef CONFIG_PPC_BOOK3S_64
> +void do_stf_entry_barrier_fixups(enum stf_barrier_type types)
> +{
> + unsigned int instrs[3], *dest;
> + long *start, *end;
> + int i;
> +
> + start = PTRRELOC(&__start___stf_entry_barrier_fixup),
> + end = PTRRELOC(&__stop___stf_entry_barrier_fixup);
> +
> + instrs[0] = 0x60000000; /* nop */
> + instrs[1] = 0x60000000; /* nop */
> + instrs[2] = 0x60000000; /* nop */
> +
> + i = 0;
> + if (types & STF_BARRIER_FALLBACK) {
> + instrs[i++] = 0x7d4802a6; /* mflr r10 */
> + instrs[i++] = 0x60000000; /* branch patched below */
> + instrs[i++] = 0x7d4803a6; /* mtlr r10 */
> + } else if (types & STF_BARRIER_EIEIO) {
> + instrs[i++] = 0x7e0006ac; /* eieio + bit 6 hint */
> + } else if (types & STF_BARRIER_SYNC_ORI) {
> + instrs[i++] = 0x7c0004ac; /* hwsync */
> + instrs[i++] = 0xe94d0000; /* ld r10,0(r13) */
> + instrs[i++] = 0x63ff0000; /* ori 31,31,0 speculation barrier */
> + }
> +
> + for (i = 0; start < end; start++, i++) {
> + dest = (void *)start + *start;
> +
> + pr_devel("patching dest %lx\n", (unsigned long)dest);
> +
> + patch_instruction(dest, instrs[0]);
> +
> + if (types & STF_BARRIER_FALLBACK)
> + patch_branch(dest + 1, (unsigned long)&stf_barrier_fallback,
> + BRANCH_SET_LINK);
> + else
> + patch_instruction(dest + 1, instrs[1]);
> +
> + patch_instruction(dest + 2, instrs[2]);
> + }
> +
> + printk(KERN_DEBUG "stf-barrier: patched %d entry locations (%s barrier)\n", i,
> + (types == STF_BARRIER_NONE) ? "no" :
> + (types == STF_BARRIER_FALLBACK) ? "fallback" :
> + (types == STF_BARRIER_EIEIO) ? "eieio" :
> + (types == (STF_BARRIER_SYNC_ORI)) ? "hwsync"
> + : "unknown");
> +}
> +
> +void do_stf_exit_barrier_fixups(enum stf_barrier_type types)
> +{
> + unsigned int instrs[6], *dest;
> + long *start, *end;
> + int i;
> +
> + start = PTRRELOC(&__start___stf_exit_barrier_fixup),
> + end = PTRRELOC(&__stop___stf_exit_barrier_fixup);
> +
> + instrs[0] = 0x60000000; /* nop */
> + instrs[1] = 0x60000000; /* nop */
> + instrs[2] = 0x60000000; /* nop */
> + instrs[3] = 0x60000000; /* nop */
> + instrs[4] = 0x60000000; /* nop */
> + instrs[5] = 0x60000000; /* nop */
> +
> + i = 0;
> + if (types & STF_BARRIER_FALLBACK || types & STF_BARRIER_SYNC_ORI) {
> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
> + instrs[i++] = 0x7db14ba6; /* mtspr 0x131, r13 (HSPRG1) */
> + instrs[i++] = 0x7db04aa6; /* mfspr r13, 0x130 (HSPRG0) */
> + } else {
> + instrs[i++] = 0x7db243a6; /* mtsprg 2,r13 */
> + instrs[i++] = 0x7db142a6; /* mfsprg r13,1 */
> + }
> + instrs[i++] = 0x7c0004ac; /* hwsync */
> + instrs[i++] = 0xe9ad0000; /* ld r13,0(r13) */
> + instrs[i++] = 0x63ff0000; /* ori 31,31,0 speculation barrier */
> + if (cpu_has_feature(CPU_FTR_HVMODE)) {
> + instrs[i++] = 0x7db14aa6; /* mfspr r13, 0x131 (HSPRG1) */
> + } else {
> + instrs[i++] = 0x7db242a6; /* mfsprg r13,2 */
> + }
> + } else if (types & STF_BARRIER_EIEIO) {
> + instrs[i++] = 0x7e0006ac; /* eieio + bit 6 hint */
> + }
> +
> + for (i = 0; start < end; start++, i++) {
> + dest = (void *)start + *start;
> +
> + pr_devel("patching dest %lx\n", (unsigned long)dest);
> +
> + patch_instruction(dest, instrs[0]);
> + patch_instruction(dest + 1, instrs[1]);
> + patch_instruction(dest + 2, instrs[2]);
> + patch_instruction(dest + 3, instrs[3]);
> + patch_instruction(dest + 4, instrs[4]);
> + patch_instruction(dest + 5, instrs[5]);
> + }
> + printk(KERN_DEBUG "stf-barrier: patched %d exit locations (%s barrier)\n", i,
> + (types == STF_BARRIER_NONE) ? "no" :
> + (types == STF_BARRIER_FALLBACK) ? "fallback" :
> + (types == STF_BARRIER_EIEIO) ? "eieio" :
> + (types == (STF_BARRIER_SYNC_ORI)) ? "hwsync"
> + : "unknown");
> +}
> +
> +
> +void do_stf_barrier_fixups(enum stf_barrier_type types)
> +{
> + do_stf_entry_barrier_fixups(types);
> + do_stf_exit_barrier_fixups(types);
> +}
> +
> void do_rfi_flush_fixups(enum l1d_flush_type types)
> {
> unsigned int instrs[3], *dest;
> @@ -151,10 +265,110 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
> patch_instruction(dest + 2, instrs[2]);
> }
>
> - - printk(KERN_DEBUG "rfi-flush: patched %d locations\n", i);
> + printk(KERN_DEBUG "rfi-flush: patched %d locations (%s flush)\n", i,
> + (types == L1D_FLUSH_NONE) ? "no" :
> + (types == L1D_FLUSH_FALLBACK) ? "fallback displacement" :
> + (types & L1D_FLUSH_ORI) ? (types & L1D_FLUSH_MTTRIG)
> + ? "ori+mttrig type"
> + : "ori type" :
> + (types & L1D_FLUSH_MTTRIG) ? "mttrig type"
> + : "unknown");
> +}
> +
> +void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void *fixup_end)
> +{
> + unsigned int instr, *dest;
> + long *start, *end;
> + int i;
> +
> + start = fixup_start;
> + end = fixup_end;
> +
> + instr = 0x60000000; /* nop */
> +
> + if (enable) {
> + pr_info("barrier-nospec: using ORI speculation barrier\n");
> + instr = 0x63ff0000; /* ori 31,31,0 speculation barrier */
> + }
> +
> + for (i = 0; start < end; start++, i++) {
> + dest = (void *)start + *start;
> +
> + pr_devel("patching dest %lx\n", (unsigned long)dest);
> + patch_instruction(dest, instr);
> + }
> +
> + printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
> }
> +
> #endif /* CONFIG_PPC_BOOK3S_64 */
>
> +#ifdef CONFIG_PPC_BARRIER_NOSPEC
> +void do_barrier_nospec_fixups(bool enable)
> +{
> + void *start, *end;
> +
> + start = PTRRELOC(&__start___barrier_nospec_fixup),
> + end = PTRRELOC(&__stop___barrier_nospec_fixup);
> +
> + do_barrier_nospec_fixups_range(enable, start, end);
> +}
> +#endif /* CONFIG_PPC_BARRIER_NOSPEC */
> +
> +#ifdef CONFIG_PPC_FSL_BOOK3E
> +void do_barrier_nospec_fixups_range(bool enable, void *fixup_start, void *fixup_end)
> +{
> + unsigned int instr[2], *dest;
> + long *start, *end;
> + int i;
> +
> + start = fixup_start;
> + end = fixup_end;
> +
> + instr[0] = PPC_INST_NOP;
> + instr[1] = PPC_INST_NOP;
> +
> + if (enable) {
> + pr_info("barrier-nospec: using isync; sync as speculation barrier\n");
> + instr[0] = PPC_INST_ISYNC;
> + instr[1] = PPC_INST_SYNC;
> + }
> +
> + for (i = 0; start < end; start++, i++) {
> + dest = (void *)start + *start;
> +
> + pr_devel("patching dest %lx\n", (unsigned long)dest);
> + patch_instruction(dest, instr[0]);
> + patch_instruction(dest + 1, instr[1]);
> + }
> +
> + printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
> +}
> +
> +static void patch_btb_flush_section(long *curr)
> +{
> + unsigned int *start, *end;
> +
> + start = (void *)curr + *curr;
> + end = (void *)curr + *(curr + 1);
> + for (; start < end; start++) {
> + pr_devel("patching dest %lx\n", (unsigned long)start);
> + patch_instruction(start, PPC_INST_NOP);
> + }
> +}
> +
> +void do_btb_flush_fixups(void)
> +{
> + long *start, *end;
> +
> + start = PTRRELOC(&__start__btb_flush_fixup);
> + end = PTRRELOC(&__stop__btb_flush_fixup);
> +
> + for (; start < end; start += 2)
> + patch_btb_flush_section(start);
> +}
> +#endif /* CONFIG_PPC_FSL_BOOK3E */
> +
> void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
> {
> long *start, *end;
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 22d94c3e6fc4..1efe5ca5c3bc 100644
> - --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -62,6 +62,7 @@
> #endif
>
> unsigned long long memory_limit;
> +bool init_mem_is_free;
>
> #ifdef CONFIG_HIGHMEM
> pte_t *kmap_pte;
> @@ -381,6 +382,7 @@ void __init mem_init(void)
> void free_initmem(void)
> {
> ppc_md.progress = ppc_printk_progress;
> + init_mem_is_free = true;
> free_initmem_default(POISON_FREE_INITMEM);
> }
>
> diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
> index 29d6987c37ba..5486d56da289 100644
> - --- a/arch/powerpc/mm/tlb_low_64e.S
> +++ b/arch/powerpc/mm/tlb_low_64e.S
> @@ -69,6 +69,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> std r15,EX_TLB_R15(r12)
> std r10,EX_TLB_CR(r12)
> #ifdef CONFIG_PPC_FSL_BOOK3E
> +START_BTB_FLUSH_SECTION
> + mfspr r11, SPRN_SRR1
> + andi. r10,r11,MSR_PR
> + beq 1f
> + BTB_FLUSH(r10)
> +1:
> +END_BTB_FLUSH_SECTION
> std r7,EX_TLB_R7(r12)
> #endif
> TLB_MISS_PROLOG_STATS
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index c57afc619b20..e14b52c7ebd8 100644
> - --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -37,53 +37,99 @@
> #include <asm/smp.h>
> #include <asm/tm.h>
> #include <asm/setup.h>
> +#include <asm/security_features.h>
>
> #include "powernv.h"
>
> +
> +static bool fw_feature_is(const char *state, const char *name,
> + struct device_node *fw_features)
> +{
> + struct device_node *np;
> + bool rc = false;
> +
> + np = of_get_child_by_name(fw_features, name);
> + if (np) {
> + rc = of_property_read_bool(np, state);
> + of_node_put(np);
> + }
> +
> + return rc;
> +}
> +
> +static void init_fw_feat_flags(struct device_node *np)
> +{
> + if (fw_feature_is("enabled", "inst-spec-barrier-ori31,31,0", np))
> + security_ftr_set(SEC_FTR_SPEC_BAR_ORI31);
> +
> + if (fw_feature_is("enabled", "fw-bcctrl-serialized", np))
> + security_ftr_set(SEC_FTR_BCCTRL_SERIALISED);
> +
> + if (fw_feature_is("enabled", "inst-l1d-flush-ori30,30,0", np))
> + security_ftr_set(SEC_FTR_L1D_FLUSH_ORI30);
> +
> + if (fw_feature_is("enabled", "inst-l1d-flush-trig2", np))
> + security_ftr_set(SEC_FTR_L1D_FLUSH_TRIG2);
> +
> + if (fw_feature_is("enabled", "fw-l1d-thread-split", np))
> + security_ftr_set(SEC_FTR_L1D_THREAD_PRIV);
> +
> + if (fw_feature_is("enabled", "fw-count-cache-disabled", np))
> + security_ftr_set(SEC_FTR_COUNT_CACHE_DISABLED);
> +
> + if (fw_feature_is("enabled", "fw-count-cache-flush-bcctr2,0,0", np))
> + security_ftr_set(SEC_FTR_BCCTR_FLUSH_ASSIST);
> +
> + if (fw_feature_is("enabled", "needs-count-cache-flush-on-context-switch", np))
> + security_ftr_set(SEC_FTR_FLUSH_COUNT_CACHE);
> +
> + /*
> + * The features below are enabled by default, so we instead look to see
> + * if firmware has *disabled* them, and clear them if so.
> + */
> + if (fw_feature_is("disabled", "speculation-policy-favor-security", np))
> + security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
> +
> + if (fw_feature_is("disabled", "needs-l1d-flush-msr-pr-0-to-1", np))
> + security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
> +
> + if (fw_feature_is("disabled", "needs-l1d-flush-msr-hv-1-to-0", np))
> + security_ftr_clear(SEC_FTR_L1D_FLUSH_HV);
> +
> + if (fw_feature_is("disabled", "needs-spec-barrier-for-bound-checks", np))
> + security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
> +}
> +
> static void pnv_setup_rfi_flush(void)
> {
> struct device_node *np, *fw_features;
> enum l1d_flush_type type;
> - - int enable;
> + bool enable;
>
> /* Default to fallback in case fw-features are not available */
> type = L1D_FLUSH_FALLBACK;
> - - enable = 1;
>
> np = of_find_node_by_name(NULL, "ibm,opal");
> fw_features = of_get_child_by_name(np, "fw-features");
> of_node_put(np);
>
> if (fw_features) {
> - - np = of_get_child_by_name(fw_features, "inst-l1d-flush-trig2");
> - - if (np && of_property_read_bool(np, "enabled"))
> - - type = L1D_FLUSH_MTTRIG;
> + init_fw_feat_flags(fw_features);
> + of_node_put(fw_features);
>
> - - of_node_put(np);
> + if (security_ftr_enabled(SEC_FTR_L1D_FLUSH_TRIG2))
> + type = L1D_FLUSH_MTTRIG;
>
> - - np = of_get_child_by_name(fw_features, "inst-l1d-flush-ori30,30,0");
> - - if (np && of_property_read_bool(np, "enabled"))
> + if (security_ftr_enabled(SEC_FTR_L1D_FLUSH_ORI30))
> type = L1D_FLUSH_ORI;
> - -
> - - of_node_put(np);
> - -
> - - /* Enable unless firmware says NOT to */
> - - enable = 2;
> - - np = of_get_child_by_name(fw_features, "needs-l1d-flush-msr-hv-1-to-0");
> - - if (np && of_property_read_bool(np, "disabled"))
> - - enable--;
> - -
> - - of_node_put(np);
> - -
> - - np = of_get_child_by_name(fw_features, "needs-l1d-flush-msr-pr-0-to-1");
> - - if (np && of_property_read_bool(np, "disabled"))
> - - enable--;
> - -
> - - of_node_put(np);
> - - of_node_put(fw_features);
> }
>
> - - setup_rfi_flush(type, enable > 0);
> + enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \
> + (security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR) || \
> + security_ftr_enabled(SEC_FTR_L1D_FLUSH_HV));
> +
> + setup_rfi_flush(type, enable);
> + setup_count_cache_flush();
> }
>
> static void __init pnv_setup_arch(void)
> @@ -91,6 +137,7 @@ static void __init pnv_setup_arch(void)
> set_arch_panic_timeout(10, ARCH_PANIC_TIMEOUT);
>
> pnv_setup_rfi_flush();
> + setup_stf_barrier();
>
> /* Initialize SMP */
> pnv_smp_init();
> diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
> index 8dd0c8edefd6..c773396d0969 100644
> - --- a/arch/powerpc/platforms/pseries/mobility.c
> +++ b/arch/powerpc/platforms/pseries/mobility.c
> @@ -314,6 +314,9 @@ void post_mobility_fixup(void)
> printk(KERN_ERR "Post-mobility device tree update "
> "failed: %d\n", rc);
>
> + /* Possibly switch to a new RFI flush type */
> + pseries_setup_rfi_flush();
> +
> return;
> }
>
> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
> index 8411c27293e4..e7d80797384d 100644
> - --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -81,4 +81,6 @@ extern struct pci_controller_ops pseries_pci_controller_ops;
>
> unsigned long pseries_memory_block_size(void);
>
> +void pseries_setup_rfi_flush(void);
> +
> #endif /* _PSERIES_PSERIES_H */
> diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
> index dd2545fc9947..9cc976ff7fec 100644
> - --- a/arch/powerpc/platforms/pseries/setup.c
> +++ b/arch/powerpc/platforms/pseries/setup.c
> @@ -67,6 +67,7 @@
> #include <asm/eeh.h>
> #include <asm/reg.h>
> #include <asm/plpar_wrappers.h>
> +#include <asm/security_features.h>
>
> #include "pseries.h"
>
> @@ -499,37 +500,87 @@ static void __init find_and_init_phbs(void)
> of_pci_check_probe_only();
> }
>
> - -static void pseries_setup_rfi_flush(void)
> +static void init_cpu_char_feature_flags(struct h_cpu_char_result *result)
> +{
> + /*
> + * The features below are disabled by default, so we instead look to see
> + * if firmware has *enabled* them, and set them if so.
> + */
> + if (result->character & H_CPU_CHAR_SPEC_BAR_ORI31)
> + security_ftr_set(SEC_FTR_SPEC_BAR_ORI31);
> +
> + if (result->character & H_CPU_CHAR_BCCTRL_SERIALISED)
> + security_ftr_set(SEC_FTR_BCCTRL_SERIALISED);
> +
> + if (result->character & H_CPU_CHAR_L1D_FLUSH_ORI30)
> + security_ftr_set(SEC_FTR_L1D_FLUSH_ORI30);
> +
> + if (result->character & H_CPU_CHAR_L1D_FLUSH_TRIG2)
> + security_ftr_set(SEC_FTR_L1D_FLUSH_TRIG2);
> +
> + if (result->character & H_CPU_CHAR_L1D_THREAD_PRIV)
> + security_ftr_set(SEC_FTR_L1D_THREAD_PRIV);
> +
> + if (result->character & H_CPU_CHAR_COUNT_CACHE_DISABLED)
> + security_ftr_set(SEC_FTR_COUNT_CACHE_DISABLED);
> +
> + if (result->character & H_CPU_CHAR_BCCTR_FLUSH_ASSIST)
> + security_ftr_set(SEC_FTR_BCCTR_FLUSH_ASSIST);
> +
> + if (result->behaviour & H_CPU_BEHAV_FLUSH_COUNT_CACHE)
> + security_ftr_set(SEC_FTR_FLUSH_COUNT_CACHE);
> +
> + /*
> + * The features below are enabled by default, so we instead look to see
> + * if firmware has *disabled* them, and clear them if so.
> + */
> + if (!(result->behaviour & H_CPU_BEHAV_FAVOUR_SECURITY))
> + security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
> +
> + if (!(result->behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
> + security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
> +
> + if (!(result->behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
> + security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
> +}
> +
> +void pseries_setup_rfi_flush(void)
> {
> struct h_cpu_char_result result;
> enum l1d_flush_type types;
> bool enable;
> long rc;
>
> - - /* Enable by default */
> - - enable = true;
> + /*
> + * Set features to the defaults assumed by init_cpu_char_feature_flags()
> + * so it can set/clear again any features that might have changed after
> + * migration, and in case the hypercall fails and it is not even called.
> + */
> + powerpc_security_features = SEC_FTR_DEFAULT;
>
> rc = plpar_get_cpu_characteristics(&result);
> - - if (rc == H_SUCCESS) {
> - - types = L1D_FLUSH_NONE;
> + if (rc == H_SUCCESS)
> + init_cpu_char_feature_flags(&result);
>
> - - if (result.character & H_CPU_CHAR_L1D_FLUSH_TRIG2)
> - - types |= L1D_FLUSH_MTTRIG;
> - - if (result.character & H_CPU_CHAR_L1D_FLUSH_ORI30)
> - - types |= L1D_FLUSH_ORI;
> + /*
> + * We're the guest so this doesn't apply to us, clear it to simplify
> + * handling of it elsewhere.
> + */
> + security_ftr_clear(SEC_FTR_L1D_FLUSH_HV);
>
> - - /* Use fallback if nothing set in hcall */
> - - if (types == L1D_FLUSH_NONE)
> - - types = L1D_FLUSH_FALLBACK;
> + types = L1D_FLUSH_FALLBACK;
>
> - - if (!(result.behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
> - - enable = false;
> - - } else {
> - - /* Default to fallback if case hcall is not available */
> - - types = L1D_FLUSH_FALLBACK;
> - - }
> + if (security_ftr_enabled(SEC_FTR_L1D_FLUSH_TRIG2))
> + types |= L1D_FLUSH_MTTRIG;
> +
> + if (security_ftr_enabled(SEC_FTR_L1D_FLUSH_ORI30))
> + types |= L1D_FLUSH_ORI;
> +
> + enable = security_ftr_enabled(SEC_FTR_FAVOUR_SECURITY) && \
> + security_ftr_enabled(SEC_FTR_L1D_FLUSH_PR);
>
> setup_rfi_flush(types, enable);
> + setup_count_cache_flush();
> }
>
> static void __init pSeries_setup_arch(void)
> @@ -549,6 +600,7 @@ static void __init pSeries_setup_arch(void)
> fwnmi_init();
>
> pseries_setup_rfi_flush();
> + setup_stf_barrier();
>
> /* By default, only probe PCI (can be overridden by rtas_pci) */
> pci_add_flags(PCI_PROBE_ONLY);
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 786bf01691c9..83619ebede93 100644
> - --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -2144,6 +2144,8 @@ static void dump_one_paca(int cpu)
> DUMP(p, slb_cache_ptr, "x");
> for (i = 0; i < SLB_CACHE_ENTRIES; i++)
> printf(" slb_cache[%d]: = 0x%016lx\n", i, p->slb_cache[i]);
> +
> + DUMP(p, rfi_flush_fallback_area, "px");
> #endif
> DUMP(p, dscr_default, "llx");
> #ifdef CONFIG_PPC_BOOK3E
> - --
> 2.20.1
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBAgAGBQJcvHWhAAoJEFHr6jzI4aWA6nsP/0YskmAfLovcUmERQ7+bIjq6
> IcS1T466dvy6MlqeBXU4x8pVgInWeHKEC9XJdkM1lOeib/SLW7Hbz4kgJeOGwFGY
> lOTaexrxvsBqPm7f6GC0zbl9obEIIIIUs+TielFQANBgqm+q8Wio+XXPP9bpKeKY
> agSpQ3nwL/PYixznbNmN/lP9py5p89LQ0IBcR7dDBGGWJtD/AXeZ9hslsZxPbPtI
> nZJ0vdnjuoB2z+hCxfKWlYfLwH0VfoTpqP5x3ALCkvbBr67e8bf6EK8+trnvhyQ8
> iLY4bp1pm2epAI0/3NfyEiDMsGjVJ6IFlkyhDkHJgJNu0BGcGOSX2GpyU3juviAK
> c95FtBft/i8AwigOMCivg2mN5edYjsSiPoEItwT5KWqgByJsdr5i5mYVx8cUjMOz
> iAxLZCdg+UHZYuCBCAO2ZI1G9bVXI1Pa3btMspiCOOOsYGjXGf0oFfKQ+7957hUO
> ftYYJoGHlMHiHR1OPas6T3lk6YKF9uvfIDTE3OKw2obHbbRz3u82xoWMRGW503MN
> 7WpkpAP7oZ9RgqIWFVhatWy5f+7GFL0akEi4o2tsZHhYlPau7YWo+nToTd87itwt
> GBaWJipzge4s13VkhAE+jWFO35Fvwi8uNZ7UgpuKMBECEjkGbtzBTq2MjSF5G8wc
> yPEod5jby/Iqb7DkGPVG
> =6DnF
> -----END PGP SIGNATURE-----
>
^ permalink raw reply
* Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4
From: Diana Madalina Craciun @ 2019-04-22 15:27 UTC (permalink / raw)
To: Greg KH, Michael Ellerman
Cc: linuxppc-dev@ozlabs.org, msuchanek@suse.de, npiggin@gmail.com,
stable@vger.kernel.org
In-Reply-To: <20190421163421.GA8449@kroah.com>
On 4/21/2019 7:34 PM, Greg KH wrote:
> On Mon, Apr 22, 2019 at 12:19:45AM +1000, Michael Ellerman wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Greg/Sasha,
>>
>> Please queue up these powerpc patches for 4.4 if you have no objections.
> why? Do you, or someone else, really care about spectre issues in 4.4?
> Who is using ppc for 4.4 becides a specific enterprise distro (and they
> don't seem to be pulling in my stable updates anyway...)?
We (NXP) received questions from customers regarding Spectre mitigations
on kernel 4.4. Not sure if they really need them as some systems are
enclosed embedded ones, but they asked for them.
Thanks,
Diana
> I'll be glad to take these, just want to make sure that someone actually
> will use them :)
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* [PATCH v2 19/79] docs: kdump: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-04-22 13:27 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Rich Felker, linux-sh, Catalin Marinas, Will Deacon, Harry Wei,
Paul Mackerras, H. Peter Anvin, Mauro Carvalho Chehab, Alex Shi,
Yoshinori Sato, Jonathan Corbet, x86, Russell King, Ingo Molnar,
Dave Young, Guenter Roeck, linux-watchdog, Mauro Carvalho Chehab,
Borislav Petkov, Thomas Gleixner, Wim Van Sebroeck,
linux-arm-kernel, Baoquan He, kexec, linux-kernel, Vivek Goyal,
linuxppc-dev
In-Reply-To: <cover.1555938375.git.mchehab+samsung@kernel.org>
Convert kdump documentation to ReST and add it to the
user faced manual, as the documents are mainly focused on
sysadmins that would be enabling kdump.
Note: the vmcoreinfo.rst has one very long title on one of its
sub-sections:
PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask|PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
I opted to break this one, into two entries with the same content,
in order to make it easier to display after being parsed in html and PDF.
The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/admin-guide/bug-hunting.rst | 2 +-
.../admin-guide/kernel-parameters.txt | 6 +-
Documentation/kdump/index.rst | 21 +++
Documentation/kdump/{kdump.txt => kdump.rst} | 131 +++++++++++-------
.../kdump/{vmcoreinfo.txt => vmcoreinfo.rst} | 59 ++++----
.../powerpc/firmware-assisted-dump.txt | 2 +-
.../translations/zh_CN/oops-tracing.txt | 2 +-
Documentation/watchdog/hpwdt.txt | 2 +-
arch/arm/Kconfig | 2 +-
arch/arm64/Kconfig | 2 +-
arch/sh/Kconfig | 2 +-
arch/x86/Kconfig | 4 +-
12 files changed, 137 insertions(+), 98 deletions(-)
create mode 100644 Documentation/kdump/index.rst
rename Documentation/kdump/{kdump.txt => kdump.rst} (91%)
rename Documentation/kdump/{vmcoreinfo.txt => vmcoreinfo.rst} (95%)
diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
index f278b289e260..b761aa2a51d2 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -90,7 +90,7 @@ the disk is not available then you have three options:
run a null modem to a second machine and capture the output there
using your favourite communication program. Minicom works well.
-(3) Use Kdump (see Documentation/kdump/kdump.txt),
+(3) Use Kdump (see Documentation/kdump/kdump.rst),
extract the kernel ring buffer from old memory with using dmesg
gdbmacro in Documentation/kdump/gdbmacros.txt.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index bfe926a7b15f..a4e8e6435fff 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -705,14 +705,14 @@
memory region [offset, offset + size] for that kernel
image. If '@offset' is omitted, then a suitable offset
is selected automatically. Check
- Documentation/kdump/kdump.txt for further details.
+ Documentation/kdump/kdump.rst for further details.
crashkernel=range1:size1[,range2:size2,...][@offset]
[KNL] Same as above, but depends on the memory
in the running system. The syntax of range is
start-[end] where start and end are both
a memory unit (amount[KMG]). See also
- Documentation/kdump/kdump.txt for an example.
+ Documentation/kdump/kdump.rst for an example.
crashkernel=size[KMG],high
[KNL, x86_64] range could be above 4G. Allow kernel
@@ -1206,7 +1206,7 @@
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
kexec loader will pass this option to capture kernel.
- See Documentation/kdump/kdump.txt for details.
+ See Documentation/kdump/kdump.rst for details.
enable_mtrr_cleanup [X86]
The kernel tries to adjust MTRR layout from continuous
diff --git a/Documentation/kdump/index.rst b/Documentation/kdump/index.rst
new file mode 100644
index 000000000000..2b17fcf6867a
--- /dev/null
+++ b/Documentation/kdump/index.rst
@@ -0,0 +1,21 @@
+:orphan:
+
+================================================================
+Documentation for Kdump - The kexec-based Crash Dumping Solution
+================================================================
+
+This document includes overview, setup and installation, and analysis
+information.
+
+.. toctree::
+ :maxdepth: 1
+
+ kdump
+ vmcoreinfo
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.rst
similarity index 91%
rename from Documentation/kdump/kdump.txt
rename to Documentation/kdump/kdump.rst
index 51814450a7f8..1da2d7b765f6 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.rst
@@ -71,9 +71,8 @@ This is a symlink to the latest version.
The latest kexec-tools git tree is available at:
-git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
-and
-http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
+- git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
+- http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
There is also a gitweb interface available at
http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
@@ -81,25 +80,25 @@ http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
More information about kexec-tools can be found at
http://horms.net/projects/kexec/
-3) Unpack the tarball with the tar command, as follows:
+3) Unpack the tarball with the tar command, as follows::
- tar xvpzf kexec-tools.tar.gz
+ tar xvpzf kexec-tools.tar.gz
-4) Change to the kexec-tools directory, as follows:
+4) Change to the kexec-tools directory, as follows::
- cd kexec-tools-VERSION
+ cd kexec-tools-VERSION
-5) Configure the package, as follows:
+5) Configure the package, as follows::
- ./configure
+ ./configure
-6) Compile the package, as follows:
+6) Compile the package, as follows::
- make
+ make
-7) Install the package, as follows:
+7) Install the package, as follows::
- make install
+ make install
Build the system and dump-capture kernels
@@ -126,25 +125,25 @@ dump-capture kernels for enabling kdump support.
System kernel config options
----------------------------
-1) Enable "kexec system call" in "Processor type and features."
+1) Enable "kexec system call" in "Processor type and features."::
- CONFIG_KEXEC=y
+ CONFIG_KEXEC=y
2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
- filesystems." This is usually enabled by default.
+ filesystems." This is usually enabled by default::
- CONFIG_SYSFS=y
+ CONFIG_SYSFS=y
Note that "sysfs file system support" might not appear in the "Pseudo
filesystems" menu if "Configure standard kernel features (for small
systems)" is not enabled in "General Setup." In this case, check the
- .config file itself to ensure that sysfs is turned on, as follows:
+ .config file itself to ensure that sysfs is turned on, as follows::
- grep 'CONFIG_SYSFS' .config
+ grep 'CONFIG_SYSFS' .config
-3) Enable "Compile the kernel with debug info" in "Kernel hacking."
+3) Enable "Compile the kernel with debug info" in "Kernel hacking."::
- CONFIG_DEBUG_INFO=Y
+ CONFIG_DEBUG_INFO=Y
This causes the kernel to be built with debug symbols. The dump
analysis tools require a vmlinux with debug symbols in order to read
@@ -154,29 +153,32 @@ Dump-capture kernel config options (Arch Independent)
-----------------------------------------------------
1) Enable "kernel crash dumps" support under "Processor type and
- features":
+ features"::
- CONFIG_CRASH_DUMP=y
+ CONFIG_CRASH_DUMP=y
-2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems".
+2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems"::
+
+ CONFIG_PROC_VMCORE=y
- CONFIG_PROC_VMCORE=y
(CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.)
Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
--------------------------------------------------------------------
1) On i386, enable high memory support under "Processor type and
- features":
+ features"::
- CONFIG_HIGHMEM64G=y
- or
- CONFIG_HIGHMEM4G
+ CONFIG_HIGHMEM64G=y
+
+ or::
+
+ CONFIG_HIGHMEM4G
2) On i386 and x86_64, disable symmetric multi-processing support
- under "Processor type and features":
+ under "Processor type and features"::
- CONFIG_SMP=n
+ CONFIG_SMP=n
(If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line
when loading the dump-capture kernel, see section "Load the Dump-capture
@@ -184,9 +186,9 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
3) If one wants to build and use a relocatable kernel,
Enable "Build a relocatable kernel" support under "Processor type and
- features"
+ features"::
- CONFIG_RELOCATABLE=y
+ CONFIG_RELOCATABLE=y
4) Use a suitable value for "Physical address where the kernel is
loaded" (under "Processor type and features"). This only appears when
@@ -211,13 +213,13 @@ Dump-capture kernel config options (Arch Dependent, i386 and x86_64)
Dump-capture kernel config options (Arch Dependent, ppc64)
----------------------------------------------------------
-1) Enable "Build a kdump crash kernel" support under "Kernel" options:
+1) Enable "Build a kdump crash kernel" support under "Kernel" options::
- CONFIG_CRASH_DUMP=y
+ CONFIG_CRASH_DUMP=y
-2) Enable "Build a relocatable kernel" support
+2) Enable "Build a relocatable kernel" support::
- CONFIG_RELOCATABLE=y
+ CONFIG_RELOCATABLE=y
Make and install the kernel and its modules.
@@ -231,11 +233,13 @@ Dump-capture kernel config options (Arch Dependent, ia64)
The crashkernel region can be automatically placed by the system
kernel at run time. This is done by specifying the base address as 0,
- or omitting it all together.
+ or omitting it all together::
- crashkernel=256M@0
- or
- crashkernel=256M
+ crashkernel=256M@0
+
+ or::
+
+ crashkernel=256M
If the start address is specified, note that the start address of the
kernel will be aligned to 64Mb, so if the start address is not then
@@ -245,9 +249,9 @@ Dump-capture kernel config options (Arch Dependent, arm)
----------------------------------------------------------
- To use a relocatable kernel,
- Enable "AUTO_ZRELADDR" support under "Boot" options:
+ Enable "AUTO_ZRELADDR" support under "Boot" options::
- AUTO_ZRELADDR=y
+ AUTO_ZRELADDR=y
Dump-capture kernel config options (Arch Dependent, arm64)
----------------------------------------------------------
@@ -265,12 +269,12 @@ on the value of System RAM -- that's mostly for distributors that pre-setup
the kernel command line to avoid a unbootable system after some memory has
been removed from the machine.
-The syntax is:
+The syntax is::
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
-For example:
+For example::
crashkernel=512M-2G:64M,2G-:128M
@@ -326,35 +330,46 @@ can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz
of dump-capture kernel. Following is the summary.
For i386 and x86_64:
+
- Use vmlinux if kernel is not relocatable.
- Use bzImage/vmlinuz if kernel is relocatable.
+
For ppc64:
+
- Use vmlinux
+
For ia64:
+
- Use vmlinux or vmlinuz.gz
+
For s390x:
+
- Use image or bzImage
+
For arm:
+
- Use zImage
+
For arm64:
+
- Use vmlinux or Image
If you are using an uncompressed vmlinux image then use following command
-to load dump-capture kernel.
+to load dump-capture kernel::
kexec -p <dump-capture-kernel-vmlinux-image> \
--initrd=<initrd-for-dump-capture-kernel> --args-linux \
--append="root=<root-dev> <arch-specific-options>"
If you are using a compressed bzImage/vmlinuz, then use following command
-to load dump-capture kernel.
+to load dump-capture kernel::
kexec -p <dump-capture-kernel-bzImage> \
--initrd=<initrd-for-dump-capture-kernel> \
--append="root=<root-dev> <arch-specific-options>"
If you are using a compressed zImage, then use following command
-to load dump-capture kernel.
+to load dump-capture kernel::
kexec --type zImage -p <dump-capture-kernel-bzImage> \
--initrd=<initrd-for-dump-capture-kernel> \
@@ -362,7 +377,7 @@ to load dump-capture kernel.
--append="root=<root-dev> <arch-specific-options>"
If you are using an uncompressed Image, then use following command
-to load dump-capture kernel.
+to load dump-capture kernel::
kexec -p <dump-capture-kernel-Image> \
--initrd=<initrd-for-dump-capture-kernel> \
@@ -376,18 +391,23 @@ Following are the arch specific command line options to be used while
loading dump-capture kernel.
For i386, x86_64 and ia64:
+
"1 irqpoll maxcpus=1 reset_devices"
For ppc64:
+
"1 maxcpus=1 noirqdistrib reset_devices"
For s390x:
+
"1 maxcpus=1 cgroup_disable=memory"
For arm:
+
"1 maxcpus=1 reset_devices"
For arm64:
+
"1 maxcpus=1 reset_devices"
Notes on loading the dump-capture kernel:
@@ -464,7 +484,7 @@ Write Out the Dump File
=======================
After the dump-capture kernel is booted, write out the dump file with
-the following command:
+the following command::
cp /proc/vmcore <dump-file>
@@ -476,7 +496,7 @@ Before analyzing the dump image, you should reboot into a stable kernel.
You can do limited analysis using GDB on the dump file copied out of
/proc/vmcore. Use the debug vmlinux built with -g and run the following
-command:
+command::
gdb vmlinux <dump-file>
@@ -504,6 +524,11 @@ to achieve the same behaviour.
Contact
=======
-Vivek Goyal (vgoyal@redhat.com)
-Maneesh Soni (maneesh@in.ibm.com)
+- Vivek Goyal (vgoyal@redhat.com)
+- Maneesh Soni (maneesh@in.ibm.com)
+GDB macros
+==========
+
+.. include:: gdbmacros.txt
+ :literal:
diff --git a/Documentation/kdump/vmcoreinfo.txt b/Documentation/kdump/vmcoreinfo.rst
similarity index 95%
rename from Documentation/kdump/vmcoreinfo.txt
rename to Documentation/kdump/vmcoreinfo.rst
index bb94a4bd597a..007a6b86e0ee 100644
--- a/Documentation/kdump/vmcoreinfo.txt
+++ b/Documentation/kdump/vmcoreinfo.rst
@@ -1,8 +1,7 @@
-================================================================
- VMCOREINFO
-================================================================
+==========
+VMCOREINFO
+==========
-===========
What is it?
===========
@@ -12,7 +11,6 @@ values, field offsets, etc. These data are packed into an ELF note
section and used by user-space tools like crash and makedumpfile to
analyze a kernel's memory layout.
-================
Common variables
================
@@ -49,7 +47,7 @@ in a system, one bit position per node number. Used to keep track of
which nodes are in the system and online.
swapper_pg_dir
--------------
+--------------
The global page directory pointer of the kernel. Used to translate
virtual to physical addresses.
@@ -132,16 +130,14 @@ nodemask_t
The size of a nodemask_t type. Used to compute the number of online
nodes.
-(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|
- compound_order|compound_head)
--------------------------------------------------------------------
+(page, flags|_refcount|mapping|lru|_mapcount|private|compound_dtor|compound_order|compound_head)
+-------------------------------------------------------------------------------------------------
User-space tools compute their values based on the offset of these
variables. The variables are used when excluding unnecessary pages.
-(pglist_data, node_zones|nr_zones|node_mem_map|node_start_pfn|node_
- spanned_pages|node_id)
--------------------------------------------------------------------
+(pglist_data, node_zones|nr_zones|node_mem_map|node_start_pfn|node_spanned_pages|node_id)
+-----------------------------------------------------------------------------------------
On NUMA machines, each NUMA node has a pg_data_t to describe its memory
layout. On UMA machines there is a single pglist_data which describes the
@@ -245,21 +241,25 @@ NR_FREE_PAGES
On linux-2.6.21 or later, the number of free pages is in
vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
-PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision
-|PG_head_mask|PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)
-|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
------------------------------------------------------------------
+PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_slab|PG_hwpoision|PG_head_mask
+------------------------------------------------------------------------------
Page attributes. These flags are used to filter various unnecessary for
dumping pages.
+PAGE_BUDDY_MAPCOUNT_VALUE(~PG_buddy)|PAGE_OFFLINE_MAPCOUNT_VALUE(~PG_offline)
+-----------------------------------------------------------------------------
+
+More page attributes. These flags are used to filter various unnecessary for
+dumping pages.
+
+
HUGETLB_PAGE_DTOR
-----------------
The HUGETLB_PAGE_DTOR flag denotes hugetlbfs pages. Makedumpfile
excludes these pages.
-======
x86_64
======
@@ -318,12 +318,12 @@ address.
Currently, sme_mask stores the value of the C-bit position. If needed,
additional SME-relevant info can be placed in that variable.
-For example:
-[ misc ][ enc bit ][ other misc SME info ]
-0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
-63 59 55 51 47 43 39 35 31 27 ... 3
+For example::
+
+ [ misc ][ enc bit ][ other misc SME info ]
+ 0000_0000_0000_0000_1000_0000_0000_0000_0000_0000_..._0000
+ 63 59 55 51 47 43 39 35 31 27 ... 3
-======
x86_32
======
@@ -335,7 +335,6 @@ of a higher page table lookup overhead, and also consumes more page
table space per process. Used to check whether PAE was enabled in the
crash kernel when converting virtual addresses to physical addresses.
-====
ia64
====
@@ -366,7 +365,6 @@ PGTABLE_3|PGTABLE_4
User-space tools need to know whether the crash kernel was in 3-level or
4-level paging mode. Used to distinguish the page table.
-=====
ARM64
=====
@@ -395,9 +393,8 @@ KERNELOFFSET
The kernel randomization offset. Used to compute the page offset. If
KASLR is disabled, this value is zero.
-====
arm
-====
+===
ARM_LPAE
--------
@@ -405,12 +402,11 @@ ARM_LPAE
It indicates whether the crash kernel supports large physical address
extensions. Used to translate virtual to physical addresses.
-====
s390
====
lowcore_ptr
-----------
+-----------
An array with a pointer to the lowcore of every CPU. Used to print the
psw and all registers information.
@@ -425,7 +421,6 @@ Used to get the vmalloc_start address from the high_memory symbol.
The maximum number of CPUs.
-=======
powerpc
=======
@@ -460,9 +455,8 @@ Page size definitions, i.e. 4k, 64k, or 16M.
Used to make vtop translations.
-vmemmap_backing|(vmemmap_backing, list)|(vmemmap_backing, phys)|
-(vmemmap_backing, virt_addr)
-----------------------------------------------------------------
+vmemmap_backing|(vmemmap_backing, list)|(vmemmap_backing, phys)|(vmemmap_backing, virt_addr)
+--------------------------------------------------------------------------------------------
The vmemmap virtual address space management does not have a traditional
page table to track which virtual struct pages are backed by a physical
@@ -480,7 +474,6 @@ member.
Used in vtop translations.
-==
sh
==
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt
index 18c5feef2577..0c41d6d463f3 100644
--- a/Documentation/powerpc/firmware-assisted-dump.txt
+++ b/Documentation/powerpc/firmware-assisted-dump.txt
@@ -59,7 +59,7 @@ as follows:
the default calculated size. Use this option if default
boot memory size is not sufficient for second kernel to
boot successfully. For syntax of crashkernel= parameter,
- refer to Documentation/kdump/kdump.txt. If any offset is
+ refer to Documentation/kdump/kdump.rst. If any offset is
provided in crashkernel= parameter, it will be ignored
as fadump uses a predefined offset to reserve memory
for boot memory dump preservation in case of a crash.
diff --git a/Documentation/translations/zh_CN/oops-tracing.txt b/Documentation/translations/zh_CN/oops-tracing.txt
index 93fa061cf9e4..368ddd05b304 100644
--- a/Documentation/translations/zh_CN/oops-tracing.txt
+++ b/Documentation/translations/zh_CN/oops-tracing.txt
@@ -53,7 +53,7 @@ cat /proc/kmsg > file， 然而你必须介入中止传输， kmsg是一个“
（2）用串口终端启动（请参看Documentation/admin-guide/serial-console.rst），运行一个null
modem到另一台机器并用你喜欢的通讯工具获取输出。Minicom工作地很好。
-（3）使用Kdump（请参看Documentation/kdump/kdump.txt），
+（3）使用Kdump（请参看Documentation/kdump/kdump.rst），
使用在Documentation/kdump/gdbmacros.txt中定义的dmesg gdb宏，从旧的内存中提取内核
环形缓冲区。
diff --git a/Documentation/watchdog/hpwdt.txt b/Documentation/watchdog/hpwdt.txt
index 55df692c5595..aaa9e4b4bdcd 100644
--- a/Documentation/watchdog/hpwdt.txt
+++ b/Documentation/watchdog/hpwdt.txt
@@ -51,7 +51,7 @@ Last reviewed: 08/20/2018
and loop forever. This is generally not what a watchdog user wants.
For those wishing to learn more please see:
- Documentation/kdump/kdump.txt
+ Documentation/kdump/kdump.rst
Documentation/admin-guide/kernel-parameters.txt (panic=)
Your Linux Distribution specific documentation.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b509cd338219..c81ee94e8256 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2007,7 +2007,7 @@ config CRASH_DUMP
kdump/kexec. The crash dump kernel must be compiled to a
memory address not used by the main kernel
- For more details see Documentation/kdump/kdump.txt
+ For more details see Documentation/kdump/kdump.rst
config AUTO_ZRELADDR
bool "Auto calculation of the decompressed kernel image address"
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 8e33203e3583..e67ad4dad1cf 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -974,7 +974,7 @@ config CRASH_DUMP
reserved region and then later executed after a crash by
kdump/kexec.
- For more details see Documentation/kdump/kdump.txt
+ For more details see Documentation/kdump/kdump.rst
config XEN_DOM0
def_bool y
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 2a77033e1e7c..9883516e682c 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -624,7 +624,7 @@ config CRASH_DUMP
to a memory address not used by the main kernel using
PHYSICAL_START.
- For more details see Documentation/kdump/kdump.txt
+ For more details see Documentation/kdump/kdump.rst
config KEXEC_JUMP
bool "kexec jump (EXPERIMENTAL)"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 17f01a0800b3..bd8dea466b04 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2038,7 +2038,7 @@ config CRASH_DUMP
to a memory address not used by the main kernel or BIOS using
PHYSICAL_START, or it must be built as a relocatable image
(CONFIG_RELOCATABLE=y).
- For more details see Documentation/kdump/kdump.txt
+ For more details see Documentation/kdump/kdump.rst
config KEXEC_JUMP
bool "kexec jump"
@@ -2075,7 +2075,7 @@ config PHYSICAL_START
the reserved region. In other words, it can be set based on
the "X" value as specified in the "crashkernel=YM@XM"
command line boot parameter passed to the panic-ed
- kernel. Please take a look at Documentation/kdump/kdump.txt
+ kernel. Please take a look at Documentation/kdump/kdump.rst
for more details about crash dumps.
Usage of bzImage for capturing the crash dump is recommended as
--
2.20.1
^ permalink raw reply related
* [PATCH v2 26/79] docs: powerpc: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-04-22 13:27 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Paul Mackerras, Mauro Carvalho Chehab, Qiang Zhao, linux-scsi,
Jonathan Corbet, linux-pci, Jiri Slaby, Mauro Carvalho Chehab,
Manoj N. Kumar, Bjorn Helgaas, linux-arm-kernel, Matthew R. Ochs,
Uma Krishnan, Sam Bobroff, Greg Kroah-Hartman, linux-kernel,
Li Yang, Andrew Donnellan, Frederic Barrat, Oliver O'Halloran,
linuxppc-dev
In-Reply-To: <cover.1555938375.git.mchehab+samsung@kernel.org>
Convert docs to ReST and add them to the arch-specific
book.
The conversion here was trivial, as almost every file there
was already using an elegant format close to ReST standard.
The changes were mostly to mark literal blocks and add a few
missing section title identifiers.
One note with regards to "--": on Sphinx, this can't be used
to identify a list, as it will format it badly. This can be
used, however, to identify a long hyphen - and "---" is an
even longer one.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/PCI/pci-error-recovery.txt | 2 +-
.../{bootwrapper.txt => bootwrapper.rst} | 28 +++-
.../{cpu_families.txt => cpu_families.rst} | 23 +--
.../{cpu_features.txt => cpu_features.rst} | 6 +-
Documentation/powerpc/{cxl.txt => cxl.rst} | 46 ++++--
.../powerpc/{cxlflash.txt => cxlflash.rst} | 10 +-
.../{DAWR-POWER9.txt => dawr-power9.rst} | 10 +-
Documentation/powerpc/{dscr.txt => dscr.rst} | 18 +-
...ecovery.txt => eeh-pci-error-recovery.rst} | 108 ++++++------
...ed-dump.txt => firmware-assisted-dump.rst} | 117 +++++++------
Documentation/powerpc/{hvcs.txt => hvcs.rst} | 108 ++++++------
Documentation/powerpc/index.rst | 34 ++++
Documentation/powerpc/isa-versions.rst | 13 +-
.../powerpc/{mpc52xx.txt => mpc52xx.rst} | 12 +-
...nv.txt => pci_iov_resource_on_powernv.rst} | 15 +-
.../powerpc/{pmu-ebb.txt => pmu-ebb.rst} | 1 +
Documentation/powerpc/ptrace.rst | 156 ++++++++++++++++++
Documentation/powerpc/ptrace.txt | 151 -----------------
.../{qe_firmware.txt => qe_firmware.rst} | 37 +++--
.../{syscall64-abi.txt => syscall64-abi.rst} | 29 ++--
...al_memory.txt => transactional_memory.rst} | 45 ++---
MAINTAINERS | 6 +-
arch/powerpc/kernel/exceptions-64s.S | 2 +-
drivers/soc/fsl/qe/qe.c | 2 +-
drivers/tty/hvc/hvcs.c | 2 +-
include/soc/fsl/qe/qe.h | 2 +-
26 files changed, 559 insertions(+), 424 deletions(-)
rename Documentation/powerpc/{bootwrapper.txt => bootwrapper.rst} (93%)
rename Documentation/powerpc/{cpu_families.txt => cpu_families.rst} (95%)
rename Documentation/powerpc/{cpu_features.txt => cpu_features.rst} (97%)
rename Documentation/powerpc/{cxl.txt => cxl.rst} (95%)
rename Documentation/powerpc/{cxlflash.txt => cxlflash.rst} (98%)
rename Documentation/powerpc/{DAWR-POWER9.txt => dawr-power9.rst} (95%)
rename Documentation/powerpc/{dscr.txt => dscr.rst} (91%)
rename Documentation/powerpc/{eeh-pci-error-recovery.txt => eeh-pci-error-recovery.rst} (82%)
rename Documentation/powerpc/{firmware-assisted-dump.txt => firmware-assisted-dump.rst} (80%)
rename Documentation/powerpc/{hvcs.txt => hvcs.rst} (91%)
create mode 100644 Documentation/powerpc/index.rst
rename Documentation/powerpc/{mpc52xx.txt => mpc52xx.rst} (91%)
rename Documentation/powerpc/{pci_iov_resource_on_powernv.txt => pci_iov_resource_on_powernv.rst} (97%)
rename Documentation/powerpc/{pmu-ebb.txt => pmu-ebb.rst} (99%)
create mode 100644 Documentation/powerpc/ptrace.rst
delete mode 100644 Documentation/powerpc/ptrace.txt
rename Documentation/powerpc/{qe_firmware.txt => qe_firmware.rst} (95%)
rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (82%)
rename Documentation/powerpc/{transactional_memory.txt => transactional_memory.rst} (93%)
diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt
index 0b6bb3ef449e..1ba6a89cf92f 100644
--- a/Documentation/PCI/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
@@ -389,7 +389,7 @@ platforms aren't supposed to share interrupts between many devices
anyway :)
>>> Implementation details for the powerpc platform are discussed in
->>> the file Documentation/powerpc/eeh-pci-error-recovery.txt
+>>> the file Documentation/powerpc/eeh-pci-error-recovery.rst
>>> As of this writing, there is a growing list of device drivers with
>>> patches implementing error recovery. Not all of these patches are in
diff --git a/Documentation/powerpc/bootwrapper.txt b/Documentation/powerpc/bootwrapper.rst
similarity index 93%
rename from Documentation/powerpc/bootwrapper.txt
rename to Documentation/powerpc/bootwrapper.rst
index d60fced5e1cc..a6292afba573 100644
--- a/Documentation/powerpc/bootwrapper.txt
+++ b/Documentation/powerpc/bootwrapper.rst
@@ -1,5 +1,7 @@
+========================
The PowerPC boot wrapper
-------------------------
+========================
+
Copyright (C) Secret Lab Technologies Ltd.
PowerPC image targets compresses and wraps the kernel image (vmlinux) with
@@ -21,6 +23,7 @@ it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
image. The details of the build system is discussed in the next section.
Currently, the following image format targets exist:
+ ==================== ========================================================
cuImage.%: Backwards compatible uImage for older version of
U-Boot (for versions that don't understand the device
tree). This image embeds a device tree blob inside
@@ -29,31 +32,36 @@ Currently, the following image format targets exist:
with boot wrapper code that extracts data from the old
bd_info structure and loads the data into the device
tree before jumping into the kernel.
- Because of the series of #ifdefs found in the
+
+ Because of the series of #ifdefs found in the
bd_info structure used in the old U-Boot interfaces,
cuImages are platform specific. Each specific
U-Boot platform has a different platform init file
which populates the embedded device tree with data
from the platform specific bd_info file. The platform
specific cuImage platform init code can be found in
- arch/powerpc/boot/cuboot.*.c. Selection of the correct
+ `arch/powerpc/boot/cuboot.*.c`. Selection of the correct
cuImage init code for a specific board can be found in
the wrapper structure.
+
dtbImage.%: Similar to zImage, except device tree blob is embedded
inside the image instead of provided by firmware. The
output image file can be either an elf file or a flat
binary depending on the platform.
- dtbImages are used on systems which do not have an
+
+ dtbImages are used on systems which do not have an
interface for passing a device tree directly.
dtbImages are similar to simpleImages except that
dtbImages have platform specific code for extracting
data from the board firmware, but simpleImages do not
talk to the firmware at all.
- PlayStation 3 support uses dtbImage. So do Embedded
+
+ PlayStation 3 support uses dtbImage. So do Embedded
Planet boards using the PlanetCore firmware. Board
specific initialization code is typically found in a
file named arch/powerpc/boot/<platform>.c; but this
can be overridden by the wrapper script.
+
simpleImage.%: Firmware independent compressed image that does not
depend on any particular firmware interface and embeds
a device tree blob. This image is a flat binary that
@@ -61,14 +69,16 @@ Currently, the following image format targets exist:
Firmware cannot pass any configuration data to the
kernel with this image type and it depends entirely on
the embedded device tree for all information.
- The simpleImage is useful for booting systems with
+
+ The simpleImage is useful for booting systems with
an unknown firmware interface or for booting from
a debugger when no firmware is present (such as on
the Xilinx Virtex platform). The only assumption that
simpleImage makes is that RAM is correctly initialized
and that the MMU is either off or has RAM mapped to
base address 0.
- simpleImage also supports inserting special platform
+
+ simpleImage also supports inserting special platform
specific initialization code to the start of the bootup
sequence. The virtex405 platform uses this feature to
ensure that the cache is invalidated before caching
@@ -81,9 +91,11 @@ Currently, the following image format targets exist:
named (virtex405-<board>.dts). Search the wrapper
script for 'virtex405' and see the file
arch/powerpc/boot/virtex405-head.S for details.
+
treeImage.%; Image format for used with OpenBIOS firmware found
on some ppc4xx hardware. This image embeds a device
tree blob inside the image.
+
uImage: Native image format used by U-Boot. The uImage target
does not add any boot code. It just wraps a compressed
vmlinux in the uImage data structure. This image
@@ -91,12 +103,14 @@ Currently, the following image format targets exist:
a device tree to the kernel at boot. If using an older
version of U-Boot, then you need to use a cuImage
instead.
+
zImage.%: Image format which does not embed a device tree.
Used by OpenFirmware and other firmware interfaces
which are able to supply a device tree. This image
expects firmware to provide the device tree at boot.
Typically, if you have general purpose PowerPC
hardware then you want this image format.
+ ==================== ========================================================
Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
and cuImage) all generate the device tree blob from a file in the
diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.rst
similarity index 95%
rename from Documentation/powerpc/cpu_families.txt
rename to Documentation/powerpc/cpu_families.rst
index fc08e22feb1a..1e063c5440c3 100644
--- a/Documentation/powerpc/cpu_families.txt
+++ b/Documentation/powerpc/cpu_families.rst
@@ -1,3 +1,4 @@
+============
CPU Families
============
@@ -8,8 +9,8 @@ and are supported by arch/powerpc.
Book3S (aka sPAPR)
------------------
- - Hash MMU
- - Mix of 32 & 64 bit
+- Hash MMU
+- Mix of 32 & 64 bit::
+--------------+ +----------------+
| Old POWER | --------------> | RS64 (threads) |
@@ -108,8 +109,8 @@ Book3S (aka sPAPR)
IBM BookE
---------
- - Software loaded TLB.
- - All 32 bit
+- Software loaded TLB.
+- All 32 bit::
+--------------+
| 401 |
@@ -155,8 +156,8 @@ IBM BookE
Motorola/Freescale 8xx
----------------------
- - Software loaded with hardware assist.
- - All 32 bit
+- Software loaded with hardware assist.
+- All 32 bit::
+-------------+
| MPC8xx Core |
@@ -166,9 +167,9 @@ Motorola/Freescale 8xx
Freescale BookE
---------------
- - Software loaded TLB.
- - e6500 adds HW loaded indirect TLB entries.
- - Mix of 32 & 64 bit
+- Software loaded TLB.
+- e6500 adds HW loaded indirect TLB entries.
+- Mix of 32 & 64 bit::
+--------------+
| e200 |
@@ -207,8 +208,8 @@ Freescale BookE
IBM A2 core
-----------
- - Book3E, software loaded TLB + HW loaded indirect TLB entries.
- - 64 bit
+- Book3E, software loaded TLB + HW loaded indirect TLB entries.
+- 64 bit::
+--------------+ +----------------+
| A2 core | --> | WSP |
diff --git a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.rst
similarity index 97%
rename from Documentation/powerpc/cpu_features.txt
rename to Documentation/powerpc/cpu_features.rst
index ae09df8722c8..b7bcdd2f41bb 100644
--- a/Documentation/powerpc/cpu_features.txt
+++ b/Documentation/powerpc/cpu_features.rst
@@ -1,3 +1,7 @@
+============
+CPU Features
+============
+
Hollis Blanchard <hollis@austin.ibm.com>
5 Jun 2002
@@ -32,7 +36,7 @@ anyways).
After detecting the processor type, the kernel patches out sections of code
that shouldn't be used by writing nop's over it. Using cpufeatures requires
just 2 macros (found in arch/powerpc/include/asm/cputable.h), as seen in head.S
-transfer_to_handler:
+transfer_to_handler::
#ifdef CONFIG_ALTIVEC
BEGIN_FTR_SECTION
diff --git a/Documentation/powerpc/cxl.txt b/Documentation/powerpc/cxl.rst
similarity index 95%
rename from Documentation/powerpc/cxl.txt
rename to Documentation/powerpc/cxl.rst
index c5e8d5098ed3..99e704afb09d 100644
--- a/Documentation/powerpc/cxl.txt
+++ b/Documentation/powerpc/cxl.rst
@@ -1,3 +1,4 @@
+====================================
Coherent Accelerator Interface (CXL)
====================================
@@ -21,6 +22,8 @@ Introduction
Hardware overview
=================
+ ::
+
POWER8/9 FPGA
+----------+ +---------+
| | | |
@@ -59,14 +62,16 @@ Hardware overview
the fault. The context to which this fault is serviced is based on
who owns that acceleration function.
- POWER8 <-----> PSL Version 8 is compliant to the CAIA Version 1.0.
- POWER9 <-----> PSL Version 9 is compliant to the CAIA Version 2.0.
+ - POWER8 <------> PSL Version 8 is compliant to the CAIA Version 1.0.
+ - POWER9 <------> PSL Version 9 is compliant to the CAIA Version 2.0.
+
This PSL Version 9 provides new features such as:
+
* Interaction with the nest MMU on the P9 chip.
* Native DMA support.
* Supports sending ASB_Notify messages for host thread wakeup.
* Supports Atomic operations.
- * ....
+ * etc.
Cards with a PSL9 won't work on a POWER8 system and cards with a
PSL8 won't work on a POWER9 system.
@@ -147,7 +152,9 @@ User API
master devices.
A userspace library libcxl is available here:
+
https://github.com/ibm-capi/libcxl
+
This provides a C interface to this kernel API.
open
@@ -165,7 +172,8 @@ open
When all available contexts are allocated the open call will fail
and return -ENOSPC.
- Note: IRQs need to be allocated for each context, which may limit
+ Note:
+ IRQs need to be allocated for each context, which may limit
the number of contexts that can be created, and therefore
how many times the device can be opened. The POWER8 CAPP
supports 2040 IRQs and 3 are used by the kernel, so 2037 are
@@ -186,7 +194,9 @@ ioctl
updated as userspace allocates and frees memory. This ioctl
returns once the AFU context is started.
- Takes a pointer to a struct cxl_ioctl_start_work:
+ Takes a pointer to a struct cxl_ioctl_start_work
+
+ ::
struct cxl_ioctl_start_work {
__u64 flags;
@@ -269,7 +279,7 @@ read
The buffer passed to read() must be at least 4K bytes.
The result of the read will be a buffer of one or more events,
- each event is of type struct cxl_event, of varying size.
+ each event is of type struct cxl_event, of varying size::
struct cxl_event {
struct cxl_event_header header;
@@ -280,7 +290,9 @@ read
};
};
- The struct cxl_event_header is defined as:
+ The struct cxl_event_header is defined as
+
+ ::
struct cxl_event_header {
__u16 type;
@@ -307,7 +319,9 @@ read
For future extensions and padding.
If the event type is CXL_EVENT_AFU_INTERRUPT then the event
- structure is defined as:
+ structure is defined as
+
+ ::
struct cxl_event_afu_interrupt {
__u16 flags;
@@ -326,7 +340,9 @@ read
For future extensions and padding.
If the event type is CXL_EVENT_DATA_STORAGE then the event
- structure is defined as:
+ structure is defined as
+
+ ::
struct cxl_event_data_storage {
__u16 flags;
@@ -356,7 +372,9 @@ read
For future extensions
If the event type is CXL_EVENT_AFU_ERROR then the event structure
- is defined as:
+ is defined as
+
+ ::
struct cxl_event_afu_error {
__u16 flags;
@@ -393,15 +411,15 @@ open
ioctl
-----
-CXL_IOCTL_DOWNLOAD_IMAGE:
-CXL_IOCTL_VALIDATE_IMAGE:
+CXL_IOCTL_DOWNLOAD_IMAGE / CXL_IOCTL_VALIDATE_IMAGE:
Starts and controls flashing a new FPGA image. Partial
reconfiguration is not supported (yet), so the image must contain
a copy of the PSL and AFU(s). Since an image can be quite large,
the caller may have to iterate, splitting the image in smaller
chunks.
- Takes a pointer to a struct cxl_adapter_image:
+ Takes a pointer to a struct cxl_adapter_image::
+
struct cxl_adapter_image {
__u64 flags;
__u64 data;
@@ -442,7 +460,7 @@ Udev rules
The following udev rules could be used to create a symlink to the
most logical chardev to use in any programming mode (afuX.Yd for
dedicated, afuX.Ys for afu directed), since the API is virtually
- identical for each:
+ identical for each::
SUBSYSTEM=="cxl", ATTRS{mode}=="dedicated_process", SYMLINK="cxl/%b"
SUBSYSTEM=="cxl", ATTRS{mode}=="afu_directed", \
diff --git a/Documentation/powerpc/cxlflash.txt b/Documentation/powerpc/cxlflash.rst
similarity index 98%
rename from Documentation/powerpc/cxlflash.txt
rename to Documentation/powerpc/cxlflash.rst
index a64bdaa0a1cf..cea67931b3b9 100644
--- a/Documentation/powerpc/cxlflash.txt
+++ b/Documentation/powerpc/cxlflash.rst
@@ -1,3 +1,7 @@
+================================
+Coherent Accelerator (CXL) Flash
+================================
+
Introduction
============
@@ -28,7 +32,7 @@ Introduction
responsible for the initialization of the adapter, setting up the
special path for user space access, and performing error recovery. It
communicates directly the Flash Accelerator Functional Unit (AFU)
- as described in Documentation/powerpc/cxl.txt.
+ as described in Documentation/powerpc/cxl.rst.
The cxlflash driver supports two, mutually exclusive, modes of
operation at the device (LUN) level:
@@ -58,7 +62,7 @@ Overview
The CXL Flash Adapter Driver establishes a master context with the
AFU. It uses memory mapped I/O (MMIO) for this control and setup. The
- Adapter Problem Space Memory Map looks like this:
+ Adapter Problem Space Memory Map looks like this::
+-------------------------------+
| 512 * 64 KB User MMIO |
@@ -375,7 +379,7 @@ CXL Flash Driver Host IOCTLs
Each host adapter instance that is supported by the cxlflash driver
has a special character device associated with it to enable a set of
host management function. These character devices are hosted in a
- class dedicated for cxlflash and can be accessed via /dev/cxlflash/*.
+ class dedicated for cxlflash and can be accessed via `/dev/cxlflash/*`.
Applications can be written to perform various functions using the
host ioctl APIs below.
diff --git a/Documentation/powerpc/DAWR-POWER9.txt b/Documentation/powerpc/dawr-power9.rst
similarity index 95%
rename from Documentation/powerpc/DAWR-POWER9.txt
rename to Documentation/powerpc/dawr-power9.rst
index 2feaa6619658..882e5af02b9c 100644
--- a/Documentation/powerpc/DAWR-POWER9.txt
+++ b/Documentation/powerpc/dawr-power9.rst
@@ -1,10 +1,11 @@
+=====================
DAWR issues on POWER9
-============================
+=====================
On POWER9 the DAWR can cause a checkstop if it points to cache
inhibited (CI) memory. Currently Linux has no way to disinguish CI
memory when configuring the DAWR, so (for now) the DAWR is disabled by
-this commit:
+this commit::
commit 9654153158d3e0684a1bdb76dbababdb7111d5a0
Author: Michael Neuling <mikey@neuling.org>
@@ -12,7 +13,7 @@ this commit:
powerpc: Disable DAWR in the base POWER9 CPU features
Technical Details:
-============================
+==================
DAWR has 6 different ways of being set.
1) ptrace
@@ -37,7 +38,7 @@ DAWR on the migration.
For xmon, the 'bd' command will return an error on P9.
Consequences for users
-============================
+======================
For GDB watchpoints (ie 'watch' command) on POWER9 bare metal , GDB
will accept the command. Unfortunately since there is no hardware
@@ -55,4 +56,3 @@ guest is migrated to a POWER9 host, the watchpoint will be lost on the
POWER9. Loads and stores to the watchpoint locations will not be
trapped in GDB. The watchpoint is remembered, so if the guest is
migrated back to the POWER8 host, it will start working again.
-
diff --git a/Documentation/powerpc/dscr.txt b/Documentation/powerpc/dscr.rst
similarity index 91%
rename from Documentation/powerpc/dscr.txt
rename to Documentation/powerpc/dscr.rst
index ece300c64f76..2ab99006014c 100644
--- a/Documentation/powerpc/dscr.txt
+++ b/Documentation/powerpc/dscr.rst
@@ -1,5 +1,6 @@
- DSCR (Data Stream Control Register)
- ================================================
+===================================
+DSCR (Data Stream Control Register)
+===================================
DSCR register in powerpc allows user to have some control of prefetch of data
stream in the processor. Please refer to the ISA documents or related manual
@@ -10,14 +11,17 @@ user interface.
(A) Data Structures:
- (1) thread_struct:
+ (1) thread_struct::
+
dscr /* Thread DSCR value */
dscr_inherit /* Thread has changed default DSCR */
- (2) PACA:
+ (2) PACA::
+
dscr_default /* per-CPU DSCR default value */
- (3) sysfs.c:
+ (3) sysfs.c::
+
dscr_default /* System DSCR default value */
(B) Scheduler Changes:
@@ -35,8 +39,8 @@ user interface.
(C) SYSFS Interface:
- Global DSCR default: /sys/devices/system/cpu/dscr_default
- CPU specific DSCR default: /sys/devices/system/cpu/cpuN/dscr
+ - Global DSCR default: /sys/devices/system/cpu/dscr_default
+ - CPU specific DSCR default: /sys/devices/system/cpu/cpuN/dscr
Changing the global DSCR default in the sysfs will change all the CPU
specific DSCR defaults immediately in their PACA structures. Again if
diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.rst
similarity index 82%
rename from Documentation/powerpc/eeh-pci-error-recovery.txt
rename to Documentation/powerpc/eeh-pci-error-recovery.rst
index 678189280bb4..438a87ebc095 100644
--- a/Documentation/powerpc/eeh-pci-error-recovery.txt
+++ b/Documentation/powerpc/eeh-pci-error-recovery.rst
@@ -1,10 +1,10 @@
+==========================
+PCI Bus EEH Error Recovery
+==========================
+Linas Vepstas <linas@austin.ibm.com>
- PCI Bus EEH Error Recovery
- --------------------------
- Linas Vepstas
- <linas@austin.ibm.com>
- 12 January 2005
+12 January 2005
Overview:
@@ -143,17 +143,17 @@ seen in /proc/ppc64/eeh (subject to change). Normally, almost
all of these occur during boot, when the PCI bus is scanned, where
a large number of 0xff reads are part of the bus scan procedure.
-If a frozen slot is detected, code in
-arch/powerpc/platforms/pseries/eeh.c will print a stack trace to
-syslog (/var/log/messages). This stack trace has proven to be very
-useful to device-driver authors for finding out at what point the EEH
-error was detected, as the error itself usually occurs slightly
+If a frozen slot is detected, code in
+arch/powerpc/platforms/pseries/eeh.c will print a stack trace to
+syslog (/var/log/messages). This stack trace has proven to be very
+useful to device-driver authors for finding out at what point the EEH
+error was detected, as the error itself usually occurs slightly
beforehand.
Next, it uses the Linux kernel notifier chain/work queue mechanism to
allow any interested parties to find out about the failure. Device
drivers, or other parts of the kernel, can use
-eeh_register_notifier(struct notifier_block *) to find out about EEH
+`eeh_register_notifier(struct notifier_block *)` to find out about EEH
events. The event will include a pointer to the pci device, the
device node and some state info. Receivers of the event can "do as
they wish"; the default handler will be described further in this
@@ -162,10 +162,13 @@ section.
To assist in the recovery of the device, eeh.c exports the
following functions:
-rtas_set_slot_reset() -- assert the PCI #RST line for 1/8th of a second
-rtas_configure_bridge() -- ask firmware to configure any PCI bridges
+rtas_set_slot_reset()
+ assert the PCI #RST line for 1/8th of a second
+rtas_configure_bridge()
+ ask firmware to configure any PCI bridges
located topologically under the pci slot.
-eeh_save_bars() and eeh_restore_bars(): save and restore the PCI
+eeh_save_bars() and eeh_restore_bars():
+ save and restore the PCI
config-space info for a device and any devices under it.
@@ -191,7 +194,7 @@ events get delivered to user-space scripts.
Following is an example sequence of events that cause a device driver
close function to be called during the first phase of an EEH reset.
-The following sequence is an example of the pcnet32 device driver.
+The following sequence is an example of the pcnet32 device driver::
rpa_php_unconfig_pci_adapter (struct slot *) // in rpaphp_pci.c
{
@@ -241,53 +244,54 @@ The following sequence is an example of the pcnet32 device driver.
}}}}}}
- in drivers/pci/pci_driver.c,
- struct device_driver->remove() is just pci_device_remove()
- which calls struct pci_driver->remove() which is pcnet32_remove_one()
- which calls unregister_netdev() (in net/core/dev.c)
- which calls dev_close() (in net/core/dev.c)
- which calls dev->stop() which is pcnet32_close()
- which then does the appropriate shutdown.
+in drivers/pci/pci_driver.c,
+struct device_driver->remove() is just pci_device_remove()
+which calls struct pci_driver->remove() which is pcnet32_remove_one()
+which calls unregister_netdev() (in net/core/dev.c)
+which calls dev_close() (in net/core/dev.c)
+which calls dev->stop() which is pcnet32_close()
+which then does the appropriate shutdown.
---
+
Following is the analogous stack trace for events sent to user-space
-when the pci device is unconfigured.
+when the pci device is unconfigured::
-rpa_php_unconfig_pci_adapter() { // in rpaphp_pci.c
- calls
- pci_remove_bus_device (struct pci_dev *) { // in /drivers/pci/remove.c
+ rpa_php_unconfig_pci_adapter() { // in rpaphp_pci.c
calls
- pci_destroy_dev (struct pci_dev *) {
+ pci_remove_bus_device (struct pci_dev *) { // in /drivers/pci/remove.c
calls
- device_unregister (&dev->dev) { // in /drivers/base/core.c
+ pci_destroy_dev (struct pci_dev *) {
calls
- device_del(struct device * dev) { // in /drivers/base/core.c
+ device_unregister (&dev->dev) { // in /drivers/base/core.c
calls
- kobject_del() { //in /libs/kobject.c
+ device_del(struct device * dev) { // in /drivers/base/core.c
calls
- kobject_uevent() { // in /libs/kobject.c
+ kobject_del() { //in /libs/kobject.c
calls
- kset_uevent() { // in /lib/kobject.c
+ kobject_uevent() { // in /libs/kobject.c
calls
- kset->uevent_ops->uevent() // which is really just
- a call to
- dev_uevent() { // in /drivers/base/core.c
+ kset_uevent() { // in /lib/kobject.c
calls
- dev->bus->uevent() which is really just a call to
- pci_uevent () { // in drivers/pci/hotplug.c
- which prints device name, etc....
+ kset->uevent_ops->uevent() // which is really just
+ a call to
+ dev_uevent() { // in /drivers/base/core.c
+ calls
+ dev->bus->uevent() which is really just a call to
+ pci_uevent () { // in drivers/pci/hotplug.c
+ which prints device name, etc....
+ }
}
- }
- then kobject_uevent() sends a netlink uevent to userspace
- --> userspace uevent
- (during early boot, nobody listens to netlink events and
- kobject_uevent() executes uevent_helper[], which runs the
- event process /sbin/hotplug)
+ then kobject_uevent() sends a netlink uevent to userspace
+ --> userspace uevent
+ (during early boot, nobody listens to netlink events and
+ kobject_uevent() executes uevent_helper[], which runs the
+ event process /sbin/hotplug)
+ }
}
- }
- kobject_del() then calls sysfs_remove_dir(), which would
- trigger any user-space daemon that was watching /sysfs,
- and notice the delete event.
+ kobject_del() then calls sysfs_remove_dir(), which would
+ trigger any user-space daemon that was watching /sysfs,
+ and notice the delete event.
Pro's and Con's of the Current Design
@@ -299,12 +303,12 @@ individual device drivers, so that the current design throws a wide net.
The biggest negative of the design is that it potentially disturbs
network daemons and file systems that didn't need to be disturbed.
--- A minor complaint is that resetting the network card causes
+- A minor complaint is that resetting the network card causes
user-space back-to-back ifdown/ifup burps that potentially disturb
network daemons, that didn't need to even know that the pci
card was being rebooted.
--- A more serious concern is that the same reset, for SCSI devices,
+- A more serious concern is that the same reset, for SCSI devices,
causes havoc to mounted file systems. Scripts cannot post-facto
unmount a file system without flushing pending buffers, but this
is impossible, because I/O has already been stopped. Thus,
@@ -322,7 +326,7 @@ network daemons and file systems that didn't need to be disturbed.
from the block layer. It would be very natural to add an EEH
reset into this chain of events.
--- If a SCSI error occurs for the root device, all is lost unless
+- If a SCSI error occurs for the root device, all is lost unless
the sysadmin had the foresight to run /bin, /sbin, /etc, /var
and so on, out of ramdisk/tmpfs.
@@ -330,5 +334,3 @@ network daemons and file systems that didn't need to be disturbed.
Conclusions
-----------
There's forward progress ...
-
-
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.rst
similarity index 80%
rename from Documentation/powerpc/firmware-assisted-dump.txt
rename to Documentation/powerpc/firmware-assisted-dump.rst
index 0c41d6d463f3..d7fa7c35dd12 100644
--- a/Documentation/powerpc/firmware-assisted-dump.txt
+++ b/Documentation/powerpc/firmware-assisted-dump.rst
@@ -1,7 +1,8 @@
+======================
+Firmware-Assisted Dump
+======================
- Firmware-Assisted Dump
- ------------------------
- July 2011
+July 2011
The goal of firmware-assisted dump is to enable the dump of
a crashed system, and to do so from a fully-reset system, and
@@ -27,11 +28,11 @@ in production use.
Comparing with kdump or other strategies, firmware-assisted
dump offers several strong, practical advantages:
--- Unlike kdump, the system has been reset, and loaded
+- Unlike kdump, the system has been reset, and loaded
with a fresh copy of the kernel. In particular,
PCI and I/O devices have been reinitialized and are
in a clean, consistent state.
--- Once the dump is copied out, the memory that held the dump
+- Once the dump is copied out, the memory that held the dump
is immediately available to the running kernel. And therefore,
unlike kdump, fadump doesn't need a 2nd reboot to get back
the system to the production configuration.
@@ -40,17 +41,18 @@ The above can only be accomplished by coordination with,
and assistance from the Power firmware. The procedure is
as follows:
--- The first kernel registers the sections of memory with the
+- The first kernel registers the sections of memory with the
Power firmware for dump preservation during OS initialization.
These registered sections of memory are reserved by the first
kernel during early boot.
--- When a system crashes, the Power firmware will save
+- When a system crashes, the Power firmware will save
the low memory (boot memory of size larger of 5% of system RAM
or 256MB) of RAM to the previous registered region. It will
also save system registers, and hardware PTE's.
- NOTE: The term 'boot memory' means size of the low memory chunk
+ NOTE:
+ The term 'boot memory' means size of the low memory chunk
that is required for a kernel to boot successfully when
booted with restricted memory. By default, the boot memory
size will be the larger of 5% of system RAM or 256MB.
@@ -64,12 +66,12 @@ as follows:
as fadump uses a predefined offset to reserve memory
for boot memory dump preservation in case of a crash.
--- After the low memory (boot memory) area has been saved, the
+- After the low memory (boot memory) area has been saved, the
firmware will reset PCI and other hardware state. It will
*not* clear the RAM. It will then launch the bootloader, as
normal.
--- The freshly booted kernel will notice that there is a new
+- The freshly booted kernel will notice that there is a new
node (ibm,dump-kernel) in the device tree, indicating that
there is crash data available from a previous boot. During
the early boot OS will reserve rest of the memory above
@@ -77,17 +79,18 @@ as follows:
size. This will make sure that the second kernel will not
touch any of the dump memory area.
--- User-space tools will read /proc/vmcore to obtain the contents
+- User-space tools will read /proc/vmcore to obtain the contents
of memory, which holds the previous crashed kernel dump in ELF
format. The userspace tools may copy this info to disk, or
network, nas, san, iscsi, etc. as desired.
--- Once the userspace tool is done saving dump, it will echo
+- Once the userspace tool is done saving dump, it will echo
'1' to /sys/kernel/fadump_release_mem to release the reserved
memory back to general use, except the memory required for
next firmware-assisted dump registration.
- e.g.
+ e.g.::
+
# echo 1 > /sys/kernel/fadump_release_mem
Please note that the firmware-assisted dump feature
@@ -95,7 +98,7 @@ is only available on Power6 and above systems with recent
firmware versions.
Implementation details:
-----------------------
+-----------------------
During boot, a check is made to see if firmware supports
this feature on that particular machine. If it does, then
@@ -121,7 +124,7 @@ Allocator (CMA) for memory reservation if CMA is configured for kernel.
With CMA reservation this memory will be available for applications to
use it, while kernel is prevented from using it. With this fadump will
still be able to capture all of the kernel memory and most of the user
-space memory except the user pages that were present in CMA region.
+space memory except the user pages that were present in CMA region::
o Memory Reservation during first kernel
@@ -166,7 +169,7 @@ The tools to examine the dump will be same as the ones
used for kdump.
How to enable firmware-assisted dump (fadump):
--------------------------------------
+----------------------------------------------
1. Set config option CONFIG_FA_DUMP=y and build kernel.
2. Boot into linux kernel with 'fadump=on' kernel cmdline option.
@@ -177,19 +180,20 @@ How to enable firmware-assisted dump (fadump):
to specify size of the memory to reserve for boot memory dump
preservation.
-NOTE: 1. 'fadump_reserve_mem=' parameter has been deprecated. Instead
- use 'crashkernel=' to specify size of the memory to reserve
- for boot memory dump preservation.
- 2. If firmware-assisted dump fails to reserve memory then it
- will fallback to existing kdump mechanism if 'crashkernel='
- option is set at kernel cmdline.
- 3. if user wants to capture all of user space memory and ok with
- reserved memory not available to production system, then
- 'fadump=nocma' kernel parameter can be used to fallback to
- old behaviour.
+NOTE:
+ 1. 'fadump_reserve_mem=' parameter has been deprecated. Instead
+ use 'crashkernel=' to specify size of the memory to reserve
+ for boot memory dump preservation.
+ 2. If firmware-assisted dump fails to reserve memory then it
+ will fallback to existing kdump mechanism if 'crashkernel='
+ option is set at kernel cmdline.
+ 3. if user wants to capture all of user space memory and ok with
+ reserved memory not available to production system, then
+ 'fadump=nocma' kernel parameter can be used to fallback to
+ old behaviour.
Sysfs/debugfs files:
-------------
+--------------------
Firmware-assisted dump feature uses sysfs file system to hold
the control files and debugfs file to display memory reserved region.
@@ -197,20 +201,20 @@ the control files and debugfs file to display memory reserved region.
Here is the list of files under kernel sysfs:
/sys/kernel/fadump_enabled
-
This is used to display the fadump status.
- 0 = fadump is disabled
- 1 = fadump is enabled
+
+ - 0 = fadump is disabled
+ - 1 = fadump is enabled
This interface can be used by kdump init scripts to identify if
fadump is enabled in the kernel and act accordingly.
/sys/kernel/fadump_registered
-
This is used to display the fadump registration status as well
as to control (start/stop) the fadump registration.
- 0 = fadump is not registered.
- 1 = fadump is registered and ready to handle system crash.
+
+ - 0 = fadump is not registered.
+ - 1 = fadump is registered and ready to handle system crash.
To register fadump echo 1 > /sys/kernel/fadump_registered and
echo 0 > /sys/kernel/fadump_registered for un-register and stop the
@@ -219,13 +223,12 @@ Here is the list of files under kernel sysfs:
easily integrated with kdump service start/stop.
/sys/kernel/fadump_release_mem
-
This file is available only when fadump is active during
second kernel. This is used to release the reserved memory
region that are held for saving crash dump. To release the
- reserved memory echo 1 to it:
+ reserved memory echo 1 to it::
- echo 1 > /sys/kernel/fadump_release_mem
+ echo 1 > /sys/kernel/fadump_release_mem
After echo 1, the content of the /sys/kernel/debug/powerpc/fadump_region
file will change to reflect the new memory reservations.
@@ -238,38 +241,39 @@ Here is the list of files under powerpc debugfs:
(Assuming debugfs is mounted on /sys/kernel/debug directory.)
/sys/kernel/debug/powerpc/fadump_region
-
This file shows the reserved memory regions if fadump is
enabled otherwise this file is empty. The output format
- is:
- <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
+ is::
+
+ <region>: [<start>-<end>] <reserved-size> bytes, Dumped: <dump-size>
e.g.
- Contents when fadump is registered during first kernel
+ Contents when fadump is registered during first kernel::
- # cat /sys/kernel/debug/powerpc/fadump_region
- CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
- HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
- DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
+ # cat /sys/kernel/debug/powerpc/fadump_region
+ CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0
+ HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0
+ DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0
- Contents when fadump is active during second kernel
+ Contents when fadump is active during second kernel::
- # cat /sys/kernel/debug/powerpc/fadump_region
- CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020
- HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000
- DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000
- : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000
+ # cat /sys/kernel/debug/powerpc/fadump_region
+ CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020
+ HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000
+ DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000
+ : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000
-NOTE: Please refer to Documentation/filesystems/debugfs.txt on
+NOTE:
+ Please refer to Documentation/filesystems/debugfs.txt on
how to mount the debugfs filesystem.
TODO:
-----
- o Need to come up with the better approach to find out more
+ - Need to come up with the better approach to find out more
accurate boot memory size that is required for a kernel to
boot successfully when booted with restricted memory.
- o The fadump implementation introduces a fadump crash info structure
+ - The fadump implementation introduces a fadump crash info structure
in the scratch area before the ELF core header. The idea of introducing
this structure is to pass some important crash info data to the second
kernel which will help second kernel to populate ELF core header with
@@ -277,7 +281,9 @@ TODO:
design implementation does not address a possibility of introducing
additional fields (in future) to this structure without affecting
compatibility. Need to come up with the better approach to address this.
+
The possible approaches are:
+
1. Introduce version field for version tracking, bump up the version
whenever a new field is added to the structure in future. The version
field can be used to find out what fields are valid for the current
@@ -285,8 +291,11 @@ TODO:
2. Reserve the area of predefined size (say PAGE_SIZE) for this
structure and have unused area as reserved (initialized to zero)
for future field additions.
+
The advantage of approach 1 over 2 is we don't need to reserve extra space.
----
+
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
+
This document is based on the original documentation written for phyp
+
assisted dump by Linas Vepstas and Manish Ahuja.
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.rst
similarity index 91%
rename from Documentation/powerpc/hvcs.txt
rename to Documentation/powerpc/hvcs.rst
index a730ca5a07f8..6808acde672f 100644
--- a/Documentation/powerpc/hvcs.txt
+++ b/Documentation/powerpc/hvcs.rst
@@ -1,19 +1,22 @@
-===========================================================================
- HVCS
- IBM "Hypervisor Virtual Console Server" Installation Guide
- for Linux Kernel 2.6.4+
- Copyright (C) 2004 IBM Corporation
+===============================================================
+HVCS IBM "Hypervisor Virtual Console Server" Installation Guide
+===============================================================
-===========================================================================
-NOTE:Eight space tabs are the optimum editor setting for reading this file.
-===========================================================================
+for Linux Kernel 2.6.4+
- Author(s) : Ryan S. Arnold <rsa@us.ibm.com>
- Date Created: March, 02, 2004
- Last Changed: August, 24, 2004
+Copyright (C) 2004 IBM Corporation
----------------------------------------------------------------------------
-Table of contents:
+.. ===========================================================================
+.. NOTE:Eight space tabs are the optimum editor setting for reading this file.
+.. ===========================================================================
+
+
+Author(s): Ryan S. Arnold <rsa@us.ibm.com>
+
+Date Created: March, 02, 2004
+Last Changed: August, 24, 2004
+
+.. Table of contents:
1. Driver Introduction:
2. System Requirements
@@ -27,8 +30,8 @@ Table of contents:
8. Questions & Answers:
9. Reporting Bugs:
----------------------------------------------------------------------------
1. Driver Introduction:
+=======================
This is the device driver for the IBM Hypervisor Virtual Console Server,
"hvcs". The IBM hvcs provides a tty driver interface to allow Linux user
@@ -38,8 +41,8 @@ ppc64 system. Physical hardware consoles per partition are not practical
on this hardware so system consoles are accessed by this driver using
firmware interfaces to virtual terminal devices.
----------------------------------------------------------------------------
2. System Requirements:
+=======================
This device driver was written using 2.6.4 Linux kernel APIs and will only
build and run on kernels of this version or later.
@@ -52,8 +55,8 @@ Sysfs must be mounted on the system so that the user can determine which
major and minor numbers are associated with each vty-server. Directions
for sysfs mounting are outside the scope of this document.
----------------------------------------------------------------------------
3. Build Options:
+=================
The hvcs driver registers itself as a tty driver. The tty layer
dynamically allocates a block of major and minor numbers in a quantity
@@ -65,11 +68,11 @@ If the default number of device entries is adequate then this driver can be
built into the kernel. If not, the default can be over-ridden by inserting
the driver as a module with insmod parameters.
----------------------------------------------------------------------------
3.1 Built-in:
+-------------
The following menuconfig example demonstrates selecting to build this
-driver into the kernel.
+driver into the kernel::
Device Drivers --->
Character devices --->
@@ -77,11 +80,11 @@ driver into the kernel.
Begin the kernel make process.
----------------------------------------------------------------------------
3.2 Module:
+-----------
The following menuconfig example demonstrates selecting to build this
-driver as a kernel module.
+driver as a kernel module::
Device Drivers --->
Character devices --->
@@ -89,11 +92,11 @@ driver as a kernel module.
The make process will build the following kernel modules:
- hvcs.ko
- hvcserver.ko
+ - hvcs.ko
+ - hvcserver.ko
To insert the module with the default allocation execute the following
-commands in the order they appear:
+commands in the order they appear::
insmod hvcserver.ko
insmod hvcs.ko
@@ -103,7 +106,7 @@ be inserted first, otherwise the hvcs module will not find some of the
symbols it expects.
To override the default use an insmod parameter as follows (requesting 4
-tty devices as an example):
+tty devices as an example)::
insmod hvcs.ko hvcs_parm_num_devs=4
@@ -115,31 +118,31 @@ source file before building.
NOTE: The length of time it takes to insmod the driver seems to be related
to the number of tty interfaces the registering driver requests.
-In order to remove the driver module execute the following command:
+In order to remove the driver module execute the following command::
rmmod hvcs.ko
The recommended method for installing hvcs as a module is to use depmod to
build a current modules.dep file in /lib/modules/`uname -r` and then
-execute:
+execute::
-modprobe hvcs hvcs_parm_num_devs=4
+ modprobe hvcs hvcs_parm_num_devs=4
The modules.dep file indicates that hvcserver.ko needs to be inserted
before hvcs.ko and modprobe uses this file to smartly insert the modules in
the proper order.
The following modprobe command is used to remove hvcs and hvcserver in the
-proper order:
+proper order::
-modprobe -r hvcs
+ modprobe -r hvcs
----------------------------------------------------------------------------
4. Installation:
+================
The tty layer creates sysfs entries which contain the major and minor
numbers allocated for the hvcs driver. The following snippet of "tree"
-output of the sysfs directory shows where these numbers are presented:
+output of the sysfs directory shows where these numbers are presented::
sys/
|-- *other sysfs base dirs*
@@ -164,7 +167,7 @@ output of the sysfs directory shows where these numbers are presented:
|-- *other sysfs base dirs*
For the above examples the following output is a result of cat'ing the
-"dev" entry in the hvcs directory:
+"dev" entry in the hvcs directory::
Pow5:/sys/class/tty/hvcs0/ # cat dev
254:0
@@ -184,7 +187,7 @@ systems running hvcs will already have the device entries created or udev
will do it automatically.
Given the example output above, to manually create a /dev/hvcs* node entry
-mknod can be used as follows:
+mknod can be used as follows::
mknod /dev/hvcs0 c 254 0
mknod /dev/hvcs1 c 254 1
@@ -195,15 +198,15 @@ Using mknod to manually create the device entries makes these device nodes
persistent. Once created they will exist prior to the driver insmod.
Attempting to connect an application to /dev/hvcs* prior to insertion of
-the hvcs module will result in an error message similar to the following:
+the hvcs module will result in an error message similar to the following::
"/dev/hvcs*: No such device".
NOTE: Just because there is a device node present doesn't mean that there
is a vty-server device configured for that node.
----------------------------------------------------------------------------
5. Connection
+=============
Since this driver controls devices that provide a tty interface a user can
interact with the device node entries using any standard tty-interactive
@@ -249,7 +252,7 @@ vty-server adapter is associated with which /dev/hvcs* node a special sysfs
attribute has been added to each vty-server sysfs entry. This entry is
called "index" and showing it reveals an integer that refers to the
/dev/hvcs* entry to use to connect to that device. For instance cating the
-index attribute of vty-server adapter 30000004 shows the following.
+index attribute of vty-server adapter 30000004 shows the following::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat index
2
@@ -262,8 +265,8 @@ system the /dev/hvcs* entry that interacts with a particular vty-server
adapter is not guaranteed to remain the same across system reboots. Look
in the Q & A section for more on this issue.
----------------------------------------------------------------------------
6. Disconnection
+================
As a security feature to prevent the delivery of stale data to an
unintended target the Power5 system firmware disables the fetching of data
@@ -305,7 +308,7 @@ connection between the vty-server and target vty ONLY if the vterm_state
previously read '1'. The write directive is ignored if the vterm_state
read '0' or if any value other than '0' was written to the vterm_state
attribute. The following example will show the method used for verifying
-the vty-server connection status and disconnecting a vty-server connection.
+the vty-server connection status and disconnecting a vty-server connection::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat vterm_state
1
@@ -318,12 +321,12 @@ the vty-server connection status and disconnecting a vty-server connection.
All vty-server connections are automatically terminated when the device is
hotplug removed and when the module is removed.
----------------------------------------------------------------------------
7. Configuration
+================
Each vty-server has a sysfs entry in the /sys/devices/vio directory, which
is symlinked in several other sysfs tree directories, notably under the
-hvcs driver entry, which looks like the following example:
+hvcs driver entry, which looks like the following example::
Pow5:/sys/bus/vio/drivers/hvcs # ls
. .. 30000003 30000004 rescan
@@ -344,7 +347,7 @@ completed or was never executed.
Vty-server entries in this directory are a 32 bit partition unique unit
address that is created by firmware. An example vty-server sysfs entry
-looks like the following:
+looks like the following::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # ls
. current_vty devspec name partner_vtys
@@ -352,21 +355,21 @@ looks like the following:
Each entry is provided, by default with a "name" attribute. Reading the
"name" attribute will reveal the device type as shown in the following
-example:
+example::
Pow5:/sys/bus/vio/drivers/hvcs/30000003 # cat name
vty-server
Each entry is also provided, by default, with a "devspec" attribute which
reveals the full device specification when read, as shown in the following
-example:
+example::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat devspec
/vdevice/vty-server@30000004
Each vty-server sysfs dir is provided with two read-only attributes that
provide lists of easily parsed partner vty data: "partner_vtys" and
-"partner_clcs".
+"partner_clcs"::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # cat partner_vtys
30000000
@@ -396,7 +399,7 @@ A vty-server can only be connected to a single vty at a time. The entry,
read.
The current_vty can be changed by writing a valid partner clc to the entry
-as in the following example:
+as in the following example::
Pow5:/sys/bus/vio/drivers/hvcs/30000004 # echo U5112.428.10304
8A-V4-C0 > current_vty
@@ -408,9 +411,9 @@ currently open connection is freed.
Information on the "vterm_state" attribute was covered earlier on the
chapter entitled "disconnection".
----------------------------------------------------------------------------
8. Questions & Answers:
-===========================================================================
+=======================
+
Q: What are the security concerns involving hvcs?
A: There are three main security concerns:
@@ -429,6 +432,7 @@ A: There are three main security concerns:
partition) will experience the previously logged in session.
---------------------------------------------------------------------------
+
Q: How do I multiplex a console that I grab through hvcs so that other
people can see it:
@@ -440,6 +444,7 @@ term type "screen" to others. This means that curses based programs may
not display properly in screen sessions.
---------------------------------------------------------------------------
+
Q: Why are the colors all messed up?
Q: Why are the control characters acting strange or not working?
Q: Why is the console output all strange and unintelligible?
@@ -455,6 +460,7 @@ disconnect from the console. This will ensure that the next user gets
their own TERM type set when they login.
---------------------------------------------------------------------------
+
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, can't open connection: /dev/hvcs*"What is happening?
@@ -490,6 +496,7 @@ A: There is not a corresponding vty-server device that maps to an existing
/dev/hvcs* entry.
---------------------------------------------------------------------------
+
Q: When I try to CONNECT kermit to an hvcs device I get:
"Sorry, write access to UUCP lockfile directory denied."
@@ -497,6 +504,7 @@ A: The /dev/hvcs* entry you have specified doesn't exist where you said it
does? Maybe you haven't inserted the module (on systems with udev).
---------------------------------------------------------------------------
+
Q: If I already have one Linux partition installed can I use hvcs on said
partition to provide the console for the install of a second Linux
partition?
@@ -505,6 +513,7 @@ A: Yes granted that your are connected to the /dev/hvcs* device using
kermit or cu or some other program that doesn't provide terminal emulation.
---------------------------------------------------------------------------
+
Q: Can I connect to more than one partition's console at a time using this
driver?
@@ -512,6 +521,7 @@ A: Yes. Of course this means that there must be more than one vty-server
configured for this partition and each must point to a disconnected vty.
---------------------------------------------------------------------------
+
Q: Does the hvcs driver support dynamic (hotplug) addition of devices?
A: Yes, if you have dlpar and hotplug enabled for your system and it has
@@ -519,6 +529,7 @@ been built into the kernel the hvcs drivers is configured to dynamically
handle additions of new devices and removals of unused devices.
---------------------------------------------------------------------------
+
Q: For some reason /dev/hvcs* doesn't map to the same vty-server adapter
after a reboot. What happened?
@@ -533,6 +544,7 @@ on how to determine which vty-server goes with which /dev/hvcs* node.
Hint; look at the sysfs "index" attribute for the vty-server.
---------------------------------------------------------------------------
+
Q: Can I use /dev/hvcs* as a conduit to another partition and use a tty
device on that partition as the other end of the pipe?
@@ -554,7 +566,9 @@ read or write to /dev/hvcs*. Now you have a tty conduit between two
partitions.
---------------------------------------------------------------------------
+
9. Reporting Bugs:
+==================
The proper channel for reporting bugs is either through the Linux OS
distribution company that provided your OS or by posting issues to the
diff --git a/Documentation/powerpc/index.rst b/Documentation/powerpc/index.rst
new file mode 100644
index 000000000000..1ff17268db46
--- /dev/null
+++ b/Documentation/powerpc/index.rst
@@ -0,0 +1,34 @@
+:orphan:
+
+=======
+powerpc
+=======
+
+.. toctree::
+ :maxdepth: 1
+
+ bootwrapper
+ cpu_families
+ cpu_features
+ cxl
+ cxlflash
+ dawr-power9
+ dscr
+ eeh-pci-error-recovery
+ firmware-assisted-dump
+ hvcs
+ isa-versions
+ mpc52xx
+ pci_iov_resource_on_powernv
+ pmu-ebb
+ ptrace
+ qe_firmware
+ syscall64-abi
+ transactional_memory
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/powerpc/isa-versions.rst b/Documentation/powerpc/isa-versions.rst
index 812e20cc898c..a363d8c1603c 100644
--- a/Documentation/powerpc/isa-versions.rst
+++ b/Documentation/powerpc/isa-versions.rst
@@ -1,11 +1,12 @@
+==========================
CPU to ISA Version Mapping
==========================
Mapping of some CPU versions to relevant ISA versions.
-========= ====================
+========= ====================================================================
CPU Architecture version
-========= ====================
+========= ====================================================================
Power9 Power ISA v3.0B
Power8 Power ISA v2.07
Power7 Power ISA v2.06
@@ -22,7 +23,7 @@ PPC970 - PowerPC User Instruction Set Architecture Book I v2.01
- PowerPC Virtual Environment Architecture Book II v2.01
- PowerPC Operating Environment Architecture Book III v2.01
- Plus Altivec/VMX ~= 2.03
-========= ====================
+========= ====================================================================
Key Features
@@ -58,9 +59,9 @@ Power5 No
PPC970 No
========== ====
-========== ====================
+========== ====================================
CPU Transactional Memory
-========== ====================
+========== ====================================
Power9 Yes (* see transactional_memory.txt)
Power8 Yes
Power7 No
@@ -71,4 +72,4 @@ Power5++ No
Power5+ No
Power5 No
PPC970 No
-========== ====================
+========== ====================================
diff --git a/Documentation/powerpc/mpc52xx.txt b/Documentation/powerpc/mpc52xx.rst
similarity index 91%
rename from Documentation/powerpc/mpc52xx.txt
rename to Documentation/powerpc/mpc52xx.rst
index 0d540a31ea1a..8676ac63e077 100644
--- a/Documentation/powerpc/mpc52xx.txt
+++ b/Documentation/powerpc/mpc52xx.rst
@@ -1,11 +1,13 @@
+=============================
Linux 2.6.x on MPC52xx family
------------------------------
+=============================
For the latest info, go to http://www.246tNt.com/mpc52xx/
To compile/use :
- - U-Boot:
+ - U-Boot::
+
# <edit Makefile to set ARCH=ppc & CROSS_COMPILE=... ( also EXTRAVERSION
if you wish to ).
# make lite5200_defconfig
@@ -16,7 +18,8 @@ To compile/use :
=> tftpboot 400000 pRamdisk
=> bootm 200000 400000
- - DBug:
+ - DBug::
+
# <edit Makefile to set ARCH=ppc & CROSS_COMPILE=... ( also EXTRAVERSION
if you wish to ).
# make lite5200_defconfig
@@ -28,7 +31,8 @@ To compile/use :
DBug> dn -i zImage.initrd.lite5200
-Some remarks :
+Some remarks:
+
- The port is named mpc52xxx, and config options are PPC_MPC52xx. The MGT5100
is not supported, and I'm not sure anyone is interesting in working on it
so. I didn't took 5xxx because there's apparently a lot of 5xxx that have
diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt b/Documentation/powerpc/pci_iov_resource_on_powernv.rst
similarity index 97%
rename from Documentation/powerpc/pci_iov_resource_on_powernv.txt
rename to Documentation/powerpc/pci_iov_resource_on_powernv.rst
index b55c5cd83f8d..f5a5793e1613 100644
--- a/Documentation/powerpc/pci_iov_resource_on_powernv.txt
+++ b/Documentation/powerpc/pci_iov_resource_on_powernv.rst
@@ -1,6 +1,13 @@
+===================================================
+PCI Express I/O Virtualization Resource on Powerenv
+===================================================
+
Wei Yang <weiyang@linux.vnet.ibm.com>
+
Benjamin Herrenschmidt <benh@au1.ibm.com>
+
Bjorn Helgaas <bhelgaas@google.com>
+
26 Aug 2014
This document describes the requirement from hardware for PCI MMIO resource
@@ -10,6 +17,7 @@ Endpoints and the implementation on P8 (IODA2). The next two sections talks
about considerations on enabling SRIOV on IODA2.
1. Introduction to Partitionable Endpoints
+==========================================
A Partitionable Endpoint (PE) is a way to group the various resources
associated with a device or a set of devices to provide isolation between
@@ -35,6 +43,7 @@ is a completely separate HW entity that replicates the entire logic, so has
its own set of PEs, etc.
2. Implementation of Partitionable Endpoints on P8 (IODA2)
+==========================================================
P8 supports up to 256 Partitionable Endpoints per PHB.
@@ -149,6 +158,7 @@ P8 supports up to 256 Partitionable Endpoints per PHB.
sense, but we haven't done it yet.
3. Considerations for SR-IOV on PowerKVM
+========================================
* SR-IOV Background
@@ -224,7 +234,7 @@ P8 supports up to 256 Partitionable Endpoints per PHB.
IODA supports 256 PEs, so segmented windows contain 256 segments, so if
total_VFs is less than 256, we have the situation in Figure 1.0, where
segments [total_VFs, 255] of the M64 window may map to some MMIO range on
- other devices:
+ other devices::
0 1 total_VFs - 1
+------+------+- -+------+------+
@@ -243,7 +253,7 @@ P8 supports up to 256 Partitionable Endpoints per PHB.
Figure 1.0 Direct map VF(n) BAR space
Our current solution is to allocate 256 segments even if the VF(n) BAR
- space doesn't need that much, as shown in Figure 1.1:
+ space doesn't need that much, as shown in Figure 1.1::
0 1 total_VFs - 1 255
+------+------+- -+------+------+- -+------+------+
@@ -269,6 +279,7 @@ P8 supports up to 256 Partitionable Endpoints per PHB.
responds to segments [total_VFs, 255].
4. Implications for the Generic PCI Code
+========================================
The PCIe SR-IOV spec requires that the base of the VF(n) BAR space be
aligned to the size of an individual VF BAR.
diff --git a/Documentation/powerpc/pmu-ebb.txt b/Documentation/powerpc/pmu-ebb.rst
similarity index 99%
rename from Documentation/powerpc/pmu-ebb.txt
rename to Documentation/powerpc/pmu-ebb.rst
index 73cd163dbfb8..4f474758eb55 100644
--- a/Documentation/powerpc/pmu-ebb.txt
+++ b/Documentation/powerpc/pmu-ebb.rst
@@ -1,3 +1,4 @@
+========================
PMU Event Based Branches
========================
diff --git a/Documentation/powerpc/ptrace.rst b/Documentation/powerpc/ptrace.rst
new file mode 100644
index 000000000000..864d4b6dddd1
--- /dev/null
+++ b/Documentation/powerpc/ptrace.rst
@@ -0,0 +1,156 @@
+======
+Ptrace
+======
+
+GDB intends to support the following hardware debug features of BookE
+processors:
+
+4 hardware breakpoints (IAC)
+2 hardware watchpoints (read, write and read-write) (DAC)
+2 value conditions for the hardware watchpoints (DVC)
+
+For that, we need to extend ptrace so that GDB can query and set these
+resources. Since we're extending, we're trying to create an interface
+that's extendable and that covers both BookE and server processors, so
+that GDB doesn't need to special-case each of them. We added the
+following 3 new ptrace requests.
+
+1. PTRACE_PPC_GETHWDEBUGINFO
+============================
+
+Query for GDB to discover the hardware debug features. The main info to
+be returned here is the minimum alignment for the hardware watchpoints.
+BookE processors don't have restrictions here, but server processors have
+an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
+adding special cases to GDB based on what it sees in AUXV.
+
+Since we're at it, we added other useful info that the kernel can return to
+GDB: this query will return the number of hardware breakpoints, hardware
+watchpoints and whether it supports a range of addresses and a condition.
+The query will fill the following structure provided by the requesting process::
+
+ struct ppc_debug_info {
+ unit32_t version;
+ unit32_t num_instruction_bps;
+ unit32_t num_data_bps;
+ unit32_t num_condition_regs;
+ unit32_t data_bp_alignment;
+ unit32_t sizeof_condition; /* size of the DVC register */
+ uint64_t features; /* bitmask of the individual flags */
+ };
+
+features will have bits indicating whether there is support for::
+
+ #define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
+ #define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
+ #define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
+ #define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
+ #define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
+
+2. PTRACE_SETHWDEBUG
+
+Sets a hardware breakpoint or watchpoint, according to the provided structure::
+
+ struct ppc_hw_breakpoint {
+ uint32_t version;
+ #define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
+ #define PPC_BREAKPOINT_TRIGGER_READ 0x2
+ #define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
+ uint32_t trigger_type; /* only some combinations allowed */
+ #define PPC_BREAKPOINT_MODE_EXACT 0x0
+ #define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
+ #define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
+ #define PPC_BREAKPOINT_MODE_MASK 0x3
+ uint32_t addr_mode; /* address match mode */
+
+ #define PPC_BREAKPOINT_CONDITION_MODE 0x3
+ #define PPC_BREAKPOINT_CONDITION_NONE 0x0
+ #define PPC_BREAKPOINT_CONDITION_AND 0x1
+ #define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same thing as above */
+ #define PPC_BREAKPOINT_CONDITION_OR 0x2
+ #define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
+ #define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000 /* byte enable bits */
+ #define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
+ uint32_t condition_mode; /* break/watchpoint condition flags */
+
+ uint64_t addr;
+ uint64_t addr2;
+ uint64_t condition_value;
+ };
+
+A request specifies one event, not necessarily just one register to be set.
+For instance, if the request is for a watchpoint with a condition, both the
+DAC and DVC registers will be set in the same request.
+
+With this GDB can ask for all kinds of hardware breakpoints and watchpoints
+that the BookE supports. COMEFROM breakpoints available in server processors
+are not contemplated, but that is out of the scope of this work.
+
+ptrace will return an integer (handle) uniquely identifying the breakpoint or
+watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
+request to ask for its removal. Return -ENOSPC if the requested breakpoint
+can't be allocated on the registers.
+
+Some examples of using the structure to:
+
+- set a breakpoint in the first breakpoint register::
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = 0;
+
+- set a watchpoint which triggers on reads in the second watchpoint register::
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = 0;
+
+- set a watchpoint which triggers only with a specific value::
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
+ p.addr = (uint64_t) address;
+ p.addr2 = 0;
+ p.condition_value = (uint64_t) condition;
+
+- set a ranged hardware breakpoint::
+
+ p.version = PPC_DEBUG_CURRENT_VERSION;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
+- set a watchpoint in server processors (BookS)::
+
+ p.version = 1;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
+3. PTRACE_DELHWDEBUG
+
+Takes an integer which identifies an existing breakpoint or watchpoint
+(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
+corresponding breakpoint or watchpoint..
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
deleted file mode 100644
index 99c5ce88d0fe..000000000000
--- a/Documentation/powerpc/ptrace.txt
+++ /dev/null
@@ -1,151 +0,0 @@
-GDB intends to support the following hardware debug features of BookE
-processors:
-
-4 hardware breakpoints (IAC)
-2 hardware watchpoints (read, write and read-write) (DAC)
-2 value conditions for the hardware watchpoints (DVC)
-
-For that, we need to extend ptrace so that GDB can query and set these
-resources. Since we're extending, we're trying to create an interface
-that's extendable and that covers both BookE and server processors, so
-that GDB doesn't need to special-case each of them. We added the
-following 3 new ptrace requests.
-
-1. PTRACE_PPC_GETHWDEBUGINFO
-
-Query for GDB to discover the hardware debug features. The main info to
-be returned here is the minimum alignment for the hardware watchpoints.
-BookE processors don't have restrictions here, but server processors have
-an 8-byte alignment restriction for hardware watchpoints. We'd like to avoid
-adding special cases to GDB based on what it sees in AUXV.
-
-Since we're at it, we added other useful info that the kernel can return to
-GDB: this query will return the number of hardware breakpoints, hardware
-watchpoints and whether it supports a range of addresses and a condition.
-The query will fill the following structure provided by the requesting process:
-
-struct ppc_debug_info {
- unit32_t version;
- unit32_t num_instruction_bps;
- unit32_t num_data_bps;
- unit32_t num_condition_regs;
- unit32_t data_bp_alignment;
- unit32_t sizeof_condition; /* size of the DVC register */
- uint64_t features; /* bitmask of the individual flags */
-};
-
-features will have bits indicating whether there is support for:
-
-#define PPC_DEBUG_FEATURE_INSN_BP_RANGE 0x1
-#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x2
-#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x4
-#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x8
-#define PPC_DEBUG_FEATURE_DATA_BP_DAWR 0x10
-
-2. PTRACE_SETHWDEBUG
-
-Sets a hardware breakpoint or watchpoint, according to the provided structure:
-
-struct ppc_hw_breakpoint {
- uint32_t version;
-#define PPC_BREAKPOINT_TRIGGER_EXECUTE 0x1
-#define PPC_BREAKPOINT_TRIGGER_READ 0x2
-#define PPC_BREAKPOINT_TRIGGER_WRITE 0x4
- uint32_t trigger_type; /* only some combinations allowed */
-#define PPC_BREAKPOINT_MODE_EXACT 0x0
-#define PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE 0x1
-#define PPC_BREAKPOINT_MODE_RANGE_EXCLUSIVE 0x2
-#define PPC_BREAKPOINT_MODE_MASK 0x3
- uint32_t addr_mode; /* address match mode */
-
-#define PPC_BREAKPOINT_CONDITION_MODE 0x3
-#define PPC_BREAKPOINT_CONDITION_NONE 0x0
-#define PPC_BREAKPOINT_CONDITION_AND 0x1
-#define PPC_BREAKPOINT_CONDITION_EXACT 0x1 /* different name for the same thing as above */
-#define PPC_BREAKPOINT_CONDITION_OR 0x2
-#define PPC_BREAKPOINT_CONDITION_AND_OR 0x3
-#define PPC_BREAKPOINT_CONDITION_BE_ALL 0x00ff0000 /* byte enable bits */
-#define PPC_BREAKPOINT_CONDITION_BE(n) (1<<((n)+16))
- uint32_t condition_mode; /* break/watchpoint condition flags */
-
- uint64_t addr;
- uint64_t addr2;
- uint64_t condition_value;
-};
-
-A request specifies one event, not necessarily just one register to be set.
-For instance, if the request is for a watchpoint with a condition, both the
-DAC and DVC registers will be set in the same request.
-
-With this GDB can ask for all kinds of hardware breakpoints and watchpoints
-that the BookE supports. COMEFROM breakpoints available in server processors
-are not contemplated, but that is out of the scope of this work.
-
-ptrace will return an integer (handle) uniquely identifying the breakpoint or
-watchpoint just created. This integer will be used in the PTRACE_DELHWDEBUG
-request to ask for its removal. Return -ENOSPC if the requested breakpoint
-can't be allocated on the registers.
-
-Some examples of using the structure to:
-
-- set a breakpoint in the first breakpoint register
-
- p.version = PPC_DEBUG_CURRENT_VERSION;
- p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
- p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
- p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
- p.addr = (uint64_t) address;
- p.addr2 = 0;
- p.condition_value = 0;
-
-- set a watchpoint which triggers on reads in the second watchpoint register
-
- p.version = PPC_DEBUG_CURRENT_VERSION;
- p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
- p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
- p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
- p.addr = (uint64_t) address;
- p.addr2 = 0;
- p.condition_value = 0;
-
-- set a watchpoint which triggers only with a specific value
-
- p.version = PPC_DEBUG_CURRENT_VERSION;
- p.trigger_type = PPC_BREAKPOINT_TRIGGER_READ;
- p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
- p.condition_mode = PPC_BREAKPOINT_CONDITION_AND | PPC_BREAKPOINT_CONDITION_BE_ALL;
- p.addr = (uint64_t) address;
- p.addr2 = 0;
- p.condition_value = (uint64_t) condition;
-
-- set a ranged hardware breakpoint
-
- p.version = PPC_DEBUG_CURRENT_VERSION;
- p.trigger_type = PPC_BREAKPOINT_TRIGGER_EXECUTE;
- p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
- p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
- p.addr = (uint64_t) begin_range;
- p.addr2 = (uint64_t) end_range;
- p.condition_value = 0;
-
-- set a watchpoint in server processors (BookS)
-
- p.version = 1;
- p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
- p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
- or
- p.addr_mode = PPC_BREAKPOINT_MODE_EXACT;
-
- p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
- p.addr = (uint64_t) begin_range;
- /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
- * addr2 - addr <= 8 Bytes.
- */
- p.addr2 = (uint64_t) end_range;
- p.condition_value = 0;
-
-3. PTRACE_DELHWDEBUG
-
-Takes an integer which identifies an existing breakpoint or watchpoint
-(i.e., the value returned from PTRACE_SETHWDEBUG), and deletes the
-corresponding breakpoint or watchpoint..
diff --git a/Documentation/powerpc/qe_firmware.txt b/Documentation/powerpc/qe_firmware.rst
similarity index 95%
rename from Documentation/powerpc/qe_firmware.txt
rename to Documentation/powerpc/qe_firmware.rst
index e7ac24aec4ff..42f5103140c9 100644
--- a/Documentation/powerpc/qe_firmware.txt
+++ b/Documentation/powerpc/qe_firmware.rst
@@ -1,23 +1,23 @@
- Freescale QUICC Engine Firmware Uploading
- -----------------------------------------
+=========================================
+Freescale QUICC Engine Firmware Uploading
+=========================================
(c) 2007 Timur Tabi <timur at freescale.com>,
Freescale Semiconductor
-Table of Contents
-=================
+.. Table of Contents
- I - Software License for Firmware
+ I - Software License for Firmware
- II - Microcode Availability
+ II - Microcode Availability
- III - Description and Terminology
+ III - Description and Terminology
- IV - Microcode Programming Details
+ IV - Microcode Programming Details
- V - Firmware Structure Layout
+ V - Firmware Structure Layout
- VI - Sample Code for Creating Firmware Files
+ VI - Sample Code for Creating Firmware Files
Revision Information
====================
@@ -39,7 +39,7 @@ http://opensource.freescale.com. For other firmware files, please contact
your Freescale representative or your operating system vendor.
III - Description and Terminology
-================================
+=================================
In this document, the term 'microcode' refers to the sequence of 32-bit
integers that compose the actual QE microcode.
@@ -89,7 +89,7 @@ being fixed in the RAM package utilizing they should be activated. This data
structure signals the microcode which of these virtual traps is active.
This structure contains 6 words that the application should copy to some
-specific been defined. This table describes the structure.
+specific been defined. This table describes the structure::
---------------------------------------------------------------
| Offset in | | Destination Offset | Size of |
@@ -119,7 +119,7 @@ Extended Modes
This is a double word bit array (64 bits) that defines special functionality
which has an impact on the software drivers. Each bit has its own impact
and has special instructions for the s/w associated with it. This structure is
-described in this table:
+described in this table::
-----------------------------------------------------------------------
| Bit # | Name | Description |
@@ -220,7 +220,8 @@ The 'model' field is a 16-bit number that matches the actual SOC. The
'major' and 'minor' fields are the major and minor revision numbers,
respectively, of the SOC.
-For example, to match the 8323, revision 1.0:
+For example, to match the 8323, revision 1.0::
+
soc.model = 8323
soc.major = 1
soc.minor = 0
@@ -273,10 +274,10 @@ library and available to any driver that calles qe_get_firmware_info().
'reserved'.
After the last microcode is a 32-bit CRC. It can be calculated using
-this algorithm:
+this algorithm::
-u32 crc32(const u8 *p, unsigned int len)
-{
+ u32 crc32(const u8 *p, unsigned int len)
+ {
unsigned int i;
u32 crc = 0;
@@ -286,7 +287,7 @@ u32 crc32(const u8 *p, unsigned int len)
crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
}
return crc;
-}
+ }
VI - Sample Code for Creating Firmware Files
============================================
diff --git a/Documentation/powerpc/syscall64-abi.txt b/Documentation/powerpc/syscall64-abi.rst
similarity index 82%
rename from Documentation/powerpc/syscall64-abi.txt
rename to Documentation/powerpc/syscall64-abi.rst
index fa716a0d88bd..e49f69f941b9 100644
--- a/Documentation/powerpc/syscall64-abi.txt
+++ b/Documentation/powerpc/syscall64-abi.rst
@@ -5,12 +5,12 @@ Power Architecture 64-bit Linux system call ABI
syscall
=======
-syscall calling sequence[*] matches the Power Architecture 64-bit ELF ABI
+syscall calling sequence\ [1]_ matches the Power Architecture 64-bit ELF ABI
specification C function calling sequence, including register preservation
rules, with the following differences.
-[*] Some syscalls (typically low-level management functions) may have
- different calling sequences (e.g., rt_sigreturn).
+.. [1] Some syscalls (typically low-level management functions) may have
+ different calling sequences (e.g., rt_sigreturn).
Parameters and return value
---------------------------
@@ -33,12 +33,14 @@ Register preservation rules
Register preservation rules match the ELF ABI calling sequence with the
following differences:
-r0: Volatile. (System call number.)
-r3: Volatile. (Parameter 1, and return value.)
-r4-r8: Volatile. (Parameters 2-6.)
-cr0: Volatile (cr0.SO is the return error condition)
-cr1, cr5-7: Nonvolatile.
-lr: Nonvolatile.
+=========== ============= ========================================
+r0 Volatile (System call number.)
+r3 Volatile (Parameter 1, and return value.)
+r4-r8 Volatile (Parameters 2-6.)
+cr0 Volatile (cr0.SO is the return error condition)
+cr1, cr5-7 Nonvolatile
+lr Nonvolatile
+=========== ============= ========================================
All floating point and vector data registers as well as control and status
registers are nonvolatile.
@@ -90,9 +92,12 @@ The vsyscall may or may not use the caller's stack frame save areas.
Register preservation rules
---------------------------
-r0: Volatile.
-cr1, cr5-7: Volatile.
-lr: Volatile.
+
+=========== ========
+r0 Volatile
+cr1, cr5-7 Volatile
+lr Volatile
+=========== ========
Invocation
----------
diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.rst
similarity index 93%
rename from Documentation/powerpc/transactional_memory.txt
rename to Documentation/powerpc/transactional_memory.rst
index 52c023e14f26..09955103acb4 100644
--- a/Documentation/powerpc/transactional_memory.txt
+++ b/Documentation/powerpc/transactional_memory.rst
@@ -1,3 +1,4 @@
+============================
Transactional Memory support
============================
@@ -17,29 +18,29 @@ instructions are presented to delimit transactions; transactions are
guaranteed to either complete atomically or roll back and undo any partial
changes.
-A simple transaction looks like this:
+A simple transaction looks like this::
-begin_move_money:
- tbegin
- beq abort_handler
+ begin_move_money:
+ tbegin
+ beq abort_handler
- ld r4, SAVINGS_ACCT(r3)
- ld r5, CURRENT_ACCT(r3)
- subi r5, r5, 1
- addi r4, r4, 1
- std r4, SAVINGS_ACCT(r3)
- std r5, CURRENT_ACCT(r3)
+ ld r4, SAVINGS_ACCT(r3)
+ ld r5, CURRENT_ACCT(r3)
+ subi r5, r5, 1
+ addi r4, r4, 1
+ std r4, SAVINGS_ACCT(r3)
+ std r5, CURRENT_ACCT(r3)
- tend
+ tend
- b continue
+ b continue
-abort_handler:
- ... test for odd failures ...
+ abort_handler:
+ ... test for odd failures ...
- /* Retry the transaction if it failed because it conflicted with
- * someone else: */
- b begin_move_money
+ /* Retry the transaction if it failed because it conflicted with
+ * someone else: */
+ b begin_move_money
The 'tbegin' instruction denotes the start point, and 'tend' the end point.
@@ -123,7 +124,7 @@ Transaction-aware signal handlers can read the transactional register state
from the second ucontext. This will be necessary for crash handlers to
determine, for example, the address of the instruction causing the SIGSEGV.
-Example signal handler:
+Example signal handler::
void crash_handler(int sig, siginfo_t *si, void *uc)
{
@@ -133,9 +134,9 @@ Example signal handler:
if (ucp_link) {
u64 msr = ucp->uc_mcontext.regs->msr;
/* May have transactional ucontext! */
-#ifndef __powerpc64__
+ #ifndef __powerpc64__
msr |= ((u64)transactional_ucp->uc_mcontext.regs->msr) << 32;
-#endif
+ #endif
if (MSR_TM_ACTIVE(msr)) {
/* Yes, we crashed during a transaction. Oops. */
fprintf(stderr, "Transaction to be restarted at 0x%llx, but "
@@ -176,6 +177,7 @@ Failure cause codes used by kernel
These are defined in <asm/reg.h>, and distinguish different reasons why the
kernel aborted a transaction:
+ ====================== ================================
TM_CAUSE_RESCHED Thread was rescheduled.
TM_CAUSE_TLBI Software TLB invalid.
TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
@@ -184,6 +186,7 @@ kernel aborted a transaction:
TM_CAUSE_MISC Currently unused.
TM_CAUSE_ALIGNMENT Alignment fault.
TM_CAUSE_EMULATE Emulation that touched memory.
+ ====================== ================================
These can be checked by the user program's abort handler as TEXASR[0:7]. If
bit 7 is set, it indicates that the error is consider persistent. For example
@@ -203,7 +206,7 @@ POWER9
======
TM on POWER9 has issues with storing the complete register state. This
-is described in this commit:
+is described in this commit::
commit 4bb3c7a0208fc13ca70598efd109901a7cd45ae7
Author: Paul Mackerras <paulus@ozlabs.org>
diff --git a/MAINTAINERS b/MAINTAINERS
index 518b73924d7e..5badbf8fa37b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4326,7 +4326,7 @@ F: arch/powerpc/platforms/powernv/pci-cxl.c
F: drivers/misc/cxl/
F: include/misc/cxl*
F: include/uapi/misc/cxl.h
-F: Documentation/powerpc/cxl.txt
+F: Documentation/powerpc/cxl.rst
F: Documentation/ABI/testing/sysfs-class-cxl
CXLFLASH (IBM Coherent Accelerator Processor Interface CAPI Flash) SCSI DRIVER
@@ -4337,7 +4337,7 @@ L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/cxlflash/
F: include/uapi/scsi/cxlflash_ioctl.h
-F: Documentation/powerpc/cxlflash.txt
+F: Documentation/powerpc/cxlflash.rst
CYBERPRO FB DRIVER
M: Russell King <linux@armlinux.org.uk>
@@ -12048,7 +12048,7 @@ F: Documentation/PCI/pci-error-recovery.txt
F: drivers/pci/pcie/aer.c
F: drivers/pci/pcie/dpc.c
F: drivers/pci/pcie/err.c
-F: Documentation/powerpc/eeh-pci-error-recovery.txt
+F: Documentation/powerpc/eeh-pci-error-recovery.rst
F: arch/powerpc/kernel/eeh*.c
F: arch/powerpc/platforms/*/eeh*.c
F: arch/powerpc/include/*/eeh*.h
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 9481a117e242..9b9c463e55d1 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -903,7 +903,7 @@ EXC_COMMON(trap_0b_common, 0xb00, unknown_exception)
*
* Call convention:
*
- * syscall register convention is in Documentation/powerpc/syscall64-abi.txt
+ * syscall register convention is in Documentation/powerpc/syscall64-abi.rst
*
* For hypercalls, the register convention is as follows:
* r0 volatile
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 612d9c551be5..53c6778518ac 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -423,7 +423,7 @@ static void qe_upload_microcode(const void *base,
/*
* Upload a microcode to the I-RAM at a specific address.
*
- * See Documentation/powerpc/qe_firmware.txt for information on QE microcode
+ * See Documentation/powerpc/qe_firmware.rst for information on QE microcode
* uploading.
*
* Currently, only version 1 is supported, so the 'version' field must be
diff --git a/drivers/tty/hvc/hvcs.c b/drivers/tty/hvc/hvcs.c
index cb4db1b3ca3c..5fb214e67d73 100644
--- a/drivers/tty/hvc/hvcs.c
+++ b/drivers/tty/hvc/hvcs.c
@@ -47,7 +47,7 @@
* using the 2.6 Linux kernel kref construct.
*
* For direction on installation and usage of this driver please reference
- * Documentation/powerpc/hvcs.txt.
+ * Documentation/powerpc/hvcs.rst.
*/
#include <linux/device.h>
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index b3d1aff5e8ad..7afc6b1df77a 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -263,7 +263,7 @@ static inline int qe_alive_during_sleep(void)
/* Structure that defines QE firmware binary files.
*
- * See Documentation/powerpc/qe_firmware.txt for a description of these
+ * See Documentation/powerpc/qe_firmware.rst for a description of these
* fields.
*/
struct qe_firmware {
--
2.20.1
^ permalink raw reply related
* [PATCH v2 33/79] docs: serial: convert docs to ReST and rename to *.rst
From: Mauro Carvalho Chehab @ 2019-04-22 13:27 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Timur Tabi, Jonathan Corbet, Greg Kroah-Hartman, linux-kernel,
Mauro Carvalho Chehab, linux-serial, Jiri Slaby,
Mauro Carvalho Chehab, linuxppc-dev
In-Reply-To: <cover.1555938375.git.mchehab+samsung@kernel.org>
The converted files are focused at the Kernel internal API,
so, this is a good candidate for the kernel API set of books.
The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.
At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../{README.cycladesZ => cyclades_z.rst} | 5 +-
Documentation/serial/{driver => driver.rst} | 115 +++-
Documentation/serial/index.rst | 32 +
Documentation/serial/moxa-smartio | 523 ---------------
Documentation/serial/moxa-smartio.rst | 615 ++++++++++++++++++
Documentation/serial/n_gsm.rst | 103 +++
Documentation/serial/n_gsm.txt | 96 ---
.../serial/{rocket.txt => rocket.rst} | 144 ++--
...{serial-iso7816.txt => serial-iso7816.rst} | 21 +-
.../{serial-rs485.txt => serial-rs485.rst} | 22 +-
Documentation/serial/{tty.txt => tty.rst} | 111 ++--
MAINTAINERS | 4 +-
drivers/tty/Kconfig | 4 +-
drivers/tty/serial/ucc_uart.c | 2 +-
include/linux/serial_core.h | 2 +-
15 files changed, 1011 insertions(+), 788 deletions(-)
rename Documentation/serial/{README.cycladesZ => cyclades_z.rst} (85%)
rename Documentation/serial/{driver => driver.rst} (92%)
create mode 100644 Documentation/serial/index.rst
delete mode 100644 Documentation/serial/moxa-smartio
create mode 100644 Documentation/serial/moxa-smartio.rst
create mode 100644 Documentation/serial/n_gsm.rst
delete mode 100644 Documentation/serial/n_gsm.txt
rename Documentation/serial/{rocket.txt => rocket.rst} (68%)
rename Documentation/serial/{serial-iso7816.txt => serial-iso7816.rst} (85%)
rename Documentation/serial/{serial-rs485.txt => serial-rs485.rst} (89%)
rename Documentation/serial/{tty.txt => tty.rst} (74%)
diff --git a/Documentation/serial/README.cycladesZ b/Documentation/serial/cyclades_z.rst
similarity index 85%
rename from Documentation/serial/README.cycladesZ
rename to Documentation/serial/cyclades_z.rst
index 024a69443cc2..532ff67e2f1c 100644
--- a/Documentation/serial/README.cycladesZ
+++ b/Documentation/serial/cyclades_z.rst
@@ -1,8 +1,11 @@
+================
+Cyclades-Z notes
+================
The Cyclades-Z must have firmware loaded onto the card before it will
operate. This operation should be performed during system startup,
The firmware, loader program and the latest device driver code are
available from Cyclades at
+
ftp://ftp.cyclades.com/pub/cyclades/cyclades-z/linux/
-
diff --git a/Documentation/serial/driver b/Documentation/serial/driver.rst
similarity index 92%
rename from Documentation/serial/driver
rename to Documentation/serial/driver.rst
index 86e47c19a924..4537119bf624 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver.rst
@@ -1,6 +1,6 @@
-
- Low Level Serial API
- --------------------
+====================
+Low Level Serial API
+====================
This document is meant as a brief overview of some aspects of the new serial
@@ -44,7 +44,7 @@ are described in the uart_ops listing below.)
There are two locks. A per-port spinlock, and an overall semaphore.
From the core driver perspective, the port->lock locks the following
-data:
+data::
port->mctrl
port->icount
@@ -75,41 +75,51 @@ hardware.
return TIOCSER_TEMT.
Locking: none.
+
Interrupts: caller dependent.
+
This call must not sleep
set_mctrl(port, mctrl)
This function sets the modem control lines for port described
by 'port' to the state described by mctrl. The relevant bits
of mctrl are:
+
- TIOCM_RTS RTS signal.
- TIOCM_DTR DTR signal.
- TIOCM_OUT1 OUT1 signal.
- TIOCM_OUT2 OUT2 signal.
- TIOCM_LOOP Set the port into loopback mode.
+
If the appropriate bit is set, the signal should be driven
active. If the bit is clear, the signal should be driven
inactive.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
get_mctrl(port)
Returns the current state of modem control inputs. The state
of the outputs should not be returned, since the core keeps
track of their state. The state information should include:
+
- TIOCM_CAR state of DCD signal
- TIOCM_CTS state of CTS signal
- TIOCM_DSR state of DSR signal
- TIOCM_RI state of RI signal
+
The bit is set if the signal is currently driven active. If
the port does not support CTS, DCD or DSR, the driver should
indicate that the signal is permanently active. If RI is
not available, the signal should not be indicated as active.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
stop_tx(port)
@@ -121,14 +131,18 @@ hardware.
possible.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
start_tx(port)
Start transmitting characters.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
throttle(port)
@@ -138,16 +152,17 @@ hardware.
This will be called only if hardware assisted flow control is enabled.
Locking: serialized with .unthrottle() and termios modification by the
- tty layer.
+ tty layer.
unthrottle(port)
Notify the serial driver that characters can now be sent to the serial
port without fear of overrunning the input buffers of the line
disciplines.
+
This will be called only if hardware assisted flow control is enabled.
Locking: serialized with .throttle() and termios modification by the
- tty layer.
+ tty layer.
send_xchar(port,ch)
Transmit a high priority character, even if the port is stopped.
@@ -159,6 +174,7 @@ hardware.
Do not transmit if ch == '\0' (__DISABLED_CHAR).
Locking: none.
+
Interrupts: caller dependent.
stop_rx(port)
@@ -166,7 +182,9 @@ hardware.
being closed.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
enable_ms(port)
@@ -177,7 +195,9 @@ hardware.
called.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
break_ctl(port,ctl)
@@ -196,6 +216,7 @@ hardware.
This method will only be called when the port is initially opened.
Locking: port_sem taken.
+
Interrupts: globally disabled.
shutdown(port)
@@ -210,6 +231,7 @@ hardware.
this port.
Locking: port_sem taken.
+
Interrupts: caller dependent.
flush_buffer(port)
@@ -220,7 +242,9 @@ hardware.
buffer is cleared.
Locking: port->lock taken.
+
Interrupts: locally disabled.
+
This call must not sleep
set_termios(port,termios,oldtermios)
@@ -228,29 +252,46 @@ hardware.
bits. Update read_status_mask and ignore_status_mask to indicate
the types of events we are interested in receiving. Relevant
termios->c_cflag bits are:
- CSIZE - word size
- CSTOPB - 2 stop bits
- PARENB - parity enable
- PARODD - odd parity (when PARENB is in force)
- CREAD - enable reception of characters (if not set,
+
+ CSIZE
+ - word size
+ CSTOPB
+ - 2 stop bits
+ PARENB
+ - parity enable
+ PARODD
+ - odd parity (when PARENB is in force)
+ CREAD
+ - enable reception of characters (if not set,
still receive characters from the port, but
throw them away.
- CRTSCTS - if set, enable CTS status change reporting
- CLOCAL - if not set, enable modem status change
+ CRTSCTS
+ - if set, enable CTS status change reporting
+ CLOCAL
+ - if not set, enable modem status change
reporting.
+
Relevant termios->c_iflag bits are:
- INPCK - enable frame and parity error events to be
+
+ INPCK
+ - enable frame and parity error events to be
passed to the TTY layer.
- BRKINT
- PARMRK - both of these enable break events to be
+ BRKINT / PARMRK
+ - both of these enable break events to be
passed to the TTY layer.
- IGNPAR - ignore parity and framing errors
- IGNBRK - ignore break errors, If IGNPAR is also
+ IGNPAR
+ - ignore parity and framing errors
+ IGNBRK
+ - ignore break errors, If IGNPAR is also
set, ignore overrun errors as well.
+
The interaction of the iflag bits is as follows (parity error
given as an example):
+
+ =============== ======= ====== =============================
Parity error INPCK IGNPAR
+ =============== ======= ====== =============================
n/a 0 n/a character received, marked as
TTY_NORMAL
None 1 n/a character received, marked as
@@ -258,16 +299,19 @@ hardware.
Yes 1 0 character received, marked as
TTY_PARITY
Yes 1 1 character discarded
+ =============== ======= ====== =============================
Other flags may be used (eg, xon/xoff characters) if your
hardware supports hardware "soft" flow control.
Locking: caller holds tty_port->mutex
+
Interrupts: caller dependent.
+
This call must not sleep
set_ldisc(port,termios)
- Notifier for discipline change. See Documentation/serial/tty.txt.
+ Notifier for discipline change. See Documentation/serial/tty.rst.
Locking: caller holds tty_port->mutex
@@ -283,6 +327,7 @@ hardware.
will occur even if CONFIG_PM is not set.
Locking: none.
+
Interrupts: caller dependent.
type(port)
@@ -291,6 +336,7 @@ hardware.
substituted.
Locking: none.
+
Interrupts: caller dependent.
release_port(port)
@@ -298,6 +344,7 @@ hardware.
the port.
Locking: none.
+
Interrupts: caller dependent.
request_port(port)
@@ -306,6 +353,7 @@ hardware.
returns, and it should return -EBUSY on failure.
Locking: none.
+
Interrupts: caller dependent.
config_port(port,type)
@@ -321,6 +369,7 @@ hardware.
internally hard wired (eg, system on a chip implementations).
Locking: none.
+
Interrupts: caller dependent.
verify_port(port,serinfo)
@@ -328,6 +377,7 @@ hardware.
suitable for this port type.
Locking: none.
+
Interrupts: caller dependent.
ioctl(port,cmd,arg)
@@ -335,6 +385,7 @@ hardware.
using the standard numbering system found in <asm/ioctl.h>
Locking: none.
+
Interrupts: caller dependent.
poll_init(port)
@@ -343,6 +394,7 @@ hardware.
this should not request interrupts.
Locking: tty_mutex and tty_port->mutex taken.
+
Interrupts: n/a.
poll_put_char(port,ch)
@@ -350,7 +402,9 @@ hardware.
port. It can and should block until there is space in the TX FIFO.
Locking: none.
+
Interrupts: caller dependent.
+
This call must not sleep
poll_get_char(port)
@@ -359,7 +413,9 @@ hardware.
the function should return NO_POLL_CHAR immediately.
Locking: none.
+
Interrupts: caller dependent.
+
This call must not sleep
Other functions
@@ -370,6 +426,7 @@ uart_update_timeout(port,cflag,baud)
number of bits, parity, stop bits and baud rate.
Locking: caller is expected to take port->lock
+
Interrupts: n/a
uart_get_baud_rate(port,termios,old,min,max)
@@ -385,6 +442,7 @@ uart_get_baud_rate(port,termios,old,min,max)
Note: min..max must always allow 9600 baud to be selected.
Locking: caller dependent.
+
Interrupts: n/a
uart_get_divisor(port,baud)
@@ -395,6 +453,7 @@ uart_get_divisor(port,baud)
custom divisor instead.
Locking: caller dependent.
+
Interrupts: n/a
uart_match_port(port1,port2)
@@ -402,6 +461,7 @@ uart_match_port(port1,port2)
uart_port structures describe the same port.
Locking: n/a
+
Interrupts: n/a
uart_write_wakeup(port)
@@ -409,6 +469,7 @@ uart_write_wakeup(port)
characters in the transmit buffer have dropped below a threshold.
Locking: port->lock should be held.
+
Interrupts: n/a
uart_register_driver(drv)
@@ -419,6 +480,7 @@ uart_register_driver(drv)
registered using uart_add_one_port after this call has succeeded.
Locking: none
+
Interrupts: enabled
uart_unregister_driver()
@@ -427,15 +489,16 @@ uart_unregister_driver()
uart_remove_one_port() if it registered them with uart_add_one_port().
Locking: none
+
Interrupts: enabled
-uart_suspend_port()
+**uart_suspend_port()**
-uart_resume_port()
+**uart_resume_port()**
-uart_add_one_port()
+**uart_add_one_port()**
-uart_remove_one_port()
+**uart_remove_one_port()**
Other notes
-----------
@@ -444,7 +507,7 @@ It is intended some day to drop the 'unused' entries from uart_port, and
allow low level drivers to register their own individual uart_port's with
the core. This will allow drivers to use uart_port as a pointer to a
structure containing both the uart_port entry with their own extensions,
-thus:
+thus::
struct my_port {
struct uart_port port;
@@ -459,14 +522,14 @@ Some helpers are provided in order to set/get modem control lines via GPIO.
mctrl_gpio_init(port, idx):
This will get the {cts,rts,...}-gpios from device tree if they are
present and request them, set direction etc, and return an
- allocated structure. devm_* functions are used, so there's no need
+ allocated structure. `devm_*` functions are used, so there's no need
to call mctrl_gpio_free().
As this sets up the irq handling make sure to not handle changes to the
gpio input lines in your driver, too.
mctrl_gpio_free(dev, gpios):
This will free the requested gpios in mctrl_gpio_init().
- As devm_* functions are used, there's generally no need to call
+ As `devm_*` functions are used, there's generally no need to call
this function.
mctrl_gpio_to_gpiod(gpios, gidx)
diff --git a/Documentation/serial/index.rst b/Documentation/serial/index.rst
new file mode 100644
index 000000000000..d0ba22ea23bf
--- /dev/null
+++ b/Documentation/serial/index.rst
@@ -0,0 +1,32 @@
+:orphan:
+
+==========================
+Support for Serial devices
+==========================
+
+.. toctree::
+ :maxdepth: 1
+
+
+ driver
+ tty
+
+Serial drivers
+==============
+
+.. toctree::
+ :maxdepth: 1
+
+ cyclades_z
+ moxa-smartio
+ n_gsm
+ rocket
+ serial-iso7816
+ serial-rs485
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio
deleted file mode 100644
index 5d2a33be0bd8..000000000000
--- a/Documentation/serial/moxa-smartio
+++ /dev/null
@@ -1,523 +0,0 @@
-=============================================================================
- MOXA Smartio/Industio Family Device Driver Installation Guide
- for Linux Kernel 2.4.x, 2.6.x
- Copyright (C) 2008, Moxa Inc.
-=============================================================================
-Date: 01/21/2008
-
-Content
-
-1. Introduction
-2. System Requirement
-3. Installation
- 3.1 Hardware installation
- 3.2 Driver files
- 3.3 Device naming convention
- 3.4 Module driver configuration
- 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x.
- 3.6 Custom configuration
- 3.7 Verify driver installation
-4. Utilities
-5. Setserial
-6. Troubleshooting
-
------------------------------------------------------------------------------
-1. Introduction
-
- The Smartio/Industio/UPCI family Linux driver supports following multiport
- boards.
-
- - 2 ports multiport board
- CP-102U, CP-102UL, CP-102UF
- CP-132U-I, CP-132UL,
- CP-132, CP-132I, CP132S, CP-132IS,
- CI-132, CI-132I, CI-132IS,
- (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S)
-
- - 4 ports multiport board
- CP-104EL,
- CP-104UL, CP-104JU,
- CP-134U, CP-134U-I,
- C104H/PCI, C104HS/PCI,
- CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL,
- C104H, C104HS,
- CI-104J, CI-104JS,
- CI-134, CI-134I, CI-134IS,
- (C114HI, CT-114I, C104P)
- POS-104UL,
- CB-114,
- CB-134I
-
- - 8 ports multiport board
- CP-118EL, CP-168EL,
- CP-118U, CP-168U,
- C168H/PCI,
- C168H, C168HS,
- (C168P),
- CB-108
-
- This driver and installation procedure have been developed upon Linux Kernel
- 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order
- to maintain compatibility, this version has also been properly tested with
- RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem
- occurs, please contact Moxa at support@moxa.com.tw.
-
- In addition to device driver, useful utilities are also provided in this
- version. They are
- - msdiag Diagnostic program for displaying installed Moxa
- Smartio/Industio boards.
- - msmon Monitor program to observe data count and line status signals.
- - msterm A simple terminal program which is useful in testing serial
- ports.
- - io-irq.exe Configuration program to setup ISA boards. Please note that
- this program can only be executed under DOS.
-
- All the drivers and utilities are published in form of source code under
- GNU General Public License in this version. Please refer to GNU General
- Public License announcement in each source code file for more detail.
-
- In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/.
-
- This version of driver can be installed as Loadable Module (Module driver)
- or built-in into kernel (Static driver). You may refer to following
- installation procedure for suitable one. Before you install the driver,
- please refer to hardware installation procedure in the User's Manual.
-
- We assume the user should be familiar with following documents.
- - Serial-HOWTO
- - Kernel-HOWTO
-
------------------------------------------------------------------------------
-2. System Requirement
- - Hardware platform: Intel x86 machine
- - Kernel version: 2.4.x or 2.6.x
- - gcc version 2.72 or later
- - Maximum 4 boards can be installed in combination
-
------------------------------------------------------------------------------
-3. Installation
-
- 3.1 Hardware installation
- 3.2 Driver files
- 3.3 Device naming convention
- 3.4 Module driver configuration
- 3.5 Static driver configuration for Linux kernel 2.4.x, 2.6.x.
- 3.6 Custom configuration
- 3.7 Verify driver installation
-
-
- 3.1 Hardware installation
-
- There are two types of buses, ISA and PCI, for Smartio/Industio
- family multiport board.
-
- ISA board
- ---------
- You'll have to configure CAP address, I/O address, Interrupt Vector
- as well as IRQ before installing this driver. Please refer to hardware
- installation procedure in User's Manual before proceed any further.
- Please make sure the JP1 is open after the ISA board is set properly.
-
- PCI/UPCI board
- --------------
- You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict
- with other ISA devices. Please refer to hardware installation
- procedure in User's Manual in advance.
-
- PCI IRQ Sharing
- -----------
- Each port within the same multiport board shares the same IRQ. Up to
- 4 Moxa Smartio/Industio PCI Family multiport boards can be installed
- together on one system and they can share the same IRQ.
-
-
- 3.2 Driver files
-
- The driver file may be obtained from ftp, CD-ROM or floppy disk. The
- first step, anyway, is to copy driver file "mxser.tgz" into specified
- directory. e.g. /moxa. The execute commands as below.
-
- # cd /
- # mkdir moxa
- # cd /moxa
- # tar xvf /dev/fd0
-
- or
-
- # cd /
- # mkdir moxa
- # cd /moxa
- # cp /mnt/cdrom/<driver directory>/mxser.tgz .
- # tar xvfz mxser.tgz
-
-
- 3.3 Device naming convention
-
- You may find all the driver and utilities files in /moxa/mxser.
- Following installation procedure depends on the model you'd like to
- run the driver. If you prefer module driver, please refer to 3.4.
- If static driver is required, please refer to 3.5.
-
- Dialin and callout port
- -----------------------
- This driver remains traditional serial device properties. There are
- two special file name for each serial port. One is dial-in port
- which is named "ttyMxx". For callout port, the naming convention
- is "cumxx".
-
- Device naming when more than 2 boards installed
- -----------------------------------------------
- Naming convention for each Smartio/Industio multiport board is
- pre-defined as below.
-
- Board Num. Dial-in Port Callout port
- 1st board ttyM0 - ttyM7 cum0 - cum7
- 2nd board ttyM8 - ttyM15 cum8 - cum15
- 3rd board ttyM16 - ttyM23 cum16 - cum23
- 4th board ttyM24 - ttym31 cum24 - cum31
-
-
- !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- Under Kernel 2.6 the cum Device is Obsolete. So use ttyM*
- device instead.
- !!!!!!!!!!!!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-
- Board sequence
- --------------
- This driver will activate ISA boards according to the parameter set
- in the driver. After all specified ISA board activated, PCI board
- will be installed in the system automatically driven.
- Therefore the board number is sorted by the CAP address of ISA boards.
- For PCI boards, their sequence will be after ISA boards and C168H/PCI
- has higher priority than C104H/PCI boards.
-
- 3.4 Module driver configuration
- Module driver is easiest way to install. If you prefer static driver
- installation, please skip this paragraph.
-
-
- ------------- Prepare to use the MOXA driver--------------------
- 3.4.1 Create tty device with correct major number
- Before using MOXA driver, your system must have the tty devices
- which are created with driver's major number. We offer one shell
- script "msmknod" to simplify the procedure.
- This step is only needed to be executed once. But you still
- need to do this procedure when:
- a. You change the driver's major number. Please refer the "3.7"
- section.
- b. Your total installed MOXA boards number is changed. Maybe you
- add/delete one MOXA board.
- c. You want to change the tty name. This needs to modify the
- shell script "msmknod"
-
- The procedure is:
- # cd /moxa/mxser/driver
- # ./msmknod
-
- This shell script will require the major number for dial-in
- device and callout device to create tty device. You also need
- to specify the total installed MOXA board number. Default major
- numbers for dial-in device and callout device are 30, 35. If
- you need to change to other number, please refer section "3.7"
- for more detailed procedure.
- Msmknod will delete any special files occupying the same device
- naming.
-
- 3.4.2 Build the MOXA driver and utilities
- Before using the MOXA driver and utilities, you need compile the
- all the source code. This step is only need to be executed once.
- But you still re-compile the source code if you modify the source
- code. For example, if you change the driver's major number (see
- "3.7" section), then you need to do this step again.
-
- Find "Makefile" in /moxa/mxser, then run
-
- # make clean; make install
-
- !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!
- For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1:
- # make clean; make installsp1
-
- For Red Hat Enterprise Linux AS4/ES4/WS4:
- # make clean; make installsp2
- !!!!!!!!!! NOTE !!!!!!!!!!!!!!!!!
-
- The driver files "mxser.o" and utilities will be properly compiled
- and copied to system directories respectively.
-
- ------------- Load MOXA driver--------------------
- 3.4.3 Load the MOXA driver
-
- # modprobe mxser <argument>
-
- will activate the module driver. You may run "lsmod" to check
- if "mxser" is activated. If the MOXA board is ISA board, the
- <argument> is needed. Please refer to section "3.4.5" for more
- information.
-
-
- ------------- Load MOXA driver on boot --------------------
- 3.4.4 For the above description, you may manually execute
- "modprobe mxser" to activate this driver and run
- "rmmod mxser" to remove it.
- However, it's better to have a boot time configuration to
- eliminate manual operation. Boot time configuration can be
- achieved by rc file. We offer one "rc.mxser" file to simplify
- the procedure under "moxa/mxser/driver".
-
- But if you use ISA board, please modify the "modprobe ..." command
- to add the argument (see "3.4.5" section). After modifying the
- rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser"
- manually to make sure the modification is ok. If any error
- encountered, please try to modify again. If the modification is
- completed, follow the below step.
-
- Run following command for setting rc files.
-
- # cd /moxa/mxser/driver
- # cp ./rc.mxser /etc/rc.d
- # cd /etc/rc.d
-
- Check "rc.serial" is existed or not. If "rc.serial" doesn't exist,
- create it by vi, run "chmod 755 rc.serial" to change the permission.
- Add "/etc/rc.d/rc.mxser" in last line,
-
- Reboot and check if moxa.o activated by "lsmod" command.
-
- 3.4.5. If you'd like to drive Smartio/Industio ISA boards in the system,
- you'll have to add parameter to specify CAP address of given
- board while activating "mxser.o". The format for parameters are
- as follows.
-
- modprobe mxser ioaddr=0x???,0x???,0x???,0x???
- | | | |
- | | | +- 4th ISA board
- | | +------ 3rd ISA board
- | +------------ 2nd ISA board
- +------------------- 1st ISA board
-
- 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x
-
- Note: To use static driver, you must install the linux kernel
- source package.
-
- 3.5.1 Backup the built-in driver in the kernel.
- # cd /usr/src/linux/drivers/char
- # mv mxser.c mxser.c.old
-
- For Red Hat 7.x user, you need to create link:
- # cd /usr/src
- # ln -s linux-2.4 linux
-
- 3.5.2 Create link
- # cd /usr/src/linux/drivers/char
- # ln -s /moxa/mxser/driver/mxser.c mxser.c
-
- 3.5.3 Add CAP address list for ISA boards. For PCI boards user,
- please skip this step.
-
- In module mode, the CAP address for ISA board is given by
- parameter. In static driver configuration, you'll have to
- assign it within driver's source code. If you will not
- install any ISA boards, you may skip to next portion.
- The instructions to modify driver source code are as
- below.
- a. # cd /moxa/mxser/driver
- # vi mxser.c
- b. Find the array mxserBoardCAP[] as below.
-
- static int mxserBoardCAP[]
- = {0x00, 0x00, 0x00, 0x00};
-
- c. Change the address within this array using vi. For
- example, to driver 2 ISA boards with CAP address
- 0x280 and 0x180 as 1st and 2nd board. Just to change
- the source code as follows.
-
- static int mxserBoardCAP[]
- = {0x280, 0x180, 0x00, 0x00};
-
- 3.5.4 Setup kernel configuration
-
- Configure the kernel:
-
- # cd /usr/src/linux
- # make menuconfig
-
- You will go into a menu-driven system. Please select [Character
- devices][Non-standard serial port support], enable the [Moxa
- SmartIO support] driver with "[*]" for built-in (not "[M]"), then
- select [Exit] to exit this program.
-
- 3.5.5 Rebuild kernel
- The following are for Linux kernel rebuilding, for your
- reference only.
- For appropriate details, please refer to the Linux document.
-
- a. cd /usr/src/linux
- b. make clean /* take a few minutes */
- c. make dep /* take a few minutes */
- d. make bzImage /* take probably 10-20 minutes */
- e. make install /* copy boot image to correct position */
- f. Please make sure the boot kernel (vmlinuz) is in the
- correct position.
- g. If you use 'lilo' utility, you should check /etc/lilo.conf
- 'image' item specified the path which is the 'vmlinuz' path,
- or you will load wrong (or old) boot kernel image (vmlinuz).
- After checking /etc/lilo.conf, please run "lilo".
-
- Note that if the result of "make bzImage" is ERROR, then you have to
- go back to Linux configuration Setup. Type "make menuconfig" in
- directory /usr/src/linux.
-
-
- 3.5.6 Make tty device and special file
- # cd /moxa/mxser/driver
- # ./msmknod
-
- 3.5.7 Make utility
- # cd /moxa/mxser/utility
- # make clean; make install
-
- 3.5.8 Reboot
-
-
-
- 3.6 Custom configuration
- Although this driver already provides you default configuration, you
- still can change the device name and major number. The instruction to
- change these parameters are shown as below.
-
- Change Device name
- ------------------
- If you'd like to use other device names instead of default naming
- convention, all you have to do is to modify the internal code
- within the shell script "msmknod". First, you have to open "msmknod"
- by vi. Locate each line contains "ttyM" and "cum" and change them
- to the device name you desired. "msmknod" creates the device names
- you need next time executed.
-
- Change Major number
- -------------------
- If major number 30 and 35 had been occupied, you may have to select
- 2 free major numbers for this driver. There are 3 steps to change
- major numbers.
-
- 3.6.1 Find free major numbers
- In /proc/devices, you may find all the major numbers occupied
- in the system. Please select 2 major numbers that are available.
- e.g. 40, 45.
- 3.6.2 Create special files
- Run /moxa/mxser/driver/msmknod to create special files with
- specified major numbers.
- 3.6.3 Modify driver with new major number
- Run vi to open /moxa/mxser/driver/mxser.c. Locate the line
- contains "MXSERMAJOR". Change the content as below.
- #define MXSERMAJOR 40
- #define MXSERCUMAJOR 45
- 3.6.4 Run "make clean; make install" in /moxa/mxser/driver.
-
- 3.7 Verify driver installation
- You may refer to /var/log/messages to check the latest status
- log reported by this driver whenever it's activated.
-
------------------------------------------------------------------------------
-4. Utilities
- There are 3 utilities contained in this driver. They are msdiag, msmon and
- msterm. These 3 utilities are released in form of source code. They should
- be compiled into executable file and copied into /usr/bin.
-
- Before using these utilities, please load driver (refer 3.4 & 3.5) and
- make sure you had run the "msmknod" utility.
-
- msdiag - Diagnostic
- --------------------
- This utility provides the function to display what Moxa Smartio/Industio
- board found by driver in the system.
-
- msmon - Port Monitoring
- -----------------------
- This utility gives the user a quick view about all the MOXA ports'
- activities. One can easily learn each port's total received/transmitted
- (Rx/Tx) character count since the time when the monitoring is started.
- Rx/Tx throughputs per second are also reported in interval basis (e.g.
- the last 5 seconds) and in average basis (since the time the monitoring
- is started). You can reset all ports' count by <HOME> key. <+> <->
- (plus/minus) keys to change the displaying time interval. Press <ENTER>
- on the port, that cursor stay, to view the port's communication
- parameters, signal status, and input/output queue.
-
- msterm - Terminal Emulation
- ---------------------------
- This utility provides data sending and receiving ability of all tty ports,
- especially for MOXA ports. It is quite useful for testing simple
- application, for example, sending AT command to a modem connected to the
- port or used as a terminal for login purpose. Note that this is only a
- dumb terminal emulation without handling full screen operation.
-
------------------------------------------------------------------------------
-5. Setserial
-
- Supported Setserial parameters are listed as below.
-
- uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO)
- close_delay set the amount of time(in 1/100 of a second) that DTR
- should be kept low while being closed.
- closing_wait set the amount of time(in 1/100 of a second) that the
- serial port should wait for data to be drained while
- being closed, before the receiver is disable.
- spd_hi Use 57.6kb when the application requests 38.4kb.
- spd_vhi Use 115.2kb when the application requests 38.4kb.
- spd_shi Use 230.4kb when the application requests 38.4kb.
- spd_warp Use 460.8kb when the application requests 38.4kb.
- spd_normal Use 38.4kb when the application requests 38.4kb.
- spd_cust Use the custom divisor to set the speed when the
- application requests 38.4kb.
- divisor This option set the custom division.
- baud_base This option set the base baud rate.
-
------------------------------------------------------------------------------
-6. Troubleshooting
-
- The boot time error messages and solutions are stated as clearly as
- possible. If all the possible solutions fail, please contact our technical
- support team to get more help.
-
-
- Error msg: More than 4 Moxa Smartio/Industio family boards found. Fifth board
- and after are ignored.
- Solution:
- To avoid this problem, please unplug fifth and after board, because Moxa
- driver supports up to 4 boards.
-
- Error msg: Request_irq fail, IRQ(?) may be conflict with another device.
- Solution:
- Other PCI or ISA devices occupy the assigned IRQ. If you are not sure
- which device causes the situation, please check /proc/interrupts to find
- free IRQ and simply change another free IRQ for Moxa board.
-
- Error msg: Board #: C1xx Series(CAP=xxx) interrupt number invalid.
- Solution:
- Each port within the same multiport board shares the same IRQ. Please set
- one IRQ (IRQ doesn't equal to zero) for one Moxa board.
-
- Error msg: No interrupt vector be set for Moxa ISA board(CAP=xxx).
- Solution:
- Moxa ISA board needs an interrupt vector.Please refer to user's manual
- "Hardware Installation" chapter to set interrupt vector.
-
- Error msg: Couldn't install MOXA Smartio/Industio family driver!
- Solution:
- Load Moxa driver fail, the major number may conflict with other devices.
- Please refer to previous section 3.7 to change a free major number for
- Moxa driver.
-
- Error msg: Couldn't install MOXA Smartio/Industio family callout driver!
- Solution:
- Load Moxa callout driver fail, the callout device major number may
- conflict with other devices. Please refer to previous section 3.7 to
- change a free callout device major number for Moxa driver.
-
-
------------------------------------------------------------------------------
-
diff --git a/Documentation/serial/moxa-smartio.rst b/Documentation/serial/moxa-smartio.rst
new file mode 100644
index 000000000000..156100f17c3f
--- /dev/null
+++ b/Documentation/serial/moxa-smartio.rst
@@ -0,0 +1,615 @@
+=============================================================
+MOXA Smartio/Industio Family Device Driver Installation Guide
+=============================================================
+
+.. note::
+
+ This file is outdated. It needs some care in order to make it
+ updated to Kernel 5.0 and upper
+
+Copyright (C) 2008, Moxa Inc.
+
+Date: 01/21/2008
+
+.. Content
+
+ 1. Introduction
+ 2. System Requirement
+ 3. Installation
+ 3.1 Hardware installation
+ 3.2 Driver files
+ 3.3 Device naming convention
+ 3.4 Module driver configuration
+ 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x.
+ 3.6 Custom configuration
+ 3.7 Verify driver installation
+ 4. Utilities
+ 5. Setserial
+ 6. Troubleshooting
+
+1. Introduction
+^^^^^^^^^^^^^^^
+
+ The Smartio/Industio/UPCI family Linux driver supports following multiport
+ boards.
+
+ - 2 ports multiport board
+ CP-102U, CP-102UL, CP-102UF
+ CP-132U-I, CP-132UL,
+ CP-132, CP-132I, CP132S, CP-132IS,
+ CI-132, CI-132I, CI-132IS,
+ (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S)
+
+ - 4 ports multiport board
+ CP-104EL,
+ CP-104UL, CP-104JU,
+ CP-134U, CP-134U-I,
+ C104H/PCI, C104HS/PCI,
+ CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL,
+ C104H, C104HS,
+ CI-104J, CI-104JS,
+ CI-134, CI-134I, CI-134IS,
+ (C114HI, CT-114I, C104P),
+ POS-104UL,
+ CB-114,
+ CB-134I
+
+ - 8 ports multiport board
+ CP-118EL, CP-168EL,
+ CP-118U, CP-168U,
+ C168H/PCI,
+ C168H, C168HS,
+ (C168P),
+ CB-108
+
+ This driver and installation procedure have been developed upon Linux Kernel
+ 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order
+ to maintain compatibility, this version has also been properly tested with
+ RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem
+ occurs, please contact Moxa at support@moxa.com.tw.
+
+ In addition to device driver, useful utilities are also provided in this
+ version. They are:
+
+ - msdiag
+ Diagnostic program for displaying installed Moxa
+ Smartio/Industio boards.
+ - msmon
+ Monitor program to observe data count and line status signals.
+ - msterm A simple terminal program which is useful in testing serial
+ ports.
+ - io-irq.exe
+ Configuration program to setup ISA boards. Please note that
+ this program can only be executed under DOS.
+
+ All the drivers and utilities are published in form of source code under
+ GNU General Public License in this version. Please refer to GNU General
+ Public License announcement in each source code file for more detail.
+
+ In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/.
+
+ This version of driver can be installed as Loadable Module (Module driver)
+ or built-in into kernel (Static driver). You may refer to following
+ installation procedure for suitable one. Before you install the driver,
+ please refer to hardware installation procedure in the User's Manual.
+
+ We assume the user should be familiar with following documents.
+
+ - Serial-HOWTO
+ - Kernel-HOWTO
+
+2. System Requirement
+^^^^^^^^^^^^^^^^^^^^^
+
+ - Hardware platform: Intel x86 machine
+ - Kernel version: 2.4.x or 2.6.x
+ - gcc version 2.72 or later
+ - Maximum 4 boards can be installed in combination
+
+3. Installation
+^^^^^^^^^^^^^^^
+
+3.1 Hardware installation
+=========================
+
+ There are two types of buses, ISA and PCI, for Smartio/Industio
+ family multiport board.
+
+ISA board
+---------
+
+ You'll have to configure CAP address, I/O address, Interrupt Vector
+ as well as IRQ before installing this driver. Please refer to hardware
+ installation procedure in User's Manual before proceed any further.
+ Please make sure the JP1 is open after the ISA board is set properly.
+
+PCI/UPCI board
+--------------
+
+ You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict
+ with other ISA devices. Please refer to hardware installation
+ procedure in User's Manual in advance.
+
+PCI IRQ Sharing
+---------------
+
+ Each port within the same multiport board shares the same IRQ. Up to
+ 4 Moxa Smartio/Industio PCI Family multiport boards can be installed
+ together on one system and they can share the same IRQ.
+
+
+3.2 Driver files
+================
+
+ The driver file may be obtained from ftp, CD-ROM or floppy disk. The
+ first step, anyway, is to copy driver file "mxser.tgz" into specified
+ directory. e.g. /moxa. The execute commands as below::
+
+ # cd /
+ # mkdir moxa
+ # cd /moxa
+ # tar xvf /dev/fd0
+
+or::
+
+ # cd /
+ # mkdir moxa
+ # cd /moxa
+ # cp /mnt/cdrom/<driver directory>/mxser.tgz .
+ # tar xvfz mxser.tgz
+
+
+3.3 Device naming convention
+============================
+
+ You may find all the driver and utilities files in /moxa/mxser.
+ Following installation procedure depends on the model you'd like to
+ run the driver. If you prefer module driver, please refer to 3.4.
+ If static driver is required, please refer to 3.5.
+
+Dialin and callout port
+-----------------------
+
+ This driver remains traditional serial device properties. There are
+ two special file name for each serial port. One is dial-in port
+ which is named "ttyMxx". For callout port, the naming convention
+ is "cumxx".
+
+Device naming when more than 2 boards installed
+-----------------------------------------------
+
+ Naming convention for each Smartio/Industio multiport board is
+ pre-defined as below.
+
+ ============ =============== ==============
+ Board Num. Dial-in Port Callout port
+ 1st board ttyM0 - ttyM7 cum0 - cum7
+ 2nd board ttyM8 - ttyM15 cum8 - cum15
+ 3rd board ttyM16 - ttyM23 cum16 - cum23
+ 4th board ttyM24 - ttym31 cum24 - cum31
+ ============ =============== ==============
+
+.. note::
+
+ Under Kernel 2.6 and upper, the cum Device is Obsolete. So use ttyM*
+ device instead.
+
+Board sequence
+--------------
+
+ This driver will activate ISA boards according to the parameter set
+ in the driver. After all specified ISA board activated, PCI board
+ will be installed in the system automatically driven.
+ Therefore the board number is sorted by the CAP address of ISA boards.
+ For PCI boards, their sequence will be after ISA boards and C168H/PCI
+ has higher priority than C104H/PCI boards.
+
+3.4 Module driver configuration
+===============================
+
+ Module driver is easiest way to install. If you prefer static driver
+ installation, please skip this paragraph.
+
+
+ ------------- Prepare to use the MOXA driver --------------------
+
+3.4.1 Create tty device with correct major number
+-------------------------------------------------
+
+ Before using MOXA driver, your system must have the tty devices
+ which are created with driver's major number. We offer one shell
+ script "msmknod" to simplify the procedure.
+ This step is only needed to be executed once. But you still
+ need to do this procedure when:
+
+ a. You change the driver's major number. Please refer the "3.7"
+ section.
+ b. Your total installed MOXA boards number is changed. Maybe you
+ add/delete one MOXA board.
+ c. You want to change the tty name. This needs to modify the
+ shell script "msmknod"
+
+ The procedure is::
+
+ # cd /moxa/mxser/driver
+ # ./msmknod
+
+ This shell script will require the major number for dial-in
+ device and callout device to create tty device. You also need
+ to specify the total installed MOXA board number. Default major
+ numbers for dial-in device and callout device are 30, 35. If
+ you need to change to other number, please refer section "3.7"
+ for more detailed procedure.
+ Msmknod will delete any special files occupying the same device
+ naming.
+
+3.4.2 Build the MOXA driver and utilities
+-----------------------------------------
+
+ Before using the MOXA driver and utilities, you need compile the
+ all the source code. This step is only need to be executed once.
+ But you still re-compile the source code if you modify the source
+ code. For example, if you change the driver's major number (see
+ "3.7" section), then you need to do this step again.
+
+ Find "Makefile" in /moxa/mxser, then run
+
+ # make clean; make install
+
+ ..note::
+
+ For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1:
+ # make clean; make installsp1
+
+ For Red Hat Enterprise Linux AS4/ES4/WS4:
+ # make clean; make installsp2
+
+ The driver files "mxser.o" and utilities will be properly compiled
+ and copied to system directories respectively.
+
+------------- Load MOXA driver--------------------
+
+3.4.3 Load the MOXA driver
+--------------------------
+
+ ::
+
+ # modprobe mxser <argument>
+
+ will activate the module driver. You may run "lsmod" to check
+ if "mxser" is activated. If the MOXA board is ISA board, the
+ <argument> is needed. Please refer to section "3.4.5" for more
+ information.
+
+------------- Load MOXA driver on boot --------------------
+
+3.4.4 Load the mxser driver
+---------------------------
+
+
+ For the above description, you may manually execute
+ "modprobe mxser" to activate this driver and run
+ "rmmod mxser" to remove it.
+
+ However, it's better to have a boot time configuration to
+ eliminate manual operation. Boot time configuration can be
+ achieved by rc file. We offer one "rc.mxser" file to simplify
+ the procedure under "moxa/mxser/driver".
+
+ But if you use ISA board, please modify the "modprobe ..." command
+ to add the argument (see "3.4.5" section). After modifying the
+ rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser"
+ manually to make sure the modification is ok. If any error
+ encountered, please try to modify again. If the modification is
+ completed, follow the below step.
+
+ Run following command for setting rc files::
+
+ # cd /moxa/mxser/driver
+ # cp ./rc.mxser /etc/rc.d
+ # cd /etc/rc.d
+
+ Check "rc.serial" is existed or not. If "rc.serial" doesn't exist,
+ create it by vi, run "chmod 755 rc.serial" to change the permission.
+
+ Add "/etc/rc.d/rc.mxser" in last line.
+
+ Reboot and check if moxa.o activated by "lsmod" command.
+
+3.4.5. specify CAP address
+--------------------------
+
+ If you'd like to drive Smartio/Industio ISA boards in the system,
+ you'll have to add parameter to specify CAP address of given
+ board while activating "mxser.o". The format for parameters are
+ as follows.::
+
+ modprobe mxser ioaddr=0x???,0x???,0x???,0x???
+ | | | |
+ | | | +- 4th ISA board
+ | | +------ 3rd ISA board
+ | +------------ 2nd ISA board
+ +-------------------1st ISA board
+
+3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x
+================================================================
+
+ Note:
+ To use static driver, you must install the linux kernel
+ source package.
+
+3.5.1 Backup the built-in driver in the kernel
+----------------------------------------------
+
+ ::
+
+ # cd /usr/src/linux/drivers/char
+ # mv mxser.c mxser.c.old
+
+ For Red Hat 7.x user, you need to create link:
+ # cd /usr/src
+ # ln -s linux-2.4 linux
+
+3.5.2 Create link
+-----------------
+ ::
+
+ # cd /usr/src/linux/drivers/char
+ # ln -s /moxa/mxser/driver/mxser.c mxser.c
+
+3.5.3 Add CAP address list for ISA boards.
+------------------------------------------
+
+ For PCI boards user, please skip this step.
+
+ In module mode, the CAP address for ISA board is given by
+ parameter. In static driver configuration, you'll have to
+ assign it within driver's source code. If you will not
+ install any ISA boards, you may skip to next portion.
+ The instructions to modify driver source code are as
+ below.
+
+ a. run::
+
+ # cd /moxa/mxser/driver
+ # vi mxser.c
+
+ b. Find the array mxserBoardCAP[] as below::
+
+ static int mxserBoardCAP[] = {0x00, 0x00, 0x00, 0x00};
+
+ c. Change the address within this array using vi. For
+ example, to driver 2 ISA boards with CAP address
+ 0x280 and 0x180 as 1st and 2nd board. Just to change
+ the source code as follows::
+
+ static int mxserBoardCAP[] = {0x280, 0x180, 0x00, 0x00};
+
+3.5.4 Setup kernel configuration
+--------------------------------
+
+ Configure the kernel::
+
+ # cd /usr/src/linux
+ # make menuconfig
+
+ You will go into a menu-driven system. Please select [Character
+ devices][Non-standard serial port support], enable the [Moxa
+ SmartIO support] driver with "[*]" for built-in (not "[M]"), then
+ select [Exit] to exit this program.
+
+3.5.5 Rebuild kernel
+--------------------
+
+ The following are for Linux kernel rebuilding, for your
+ reference only.
+
+ For appropriate details, please refer to the Linux document:
+
+ a. Run the following commands::
+
+ cd /usr/src/linux
+ make clean # take a few minutes
+ make dep # take a few minutes
+ make bzImage # take probably 10-20 minutes
+ make install # copy boot image to correct position
+
+ f. Please make sure the boot kernel (vmlinuz) is in the
+ correct position.
+ g. If you use 'lilo' utility, you should check /etc/lilo.conf
+ 'image' item specified the path which is the 'vmlinuz' path,
+ or you will load wrong (or old) boot kernel image (vmlinuz).
+ After checking /etc/lilo.conf, please run "lilo".
+
+ Note that if the result of "make bzImage" is ERROR, then you have to
+ go back to Linux configuration Setup. Type "make menuconfig" in
+ directory /usr/src/linux.
+
+
+3.5.6 Make tty device and special file
+--------------------------------------
+
+ ::
+ # cd /moxa/mxser/driver
+ # ./msmknod
+
+3.5.7 Make utility
+------------------
+
+ ::
+
+ # cd /moxa/mxser/utility
+ # make clean; make install
+
+3.5.8 Reboot
+------------
+
+
+
+3.6 Custom configuration
+========================
+
+ Although this driver already provides you default configuration, you
+ still can change the device name and major number. The instruction to
+ change these parameters are shown as below.
+
+a. Change Device name
+
+ If you'd like to use other device names instead of default naming
+ convention, all you have to do is to modify the internal code
+ within the shell script "msmknod". First, you have to open "msmknod"
+ by vi. Locate each line contains "ttyM" and "cum" and change them
+ to the device name you desired. "msmknod" creates the device names
+ you need next time executed.
+
+b. Change Major number
+
+ If major number 30 and 35 had been occupied, you may have to select
+ 2 free major numbers for this driver. There are 3 steps to change
+ major numbers.
+
+3.6.1 Find free major numbers
+-----------------------------
+
+ In /proc/devices, you may find all the major numbers occupied
+ in the system. Please select 2 major numbers that are available.
+ e.g. 40, 45.
+
+3.6.2 Create special files
+--------------------------
+
+ Run /moxa/mxser/driver/msmknod to create special files with
+ specified major numbers.
+
+3.6.3 Modify driver with new major number
+-----------------------------------------
+
+ Run vi to open /moxa/mxser/driver/mxser.c. Locate the line
+ contains "MXSERMAJOR". Change the content as below::
+
+ #define MXSERMAJOR 40
+ #define MXSERCUMAJOR 45
+
+ 3.6.4 Run "make clean; make install" in /moxa/mxser/driver.
+
+3.7 Verify driver installation
+==============================
+
+ You may refer to /var/log/messages to check the latest status
+ log reported by this driver whenever it's activated.
+
+4. Utilities
+^^^^^^^^^^^^
+
+ There are 3 utilities contained in this driver. They are msdiag, msmon and
+ msterm. These 3 utilities are released in form of source code. They should
+ be compiled into executable file and copied into /usr/bin.
+
+ Before using these utilities, please load driver (refer 3.4 & 3.5) and
+ make sure you had run the "msmknod" utility.
+
+msdiag - Diagnostic
+===================
+
+ This utility provides the function to display what Moxa Smartio/Industio
+ board found by driver in the system.
+
+msmon - Port Monitoring
+=======================
+
+ This utility gives the user a quick view about all the MOXA ports'
+ activities. One can easily learn each port's total received/transmitted
+ (Rx/Tx) character count since the time when the monitoring is started.
+
+ Rx/Tx throughputs per second are also reported in interval basis (e.g.
+ the last 5 seconds) and in average basis (since the time the monitoring
+ is started). You can reset all ports' count by <HOME> key. <+> <->
+ (plus/minus) keys to change the displaying time interval. Press <ENTER>
+ on the port, that cursor stay, to view the port's communication
+ parameters, signal status, and input/output queue.
+
+msterm - Terminal Emulation
+===========================
+
+ This utility provides data sending and receiving ability of all tty ports,
+ especially for MOXA ports. It is quite useful for testing simple
+ application, for example, sending AT command to a modem connected to the
+ port or used as a terminal for login purpose. Note that this is only a
+ dumb terminal emulation without handling full screen operation.
+
+5. Setserial
+^^^^^^^^^^^^
+
+ Supported Setserial parameters are listed as below.
+
+ ============== =========================================================
+ uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO)
+ close_delay set the amount of time(in 1/100 of a second) that DTR
+ should be kept low while being closed.
+ closing_wait set the amount of time(in 1/100 of a second) that the
+ serial port should wait for data to be drained while
+ being closed, before the receiver is disable.
+ spd_hi Use 57.6kb when the application requests 38.4kb.
+ spd_vhi Use 115.2kb when the application requests 38.4kb.
+ spd_shi Use 230.4kb when the application requests 38.4kb.
+ spd_warp Use 460.8kb when the application requests 38.4kb.
+ spd_normal Use 38.4kb when the application requests 38.4kb.
+ spd_cust Use the custom divisor to set the speed when the
+ application requests 38.4kb.
+ divisor This option set the custom division.
+ baud_base This option set the base baud rate.
+ ============== =========================================================
+
+6. Troubleshooting
+^^^^^^^^^^^^^^^^^^
+
+ The boot time error messages and solutions are stated as clearly as
+ possible. If all the possible solutions fail, please contact our technical
+ support team to get more help.
+
+
+ Error msg:
+ More than 4 Moxa Smartio/Industio family boards found. Fifth board
+ and after are ignored.
+
+ Solution:
+ To avoid this problem, please unplug fifth and after board, because Moxa
+ driver supports up to 4 boards.
+
+ Error msg:
+ Request_irq fail, IRQ(?) may be conflict with another device.
+
+ Solution:
+ Other PCI or ISA devices occupy the assigned IRQ. If you are not sure
+ which device causes the situation, please check /proc/interrupts to find
+ free IRQ and simply change another free IRQ for Moxa board.
+
+ Error msg:
+ Board #: C1xx Series(CAP=xxx) interrupt number invalid.
+
+ Solution:
+ Each port within the same multiport board shares the same IRQ. Please set
+ one IRQ (IRQ doesn't equal to zero) for one Moxa board.
+
+ Error msg:
+ No interrupt vector be set for Moxa ISA board(CAP=xxx).
+
+ Solution:
+ Moxa ISA board needs an interrupt vector.Please refer to user's manual
+ "Hardware Installation" chapter to set interrupt vector.
+
+ Error msg:
+ Couldn't install MOXA Smartio/Industio family driver!
+
+ Solution:
+ Load Moxa driver fail, the major number may conflict with other devices.
+ Please refer to previous section 3.7 to change a free major number for
+ Moxa driver.
+
+ Error msg:
+ Couldn't install MOXA Smartio/Industio family callout driver!
+
+ Solution:
+ Load Moxa callout driver fail, the callout device major number may
+ conflict with other devices. Please refer to previous section 3.7 to
+ change a free callout device major number for Moxa driver.
diff --git a/Documentation/serial/n_gsm.rst b/Documentation/serial/n_gsm.rst
new file mode 100644
index 000000000000..f3ad9fd26408
--- /dev/null
+++ b/Documentation/serial/n_gsm.rst
@@ -0,0 +1,103 @@
+==============================
+GSM 0710 tty multiplexor HOWTO
+==============================
+
+This line discipline implements the GSM 07.10 multiplexing protocol
+detailed in the following 3GPP document:
+
+ http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip
+
+This document give some hints on how to use this driver with GPRS and 3G
+modems connected to a physical serial port.
+
+How to use it
+-------------
+1. initialize the modem in 0710 mux mode (usually AT+CMUX= command) through
+ its serial port. Depending on the modem used, you can pass more or less
+ parameters to this command,
+2. switch the serial line to using the n_gsm line discipline by using
+ TIOCSETD ioctl,
+3. configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl,
+
+Major parts of the initialization program :
+(a good starting point is util-linux-ng/sys-utils/ldattach.c)::
+
+ #include <linux/gsmmux.h>
+ #define N_GSM0710 21 /* GSM 0710 Mux */
+ #define DEFAULT_SPEED B115200
+ #define SERIAL_PORT /dev/ttyS0
+
+ int ldisc = N_GSM0710;
+ struct gsm_config c;
+ struct termios configuration;
+
+ /* open the serial port connected to the modem */
+ fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY);
+
+ /* configure the serial port : speed, flow control ... */
+
+ /* send the AT commands to switch the modem to CMUX mode
+ and check that it's successful (should return OK) */
+ write(fd, "AT+CMUX=0\r", 10);
+
+ /* experience showed that some modems need some time before
+ being able to answer to the first MUX packet so a delay
+ may be needed here in some case */
+ sleep(3);
+
+ /* use n_gsm line discipline */
+ ioctl(fd, TIOCSETD, &ldisc);
+
+ /* get n_gsm configuration */
+ ioctl(fd, GSMIOC_GETCONF, &c);
+ /* we are initiator and need encoding 0 (basic) */
+ c.initiator = 1;
+ c.encapsulation = 0;
+ /* our modem defaults to a maximum size of 127 bytes */
+ c.mru = 127;
+ c.mtu = 127;
+ /* set the new configuration */
+ ioctl(fd, GSMIOC_SETCONF, &c);
+
+ /* and wait for ever to keep the line discipline enabled */
+ daemon(0,0);
+ pause();
+
+4. create the devices corresponding to the "virtual" serial ports (take care,
+ each modem has its configuration and some DLC have dedicated functions,
+ for example GPS), starting with minor 1 (DLC0 is reserved for the management
+ of the mux)::
+
+ MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}`
+ for i in `seq 1 4`; do
+ mknod /dev/ttygsm$i c $MAJOR $i
+ done
+
+5. use these devices as plain serial ports.
+
+ for example, it's possible:
+
+ - and to use gnokii to send / receive SMS on ttygsm1
+ - to use ppp to establish a datalink on ttygsm2
+
+6. first close all virtual ports before closing the physical port.
+
+ Note that after closing the physical port the modem is still in multiplexing
+ mode. This may prevent a successful re-opening of the port later. To avoid
+ this situation either reset the modem if your hardware allows that or send
+ a disconnect command frame manually before initializing the multiplexing mode
+ for the second time. The byte sequence for the disconnect command frame is::
+
+ 0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9.
+
+Additional Documentation
+------------------------
+More practical details on the protocol and how it's supported by industrial
+modems can be found in the following documents :
+
+- http://www.telit.com/module/infopool/download.php?id=616
+- http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf
+- http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx
+- http://wm.sim.com/sim/News/photo/2010721161442.pdf
+
+11-03-08 - Eric Bénard - <eric@eukrea.com>
diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt
deleted file mode 100644
index 875361bb7cb4..000000000000
--- a/Documentation/serial/n_gsm.txt
+++ /dev/null
@@ -1,96 +0,0 @@
-n_gsm.c GSM 0710 tty multiplexor HOWTO
-===================================================
-
-This line discipline implements the GSM 07.10 multiplexing protocol
-detailed in the following 3GPP document :
-http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip
-
-This document give some hints on how to use this driver with GPRS and 3G
-modems connected to a physical serial port.
-
-How to use it
--------------
-1- initialize the modem in 0710 mux mode (usually AT+CMUX= command) through
-its serial port. Depending on the modem used, you can pass more or less
-parameters to this command,
-2- switch the serial line to using the n_gsm line discipline by using
-TIOCSETD ioctl,
-3- configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl,
-
-Major parts of the initialization program :
-(a good starting point is util-linux-ng/sys-utils/ldattach.c)
-#include <linux/gsmmux.h>
-#define N_GSM0710 21 /* GSM 0710 Mux */
-#define DEFAULT_SPEED B115200
-#define SERIAL_PORT /dev/ttyS0
-
- int ldisc = N_GSM0710;
- struct gsm_config c;
- struct termios configuration;
-
- /* open the serial port connected to the modem */
- fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY);
-
- /* configure the serial port : speed, flow control ... */
-
- /* send the AT commands to switch the modem to CMUX mode
- and check that it's successful (should return OK) */
- write(fd, "AT+CMUX=0\r", 10);
-
- /* experience showed that some modems need some time before
- being able to answer to the first MUX packet so a delay
- may be needed here in some case */
- sleep(3);
-
- /* use n_gsm line discipline */
- ioctl(fd, TIOCSETD, &ldisc);
-
- /* get n_gsm configuration */
- ioctl(fd, GSMIOC_GETCONF, &c);
- /* we are initiator and need encoding 0 (basic) */
- c.initiator = 1;
- c.encapsulation = 0;
- /* our modem defaults to a maximum size of 127 bytes */
- c.mru = 127;
- c.mtu = 127;
- /* set the new configuration */
- ioctl(fd, GSMIOC_SETCONF, &c);
-
- /* and wait for ever to keep the line discipline enabled */
- daemon(0,0);
- pause();
-
-4- create the devices corresponding to the "virtual" serial ports (take care,
-each modem has its configuration and some DLC have dedicated functions,
-for example GPS), starting with minor 1 (DLC0 is reserved for the management
-of the mux)
-
-MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}`
-for i in `seq 1 4`; do
- mknod /dev/ttygsm$i c $MAJOR $i
-done
-
-5- use these devices as plain serial ports.
-for example, it's possible :
-- and to use gnokii to send / receive SMS on ttygsm1
-- to use ppp to establish a datalink on ttygsm2
-
-6- first close all virtual ports before closing the physical port.
-
-Note that after closing the physical port the modem is still in multiplexing
-mode. This may prevent a successful re-opening of the port later. To avoid
-this situation either reset the modem if your hardware allows that or send
-a disconnect command frame manually before initializing the multiplexing mode
-for the second time. The byte sequence for the disconnect command frame is:
-0xf9, 0x03, 0xef, 0x03, 0xc3, 0x16, 0xf9.
-
-Additional Documentation
-------------------------
-More practical details on the protocol and how it's supported by industrial
-modems can be found in the following documents :
-http://www.telit.com/module/infopool/download.php?id=616
-http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf
-http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx
-http://wm.sim.com/sim/News/photo/2010721161442.pdf
-
-11-03-08 - Eric Bénard - <eric@eukrea.com>
diff --git a/Documentation/serial/rocket.txt b/Documentation/serial/rocket.rst
similarity index 68%
rename from Documentation/serial/rocket.txt
rename to Documentation/serial/rocket.rst
index 60b039891057..23761eae4282 100644
--- a/Documentation/serial/rocket.txt
+++ b/Documentation/serial/rocket.rst
@@ -1,20 +1,22 @@
-Comtrol(tm) RocketPort(R)/RocketModem(TM) Series
+================================================
+Comtrol(tm) RocketPort(R)/RocketModem(TM) Series
+================================================
+
Device Driver for the Linux Operating System
+============================================
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
-PRODUCT OVERVIEW
+Product overview
----------------
This driver provides a loadable kernel driver for the Comtrol RocketPort
-and RocketModem PCI boards. These boards provide, 2, 4, 8, 16, or 32
+and RocketModem PCI boards. These boards provide, 2, 4, 8, 16, or 32
high-speed serial ports or modems. This driver supports up to a combination
of four RocketPort or RocketModems boards in one machine simultaneously.
This file assumes that you are using the RocketPort driver which is
-integrated into the kernel sources.
+integrated into the kernel sources.
-The driver can also be installed as an external module using the usual
-"make;make install" routine. This external module driver, obtainable
+The driver can also be installed as an external module using the usual
+"make;make install" routine. This external module driver, obtainable
from the Comtrol website listed below, is useful for updating the driver
or installing it into kernels which do not have the driver configured
into them. Installations instructions for the external module
@@ -29,57 +31,59 @@ information on how to set the DIP switches.
You pass the I/O port to the driver using the following module parameters:
-board1 : I/O port for the first ISA board
-board2 : I/O port for the second ISA board
-board3 : I/O port for the third ISA board
-board4 : I/O port for the fourth ISA board
+board1:
+ I/O port for the first ISA board
+board2:
+ I/O port for the second ISA board
+board3:
+ I/O port for the third ISA board
+board4:
+ I/O port for the fourth ISA board
There is a set of utilities and scripts provided with the external driver
-( downloadable from http://www.comtrol.com ) that ease the configuration and
+(downloadable from http://www.comtrol.com) that ease the configuration and
setup of the ISA cards.
The RocketModem II PCI boards require firmware to be loaded into the card
before it will function. The driver has only been tested as a module for this
board.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
-INSTALLATION PROCEDURES
+Installation Procedures
-----------------------
-RocketPort/RocketModem PCI cards require no driver configuration, they are
+RocketPort/RocketModem PCI cards require no driver configuration, they are
automatically detected and configured.
-The RocketPort driver can be installed as a module (recommended) or built
+The RocketPort driver can be installed as a module (recommended) or built
into the kernel. This is selected, as for other drivers, through the `make config`
-command from the root of the Linux source tree during the kernel build process.
+command from the root of the Linux source tree during the kernel build process.
The RocketPort/RocketModem serial ports installed by this driver are assigned
-device major number 46, and will be named /dev/ttyRx, where x is the port number
+device major number 46, and will be named /dev/ttyRx, where x is the port number
starting at zero (ex. /dev/ttyR0, /devttyR1, ...). If you have multiple cards
installed in the system, the mapping of port names to serial ports is displayed
in the system log at /var/log/messages.
If installed as a module, the module must be loaded. This can be done
manually by entering "modprobe rocket". To have the module loaded automatically
-upon system boot, edit a /etc/modprobe.d/*.conf file and add the line
+upon system boot, edit a `/etc/modprobe.d/*.conf` file and add the line
"alias char-major-46 rocket".
In order to use the ports, their device names (nodes) must be created with mknod.
-This is only required once, the system will retain the names once created. To
-create the RocketPort/RocketModem device names, use the command
-"mknod /dev/ttyRx c 46 x" where x is the port number starting at zero. For example:
+This is only required once, the system will retain the names once created. To
+create the RocketPort/RocketModem device names, use the command
+"mknod /dev/ttyRx c 46 x" where x is the port number starting at zero.
->mknod /dev/ttyR0 c 46 0
->mknod /dev/ttyR1 c 46 1
->mknod /dev/ttyR2 c 46 2
+For example::
+
+ > mknod /dev/ttyR0 c 46 0
+ > mknod /dev/ttyR1 c 46 1
+ > mknod /dev/ttyR2 c 46 2
The Linux script MAKEDEV will create the first 16 ttyRx device names (nodes)
-for you:
+for you::
->/dev/MAKEDEV ttyR
-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+ >/dev/MAKEDEV ttyR
ISA Rocketport Boards
---------------------
@@ -89,7 +93,7 @@ card before installing and using it. This is done by setting a set of DIP
switches on the Rocketport board.
-SETTING THE I/O ADDRESS
+Setting the I/O address
-----------------------
Before installing RocketPort(R) or RocketPort RA boards, you must find
@@ -130,40 +134,36 @@ the first 4 bytes of that range are used by the first board. You would
need to set the second, third, or fourth board to one of the next available
blocks such as 0x180.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
+RocketPort and RocketPort RA SW1 Settings::
-RocketPort and RocketPort RA SW1 Settings:
+ +-------------------------------+
+ | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
+ +-------+-------+---------------+
+ | Unused| Card | I/O Port Block|
+ +-------------------------------+
- +-------------------------------+
- | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
- +-------+-------+---------------+
- | Unused| Card | I/O Port Block|
- +-------------------------------+
+ DIP Switches DIP Switches
+ 7 8 6 5
+ =================== ===================
+ On On UNUSED, MUST BE ON. On On First Card <==== Default
+ On Off Second Card
+ Off On Third Card
+ Off Off Fourth Card
-DIP Switches DIP Switches
-7 8 6 5
-=================== ===================
-On On UNUSED, MUST BE ON. On On First Card <==== Default
- On Off Second Card
- Off On Third Card
- Off Off Fourth Card
+ DIP Switches I/O Address Range
+ 4 3 2 1 Used by the First Card
+ =====================================
+ On Off On Off 100-143
+ On Off Off On 140-183
+ On Off Off Off 180-1C3 <==== Default
+ Off On On Off 200-243
+ Off On Off On 240-283
+ Off On Off Off 280-2C3
+ Off Off On Off 300-343
+ Off Off Off On 340-383
+ Off Off Off Off 380-3C3
-DIP Switches I/O Address Range
-4 3 2 1 Used by the First Card
-=====================================
-On Off On Off 100-143
-On Off Off On 140-183
-On Off Off Off 180-1C3 <==== Default
-Off On On Off 200-243
-Off On Off On 240-283
-Off On Off Off 280-2C3
-Off Off On Off 300-343
-Off Off Off On 340-383
-Off Off Off Off 380-3C3
-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
-REPORTING BUGS
+Reporting Bugs
--------------
For technical support, please provide the following
@@ -171,19 +171,15 @@ information: Driver version, kernel release, distribution of
kernel, and type of board you are using. Error messages and log
printouts port configuration details are especially helpful.
-USA
- Phone: (612) 494-4100
- FAX: (612) 494-4199
- email: support@comtrol.com
+USA:
+ :Phone: (612) 494-4100
+ :FAX: (612) 494-4199
+ :email: support@comtrol.com
-Comtrol Europe
- Phone: +44 (0) 1 869 323-220
- FAX: +44 (0) 1 869 323-211
- email: support@comtrol.co.uk
+Comtrol Europe:
+ :Phone: +44 (0) 1 869 323-220
+ :FAX: +44 (0) 1 869 323-211
+ :email: support@comtrol.co.uk
Web: http://www.comtrol.com
FTP: ftp.comtrol.com
-
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-
-
diff --git a/Documentation/serial/serial-iso7816.txt b/Documentation/serial/serial-iso7816.rst
similarity index 85%
rename from Documentation/serial/serial-iso7816.txt
rename to Documentation/serial/serial-iso7816.rst
index 3193d24a2b0f..d990143de0c6 100644
--- a/Documentation/serial/serial-iso7816.txt
+++ b/Documentation/serial/serial-iso7816.rst
@@ -1,11 +1,15 @@
- ISO7816 SERIAL COMMUNICATIONS
+=============================
+ISO7816 Serial Communications
+=============================
-1. INTRODUCTION
+1. Introduction
+===============
ISO/IEC7816 is a series of standards specifying integrated circuit cards (ICC)
also known as smart cards.
-2. HARDWARE-RELATED CONSIDERATIONS
+2. Hardware-related considerations
+==================================
Some CPUs/UARTs (e.g., Microchip AT91) contain a built-in mode capable of
handling communication with a smart card.
@@ -15,7 +19,8 @@
available at user-level to allow switching from one mode to the other, and
vice versa.
-3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+3. Data Structures Already Available in the Kernel
+==================================================
The Linux kernel provides the serial_iso7816 structure (see [1]) to handle
ISO7816 communications. This data structure is used to set and configure
@@ -27,10 +32,11 @@
to TIOCGISO7816 and TIOCSISO7816 ioctls (see below). The iso7816_config
callback receives a pointer to struct serial_iso7816.
-4. USAGE FROM USER-LEVEL
+4. Usage from user-level
+========================
From user-level, ISO7816 configuration can be get/set using the previous
- ioctls. For instance, to set ISO7816 you can use the following code:
+ ioctls. For instance, to set ISO7816 you can use the following code::
#include <linux/serial.h>
@@ -78,6 +84,7 @@
/* Error handling. See errno. */
}
-5. REFERENCES
+5. References
+=============
[1] include/uapi/linux/serial.h
diff --git a/Documentation/serial/serial-rs485.txt b/Documentation/serial/serial-rs485.rst
similarity index 89%
rename from Documentation/serial/serial-rs485.txt
rename to Documentation/serial/serial-rs485.rst
index ce0c1a9b8aab..6bc824f948f9 100644
--- a/Documentation/serial/serial-rs485.txt
+++ b/Documentation/serial/serial-rs485.rst
@@ -1,6 +1,9 @@
- RS485 SERIAL COMMUNICATIONS
+===========================
+RS485 Serial Communications
+===========================
-1. INTRODUCTION
+1. Introduction
+===============
EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
electrical characteristics of drivers and receivers for use in balanced
@@ -9,7 +12,8 @@
because it can be used effectively over long distances and in electrically
noisy environments.
-2. HARDWARE-RELATED CONSIDERATIONS
+2. Hardware-related Considerations
+==================================
Some CPUs/UARTs (e.g., Atmel AT91 or 16C950 UART) contain a built-in
half-duplex mode capable of automatically controlling line direction by
@@ -22,7 +26,8 @@
available at user-level to allow switching from one mode to the other, and
vice versa.
-3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+3. Data Structures Already Available in the Kernel
+==================================================
The Linux kernel provides the serial_rs485 structure (see [1]) to handle
RS485 communications. This data structure is used to set and configure RS485
@@ -38,10 +43,11 @@
to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback
receives a pointer to struct serial_rs485.
-4. USAGE FROM USER-LEVEL
+4. Usage from user-level
+========================
From user-level, RS485 configuration can be get/set using the previous
- ioctls. For instance, to set RS485 you can use the following code:
+ ioctls. For instance, to set RS485 you can use the following code::
#include <linux/serial.h>
@@ -89,7 +95,9 @@
/* Error handling. See errno. */
}
-5. REFERENCES
+5. References
+=============
[1] include/uapi/linux/serial.h
+
[2] Documentation/devicetree/bindings/serial/rs485.txt
diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.rst
similarity index 74%
rename from Documentation/serial/tty.txt
rename to Documentation/serial/tty.rst
index b48780977a68..dd972caacf3e 100644
--- a/Documentation/serial/tty.txt
+++ b/Documentation/serial/tty.rst
@@ -1,5 +1,6 @@
-
- The Lockronomicon
+=================
+The Lockronomicon
+=================
Your guide to the ancient and twisted locking policies of the tty layer and
the warped logic behind them. Beware all ye who read on.
@@ -9,12 +10,12 @@ Line Discipline
---------------
Line disciplines are registered with tty_register_ldisc() passing the
-discipline number and the ldisc structure. At the point of registration the
+discipline number and the ldisc structure. At the point of registration the
discipline must be ready to use and it is possible it will get used before
the call returns success. If the call returns an error then it won't get
called. Do not re-use ldisc numbers as they are part of the userspace ABI
and writing over an existing ldisc will cause demons to eat your computer.
-After the return the ldisc data has been copied so you may free your own
+After the return the ldisc data has been copied so you may free your own
copy of the structure. You must not re-register over the top of the line
discipline even with the same data or your computer again will be eaten by
demons.
@@ -26,7 +27,7 @@ code manages the module counts this should not usually be a concern.
Heed this warning: the reference count field of the registered copies of the
tty_ldisc structure in the ldisc table counts the number of lines using this
-discipline. The reference count of the tty_ldisc structure within a tty
+discipline. The reference count of the tty_ldisc structure within a tty
counts the number of active users of the ldisc at this instant. In effect it
counts the number of threads of execution within an ldisc method (plus those
about to enter and exit although this detail matters not).
@@ -34,9 +35,11 @@ about to enter and exit although this detail matters not).
Line Discipline Methods
-----------------------
-TTY side interfaces:
+TTY side interfaces
+^^^^^^^^^^^^^^^^^^^
-open() - Called when the line discipline is attached to
+======================= =======================================================
+open() Called when the line discipline is attached to
the terminal. No other call into the line
discipline for this tty will occur until it
completes successfully. Should initialize any
@@ -47,66 +50,69 @@ open() - Called when the line discipline is attached to
Returning an error will prevent the ldisc from
being attached. Can sleep.
-close() - This is called on a terminal when the line
+close() This is called on a terminal when the line
discipline is being unplugged. At the point of
execution no further users will enter the
ldisc code for this tty. Can sleep.
-hangup() - Called when the tty line is hung up.
+hangup() Called when the tty line is hung up.
The line discipline should cease I/O to the tty.
No further calls into the ldisc code will occur.
The return value is ignored. Can sleep.
-read() - (optional) A process requests reading data from
+read() (optional) A process requests reading data from
the line. Multiple read calls may occur in parallel
and the ldisc must deal with serialization issues.
If not defined, the process will receive an EIO
error. May sleep.
-write() - (optional) A process requests writing data to the
+write() (optional) A process requests writing data to the
line. Multiple write calls are serialized by the
tty layer for the ldisc. If not defined, the
process will receive an EIO error. May sleep.
-flush_buffer() - (optional) May be called at any point between
+flush_buffer() (optional) May be called at any point between
open and close, and instructs the line discipline
to empty its input buffer.
-set_termios() - (optional) Called on termios structure changes.
+set_termios() (optional) Called on termios structure changes.
The caller passes the old termios data and the
current data is in the tty. Called under the
termios semaphore so allowed to sleep. Serialized
against itself only.
-poll() - (optional) Check the status for the poll/select
+poll() (optional) Check the status for the poll/select
calls. Multiple poll calls may occur in parallel.
May sleep.
-ioctl() - (optional) Called when an ioctl is handed to the
+ioctl() (optional) Called when an ioctl is handed to the
tty layer that might be for the ldisc. Multiple
ioctl calls may occur in parallel. May sleep.
-compat_ioctl() - (optional) Called when a 32 bit ioctl is handed
+compat_ioctl() (optional) Called when a 32 bit ioctl is handed
to the tty layer that might be for the ldisc.
Multiple ioctl calls may occur in parallel.
May sleep.
+======================= =======================================================
-Driver Side Interfaces:
+Driver Side Interfaces
+^^^^^^^^^^^^^^^^^^^^^^
-receive_buf() - (optional) Called by the low-level driver to hand
+======================= =======================================================
+receive_buf() (optional) Called by the low-level driver to hand
a buffer of received bytes to the ldisc for
processing. The number of bytes is guaranteed not
to exceed the current value of tty->receive_room.
All bytes must be processed.
-receive_buf2() - (optional) Called by the low-level driver to hand
+receive_buf2() (optional) Called by the low-level driver to hand
a buffer of received bytes to the ldisc for
processing. Returns the number of bytes processed.
If both receive_buf() and receive_buf2() are
defined, receive_buf2() should be preferred.
-write_wakeup() - May be called at any point between open and close.
+write_wakeup() May be called at any point between open and close.
The TTY_DO_WRITE_WAKEUP flag indicates if a call
is needed but always races versus calls. Thus the
ldisc must be careful about setting order and to
@@ -117,17 +123,20 @@ write_wakeup() - May be called at any point between open and close.
is permitted to call the driver write method from
this function. In such a situation defer it.
-dcd_change() - Report to the tty line the current DCD pin status
+dcd_change() Report to the tty line the current DCD pin status
changes and the relative timestamp. The timestamp
cannot be NULL.
+======================= =======================================================
Driver Access
+^^^^^^^^^^^^^
Line discipline methods can call the following methods of the underlying
hardware driver through the function pointers within the tty->driver
structure:
+======================= =======================================================
write() Write a block of characters to the tty device.
Returns the number of characters accepted. The
character buffer passed to this method is already
@@ -189,13 +198,16 @@ wait_until_sent() Waits until the device has written out all of the
characters in its transmitter FIFO.
send_xchar() Send a high-priority XON/XOFF character to the device.
+======================= =======================================================
Flags
+^^^^^
Line discipline methods have access to tty->flags field containing the
following interesting flags:
+======================= =======================================================
TTY_THROTTLED Driver input is throttled. The ldisc should call
tty->driver->unthrottle() in order to resume
reception when it is ready to process more data.
@@ -212,102 +224,105 @@ TTY_OTHER_CLOSED Device is a pty and the other side has closed.
TTY_NO_WRITE_SPLIT Prevent driver from splitting up writes into
smaller chunks.
+======================= =======================================================
Locking
+^^^^^^^
Callers to the line discipline functions from the tty layer are required to
take line discipline locks. The same is true of calls from the driver side
but not yet enforced.
-Three calls are now provided
+Three calls are now provided::
ldisc = tty_ldisc_ref(tty);
takes a handle to the line discipline in the tty and returns it. If no ldisc
is currently attached or the ldisc is being closed and re-opened at this
point then NULL is returned. While this handle is held the ldisc will not
-change or go away.
+change or go away::
tty_ldisc_deref(ldisc)
Returns the ldisc reference and allows the ldisc to be closed. Returning the
reference takes away your right to call the ldisc functions until you take
-a new reference.
+a new reference::
ldisc = tty_ldisc_ref_wait(tty);
Performs the same function as tty_ldisc_ref except that it will wait for an
-ldisc change to complete and then return a reference to the new ldisc.
+ldisc change to complete and then return a reference to the new ldisc.
While these functions are slightly slower than the old code they should have
minimal impact as most receive logic uses the flip buffers and they only
need to take a reference when they push bits up through the driver.
-A caution: The ldisc->open(), ldisc->close() and driver->set_ldisc
+A caution: The ldisc->open(), ldisc->close() and driver->set_ldisc
functions are called with the ldisc unavailable. Thus tty_ldisc_ref will
fail in this situation if used within these functions. Ldisc and driver
-code calling its own functions must be careful in this case.
+code calling its own functions must be careful in this case.
Driver Interface
----------------
-open() - Called when a device is opened. May sleep
+======================= =======================================================
+open() Called when a device is opened. May sleep
-close() - Called when a device is closed. At the point of
- return from this call the driver must make no
+close() Called when a device is closed. At the point of
+ return from this call the driver must make no
further ldisc calls of any kind. May sleep
-write() - Called to write bytes to the device. May not
- sleep. May occur in parallel in special cases.
+write() Called to write bytes to the device. May not
+ sleep. May occur in parallel in special cases.
Because this includes panic paths drivers generally
shouldn't try and do clever locking here.
-put_char() - Stuff a single character onto the queue. The
+put_char() Stuff a single character onto the queue. The
driver is guaranteed following up calls to
flush_chars.
-flush_chars() - Ask the kernel to write put_char queue
+flush_chars() Ask the kernel to write put_char queue
-write_room() - Return the number of characters that can be stuffed
+write_room() Return the number of characters that can be stuffed
into the port buffers without overflow (or less).
The ldisc is responsible for being intelligent
- about multi-threading of write_room/write calls
+ about multi-threading of write_room/write calls
-ioctl() - Called when an ioctl may be for the driver
+ioctl() Called when an ioctl may be for the driver
-set_termios() - Called on termios change, serialized against
+set_termios() Called on termios change, serialized against
itself by a semaphore. May sleep.
-set_ldisc() - Notifier for discipline change. At the point this
+set_ldisc() Notifier for discipline change. At the point this
is done the discipline is not yet usable. Can now
sleep (I think)
-throttle() - Called by the ldisc to ask the driver to do flow
+throttle() Called by the ldisc to ask the driver to do flow
control. Serialization including with unthrottle
is the job of the ldisc layer.
-unthrottle() - Called by the ldisc to ask the driver to stop flow
+unthrottle() Called by the ldisc to ask the driver to stop flow
control.
-stop() - Ldisc notifier to the driver to stop output. As with
+stop() Ldisc notifier to the driver to stop output. As with
throttle the serializations with start() are down
to the ldisc layer.
-start() - Ldisc notifier to the driver to start output.
+start() Ldisc notifier to the driver to start output.
-hangup() - Ask the tty driver to cause a hangup initiated
+hangup() Ask the tty driver to cause a hangup initiated
from the host side. [Can sleep ??]
-break_ctl() - Send RS232 break. Can sleep. Can get called in
+break_ctl() Send RS232 break. Can sleep. Can get called in
parallel, driver must serialize (for now), and
with write calls.
-wait_until_sent() - Wait for characters to exit the hardware queue
+wait_until_sent() Wait for characters to exit the hardware queue
of the driver. Can sleep
-send_xchar() - Send XON/XOFF and if possible jump the queue with
+send_xchar() Send XON/XOFF and if possible jump the queue with
it in order to get fast flow control responses.
Cannot sleep ??
-
+======================= =======================================================
diff --git a/MAINTAINERS b/MAINTAINERS
index 8c0cb2aa4c00..7e600004f993 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10512,7 +10512,7 @@ F: include/uapi/linux/meye.h
MOXA SMARTIO/INDUSTIO/INTELLIO SERIAL CARD
M: Jiri Slaby <jirislaby@gmail.com>
S: Maintained
-F: Documentation/serial/moxa-smartio
+F: Documentation/serial/moxa-smartio.rst
F: drivers/tty/mxser.*
MR800 AVERMEDIA USB FM RADIO DRIVER
@@ -13396,7 +13396,7 @@ ROCKETPORT DRIVER
P: Comtrol Corp.
W: http://www.comtrol.com
S: Maintained
-F: Documentation/serial/rocket.txt
+F: Documentation/serial/rocket.rst
F: drivers/tty/rocket*
ROCKETPORT EXPRESS/INFINITY DRIVER
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 9acf8ccdabf6..957db30b9ecb 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -176,7 +176,7 @@ config ROCKETPORT
This driver supports Comtrol RocketPort and RocketModem PCI boards.
These boards provide 2, 4, 8, 16, or 32 high-speed serial ports or
modems. For information about the RocketPort/RocketModem boards
- and this driver read <file:Documentation/serial/rocket.txt>.
+ and this driver read <file:Documentation/serial/rocket.rst>.
To compile this driver as a module, choose M here: the
module will be called rocket.
@@ -194,7 +194,7 @@ config CYCLADES
your Linux box, for instance in order to become a dial-in server.
For information about the Cyclades-Z card, read
- <file:Documentation/serial/README.cycladesZ>.
+ <file:Documentation/serial/cyclades_z.rst>.
To compile this driver as a module, choose M here: the
module will be called cyclades.
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 2b6376e6e5ad..6e3c66ab0e62 100644
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -1081,7 +1081,7 @@ static int qe_uart_verify_port(struct uart_port *port,
}
/* UART operations
*
- * Details on these functions can be found in Documentation/serial/driver
+ * Details on these functions can be found in Documentation/serial/driver.rst
*/
static const struct uart_ops qe_uart_pops = {
.tx_empty = qe_uart_tx_empty,
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5fe2b037e833..fea2216a893f 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -45,7 +45,7 @@ struct device;
/*
* This structure describes all the operations that can be done on the
- * physical hardware. See Documentation/serial/driver for details.
+ * physical hardware. See Documentation/serial/driver.rst for details.
*/
struct uart_ops {
unsigned int (*tx_empty)(struct uart_port *);
--
2.20.1
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 3/3 v3] ASoC: fsl_sai: Move clock operation to PM runtime
From: Daniel Baluta @ 2019-04-22 11:25 UTC (permalink / raw)
To: Viorel Suman
Cc: alsa-devel@alsa-project.org, linuxppc-dev@lists.ozlabs.org,
timur@kernel.org, Xiubo.Lee@gmail.com, festevam@gmail.com,
S.j. Wang, tiwai@suse.com, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, nicoleotsuka@gmail.com,
broonie@kernel.org, dl-linux-imx, Daniel Baluta
In-Reply-To: <1555931172.31656.6.camel@nxp.com>
On Mon, Apr 22, 2019 at 2:07 PM Viorel Suman <viorel.suman@nxp.com> wrote:
>
> Hi Daniel,
>
> On Du, 2019-04-21 at 19:39 +0000, Daniel Baluta wrote:
> > From: Shengjiu Wang <shengjiu.wang@nxp.com>
> >
> > Turn off/on clocks when device enters suspend/resume. This
> > can help saving power.
> >
> > As a further optimization, we turn off/on mclk only when SAI
> > is in master mode because otherwise mclk is externally provided.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> > ---
> > sound/soc/fsl/fsl_sai.c | 60 ++++++++++++++++++++++++++++++++++-------
> > 1 file changed, 50 insertions(+), 10 deletions(-)
> >
> > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > index 8623b7f882b9..13a462360ed3 100644
> > --- a/sound/soc/fsl/fsl_sai.c
> > +++ b/sound/soc/fsl/fsl_sai.c
> > @@ -596,15 +596,8 @@ static int fsl_sai_startup(struct snd_pcm_substream *substream,
> > {
> > struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> > bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > - struct device *dev = &sai->pdev->dev;
> > int ret;
> >
> > - ret = clk_prepare_enable(sai->bus_clk);
> > - if (ret) {
> > - dev_err(dev, "failed to enable bus clock: %d\n", ret);
> > - return ret;
> > - }
> > -
> > regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx), FSL_SAI_CR3_TRCE,
> > FSL_SAI_CR3_TRCE);
> >
> > @@ -621,8 +614,6 @@ static void fsl_sai_shutdown(struct snd_pcm_substream *substream,
> > bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> >
> > regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx), FSL_SAI_CR3_TRCE, 0);
> > -
> > - clk_disable_unprepare(sai->bus_clk);
> > }
> >
> > static const struct snd_soc_dai_ops fsl_sai_pcm_dai_ops = {
> > @@ -932,6 +923,16 @@ static int fsl_sai_runtime_suspend(struct device *dev)
> > {
> > struct fsl_sai *sai = dev_get_drvdata(dev);
> >
> > + if (!sai->is_slave_mode) {
> This check is redundant as the bits in sai->mclk_streams are set/unset for master
> mode only, please check fsl_sai_hw_params and fsl_sai_hw_free functions.
Hi Viorel,
I think you make a very good point here. Will fix and send v3.
Thanks!
^ permalink raw reply
* Re: [PATCH 3/3 v3] ASoC: fsl_sai: Move clock operation to PM runtime
From: Viorel Suman @ 2019-04-22 11:06 UTC (permalink / raw)
To: Daniel Baluta, broonie@kernel.org
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
timur@kernel.org, Xiubo.Lee@gmail.com, festevam@gmail.com,
S.j. Wang, linux-kernel@vger.kernel.org, tiwai@suse.com,
nicoleotsuka@gmail.com, dl-linux-imx, perex@perex.cz,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20190421193853.10188-4-daniel.baluta@nxp.com>
Hi Daniel,
On Du, 2019-04-21 at 19:39 +0000, Daniel Baluta wrote:
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> Turn off/on clocks when device enters suspend/resume. This
> can help saving power.
>
> As a further optimization, we turn off/on mclk only when SAI
> is in master mode because otherwise mclk is externally provided.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
> ---
> sound/soc/fsl/fsl_sai.c | 60 ++++++++++++++++++++++++++++++++++-------
> 1 file changed, 50 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 8623b7f882b9..13a462360ed3 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -596,15 +596,8 @@ static int fsl_sai_startup(struct snd_pcm_substream *substream,
> {
> struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> - struct device *dev = &sai->pdev->dev;
> int ret;
>
> - ret = clk_prepare_enable(sai->bus_clk);
> - if (ret) {
> - dev_err(dev, "failed to enable bus clock: %d\n", ret);
> - return ret;
> - }
> -
> regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx), FSL_SAI_CR3_TRCE,
> FSL_SAI_CR3_TRCE);
>
> @@ -621,8 +614,6 @@ static void fsl_sai_shutdown(struct snd_pcm_substream *substream,
> bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
>
> regmap_update_bits(sai->regmap, FSL_SAI_xCR3(tx), FSL_SAI_CR3_TRCE, 0);
> -
> - clk_disable_unprepare(sai->bus_clk);
> }
>
> static const struct snd_soc_dai_ops fsl_sai_pcm_dai_ops = {
> @@ -932,6 +923,16 @@ static int fsl_sai_runtime_suspend(struct device *dev)
> {
> struct fsl_sai *sai = dev_get_drvdata(dev);
>
> + if (!sai->is_slave_mode) {
This check is redundant as the bits in sai->mclk_streams are set/unset for master
mode only, please check fsl_sai_hw_params and fsl_sai_hw_free functions.
> + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_CAPTURE))
> + clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[0]]);
> +
> + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_PLAYBACK))
> + clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[1]]);
> + }
> +
> + clk_disable_unprepare(sai->bus_clk);
> +
> regcache_cache_only(sai->regmap, true);
> regcache_mark_dirty(sai->regmap);
>
> @@ -941,6 +942,27 @@ static int fsl_sai_runtime_suspend(struct device *dev)
> static int fsl_sai_runtime_resume(struct device *dev)
> {
> struct fsl_sai *sai = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(sai->bus_clk);
> + if (ret) {
> + dev_err(dev, "failed to enable bus clock: %d\n", ret);
> + return ret;
> + }
> +
> + if (!sai->is_slave_mode) {
> + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_PLAYBACK)) {
> + ret = clk_prepare_enable(sai->mclk_clk[sai->mclk_id[1]]);
> + if (ret)
> + goto disable_bus_clk;
> + }
> +
> + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_CAPTURE)) {
> + ret = clk_prepare_enable(sai->mclk_clk[sai->mclk_id[0]]);
> + if (ret)
> + goto disable_tx_clk;
> + }
> + }
>
> regcache_cache_only(sai->regmap, false);
> regmap_write(sai->regmap, FSL_SAI_TCSR, FSL_SAI_CSR_SR);
> @@ -948,7 +970,25 @@ static int fsl_sai_runtime_resume(struct device *dev)
> usleep_range(1000, 2000);
> regmap_write(sai->regmap, FSL_SAI_TCSR, 0);
> regmap_write(sai->regmap, FSL_SAI_RCSR, 0);
> - return regcache_sync(sai->regmap);
> +
> + ret = regcache_sync(sai->regmap);
> + if (ret)
> + goto disable_rx_clk;
> +
> + return 0;
> +
> +disable_rx_clk:
> + if (!sai->is_slave_mode &&
> + (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_CAPTURE)))
> + clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[0]]);
> +disable_tx_clk:
> + if (!sai->is_slave_mode &&
> + (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_PLAYBACK)))
> + clk_disable_unprepare(sai->mclk_clk[sai->mclk_id[1]]);
> +disable_bus_clk:
> + clk_disable_unprepare(sai->bus_clk);
> +
> + return ret;
> }
> #endif /* CONFIG_PM */
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: fsl: Move clock operation to PM runtime
From: Viorel Suman @ 2019-04-22 11:02 UTC (permalink / raw)
To: nicoleotsuka@gmail.com, Daniel Baluta
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
timur@kernel.org, Xiubo.Lee@gmail.com,
linuxppc-dev@lists.ozlabs.org, S.j. Wang,
linux-kernel@vger.kernel.org, tiwai@suse.com, broonie@kernel.org,
dl-linux-imx, perex@perex.cz, festevam@gmail.com
In-Reply-To: <20190421055406.GC683@Asurada-Nvidia.nvidia.com>
Hi Nicolin,
On Sb, 2019-04-20 at 22:54 -0700, Nicolin Chen wrote:
> On Sat, Apr 20, 2019 at 03:59:05PM +0000, Daniel Baluta wrote:
> >
> > Turn off/on clocks when device enters suspend/resume. This
> > helps saving power.
> >
> > @@ -934,6 +933,25 @@ static int fsl_sai_runtime_suspend(struct device *dev)
> > static int fsl_sai_runtime_resume(struct device *dev)
> > {
> > struct fsl_sai *sai = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(sai->bus_clk);
> > + if (ret) {
> > + dev_err(dev, "failed to enable bus clock: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_PLAYBACK)) {
> > + ret = clk_prepare_enable(sai->mclk_clk[sai->mclk_id[1]]);
> > + if (ret)
> > + goto disable_bus_clk;
> > + }
> > +
> > + if (sai->mclk_streams & BIT(SNDRV_PCM_STREAM_CAPTURE)) {
> > + ret = clk_prepare_enable(sai->mclk_clk[sai->mclk_id[0]]);
> > + if (ret)
> > + goto disable_tx_clk;
> > + }
> The driver only enables mclk_clks for I2S master mode. But this
> change enables them for I2S slave mode also. It doesn't sound a
> right thing to me since we are supposed to save power?
This change does not enable them for I2S slave mode, please check "fsl_sai_hw_params"
and "fsl_sai_hw_free" functions: the field "sai->mclk_streams" is modified only for
the case when "if (!sai->is_slave_mode)";
Regards,
Viorel
^ permalink raw reply
* Re: [PATCH v2 11/11] compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING
From: Borislav Petkov @ 2019-04-22 10:14 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-arch, linux-s390, Arnd Bergmann, x86, Heiko Carstens,
linux-mips, linux-kernel, Ingo Molnar, linux-mtd, Andrew Morton,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190419094754.24667-12-yamada.masahiro@socionext.com>
On Fri, Apr 19, 2019 at 06:47:54PM +0900, Masahiro Yamada wrote:
> Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
> CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
>
> The idea is obviously arch-agnostic. This commit moves the config
> entry from arch/x86/Kconfig.debug to lib/Kconfig.debug so that all
> architectures can benefit from it.
>
> This can make a huge difference in kernel image size especially when
> CONFIG_OPTIMIZE_FOR_SIZE is enabled.
>
> For example, I got 3.5% smaller arm64 kernel for v5.1-rc1.
>
> dec file
> 18983424 arch/arm64/boot/Image.before
> 18321920 arch/arm64/boot/Image.after
>
> This also slightly improves the "Kernel hacking" Kconfig menu as
> e61aca5158a8 ("Merge branch 'kconfig-diet' from Dave Hansen') suggested;
> this config option would be a good fit in the "compiler option" menu.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Changes in v2:
> - split into a separate patch
>
> arch/x86/Kconfig | 3 ---
> arch/x86/Kconfig.debug | 14 --------------
> include/linux/compiler_types.h | 3 +--
> lib/Kconfig.debug | 14 ++++++++++++++
> 4 files changed, 15 insertions(+), 19 deletions(-)
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH 1/1] cpuidle-powernv : forced wakeup for stop lite states
From: Abhishek Goel @ 2019-04-22 6:32 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, Abhishek Goel, dja
In-Reply-To: <20190422063231.51043-1-huntbag@linux.vnet.ibm.com>
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU will end up in the shallow state.
In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.
So we do not want to get stucked in such states for longer duration. To
address this, the cpuidle-core can queue timer to correspond with the
residency value of the next available state. This timer will forcefully
wakeup the cpu. Few such iterations will essentially train the governor to
select a deeper state for that cpu, as the timer here corresponds to the
next available cpuidle state residency. Cpu will be kicked out of the lite
state and end up in a non-lite state.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal-api.h | 1 +
drivers/cpuidle/cpuidle-powernv.c | 71 ++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index 870fb7b23..735dec731 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -226,6 +226,7 @@
*/
#define OPAL_PM_TIMEBASE_STOP 0x00000002
+#define OPAL_PM_LOSE_USER_CONTEXT 0x00001000
#define OPAL_PM_LOSE_HYP_CONTEXT 0x00002000
#define OPAL_PM_LOSE_FULL_CONTEXT 0x00004000
#define OPAL_PM_NAP_ENABLED 0x00010000
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 84b1ebe21..30b877962 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -15,6 +15,7 @@
#include <linux/clockchips.h>
#include <linux/of.h>
#include <linux/slab.h>
+#include <linux/hrtimer.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
@@ -43,6 +44,40 @@ struct stop_psscr_table {
static struct stop_psscr_table stop_psscr_table[CPUIDLE_STATE_MAX] __read_mostly;
+DEFINE_PER_CPU(struct hrtimer, forced_wakeup_timer);
+
+static int forced_wakeup_time_compute(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int i, timeout_us = 0;
+
+ for (i = index + 1; i < drv->state_count; i++) {
+ if (drv->states[i].disabled || dev->states_usage[i].disable)
+ continue;
+ timeout_us = drv->states[i].target_residency +
+ 2 * drv->states[i].exit_latency;
+ break;
+ }
+
+ return timeout_us;
+}
+
+enum hrtimer_restart forced_wakeup_hrtimer_callback(struct hrtimer *hrtimer)
+{
+ return HRTIMER_NORESTART;
+}
+
+static void forced_wakeup_timer_init(int cpu, struct cpuidle_driver *drv)
+{
+ struct hrtimer *cpu_forced_wakeup_timer = &per_cpu(forced_wakeup_timer,
+ cpu);
+
+ hrtimer_init(cpu_forced_wakeup_timer, CLOCK_MONOTONIC,
+ HRTIMER_MODE_REL);
+ cpu_forced_wakeup_timer->function = forced_wakeup_hrtimer_callback;
+}
+
static u64 default_snooze_timeout __read_mostly;
static bool snooze_timeout_en __read_mostly;
@@ -103,6 +138,28 @@ static int snooze_loop(struct cpuidle_device *dev,
return index;
}
+static int stop_lite_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int timeout_us;
+ struct hrtimer *this_timer = &per_cpu(forced_wakeup_timer, dev->cpu);
+
+ timeout_us = forced_wakeup_time_compute(dev, drv, index);
+
+ if (timeout_us > 0)
+ hrtimer_start(this_timer, ns_to_ktime(timeout_us * 1000),
+ HRTIMER_MODE_REL_PINNED);
+
+ power9_idle_type(stop_psscr_table[index].val,
+ stop_psscr_table[index].mask);
+
+ if (unlikely(hrtimer_is_queued(this_timer)))
+ hrtimer_cancel(this_timer);
+
+ return index;
+}
+
static int nap_loop(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
@@ -190,7 +247,7 @@ static int powernv_cpuidle_cpu_dead(unsigned int cpu)
*/
static int powernv_cpuidle_driver_init(void)
{
- int idle_state;
+ int idle_state, cpu;
struct cpuidle_driver *drv = &powernv_idle_driver;
drv->state_count = 0;
@@ -224,6 +281,9 @@ static int powernv_cpuidle_driver_init(void)
drv->cpumask = (struct cpumask *)cpu_present_mask;
+ for_each_cpu(cpu, drv->cpumask)
+ forced_wakeup_timer_init(cpu, drv);
+
return 0;
}
@@ -299,6 +359,7 @@ static int powernv_add_idle_states(void)
for (i = 0; i < dt_idle_states; i++) {
unsigned int exit_latency, target_residency;
bool stops_timebase = false;
+ bool lose_user_context = false;
struct pnv_idle_states_t *state = &pnv_idle_states[i];
/*
@@ -324,6 +385,9 @@ static int powernv_add_idle_states(void)
if (has_stop_states && !(state->valid))
continue;
+ if (state->flags & OPAL_PM_LOSE_USER_CONTEXT)
+ lose_user_context = true;
+
if (state->flags & OPAL_PM_TIMEBASE_STOP)
stops_timebase = true;
@@ -332,6 +396,11 @@ static int powernv_add_idle_states(void)
add_powernv_state(nr_idle_states, "Nap",
CPUIDLE_FLAG_NONE, nap_loop,
target_residency, exit_latency, 0, 0);
+ } else if (has_stop_states && !lose_user_context) {
+ add_powernv_state(nr_idle_states, state->name,
+ CPUIDLE_FLAG_NONE, stop_lite_loop,
+ target_residency, exit_latency,
+ state->psscr_val, state->psscr_mask);
} else if (has_stop_states && !stops_timebase) {
add_powernv_state(nr_idle_states, state->name,
CPUIDLE_FLAG_NONE, stop_loop,
--
2.17.1
^ permalink raw reply related
* [PATCH 0/1] Forced-wakeup for stop lite states on Powernv
From: Abhishek Goel @ 2019-04-22 6:32 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, linux-pm
Cc: ego, daniel.lezcano, rjw, Abhishek Goel, dja
Currently, the cpuidle governors determine what idle state a idling CPU
should enter into based on heuristics that depend on the idle history on
that CPU. Given that no predictive heuristic is perfect, there are cases
where the governor predicts a shallow idle state, hoping that the CPU will
be busy soon. However, if no new workload is scheduled on that CPU in the
near future, the CPU will end up in the shallow state.
Motivation
----------
In case of POWER, this is problematic, when the predicted state in the
aforementioned scenario is a lite stop state, as such lite states will
inhibit SMT folding, thereby depriving the other threads in the core from
using the core resources.
So we do not want to get stucked in such states for longer duration. To
address this, the cpuidle-core can queue timer to correspond with the
residency value of the next available state. This timer will forcefully
wakeup the cpu. Few such iterations will essentially train the governor to
select a deeper state for that cpu, as the timer here corresponds to the
next available cpuidle state residency. Cpu will be kicked out of the lite
state and end up in a non-lite state.
Experiment
----------
I performed experiments for three scenarios to collect some data.
case 1 :
Without this patch and without tick retained, i.e. in a upstream kernel,
It would spend more than even a second to get out of stop0_lite.
case 2 : With tick retained in a upstream kernel -
Generally, we have a sched tick at 4ms(CONF_HZ = 250). Ideally I expected
it to take 8 sched tick to get out of stop0_lite. Experimentally,
observation was
=========================================================
sample min max 99percentile
20 4ms 12ms 4ms
=========================================================
It would take atleast one sched tick to get out of stop0_lite.
case 2 : With this patch (not stopping tick, but explicitly queuing a
timer)
============================================================
sample min max 99percentile
============================================================
20 144us 192us 144us
============================================================
In this patch, we queue a timer just before entering into a stop0_lite
state. The timer fires at (residency of next available state + exit latency
of next available state * 2). Let's say if next state(stop0) is available
which has residency of 20us, it should get out in as low as (20+2*2)*8
[Based on the forumla (residency + 2xlatency)*history length] microseconds
= 192us. Ideally we would expect 8 iterations, it was observed to get out
in 6-7 iterations. Even if let's say stop2 is next available state(stop0
and stop1 both are unavailable), it would take (100+2*10)*8 = 960us to get
into stop2.
So, We are able to get out of stop0_lite generally in 150us(with this
patch) as compared to 4ms(with tick retained). As stated earlier, we do not
want to get stuck into stop0_lite as it inhibits SMT folding for other
sibling threads, depriving them of core resources. Current patch is using
forced-wakeup only for stop0_lite, as it gives performance benefit(primary
reason) along with lowering down power consumption. We may extend this
model for other states in future.
Abhishek Goel (1):
cpuidle-powernv : forced wakeup for stop lite states
arch/powerpc/include/asm/opal-api.h | 1 +
drivers/cpuidle/cpuidle-powernv.c | 71 ++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 1 deletion(-)
--
2.17.1
^ permalink raw reply
* linux-next: Fixes tag needs some work in the powerpc-fixes tree
From: Stephen Rothwell @ 2019-04-22 5:39 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Alexey Kardashevskiy, Linux Next Mailing List,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hi all,
In commit
7a3a4d763837 ("powerpc/mm_iommu: Allow pinning large regions")
Fixes tag
Fixes: 678e174c4c16 ("powerpc/mm/iommu: allow migration of cma allocated pages during mm_iommu_do_alloc", 2019-03-05)
has these problem(s):
- the ", 2019-03-05" is unexpected in a Fixes tag
Just use
git log -1 --format='Fixes: %h ("%s")'
In commit
eb9d7a62c386 ("powerpc/mm_iommu: Fix potential deadlock")
Fixes tag
Fixes: c10c21efa4bc ("powerpc/vfio/iommu/kvm: Do not pin device memory", 2018-12-19)
has these problem(s):
- the ", 2018-12-19" is unexpected in a Fixes tag
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH V6 3/3] ASoC: fsl_asrc: Unify the supported input and output rate
From: S.j. Wang @ 2019-04-22 4:52 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1555908545.git.shengjiu.wang@nxp.com>
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_asrc.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index a8d6710f2541..cbbf6257f08a 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -27,13 +27,14 @@
dev_dbg(&asrc_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__)
/* Corresponding to process_option */
-static int supported_input_rate[] = {
- 5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200,
- 96000, 176400, 192000,
+static unsigned int supported_asrc_rate[] = {
+ 5512, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
+ 64000, 88200, 96000, 128000, 176400, 192000,
};
-static int supported_asrc_rate[] = {
- 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, 96000, 176400, 192000,
+static struct snd_pcm_hw_constraint_list fsl_asrc_rate_constraints = {
+ .count = ARRAY_SIZE(supported_asrc_rate),
+ .list = supported_asrc_rate,
};
/**
@@ -293,11 +294,11 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
ideal = config->inclk == INCLK_NONE;
/* Validate input and output sample rates */
- for (in = 0; in < ARRAY_SIZE(supported_input_rate); in++)
- if (inrate == supported_input_rate[in])
+ for (in = 0; in < ARRAY_SIZE(supported_asrc_rate); in++)
+ if (inrate == supported_asrc_rate[in])
break;
- if (in == ARRAY_SIZE(supported_input_rate)) {
+ if (in == ARRAY_SIZE(supported_asrc_rate)) {
pair_err("unsupported input sample rate: %dHz\n", inrate);
return -EINVAL;
}
@@ -311,7 +312,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
return -EINVAL;
}
- if ((outrate >= 8000 && outrate <= 30000) &&
+ if ((outrate >= 5512 && outrate <= 30000) &&
(outrate > 24 * inrate || inrate > 8 * outrate)) {
pair_err("exceed supported ratio range [1/24, 8] for \
inrate/outrate: %d/%d\n", inrate, outrate);
@@ -486,7 +487,9 @@ static int fsl_asrc_dai_startup(struct snd_pcm_substream *substream,
snd_pcm_hw_constraint_step(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS, 2);
- return 0;
+
+ return snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE, &fsl_asrc_rate_constraints);
}
static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream,
@@ -599,7 +602,6 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
return 0;
}
-#define FSL_ASRC_RATES SNDRV_PCM_RATE_8000_192000
#define FSL_ASRC_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE)
@@ -610,14 +612,18 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
.stream_name = "ASRC-Playback",
.channels_min = 1,
.channels_max = 10,
- .rates = FSL_ASRC_RATES,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.capture = {
.stream_name = "ASRC-Capture",
.channels_min = 1,
.channels_max = 10,
- .rates = FSL_ASRC_RATES,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.ops = &fsl_asrc_dai_ops,
--
1.9.1
^ permalink raw reply related
* [PATCH V6 2/3] ASoC: fsl_asrc: replace the process_option table with function
From: S.j. Wang @ 2019-04-22 4:52 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1555908545.git.shengjiu.wang@nxp.com>
When we want to support more sample rate, for example 12kHz/24kHz
we need update the process_option table, if we want to support more
sample rate next time, the table need to be updated again. which
is not flexible.
We got a function fsl_asrc_sel_proc to replace the table, which can
give the pre-processing and post-processing options according to
the sample rate.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_asrc.c | 71 ++++++++++++++++++++++++++++++++++--------------
1 file changed, 51 insertions(+), 20 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index ea035c12a325..a8d6710f2541 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -26,24 +26,6 @@
#define pair_dbg(fmt, ...) \
dev_dbg(&asrc_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__)
-/* Sample rates are aligned with that defined in pcm.h file */
-static const u8 process_option[][12][2] = {
- /* 8kHz 11.025kHz 16kHz 22.05kHz 32kHz 44.1kHz 48kHz 64kHz 88.2kHz 96kHz 176kHz 192kHz */
- {{0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 5512Hz */
- {{0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 8kHz */
- {{0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 11025Hz */
- {{1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 16kHz */
- {{1, 2}, {1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 22050Hz */
- {{1, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0},}, /* 32kHz */
- {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0},}, /* 44.1kHz */
- {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0},}, /* 48kHz */
- {{2, 2}, {2, 2}, {2, 2}, {2, 1}, {1, 2}, {0, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0},}, /* 64kHz */
- {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 1}, {1, 1}, {1, 1}, {1, 1},}, /* 88.2kHz */
- {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 1}, {1, 1}, {1, 1}, {1, 1},}, /* 96kHz */
- {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 1}, {2, 1}, {2, 1}, {2, 1},}, /* 176kHz */
- {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 1}, {2, 1}, {2, 1}, {2, 1},}, /* 192kHz */
-};
-
/* Corresponding to process_option */
static int supported_input_rate[] = {
5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200,
@@ -80,6 +62,52 @@
static unsigned char *clk_map[2];
/**
+ * Select the pre-processing and post-processing options
+ * Make sure to exclude following unsupported cases before
+ * calling this function:
+ * 1) inrate > 8.125 * outrate
+ * 2) inrate > 16.125 * outrate
+ *
+ * inrate: input sample rate
+ * outrate: output sample rate
+ * pre_proc: return value for pre-processing option
+ * post_proc: return value for post-processing option
+ */
+static void fsl_asrc_sel_proc(int inrate, int outrate,
+ int *pre_proc, int *post_proc)
+{
+ bool post_proc_cond2;
+ bool post_proc_cond0;
+
+ /* select pre_proc between [0, 2] */
+ if (inrate * 8 > 33 * outrate)
+ *pre_proc = 2;
+ else if (inrate * 8 > 15 * outrate) {
+ if (inrate > 152000)
+ *pre_proc = 2;
+ else
+ *pre_proc = 1;
+ } else if (inrate < 76000)
+ *pre_proc = 0;
+ else if (inrate > 152000)
+ *pre_proc = 2;
+ else
+ *pre_proc = 1;
+
+ /* Condition for selection of post-processing */
+ post_proc_cond2 = (inrate * 15 > outrate * 16 && outrate < 56000) ||
+ (inrate > 56000 && outrate < 56000);
+ post_proc_cond0 = inrate * 23 < outrate * 8;
+
+ if (post_proc_cond2)
+ *post_proc = 2;
+ else if (post_proc_cond0)
+ *post_proc = 0;
+ else
+ *post_proc = 1;
+}
+
+/**
* Request ASRC pair
*
* It assigns pair by the order of A->C->B because allocation of pair B,
@@ -239,6 +267,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
u32 inrate, outrate, indiv, outdiv;
u32 clk_index[2], div[2];
int in, out, channels;
+ int pre_proc, post_proc;
struct clk *clk;
bool ideal;
@@ -377,11 +406,13 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
ASRCTR_IDRi_MASK(index) | ASRCTR_USRi_MASK(index),
ASRCTR_IDR(index) | ASRCTR_USR(index));
+ fsl_asrc_sel_proc(inrate, outrate, &pre_proc, &post_proc);
+
/* Apply configurations for pre- and post-processing */
regmap_update_bits(asrc_priv->regmap, REG_ASRCFG,
ASRCFG_PREMODi_MASK(index) | ASRCFG_POSTMODi_MASK(index),
- ASRCFG_PREMOD(index, process_option[in][out][0]) |
- ASRCFG_POSTMOD(index, process_option[in][out][1]));
+ ASRCFG_PREMOD(index, pre_proc) |
+ ASRCFG_POSTMOD(index, post_proc));
return fsl_asrc_set_ideal_ratio(pair, inrate, outrate);
}
--
1.9.1
^ permalink raw reply related
* [PATCH V6 1/3] ASoC: fsl_asrc: Fix the issue about unsupported rate
From: S.j. Wang @ 2019-04-22 4:52 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1555908545.git.shengjiu.wang@nxp.com>
When the output sample rate is [8kHz, 30kHz], the limitation
of the supported ratio range is [1/24, 8]. In the driver
we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
So this patch is to fix this issue and the potential rounding
issue with divider.
Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support for 8-30kHz
output sample rate")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
sound/soc/fsl/fsl_asrc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 0b937924d2e4..ea035c12a325 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -282,8 +282,8 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
return -EINVAL;
}
- if ((outrate > 8000 && outrate < 30000) &&
- (outrate/inrate > 24 || inrate/outrate > 8)) {
+ if ((outrate >= 8000 && outrate <= 30000) &&
+ (outrate > 24 * inrate || inrate > 8 * outrate)) {
pair_err("exceed supported ratio range [1/24, 8] for \
inrate/outrate: %d/%d\n", inrate, outrate);
return -EINVAL;
--
1.9.1
^ permalink raw reply related
* [PATCH V6 0/3] Support more sample rate in asrc
From: S.j. Wang @ 2019-04-22 4:51 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Support more sample rate in asrc
Shengjiu Wang (3):
ASoC: fsl_asrc: Fix the issue about unsupported rate
ASoC: fsl_asrc: replace the process_option table with function
ASoC: fsl_asrc: Unify the supported input and output rate
Changes in v6
- add acked-by
- fixed minor issue according to comments in v5
Changes in v5
- fix the [1/24, 8]
- move fsl_asrc_sel_proc before setting
Changes in v4
- add patch to Fix the [8kHz, 30kHz] open set issue.
Changes in v3
- remove FSL_ASRC_RATES
- refine fsl_asrc_sel_proc according to comments
Changes in v2
- add more comments in code
- add commit "Unify the supported input and output rate"
sound/soc/fsl/fsl_asrc.c | 105 ++++++++++++++++++++++++++++++++---------------
1 file changed, 71 insertions(+), 34 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH V5 2/3] ASoC: fsl_asrc: replace the process_option table with function
From: S.j. Wang @ 2019-04-22 3:34 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
Hi
>
>
> On Mon, Apr 22, 2019 at 03:15:34AM +0000, S.j. Wang wrote:
> > Hi
> >
> > >
> > >
> > > On Mon, Apr 22, 2019 at 02:32:35AM +0000, S.j. Wang wrote:
> > > > When we want to support more sample rate, for example
> 12kHz/24kHz
> > > we
> > > > need update the process_option table, if we want to support more
> > > > sample rate next time, the table need to be updated again. which
> > > > is not flexible.
> > > >
> > > > We got a function fsl_asrc_sel_proc to replace the table, which
> > > > can give the pre-processing and post-processing options according
> > > > to the sample rate.
> > > >
> > > > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> > >
> > > A couple of more small comments.
> > >
> > > And please add this when you resend:
> > > Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> > >
> > > > + * Unsupport cases: Tsout > 8.125 * Tsin, Tsout > 16.125 * Tsin
> > >
> > > Since we have a ratio validation somewhere else, it's okay to drop
> > > this line -
> > > - it may confuse people since the function no longer checks these
> > > unsupported cases.
> >
> > I add this for may be in the future we forget the limitation. Just for a
> reminder.
>
> Okay. Let's use something more practical like:
>
> +* Make sure to exclude following unsupported cases before calling the
> function:
> +* 1) outrate > 8.125 * inrate
> +* 2) outrate > 16.125 * inrate
Ok.
^ permalink raw reply
* Re: [PATCH V5 2/3] ASoC: fsl_asrc: replace the process_option table with function
From: Nicolin Chen @ 2019-04-22 3:23 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VE1PR04MB6479817B69545A662FFB43B4E3220@VE1PR04MB6479.eurprd04.prod.outlook.com>
On Mon, Apr 22, 2019 at 03:15:34AM +0000, S.j. Wang wrote:
> Hi
>
> >
> >
> > On Mon, Apr 22, 2019 at 02:32:35AM +0000, S.j. Wang wrote:
> > > When we want to support more sample rate, for example 12kHz/24kHz
> > we
> > > need update the process_option table, if we want to support more
> > > sample rate next time, the table need to be updated again. which is
> > > not flexible.
> > >
> > > We got a function fsl_asrc_sel_proc to replace the table, which can
> > > give the pre-processing and post-processing options according to the
> > > sample rate.
> > >
> > > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> >
> > A couple of more small comments.
> >
> > And please add this when you resend:
> > Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> >
> > > + * Unsupport cases: Tsout > 8.125 * Tsin, Tsout > 16.125 * Tsin
> >
> > Since we have a ratio validation somewhere else, it's okay to drop this line -
> > - it may confuse people since the function no longer checks these
> > unsupported cases.
>
> I add this for may be in the future we forget the limitation. Just for a reminder.
Okay. Let's use something more practical like:
+* Make sure to exclude following unsupported cases before calling the function:
+* 1) outrate > 8.125 * inrate
+* 2) outrate > 16.125 * inrate
^ permalink raw reply
* Re: [PATCH V5 2/3] ASoC: fsl_asrc: replace the process_option table with function
From: S.j. Wang @ 2019-04-22 3:15 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
Hi
>
>
> On Mon, Apr 22, 2019 at 02:32:35AM +0000, S.j. Wang wrote:
> > When we want to support more sample rate, for example 12kHz/24kHz
> we
> > need update the process_option table, if we want to support more
> > sample rate next time, the table need to be updated again. which is
> > not flexible.
> >
> > We got a function fsl_asrc_sel_proc to replace the table, which can
> > give the pre-processing and post-processing options according to the
> > sample rate.
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> A couple of more small comments.
>
> And please add this when you resend:
> Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
>
> > + * Unsupport cases: Tsout > 8.125 * Tsin, Tsout > 16.125 * Tsin
>
> Since we have a ratio validation somewhere else, it's okay to drop this line -
> - it may confuse people since the function no longer checks these
> unsupported cases.
I add this for may be in the future we forget the limitation. Just for a reminder.
Best regards
Wang shengjiu
>
> > +static int fsl_asrc_sel_proc(int inrate, int outrate,
>
> I think "void" type should be just fine as we made sure there is no
> unsupported cases running in this function.
^ permalink raw reply
* Re: [PATCH V5 3/3] ASoC: fsl_asrc: Unify the supported input and output rate
From: Nicolin Chen @ 2019-04-22 2:58 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <841aa2c4256e418759422affe6c138fa55cd1785.1555900078.git.shengjiu.wang@nxp.com>
On Mon, Apr 22, 2019 at 02:32:38AM +0000, S.j. Wang wrote:
> Unify the supported input and output rate, add the
> 12kHz/24kHz/128kHz to the support list
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Thank you
^ permalink raw reply
* Re: [PATCH V5 2/3] ASoC: fsl_asrc: replace the process_option table with function
From: Nicolin Chen @ 2019-04-22 2:57 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <cc27c775aca3a9c1ffcd310429170bbd64b74a39.1555900078.git.shengjiu.wang@nxp.com>
On Mon, Apr 22, 2019 at 02:32:35AM +0000, S.j. Wang wrote:
> When we want to support more sample rate, for example 12kHz/24kHz
> we need update the process_option table, if we want to support more
> sample rate next time, the table need to be updated again. which
> is not flexible.
>
> We got a function fsl_asrc_sel_proc to replace the table, which can
> give the pre-processing and post-processing options according to
> the sample rate.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
A couple of more small comments.
And please add this when you resend:
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
> + * Unsupport cases: Tsout > 8.125 * Tsin, Tsout > 16.125 * Tsin
Since we have a ratio validation somewhere else, it's okay to
drop this line -- it may confuse people since the function no
longer checks these unsupported cases.
> +static int fsl_asrc_sel_proc(int inrate, int outrate,
I think "void" type should be just fine as we made sure there
is no unsupported cases running in this function.
^ permalink raw reply
* Re: [PATCH V5 1/3] ASoC: fsl_asrc: Fix the issue about unsupported rate
From: Nicolin Chen @ 2019-04-22 2:49 UTC (permalink / raw)
To: S.j. Wang
Cc: alsa-devel@alsa-project.org, timur@kernel.org,
Xiubo.Lee@gmail.com, festevam@gmail.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <a74fe1798ef8f473e11f5e39452664b5e80515df.1555900078.git.shengjiu.wang@nxp.com>
On Mon, Apr 22, 2019 at 02:32:32AM +0000, S.j. Wang wrote:
> When the output sample rate is [8kHz, 30kHz], the limitation
> of the supported ratio range is (1/24, 8). In the driver
Should be [1/24, 8].
Otherwise,
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Thanks
> we use (8kHz, 30kHz) instead of [8kHz, 30kHz].
> So this patch is to fix this issue and the potential rounding
> issue with divider.
>
> Fixes: fff6e03c7b65 ("ASoC: fsl_asrc: add support for 8-30kHz
> output sample rate")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl_asrc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
> index 0b937924d2e4..ea035c12a325 100644
> --- a/sound/soc/fsl/fsl_asrc.c
> +++ b/sound/soc/fsl/fsl_asrc.c
> @@ -282,8 +282,8 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
> return -EINVAL;
> }
>
> - if ((outrate > 8000 && outrate < 30000) &&
> - (outrate/inrate > 24 || inrate/outrate > 8)) {
> + if ((outrate >= 8000 && outrate <= 30000) &&
> + (outrate > 24 * inrate || inrate > 8 * outrate)) {
> pair_err("exceed supported ratio range [1/24, 8] for \
> inrate/outrate: %d/%d\n", inrate, outrate);
> return -EINVAL;
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH V5 3/3] ASoC: fsl_asrc: Unify the supported input and output rate
From: S.j. Wang @ 2019-04-22 2:32 UTC (permalink / raw)
To: timur@kernel.org, nicoleotsuka@gmail.com, Xiubo.Lee@gmail.com,
festevam@gmail.com, broonie@kernel.org,
alsa-devel@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1555900078.git.shengjiu.wang@nxp.com>
Unify the supported input and output rate, add the
12kHz/24kHz/128kHz to the support list
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 4675ea4e8204..85c278effda1 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -27,13 +27,14 @@
dev_dbg(&asrc_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__)
/* Corresponding to process_option */
-static int supported_input_rate[] = {
- 5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200,
- 96000, 176400, 192000,
+static unsigned int supported_asrc_rate[] = {
+ 5512, 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000,
+ 64000, 88200, 96000, 128000, 176400, 192000,
};
-static int supported_asrc_rate[] = {
- 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, 96000, 176400, 192000,
+static struct snd_pcm_hw_constraint_list fsl_asrc_rate_constraints = {
+ .count = ARRAY_SIZE(supported_asrc_rate),
+ .list = supported_asrc_rate,
};
/**
@@ -292,11 +293,11 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
ideal = config->inclk == INCLK_NONE;
/* Validate input and output sample rates */
- for (in = 0; in < ARRAY_SIZE(supported_input_rate); in++)
- if (inrate == supported_input_rate[in])
+ for (in = 0; in < ARRAY_SIZE(supported_asrc_rate); in++)
+ if (inrate == supported_asrc_rate[in])
break;
- if (in == ARRAY_SIZE(supported_input_rate)) {
+ if (in == ARRAY_SIZE(supported_asrc_rate)) {
pair_err("unsupported input sample rate: %dHz\n", inrate);
return -EINVAL;
}
@@ -310,7 +311,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair)
return -EINVAL;
}
- if ((outrate >= 8000 && outrate <= 30000) &&
+ if ((outrate >= 5512 && outrate <= 30000) &&
(outrate > 24 * inrate || inrate > 8 * outrate)) {
pair_err("exceed supported ratio range [1/24, 8] for \
inrate/outrate: %d/%d\n", inrate, outrate);
@@ -485,7 +486,9 @@ static int fsl_asrc_dai_startup(struct snd_pcm_substream *substream,
snd_pcm_hw_constraint_step(substream->runtime, 0,
SNDRV_PCM_HW_PARAM_CHANNELS, 2);
- return 0;
+
+ return snd_pcm_hw_constraint_list(substream->runtime, 0,
+ SNDRV_PCM_HW_PARAM_RATE, &fsl_asrc_rate_constraints);
}
static int fsl_asrc_dai_hw_params(struct snd_pcm_substream *substream,
@@ -598,7 +601,6 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
return 0;
}
-#define FSL_ASRC_RATES SNDRV_PCM_RATE_8000_192000
#define FSL_ASRC_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE)
@@ -609,14 +611,18 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
.stream_name = "ASRC-Playback",
.channels_min = 1,
.channels_max = 10,
- .rates = FSL_ASRC_RATES,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.capture = {
.stream_name = "ASRC-Capture",
.channels_min = 1,
.channels_max = 10,
- .rates = FSL_ASRC_RATES,
+ .rate_min = 5512,
+ .rate_max = 192000,
+ .rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_ASRC_FORMATS,
},
.ops = &fsl_asrc_dai_ops,
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox