* [PATCH][next] powerpc/mm: fix spelling mistake "Outisde" -> "Outside"
From: Colin King @ 2019-04-23 15:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Aneesh Kumar K . V, linuxppc-dev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are several identical spelling mistakes in warning messages,
fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/powerpc/mm/hash_utils_64.c | 4 ++--
arch/powerpc/mm/pgtable-hash64.c | 2 +-
arch/powerpc/mm/pgtable-radix.c | 6 +++---
arch/powerpc/mm/pgtable_64.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f727197de713..6eb89643ce58 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -784,7 +784,7 @@ int hash__create_section_mapping(unsigned long start, unsigned long end, int nid
int rc;
if (end >= H_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
@@ -932,7 +932,7 @@ static void __init htab_initialize(void)
base, size, prot);
if ((base + size) >= H_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
continue;
}
diff --git a/arch/powerpc/mm/pgtable-hash64.c b/arch/powerpc/mm/pgtable-hash64.c
index d934de4e2b3a..097a3b3538b1 100644
--- a/arch/powerpc/mm/pgtable-hash64.c
+++ b/arch/powerpc/mm/pgtable-hash64.c
@@ -115,7 +115,7 @@ int __meminit hash__vmemmap_create_mapping(unsigned long start,
int rc;
if ((start + page_size) >= H_VMEMMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index e6d5065b0bc8..fcb0169e2d32 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -341,7 +341,7 @@ void __init radix_init_pgtable(void)
*/
if ((reg->base + reg->size) >= RADIX_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
continue;
}
@@ -902,7 +902,7 @@ static void __meminit remove_pagetable(unsigned long start, unsigned long end)
int __meminit radix__create_section_mapping(unsigned long start, unsigned long end, int nid)
{
if (end >= RADIX_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
@@ -934,7 +934,7 @@ int __meminit radix__vmemmap_create_mapping(unsigned long start,
int ret;
if ((start + page_size) >= RADIX_VMEMMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 72f58c076e26..95ad2a09501c 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -122,7 +122,7 @@ void __iomem *__ioremap_at(phys_addr_t pa, void *ea, unsigned long size, pgprot_
return NULL;
if ((ea + size) >= (void *)IOREMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return NULL;
}
--
2.20.1
^ permalink raw reply related
* [PATCH] powerpc/mm: Comment arch_unmap()
From: Laurent Dufour @ 2019-04-23 15:17 UTC (permalink / raw)
To: mpe; +Cc: Thomas Gleixner, linuxppc-dev, linux-kernel
During a different patch review, the check in arch_munmap() was found
spucious due the lake of explanation.
Adding a comment to clarify the test.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/include/asm/mmu_context.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 6ee8195a2ffb..638f481b3c9f 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -240,6 +240,17 @@ static inline void arch_unmap(struct mm_struct *mm,
struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{
+ /*
+ * There are 2 assumptions here:
+ * 1. the VDSO is one page size (guaranteed by vdso_data_store)
+ * 2. 'start' and 'end' are page aligned (guaranteed by the caller)
+ * The test is wrote in a way to handle unmap operation surrounding the
+ * VDSO area like:
+ * | VDSO |
+ * ^ start ^ end
+ * The test also covers the munmap() operation done to the exact VDSO's
+ * boundaries.
+ */
if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
mm->context.vdso_base = 0;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v12 01/31] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT
From: Laurent Dufour @ 2019-04-23 15:21 UTC (permalink / raw)
To: Jerome Glisse
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: <20190418214721.GA11645@redhat.com>
Le 18/04/2019 à 23:47, Jerome Glisse a écrit :
> On Tue, Apr 16, 2019 at 03:44:52PM +0200, Laurent Dufour wrote:
>> This configuration variable will be used to build the code needed to
>> handle speculative page fault.
>>
>> By default it is turned off, and activated depending on architecture
>> support, ARCH_HAS_PTE_SPECIAL, SMP and MMU.
>>
>> The architecture support is needed since the speculative page fault handler
>> is called from the architecture's page faulting code, and some code has to
>> be added there to handle the speculative handler.
>>
>> The dependency on ARCH_HAS_PTE_SPECIAL is required because vm_normal_page()
>> does processing that is not compatible with the speculative handling in the
>> case ARCH_HAS_PTE_SPECIAL is not set.
>>
>> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
>> Suggested-by: David Rientjes <rientjes@google.com>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>
> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Thanks Jérôme.
> Small question below
>
>> ---
>> mm/Kconfig | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 0eada3f818fa..ff278ac9978a 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -761,4 +761,26 @@ config GUP_BENCHMARK
>> config ARCH_HAS_PTE_SPECIAL
>> bool
>>
>> +config ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
>> + def_bool n
>> +
>> +config SPECULATIVE_PAGE_FAULT
>> + bool "Speculative page faults"
>> + default y
>> + depends on ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
>> + depends on ARCH_HAS_PTE_SPECIAL && MMU && SMP
>> + help
>> + Try to handle user space page faults without holding the mmap_sem.
>> +
>> + This should allow better concurrency for massively threaded processes
>
> Is there any case where it does not provide better concurrency ? The
> should make me wonder :)
Depending on the VMA's type, it may not provide better concurrency.
Indeed only anonymous mapping are managed currently. Perhaps this should
be mentioned here, is it ?
>> + since the page fault handler will not wait for other thread's memory
>> + layout change to be done, assuming that this change is done in
>> + another part of the process's memory space. This type of page fault
>> + is named speculative page fault.
>> +
>> + If the speculative page fault fails because a concurrent modification
>> + is detected or because underlying PMD or PTE tables are not yet
>> + allocated, the speculative page fault fails and a classic page fault
>> + is then tried.
>> +
>> endmenu
>> --
>> 2.21.0
>>
>
^ permalink raw reply
* Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Laurent Dufour @ 2019-04-23 15:36 UTC (permalink / raw)
To: Jerome Glisse, Mark Rutland
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: <20190418215113.GD11645@redhat.com>
Le 18/04/2019 à 23:51, Jerome Glisse a écrit :
> On Tue, Apr 16, 2019 at 03:41:56PM +0100, Mark Rutland wrote:
>> On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote:
>>> Le 16/04/2019 à 16:27, Mark Rutland a écrit :
>>>> On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote:
>>>>> From: Mahendran Ganesh <opensource.ganesh@gmail.com>
>>>>>
>>>>> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This
>>>>> enables Speculative Page Fault handler.
>>>>>
>>>>> Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
>>>>
>>>> This is missing your S-o-B.
>>>
>>> You're right, I missed that...
>>>
>>>> The first patch noted that the ARCH_SUPPORTS_* option was there because
>>>> the arch code had to make an explicit call to try to handle the fault
>>>> speculatively, but that isn't addeed until patch 30.
>>>>
>>>> Why is this separate from that code?
>>>
>>> Andrew was recommended this a long time ago for bisection purpose. This
>>> allows to build the code with CONFIG_SPECULATIVE_PAGE_FAULT before the code
>>> that trigger the spf handler is added to the per architecture's code.
>>
>> Ok. I think it would be worth noting that in the commit message, to
>> avoid anyone else asking the same question. :)
>
> Should have read this thread before looking at x86 and ppc :)
>
> In any case the patch is:
>
> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
Thanks Mark and Jérôme for reviewing this.
Regarding the change in the commit message, I'm wondering if this would
be better to place it in the Series's letter head.
But I'm fine to put it in each architecture's commit.
^ permalink raw reply
* Re: [PATCH 10/10] powerpc: select DYNAMIC_DEBUG_RELATIVE_POINTERS for PPC64
From: Christophe Leroy @ 2019-04-23 15:37 UTC (permalink / raw)
To: Rasmus Villemoes, Andrew Morton, linuxppc-dev; +Cc: Jason Baron, linux-kernel
In-Reply-To: <20190409212517.7321-11-linux@rasmusvillemoes.dk>
Le 09/04/2019 à 23:25, Rasmus Villemoes a écrit :
> Similar to GENERIC_BUG_RELATIVE_POINTERS, one can now relativize the
> four const char* members of struct _ddebug, thus saving 16 bytes per
> instance (one for each pr_debug(), dev_debug() etc. in a
> CONFIG_DYNAMIC_DEBUG kernel). The asm-generic implementation seems to
> work out-of-the-box, though this is only compile-tested.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> arch/powerpc/Kconfig | 1 +
> arch/powerpc/include/asm/Kbuild | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 2d0be82c3061..6821c8ae1d62 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -155,6 +155,7 @@ config PPC
> select BUILDTIME_EXTABLE_SORT
> select CLONE_BACKWARDS
> select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> + select DYNAMIC_DEBUG_RELATIVE_POINTERS if PPC64
Why only PPC64 ? Won't it work with PPC32 ? Or would it be
counter-performant on 32 bits ?
Christophe
> select DYNAMIC_FTRACE if FUNCTION_TRACER
> select EDAC_ATOMIC_SCRUB
> select EDAC_SUPPORT
> diff --git a/arch/powerpc/include/asm/Kbuild b/arch/powerpc/include/asm/Kbuild
> index a0c132bedfae..f332e202192a 100644
> --- a/arch/powerpc/include/asm/Kbuild
> +++ b/arch/powerpc/include/asm/Kbuild
> @@ -3,6 +3,7 @@ generated-y += syscall_table_64.h
> generated-y += syscall_table_c32.h
> generated-y += syscall_table_spu.h
> generic-y += div64.h
> +generic-y += dynamic_debug.h
> generic-y += export.h
> generic-y += irq_regs.h
> generic-y += local64.h
>
^ permalink raw reply
* Re: Linux 5.1-rc5
From: Martin Schwidefsky @ 2019-04-23 15:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, linuxppc-dev, Linux List Kernel Mailing,
linux-s390
In-Reply-To: <CAHk-=wj6yp7hkJ_wR38dhdDRkAHQaEx28v2FkVT9hDFXX_qfjA@mail.gmail.com>
On Fri, 19 Apr 2019 10:27:17 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Fri, Apr 19, 2019 at 6:33 AM Martin Schwidefsky
> <schwidefsky@de.ibm.com> wrote:
> >
> > That problem got stuck in my head and I thought more about it. Why not
> > emulate the static folding sequence in the s390 page table code?
>
> So this model seems much closer to what x86 does in its folding, where
> the pattern is basically
>
> > static inline pX-1d_t *pXd_offset(pXd_t *pXd, unsigned long address)
> > {
> > if (pXd_folded(pXd)
> > return (pX-1d_t *) pXd;
> > return (pX-1d_t *) pXd_deref(*pXd) + pXd_index(address);
> > }
>
> which is really how the code is designed to work (ie the folded entry
> doesn't actually do anything to the page directory pointer, it just
> says "ok, we'll use this exact page directory pointer for the next
> lower level instead".
>
> And that's very much what allows the generic gup code to load the
> entry once, and use a temporary, and as you walk down the chain, if it
> is folded it just then uses that (previous) temporary value for the
> next level instead. IOW, the lower level page table is hidden inside
> the upper level one, and folding just means "don't do any offsets,
> don't change any values, just use the entry as-is for the next lower
> level".
>
> So I think that's the right thing to do.
Ok, I added two patches for my s390/linux:features branch
Martin Schwidefsky (2):
s390/mm: make the pxd_offset functions more robust
s390/mm: convert to the generic get_user_pages_fast code
All code changes are inside arch/s390, I plan to include these patches with
the next merge window. That gives us a little bit of time to run our tests.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* Re: [PATCH v12 07/31] mm: make pte_unmap_same compatible with SPF
From: Matthew Wilcox @ 2019-04-23 15:43 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, Daniel Jordan, Ingo Molnar, David Rientjes,
paulmck, Haiyan Song, npiggin, sj38.park, Jerome Glisse, 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: <20190416134522.17540-8-ldufour@linux.ibm.com>
On Tue, Apr 16, 2019 at 03:44:58PM +0200, Laurent Dufour wrote:
> +static inline vm_fault_t pte_unmap_same(struct vm_fault *vmf)
> {
> - int same = 1;
> + int ret = 0;
Surely 'ret' should be of type vm_fault_t?
> + ret = VM_FAULT_RETRY;
... this should have thrown a sparse warning?
^ permalink raw reply
* Re: [PATCH v12 05/31] mm: prepare for FAULT_FLAG_SPECULATIVE
From: Laurent Dufour @ 2019-04-23 15:45 UTC (permalink / raw)
To: Jerome Glisse
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,
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: <20190418220415.GE11645@redhat.com>
Le 19/04/2019 à 00:04, Jerome Glisse a écrit :
> On Tue, Apr 16, 2019 at 03:44:56PM +0200, Laurent Dufour wrote:
>> From: Peter Zijlstra <peterz@infradead.org>
>>
>> When speculating faults (without holding mmap_sem) we need to validate
>> that the vma against which we loaded pages is still valid when we're
>> ready to install the new PTE.
>>
>> Therefore, replace the pte_offset_map_lock() calls that (re)take the
>> PTL with pte_map_lock() which can fail in case we find the VMA changed
>> since we started the fault.
>>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>
>> [Port to 4.12 kernel]
>> [Remove the comment about the fault_env structure which has been
>> implemented as the vm_fault structure in the kernel]
>> [move pte_map_lock()'s definition upper in the file]
>> [move the define of FAULT_FLAG_SPECULATIVE later in the series]
>> [review error path in do_swap_page(), do_anonymous_page() and
>> wp_page_copy()]
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>
> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
>
>> ---
>> mm/memory.c | 87 +++++++++++++++++++++++++++++++++++------------------
>> 1 file changed, 58 insertions(+), 29 deletions(-)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index c6ddadd9d2b7..fc3698d13cb5 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -2073,6 +2073,13 @@ int apply_to_page_range(struct mm_struct *mm, unsigned long addr,
>> }
>> EXPORT_SYMBOL_GPL(apply_to_page_range);
>>
>> +static inline bool pte_map_lock(struct vm_fault *vmf)
>
> I am not fan of the name maybe pte_offset_map_lock_if_valid() ? But
> that just a taste thing. So feel free to ignore this comment.
I agree with you that adding _if_valid or something equivalent to
highlight the conditional of this function would be a good idea.
I'll think further about that name but yours looks good ;)
>> +{
>> + vmf->pte = pte_offset_map_lock(vmf->vma->vm_mm, vmf->pmd,
>> + vmf->address, &vmf->ptl);
>> + return true;
>> +}
>> +
>> /*
>> * handle_pte_fault chooses page fault handler according to an entry which was
>> * read non-atomically. Before making any commitment, on those architectures
>
^ permalink raw reply
* Re: [PATCH v12 07/31] mm: make pte_unmap_same compatible with SPF
From: Laurent Dufour @ 2019-04-23 15:47 UTC (permalink / raw)
To: Matthew Wilcox
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, Daniel Jordan, Ingo Molnar, David Rientjes,
paulmck, Haiyan Song, npiggin, sj38.park, Jerome Glisse, dave,
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: <20190423154351.GB19031@bombadil.infradead.org>
Le 23/04/2019 à 17:43, Matthew Wilcox a écrit :
> On Tue, Apr 16, 2019 at 03:44:58PM +0200, Laurent Dufour wrote:
>> +static inline vm_fault_t pte_unmap_same(struct vm_fault *vmf)
>> {
>> - int same = 1;
>> + int ret = 0;
>
> Surely 'ret' should be of type vm_fault_t?
Nice catch !
>
>> + ret = VM_FAULT_RETRY;
>
> ... this should have thrown a sparse warning?
It should have, but I can't remember having see it, weird...
^ permalink raw reply
* Re: [PATCH v12 11/31] mm: protect mremap() against SPF hanlder
From: Laurent Dufour @ 2019-04-23 15:51 UTC (permalink / raw)
To: Jerome Glisse
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,
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: <20190422195157.GB14666@redhat.com>
Le 22/04/2019 à 21:51, Jerome Glisse a écrit :
> On Tue, Apr 16, 2019 at 03:45:02PM +0200, Laurent Dufour wrote:
>> If a thread is remapping an area while another one is faulting on the
>> destination area, the SPF handler may fetch the vma from the RB tree before
>> the pte has been moved by the other thread. This means that the moved ptes
>> will overwrite those create by the page fault handler leading to page
>> leaked.
>>
>> CPU 1 CPU2
>> enter mremap()
>> unmap the dest area
>> copy_vma() Enter speculative page fault handler
>> >> at this time the dest area is present in the RB tree
>> fetch the vma matching dest area
>> create a pte as the VMA matched
>> Exit the SPF handler
>> <data written in the new page>
>> move_ptes()
>> > it is assumed that the dest area is empty,
>> > the move ptes overwrite the page mapped by the CPU2.
>>
>> To prevent that, when the VMA matching the dest area is extended or created
>> by copy_vma(), it should be marked as non available to the SPF handler.
>> The usual way to so is to rely on vm_write_begin()/end().
>> This is already in __vma_adjust() called by copy_vma() (through
>> vma_merge()). But __vma_adjust() is calling vm_write_end() before returning
>> which create a window for another thread.
>> This patch adds a new parameter to vma_merge() which is passed down to
>> vma_adjust().
>> The assumption is that copy_vma() is returning a vma which should be
>> released by calling vm_raw_write_end() by the callee once the ptes have
>> been moved.
>>
>> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
>
> Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
>
> Small comment about a comment below but can be fix as a fixup
> patch nothing earth shattering.
>
>> ---
>> include/linux/mm.h | 24 ++++++++++++++++-----
>> mm/mmap.c | 53 +++++++++++++++++++++++++++++++++++-----------
>> mm/mremap.c | 13 ++++++++++++
>> 3 files changed, 73 insertions(+), 17 deletions(-)
>>
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 906b9e06f18e..5d45b7d8718d 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -2343,18 +2343,32 @@ void anon_vma_interval_tree_verify(struct anon_vma_chain *node);
>>
>> /* mmap.c */
>> extern int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin);
>> +
>> extern int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert,
>> - struct vm_area_struct *expand);
>> + struct vm_area_struct *expand, bool keep_locked);
>> +
>> static inline int vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert)
>> {
>> - return __vma_adjust(vma, start, end, pgoff, insert, NULL);
>> + return __vma_adjust(vma, start, end, pgoff, insert, NULL, false);
>> }
>> -extern struct vm_area_struct *vma_merge(struct mm_struct *,
>> +
>> +extern struct vm_area_struct *__vma_merge(struct mm_struct *mm,
>> + struct vm_area_struct *prev, unsigned long addr, unsigned long end,
>> + unsigned long vm_flags, struct anon_vma *anon, struct file *file,
>> + pgoff_t pgoff, struct mempolicy *mpol,
>> + struct vm_userfaultfd_ctx uff, bool keep_locked);
>> +
>> +static inline struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> struct vm_area_struct *prev, unsigned long addr, unsigned long end,
>> - unsigned long vm_flags, struct anon_vma *, struct file *, pgoff_t,
>> - struct mempolicy *, struct vm_userfaultfd_ctx);
>> + unsigned long vm_flags, struct anon_vma *anon, struct file *file,
>> + pgoff_t off, struct mempolicy *pol, struct vm_userfaultfd_ctx uff)
>> +{
>> + return __vma_merge(mm, prev, addr, end, vm_flags, anon, file, off,
>> + pol, uff, false);
>> +}
>> +
>> extern struct anon_vma *find_mergeable_anon_vma(struct vm_area_struct *);
>> extern int __split_vma(struct mm_struct *, struct vm_area_struct *,
>> unsigned long addr, int new_below);
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index b77ec0149249..13460b38b0fb 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -714,7 +714,7 @@ static inline void __vma_unlink_prev(struct mm_struct *mm,
>> */
>> int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>> unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert,
>> - struct vm_area_struct *expand)
>> + struct vm_area_struct *expand, bool keep_locked)
>> {
>> struct mm_struct *mm = vma->vm_mm;
>> struct vm_area_struct *next = vma->vm_next, *orig_vma = vma;
>> @@ -830,8 +830,12 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>>
>> importer->anon_vma = exporter->anon_vma;
>> error = anon_vma_clone(importer, exporter);
>> - if (error)
>> + if (error) {
>> + if (next && next != vma)
>> + vm_raw_write_end(next);
>> + vm_raw_write_end(vma);
>> return error;
>> + }
>> }
>> }
>> again:
>> @@ -1025,7 +1029,8 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
>>
>> if (next && next != vma)
>> vm_raw_write_end(next);
>> - vm_raw_write_end(vma);
>> + if (!keep_locked)
>> + vm_raw_write_end(vma);
>>
>> validate_mm(mm);
>>
>> @@ -1161,12 +1166,13 @@ can_vma_merge_after(struct vm_area_struct *vma, unsigned long vm_flags,
>> * parameter) may establish ptes with the wrong permissions of NNNN
>> * instead of the right permissions of XXXX.
>> */
>> -struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> +struct vm_area_struct *__vma_merge(struct mm_struct *mm,
>> struct vm_area_struct *prev, unsigned long addr,
>> unsigned long end, unsigned long vm_flags,
>> struct anon_vma *anon_vma, struct file *file,
>> pgoff_t pgoff, struct mempolicy *policy,
>> - struct vm_userfaultfd_ctx vm_userfaultfd_ctx)
>> + struct vm_userfaultfd_ctx vm_userfaultfd_ctx,
>> + bool keep_locked)
>> {
>> pgoff_t pglen = (end - addr) >> PAGE_SHIFT;
>> struct vm_area_struct *area, *next;
>> @@ -1214,10 +1220,11 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> /* cases 1, 6 */
>> err = __vma_adjust(prev, prev->vm_start,
>> next->vm_end, prev->vm_pgoff, NULL,
>> - prev);
>> + prev, keep_locked);
>> } else /* cases 2, 5, 7 */
>> err = __vma_adjust(prev, prev->vm_start,
>> - end, prev->vm_pgoff, NULL, prev);
>> + end, prev->vm_pgoff, NULL, prev,
>> + keep_locked);
>> if (err)
>> return NULL;
>> khugepaged_enter_vma_merge(prev, vm_flags);
>> @@ -1234,10 +1241,12 @@ struct vm_area_struct *vma_merge(struct mm_struct *mm,
>> vm_userfaultfd_ctx)) {
>> if (prev && addr < prev->vm_end) /* case 4 */
>> err = __vma_adjust(prev, prev->vm_start,
>> - addr, prev->vm_pgoff, NULL, next);
>> + addr, prev->vm_pgoff, NULL, next,
>> + keep_locked);
>> else { /* cases 3, 8 */
>> err = __vma_adjust(area, addr, next->vm_end,
>> - next->vm_pgoff - pglen, NULL, next);
>> + next->vm_pgoff - pglen, NULL, next,
>> + keep_locked);
>> /*
>> * In case 3 area is already equal to next and
>> * this is a noop, but in case 8 "area" has
>> @@ -3259,9 +3268,20 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
>>
>> if (find_vma_links(mm, addr, addr + len, &prev, &rb_link, &rb_parent))
>> return NULL; /* should never get here */
>> - new_vma = vma_merge(mm, prev, addr, addr + len, vma->vm_flags,
>> - vma->anon_vma, vma->vm_file, pgoff, vma_policy(vma),
>> - vma->vm_userfaultfd_ctx);
>> +
>> + /* There is 3 cases to manage here in
>> + * AAAA AAAA AAAA AAAA
>> + * PPPP.... PPPP......NNNN PPPP....NNNN PP........NN
>> + * PPPPPPPP(A) PPPP..NNNNNNNN(B) PPPPPPPPPPPP(1) NULL
>> + * PPPPPPPPNNNN(2)
>> + * PPPPNNNNNNNN(3)
>> + *
>> + * new_vma == prev in case A,1,2
>> + * new_vma == next in case B,3
>> + */
>> + new_vma = __vma_merge(mm, prev, addr, addr + len, vma->vm_flags,
>> + vma->anon_vma, vma->vm_file, pgoff,
>> + vma_policy(vma), vma->vm_userfaultfd_ctx, true);
>> if (new_vma) {
>> /*
>> * Source vma may have been merged into new_vma
>> @@ -3299,6 +3319,15 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
>> get_file(new_vma->vm_file);
>> if (new_vma->vm_ops && new_vma->vm_ops->open)
>> new_vma->vm_ops->open(new_vma);
>> + /*
>> + * As the VMA is linked right now, it may be hit by the
>> + * speculative page fault handler. But we don't want it to
>> + * to start mapping page in this area until the caller has
>> + * potentially move the pte from the moved VMA. To prevent
>> + * that we protect it right now, and let the caller unprotect
>> + * it once the move is done.
>> + */
>
> It would be better to say:
> /*
> * Block speculative page fault on the new VMA before "linking" it as
> * as once it is linked then it may be hit by speculative page fault.
> * But we don't want it to start mapping page in this area until the
> * caller has potentially move the pte from the moved VMA. To prevent
> * that we protect it before linking and let the caller unprotect it
> * once the move is done.
> */
>
I'm fine with your proposal.
Thanks for reviewing this.
>> + vm_raw_write_begin(new_vma);
>> vma_link(mm, new_vma, prev, rb_link, rb_parent);
>> *need_rmap_locks = false;
>> }
>> diff --git a/mm/mremap.c b/mm/mremap.c
>> index fc241d23cd97..ae5c3379586e 100644
>> --- a/mm/mremap.c
>> +++ b/mm/mremap.c
>> @@ -357,6 +357,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> if (!new_vma)
>> return -ENOMEM;
>>
>> + /* new_vma is returned protected by copy_vma, to prevent speculative
>> + * page fault to be done in the destination area before we move the pte.
>> + * Now, we must also protect the source VMA since we don't want pages
>> + * to be mapped in our back while we are copying the PTEs.
>> + */
>> + if (vma != new_vma)
>> + vm_raw_write_begin(vma);
>> +
>> moved_len = move_page_tables(vma, old_addr, new_vma, new_addr, old_len,
>> need_rmap_locks);
>> if (moved_len < old_len) {
>> @@ -373,6 +381,8 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> */
>> move_page_tables(new_vma, new_addr, vma, old_addr, moved_len,
>> true);
>> + if (vma != new_vma)
>> + vm_raw_write_end(vma);
>> vma = new_vma;
>> old_len = new_len;
>> old_addr = new_addr;
>> @@ -381,7 +391,10 @@ static unsigned long move_vma(struct vm_area_struct *vma,
>> mremap_userfaultfd_prep(new_vma, uf);
>> arch_remap(mm, old_addr, old_addr + old_len,
>> new_addr, new_addr + new_len);
>> + if (vma != new_vma)
>> + vm_raw_write_end(vma);
>> }
>> + vm_raw_write_end(new_vma);
>>
>> /* Conceal VM_ACCOUNT so old reservation is not undone */
>> if (vm_flags & VM_ACCOUNT) {
>> --
>> 2.21.0
>>
>
^ permalink raw reply
* Re: Linux 5.1-rc5
From: Linus Torvalds @ 2019-04-23 16:06 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Christoph Hellwig, linuxppc-dev, Linux List Kernel Mailing,
linux-s390
In-Reply-To: <20190423173859.42d5ba8b@mschwideX1>
On Tue, Apr 23, 2019 at 8:39 AM Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
>
> Ok, I added two patches for my s390/linux:features branch
>
> Martin Schwidefsky (2):
> s390/mm: make the pxd_offset functions more robust
> s390/mm: convert to the generic get_user_pages_fast code
>
> All code changes are inside arch/s390, I plan to include these patches with
> the next merge window. That gives us a little bit of time to run our tests.
Sounds good. Thanks for looking into this all.
Now I slightly wonder about all the other random architectures that
don't use the HAVE_GENERIC_GUP config option, but at least we'll have
all of arm, powerpc, x86 and s390 using the generic code..
Linus
^ permalink raw reply
* Re: [PATCH][v2] powerpc/lib: remove memcpy_flushcache redundant return
From: Christophe Leroy @ 2019-04-23 16:13 UTC (permalink / raw)
To: Li RongQing, linuxppc-dev
In-Reply-To: <1555037513-22543-1-git-send-email-lirongqing@baidu.com>
Le 12/04/2019 à 04:51, Li RongQing a écrit :
> Align it with other architectures and none of the callers has
> been interested its return
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> v1->v2: change memcpy_flushcache declaration in arch/powerpc/include/asm/string.h
>
> arch/powerpc/include/asm/string.h | 2 +-
> arch/powerpc/lib/pmem.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/string.h b/arch/powerpc/include/asm/string.h
> index 1647de15a31e..15e2e16272ea 100644
> --- a/arch/powerpc/include/asm/string.h
> +++ b/arch/powerpc/include/asm/string.h
> @@ -25,7 +25,7 @@ extern void * memcpy(void *,const void *,__kernel_size_t);
> extern void * memmove(void *,const void *,__kernel_size_t);
> extern int memcmp(const void *,const void *,__kernel_size_t);
> extern void * memchr(const void *,int,__kernel_size_t);
> -extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);
> +extern void memcpy_flushcache(void *, const void *, __kernel_size_t);
As you are modifying this line, you should make it fully iaw lastest
rules, ie no 'extern' keyword and args should have names.
I guess, just copy it from pmem.c:
void memcpy_flushcache(void *dest, const void *src, size_t size);
Christophe
>
> #ifdef CONFIG_PPC64
> #define __HAVE_ARCH_MEMSET32
> diff --git a/arch/powerpc/lib/pmem.c b/arch/powerpc/lib/pmem.c
> index 53c018762e1c..a7a1b3fc6720 100644
> --- a/arch/powerpc/lib/pmem.c
> +++ b/arch/powerpc/lib/pmem.c
> @@ -48,14 +48,12 @@ long __copy_from_user_flushcache(void *dest, const void __user *src,
> return copied;
> }
>
> -void *memcpy_flushcache(void *dest, const void *src, size_t size)
> +void memcpy_flushcache(void *dest, const void *src, size_t size)
> {
> unsigned long start = (unsigned long) dest;
>
> memcpy(dest, src, size);
> flush_inval_dcache_range(start, start + size);
> -
> - return dest;
> }
> EXPORT_SYMBOL(memcpy_flushcache);
>
>
^ permalink raw reply
* Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Mark Rutland @ 2019-04-23 16:19 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,
Jerome Glisse, 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: <73a3650d-7e9f-bc9e-6ea1-2cef36411b0c@linux.ibm.com>
On Tue, Apr 23, 2019 at 05:36:31PM +0200, Laurent Dufour wrote:
> Le 18/04/2019 à 23:51, Jerome Glisse a écrit :
> > On Tue, Apr 16, 2019 at 03:41:56PM +0100, Mark Rutland wrote:
> > > On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote:
> > > > Le 16/04/2019 à 16:27, Mark Rutland a écrit :
> > > > > On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote:
> > > > > > From: Mahendran Ganesh <opensource.ganesh@gmail.com>
> > > > > >
> > > > > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This
> > > > > > enables Speculative Page Fault handler.
> > > > > >
> > > > > > Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
> > > > >
> > > > > This is missing your S-o-B.
> > > >
> > > > You're right, I missed that...
> > > >
> > > > > The first patch noted that the ARCH_SUPPORTS_* option was there because
> > > > > the arch code had to make an explicit call to try to handle the fault
> > > > > speculatively, but that isn't addeed until patch 30.
> > > > >
> > > > > Why is this separate from that code?
> > > >
> > > > Andrew was recommended this a long time ago for bisection purpose. This
> > > > allows to build the code with CONFIG_SPECULATIVE_PAGE_FAULT before the code
> > > > that trigger the spf handler is added to the per architecture's code.
> > >
> > > Ok. I think it would be worth noting that in the commit message, to
> > > avoid anyone else asking the same question. :)
> >
> > Should have read this thread before looking at x86 and ppc :)
> >
> > In any case the patch is:
> >
> > Reviewed-by: Jérôme Glisse <jglisse@redhat.com>
>
> Thanks Mark and Jérôme for reviewing this.
>
> Regarding the change in the commit message, I'm wondering if this would be
> better to place it in the Series's letter head.
>
> But I'm fine to put it in each architecture's commit.
I think noting it in both the cover letter and specific patches is best.
Having something in the commit message means that the intent will be
clear when the patch is viewed in isolation (e.g. as they will be once
merged).
All that's necessary is something like:
Note that this patch only enables building the common speculative page
fault code such that this can be bisected, and has no functional
impact. The architecture-specific code to make use of this and enable
the feature will be addded in a subsequent patch.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 2/5] powerpc: Fix vDSO clock_getres()
From: Christophe Leroy @ 2019-04-23 16:33 UTC (permalink / raw)
To: Vincenzo Frascino, linux-arch, linux-arm-kernel, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-3-vincenzo.frascino@arm.com>
Le 16/04/2019 à 18:14, Vincenzo Frascino a écrit :
> clock_getres in the vDSO library has to preserve the same behaviour
> of posix_get_hrtimer_res().
>
> In particular, posix_get_hrtimer_res() does:
> sec = 0;
> ns = hrtimer_resolution;
> and hrtimer_resolution depends on the enablement of the high
> resolution timers that can happen either at compile or at run time.
>
> Fix the powerpc vdso implementation of clock_getres keeping a copy of
> hrtimer_resolution in vdso data and using that directly.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> arch/powerpc/include/asm/vdso_datapage.h | 2 ++
> arch/powerpc/kernel/asm-offsets.c | 2 +-
> arch/powerpc/kernel/time.c | 1 +
> arch/powerpc/kernel/vdso32/gettimeofday.S | 7 +++++--
> arch/powerpc/kernel/vdso64/gettimeofday.S | 7 +++++--
> 5 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h
> index bbc06bd72b1f..4333b9a473dc 100644
> --- a/arch/powerpc/include/asm/vdso_datapage.h
> +++ b/arch/powerpc/include/asm/vdso_datapage.h
> @@ -86,6 +86,7 @@ struct vdso_data {
> __s32 wtom_clock_nsec; /* Wall to monotonic clock nsec */
> __s64 wtom_clock_sec; /* Wall to monotonic clock sec */
> struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
> + __u32 hrtimer_res; /* hrtimer resolution */
> __u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
> __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
> };
> @@ -107,6 +108,7 @@ struct vdso_data {
> __s32 wtom_clock_nsec;
> struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
> __u32 stamp_sec_fraction; /* fractional seconds of stamp_xtime */
> + __u32 hrtimer_res; /* hrtimer resolution */
> __u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
> __u32 dcache_block_size; /* L1 d-cache block size */
> __u32 icache_block_size; /* L1 i-cache block size */
> diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
> index 86a61e5f8285..52e4b98a8492 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -383,6 +383,7 @@ int main(void)
> OFFSET(WTOM_CLOCK_NSEC, vdso_data, wtom_clock_nsec);
> OFFSET(STAMP_XTIME, vdso_data, stamp_xtime);
> OFFSET(STAMP_SEC_FRAC, vdso_data, stamp_sec_fraction);
> + OFFSET(CLOCK_REALTIME_RES, vdso_data, hrtimer_res);
> OFFSET(CFG_ICACHE_BLOCKSZ, vdso_data, icache_block_size);
> OFFSET(CFG_DCACHE_BLOCKSZ, vdso_data, dcache_block_size);
> OFFSET(CFG_ICACHE_LOGBLOCKSZ, vdso_data, icache_log_block_size);
> @@ -413,7 +414,6 @@ int main(void)
> DEFINE(CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
> DEFINE(CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_COARSE);
> DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
> - DEFINE(CLOCK_REALTIME_RES, MONOTONIC_RES_NSEC);
>
> #ifdef CONFIG_BUG
> DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index bc0503ef9c9c..62c04a6746d8 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -955,6 +955,7 @@ void update_vsyscall(struct timekeeper *tk)
> vdso_data->wtom_clock_nsec = tk->wall_to_monotonic.tv_nsec;
> vdso_data->stamp_xtime = xt;
> vdso_data->stamp_sec_fraction = frac_sec;
> + vdso_data->hrtimer_res = hrtimer_resolution;
> smp_wmb();
> ++(vdso_data->tb_update_count);
> }
> diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S b/arch/powerpc/kernel/vdso32/gettimeofday.S
> index afd516b572f8..2b5f9e83c610 100644
> --- a/arch/powerpc/kernel/vdso32/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
> @@ -160,12 +160,15 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
> bne cr0,99f
>
> + mflr r12
> + .cfi_register lr,r12
> + bl __get_datapage@local
> + lwz r5,CLOCK_REALTIME_RES(r3)
> + mtlr r12
> li r3,0
> cmpli cr0,r4,0
> crclr cr0*4+so
> beqlr
> - lis r5,CLOCK_REALTIME_RES@h
> - ori r5,r5,CLOCK_REALTIME_RES@l
> stw r3,TSPC32_TV_SEC(r4)
> stw r5,TSPC32_TV_NSEC(r4)
> blr
> diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S
> index 1f324c28705b..f07730f73d5e 100644
> --- a/arch/powerpc/kernel/vdso64/gettimeofday.S
> +++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
> @@ -190,12 +190,15 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
> bne cr0,99f
>
> + mflr r12
> + .cfi_register lr,r12
> + bl V_LOCAL_FUNC(__get_datapage)
> + lwz r5,CLOCK_REALTIME_RES(r3)
> + mtlr r12
> li r3,0
> cmpldi cr0,r4,0
> crclr cr0*4+so
> beqlr
> - lis r5,CLOCK_REALTIME_RES@h
> - ori r5,r5,CLOCK_REALTIME_RES@l
> std r3,TSPC64_TV_SEC(r4)
> std r5,TSPC64_TV_NSEC(r4)
> blr
>
^ permalink raw reply
* Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
From: Rafael J. Wysocki @ 2019-04-23 16:39 UTC (permalink / raw)
To: Changbin Du
Cc: Fenghua Yu, the arch/x86 maintainers, Mauro Carvalho Chehab,
open list:DOCUMENTATION, Linux PCI, linux-gpio, Jonathan Corbet,
Rafael J. Wysocki, Linux Kernel Mailing List,
ACPI Devel Maling List, Ingo Molnar, Bjorn Helgaas,
Thomas Gleixner, linuxppc-dev
In-Reply-To: <20190423162932.21428-1-changbin.du@gmail.com>
On Tue, Apr 23, 2019 at 6:30 PM Changbin Du <changbin.du@gmail.com> wrote:
>
> Hi Corbet and All,
> The kernel now uses Sphinx to generate intelligent and beautiful documentation
> from reStructuredText files. I converted all of the Linux ACPI/PCI/X86 docs to
> reST format in this serias.
>
> In this version I combined ACPI and PCI docs, and added new x86 docs conversion.
I'm not sure if combining all three into one big patch series has been
a good idea, honestly.
It would have been easier to review and handle otherwise.
For one, I'd like to handle the ACPI part of it myself if Jon doesn't mind that.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Comment arch_unmap()
From: Laurent Dufour @ 2019-04-23 16:46 UTC (permalink / raw)
To: mpe; +Cc: Thomas Gleixner, linuxppc-dev, linux-kernel
In-Reply-To: <20190423151712.79391-1-ldufour@linux.ibm.com>
Le 23/04/2019 à 17:17, Laurent Dufour a écrit :
> During a different patch review, the check in arch_munmap() was found
> spucious due the lake of explanation.
>
> Adding a comment to clarify the test.
>
> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
> arch/powerpc/include/asm/mmu_context.h | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
> index 6ee8195a2ffb..638f481b3c9f 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -240,6 +240,17 @@ static inline void arch_unmap(struct mm_struct *mm,
> struct vm_area_struct *vma,
> unsigned long start, unsigned long end)
> {
> + /*
> + * There are 2 assumptions here:
> + * 1. the VDSO is one page size (guaranteed by vdso_data_store)
Indeed this is not true, only the descriptor is one page size.
This makes that test not handling all the cases, especially if a upper
part of the VDSO is unmap (start > mm->context.vdso_base).
I'll sent a new fix asap.
> + * 2. 'start' and 'end' are page aligned (guaranteed by the caller)
> + * The test is wrote in a way to handle unmap operation surrounding the
> + * VDSO area like:
> + * | VDSO |
> + * ^ start ^ end
> + * The test also covers the munmap() operation done to the exact VDSO's
> + * boundaries.
> + */
> if (start <= mm->context.vdso_base && mm->context.vdso_base < end)
> mm->context.vdso_base = 0;
> }
>
^ permalink raw reply
* Re: linux-next: manual merge of the akpm-current tree with the powerpc-fixes tree
From: Ira Weiny @ 2019-04-23 17:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alexey Kardashevskiy, Linux Kernel Mailing List,
Linux Next Mailing List, Andrew Morton, PowerPC
In-Reply-To: <20190423190606.0fefb856@canb.auug.org.au>
On Tue, Apr 23, 2019 at 07:06:06PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/powerpc/mm/mmu_context_iommu.c
>
> between commits:
>
> eb9d7a62c386 ("powerpc/mm_iommu: Fix potential deadlock")
> 7a3a4d763837 ("powerpc/mm_iommu: Allow pinning large regions")
>
> from the powerpc-fixes tree and commit:
>
> 02f506bad7af ("mm/gup: replace get_user_pages_longterm() with FOLL_LONGTERM")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
Thanks Stephen
Looks good for my changes.
Acked-by: Ira Weiny <ira.weiny@intel.com>
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/powerpc/mm/mmu_context_iommu.c
> index 8330f135294f,755fe7adc0d8..000000000000
> --- a/arch/powerpc/mm/mmu_context_iommu.c
> +++ b/arch/powerpc/mm/mmu_context_iommu.c
> @@@ -135,27 -144,18 +131,28 @@@ static long mm_iommu_do_alloc(struct mm
> }
>
> down_read(&mm->mmap_sem);
> - ret = get_user_pages(ua, entries, FOLL_WRITE | FOLL_LONGTERM,
> - mem->hpages, NULL);
> + chunk = (1UL << (PAGE_SHIFT + MAX_ORDER - 1)) /
> + sizeof(struct vm_area_struct *);
> + chunk = min(chunk, entries);
> + for (entry = 0; entry < entries; entry += chunk) {
> + unsigned long n = min(entries - entry, chunk);
> +
> - ret = get_user_pages_longterm(ua + (entry << PAGE_SHIFT), n,
> - FOLL_WRITE, mem->hpages + entry, NULL);
> ++ ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
> ++ FOLL_WRITE | FOLL_LONGTERM,
> ++ mem->hpages + entry, NULL);
> + if (ret == n) {
> + pinned += n;
> + continue;
> + }
> + if (ret > 0)
> + pinned += ret;
> + break;
> + }
> up_read(&mm->mmap_sem);
> - if (ret != entries) {
> - /* free the reference taken */
> - for (i = 0; i < ret; i++)
> - put_page(mem->hpages[i]);
> -
> - vfree(mem->hpas);
> - kfree(mem);
> - ret = -EFAULT;
> - goto unlock_exit;
> + if (pinned != entries) {
> + if (!ret)
> + ret = -EFAULT;
> + goto free_exit;
> }
>
> pageshift = PAGE_SHIFT;
^ permalink raw reply
* Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
From: Bjorn Helgaas @ 2019-04-23 17:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Fenghua Yu, the arch/x86 maintainers, Jonathan Corbet, Linux PCI,
linux-gpio, open list:DOCUMENTATION, Rafael J. Wysocki,
Linux Kernel Mailing List, ACPI Devel Maling List, Ingo Molnar,
Mauro Carvalho Chehab, Thomas Gleixner, linuxppc-dev, Changbin Du
In-Reply-To: <CAJZ5v0jPyaGQcDfpW5b7A-_3bvkfL78MxFmPtjwCGZ4-=KwUwg@mail.gmail.com>
On Tue, Apr 23, 2019 at 06:39:47PM +0200, Rafael J. Wysocki wrote:
> On Tue, Apr 23, 2019 at 6:30 PM Changbin Du <changbin.du@gmail.com> wrote:
> > Hi Corbet and All,
> > The kernel now uses Sphinx to generate intelligent and beautiful
> > documentation from reStructuredText files. I converted all of the Linux
> > ACPI/PCI/X86 docs to reST format in this serias.
> >
> > In this version I combined ACPI and PCI docs, and added new x86 docs
> > conversion.
>
> I'm not sure if combining all three into one big patch series has been
> a good idea, honestly.
Yeah, if you post this again, I would find it easier to deal with if
linux-pci only got the PCI-related things. 63 patches is a little too
much for one series.
Bjorn
^ permalink raw reply
* Re: [PATCH RFT V3 1/8] clk: divider: add explicit big endian support
From: Stephen Boyd @ 2019-04-23 17:40 UTC (permalink / raw)
To: Geert Uytterhoeven, Jonas Gorski
Cc: Prashant Gaikwad, Sascha Hauer, Heiko Stuebner, Fabio Estevam,
Peter De Schrijver, Michal Simek, Shawn Guo, Jonathan Hunter,
open list:ARM/Rockchip SoC..., Michael Turquette, Paul Mackerras,
NXP Linux Team, Pengutronix Kernel Team, linux-tegra,
Thierry Reding, Anatolij Gustschin, linuxppc-dev, linux-clk,
Linux ARM
In-Reply-To: <CAOiHx=mjhzG-i8H5R0A+Mu3mcBXTNEaaBhC8rwCQPMWArDA+1A@mail.gmail.com>
Quoting Jonas Gorski (2019-04-23 03:39:59)
> No purpose at all, it's an uncaught artifact from rebasing ._.
>
> Stephen, which one is your preferred way of fixing that?
>
> a) a new V4 patchset without this line
> b) a follow up patch that removes it
> c) just removing the line yourself
I'll go for c and fix up things. Thanks for the catch Geert!
^ permalink raw reply
* Re: [PATCH v12 21/31] mm: Introduce find_vma_rcu()
From: Davidlohr Bueso @ 2019-04-23 18:13 UTC (permalink / raw)
To: Peter Zijlstra
Cc: jack, sergey.senozhatsky.work, 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, Jerome Glisse,
kemi.wang, kirill, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, Mike Rapoport, linuxppc-dev,
linux-kernel, Sergey Senozhatsky, vinayak menon, akpm, Tim Chen,
haren
In-Reply-To: <20190423092710.GI11158@hirez.programming.kicks-ass.net>
On Tue, 23 Apr 2019, Peter Zijlstra wrote:
>Also; the initial motivation was prefaulting large VMAs and the
>contention on mmap was killing things; but similarly, the contention on
>the refcount (I did try that) killed things just the same.
Right, this is just like what can happen with per-vma locking.
Thanks,
Davidlohr
^ permalink raw reply
* Re: [PATCH 10/10] powerpc: select DYNAMIC_DEBUG_RELATIVE_POINTERS for PPC64
From: Andrew Morton @ 2019-04-23 19:36 UTC (permalink / raw)
To: Christophe Leroy
Cc: linuxppc-dev, Jason Baron, Rasmus Villemoes, linux-kernel
In-Reply-To: <b5304c4c-736a-fd8b-e025-4ea040f5c346@c-s.fr>
On Tue, 23 Apr 2019 17:37:33 +0200 Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -155,6 +155,7 @@ config PPC
> > select BUILDTIME_EXTABLE_SORT
> > select CLONE_BACKWARDS
> > select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN
> > + select DYNAMIC_DEBUG_RELATIVE_POINTERS if PPC64
>
> Why only PPC64 ? Won't it work with PPC32 ? Or would it be
> counter-performant on 32 bits ?
Ditto arm and i386?
^ permalink raw reply
* [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
From: Changbin Du @ 2019-04-23 16:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: fenghua.yu, mchehab+samsung, linux-doc, linux-pci, linux-gpio,
x86, rjw, linux-kernel, linux-acpi, mingo, Bjorn Helgaas, tglx,
linuxppc-dev, Changbin Du
Hi Corbet and All,
The kernel now uses Sphinx to generate intelligent and beautiful documentation
from reStructuredText files. I converted all of the Linux ACPI/PCI/X86 docs to
reST format in this serias.
In this version I combined ACPI and PCI docs, and added new x86 docs conversion.
The hieararchy of ACPI docs are based on Corbet's suggestion:
https://lkml.org/lkml/2019/4/3/1047
I did some adjustment according to the content and finally they are placed as:
Documentation/firmware-guide/acpi/
├── acpi-lid.rst
├── aml-debugger.rst
├── apei
│ ├── einj.rst
│ └── output_format.rst
├── debug.rst
├── dsd
│ ├── data-node-references.rst
│ └── graph.rst
├── DSD-properties-rules.rst
├── enumeration.rst
├── gpio-properties.rst
├── i2c-muxes.rst
├── lpit.rst
├── method-customizing.rst
├── method-tracing.rst
├── namespace.rst
├── osi.rst
└── video_extension.rst
Documentation/driver-api/acpi/
├── linuxized-acpica.rst
└── scan_handlers.rst
ocumentation/admin-guide/acpi/
├── cppc_sysfs.rst
├── dsdt-override.rst
├── initrd_table_override.rst
└── ssdt-overlays.rst
The PCI docs are all put into driver API guide.
The X86 docs are all put into Architecture-specific documentation.
For you to preview, please visit below url:
http://www.bytemem.com:8080/kernel-doc/index.html
Thank you!
Changbin Du (63):
Documentation: add Linux ACPI to Sphinx TOC tree
Documentation: ACPI: move namespace.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move osi.txt to firmware-guide/acpi and convert
to reST
Documentation: ACPI: move linuxized-acpica.txt to driver-api/acpi and
convert to reST
Documentation: ACPI: move scan_handlers.txt to driver-api/acpi and
convert to reST
Documentation: ACPI: move DSD-properties-rules.txt to
firmware-guide/acpi and covert to reST
Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi
and convert to reST
Documentation: ACPI: move method-customizing.txt to
firmware-guide/acpi and convert to reST
Documentation: ACPI: move initrd_table_override.txt to
admin-guide/acpi and convert to reST
Documentation: ACPI: move dsdt-override.txt to admin-guide/acpi and
convert to reST
Documentation: ACPI: move i2c-muxes.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move acpi-lid.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move dsd/graph.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move dsd/data-node-references.txt to
firmware-guide/acpi and convert to reST
Documentation: ACPI: move debug.txt to firmware-guide/acpi and convert
to reST
Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi
and convert to rsST
Documentation: ACPI: move aml-debugger.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move apei/output_format.txt to
firmware-guide/acpi and convert to reST
Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and
convert to reST
Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and
convert to reST
Documentation: ACPI: move lpit.txt to firmware-guide/acpi and convert
to reST
Documentation: ACPI: move ssdt-overlays.txt to admin-guide/acpi and
convert to reST
Documentation: ACPI: move video_extension.txt to firmware-guide/acpi
and convert to reST
Documentation: add Linux PCI to Sphinx TOC tree
Documentation: PCI: convert pci.txt to reST
Documentation: PCI: convert PCIEBUS-HOWTO.txt to reST
Documentation: PCI: convert pci-iov-howto.txt to reST
Documentation: PCI: convert MSI-HOWTO.txt to reST
Documentation: PCI: convert acpi-info.txt to reST
Documentation: PCI: convert pci-error-recovery.txt to reST
Documentation: PCI: convert pcieaer-howto.txt to reST
Documentation: PCI: convert endpoint/pci-endpoint.txt to reST
Documentation: PCI: convert endpoint/pci-endpoint-cfs.txt to reST
Documentation: PCI: convert endpoint/pci-test-function.txt to reST
Documentation: PCI: convert endpoint/pci-test-howto.txt to reST
Documentation: add Linux x86 docs to Sphinx TOC tree
Documentation: x86: convert boot.txt to reST
Documentation: x86: convert topology.txt to reST
Documentation: x86: convert exception-tables.txt to reST
Documentation: x86: convert kernel-stacks to reST
Documentation: x86: convert entry_64.txt to reST
Documentation: x86: convert earlyprintk.txt to reST
Documentation: x86: convert zero-page.txt to reST
Documentation: x86: convert tlb.txt to reST
Documentation: x86: convert mtrr.txt to reST
Documentation: x86: convert pat.txt to reST
Documentation: x86: convert protection-keys.txt to reST
Documentation: x86: convert intel_mpx.txt to reST
Documentation: x86: convert amd-memory-encryption.txt to reST
Documentation: x86: convert pti.txt to reST
Documentation: x86: convert microcode.txt to reST
Documentation: x86: convert resctrl_ui.txt to reST
Documentation: x86: convert orc-unwinder.txt to reST
Documentation: x86: convert usb-legacy-support.txt to reST
Documentation: x86: convert i386/IO-APIC.txt to reST
Documentation: x86: convert x86_64/boot-options.txt to reST
Documentation: x86: convert x86_64/uefi.txt to reST
Documentation: x86: convert x86_64/mm.txt to reST
Documentation: x86: convert x86_64/5level-paging.txt to reST
Documentation: x86: convert x86_64/fake-numa-for-cpusets to reST
Documentation: x86: convert x86_64/cpu-hotplug-spec to reST
Documentation: x86: convert x86_64/machinecheck to reST
.../PCI/{MSI-HOWTO.txt => MSI-HOWTO.rst} | 83 +-
.../{PCIEBUS-HOWTO.txt => PCIEBUS-HOWTO.rst} | 140 +-
.../PCI/{acpi-info.txt => acpi-info.rst} | 11 +-
Documentation/PCI/endpoint/index.rst | 13 +
...-endpoint-cfs.txt => pci-endpoint-cfs.rst} | 99 +-
.../{pci-endpoint.txt => pci-endpoint.rst} | 95 +-
...est-function.txt => pci-test-function.rst} | 32 +-
...{pci-test-howto.txt => pci-test-howto.rst} | 81 +-
Documentation/PCI/index.rst | 18 +
...or-recovery.txt => pci-error-recovery.rst} | 178 +--
.../{pci-iov-howto.txt => pci-iov-howto.rst} | 161 ++-
Documentation/PCI/{pci.txt => pci.rst} | 267 ++--
.../{pcieaer-howto.txt => pcieaer-howto.rst} | 110 +-
Documentation/acpi/aml-debugger.txt | 66 -
Documentation/acpi/apei/output_format.txt | 147 --
Documentation/acpi/i2c-muxes.txt | 58 -
Documentation/acpi/initrd_table_override.txt | 111 --
Documentation/acpi/method-customizing.txt | 73 -
Documentation/acpi/method-tracing.txt | 192 ---
Documentation/acpi/ssdt-overlays.txt | 172 ---
.../acpi/cppc_sysfs.rst} | 71 +-
.../acpi/dsdt-override.rst} | 8 +-
Documentation/admin-guide/acpi/index.rst | 14 +
.../acpi/initrd_table_override.rst | 120 ++
.../admin-guide/acpi/ssdt-overlays.rst | 180 +++
Documentation/admin-guide/index.rst | 1 +
Documentation/driver-api/acpi/index.rst | 9 +
.../acpi/linuxized-acpica.rst} | 115 +-
.../acpi/scan_handlers.rst} | 24 +-
Documentation/driver-api/index.rst | 1 +
.../acpi/DSD-properties-rules.rst} | 21 +-
.../acpi/acpi-lid.rst} | 48 +-
.../firmware-guide/acpi/aml-debugger.rst | 75 +
.../acpi/apei/einj.rst} | 98 +-
.../acpi/apei/output_format.rst | 150 ++
.../acpi/debug.rst} | 31 +-
.../acpi/dsd/data-node-references.rst} | 28 +-
.../acpi/dsd/graph.rst} | 157 +--
.../acpi/enumeration.rst} | 135 +-
.../acpi/gpio-properties.rst} | 78 +-
.../firmware-guide/acpi/i2c-muxes.rst | 61 +
Documentation/firmware-guide/acpi/index.rst | 26 +
.../lpit.txt => firmware-guide/acpi/lpit.rst} | 18 +-
.../acpi/method-customizing.rst | 82 ++
.../firmware-guide/acpi/method-tracing.rst | 225 +++
.../acpi/namespace.rst} | 310 +++--
.../osi.txt => firmware-guide/acpi/osi.rst} | 15 +-
.../acpi/video_extension.rst} | 63 +-
Documentation/firmware-guide/index.rst | 13 +
Documentation/index.rst | 12 +
...cryption.txt => amd-memory-encryption.rst} | 13 +-
Documentation/x86/boot.rst | 1205 +++++++++++++++++
Documentation/x86/boot.txt | 1130 ----------------
Documentation/x86/earlyprintk.rst | 148 ++
Documentation/x86/earlyprintk.txt | 141 --
.../x86/{entry_64.txt => entry_64.rst} | 12 +-
...eption-tables.txt => exception-tables.rst} | 231 ++--
.../x86/i386/{IO-APIC.txt => IO-APIC.rst} | 26 +-
Documentation/x86/i386/index.rst | 10 +
Documentation/x86/index.rst | 30 +
.../x86/{intel_mpx.txt => intel_mpx.rst} | 120 +-
.../x86/{kernel-stacks => kernel-stacks.rst} | 20 +-
.../x86/{microcode.txt => microcode.rst} | 62 +-
Documentation/x86/mtrr.rst | 350 +++++
Documentation/x86/mtrr.txt | 329 -----
.../{orc-unwinder.txt => orc-unwinder.rst} | 27 +-
Documentation/x86/pat.rst | 235 ++++
Documentation/x86/pat.txt | 230 ----
...rotection-keys.txt => protection-keys.rst} | 33 +-
Documentation/x86/{pti.txt => pti.rst} | 19 +-
.../x86/{resctrl_ui.txt => resctrl_ui.rst} | 913 +++++++------
Documentation/x86/{tlb.txt => tlb.rst} | 30 +-
Documentation/x86/topology.rst | 228 ++++
Documentation/x86/topology.txt | 217 ---
...acy-support.txt => usb-legacy-support.rst} | 8 +-
.../{5level-paging.txt => 5level-paging.rst} | 16 +-
Documentation/x86/x86_64/boot-options.rst | 327 +++++
Documentation/x86/x86_64/boot-options.txt | 278 ----
...{cpu-hotplug-spec => cpu-hotplug-spec.rst} | 5 +-
...-for-cpusets => fake-numa-for-cpusets.rst} | 18 +-
Documentation/x86/x86_64/index.rst | 16 +
.../x86_64/{machinecheck => machinecheck.rst} | 11 +-
Documentation/x86/x86_64/mm.rst | 161 +++
Documentation/x86/x86_64/mm.txt | 153 ---
.../x86/x86_64/{uefi.txt => uefi.rst} | 30 +-
Documentation/x86/zero-page.rst | 47 +
Documentation/x86/zero-page.txt | 40 -
MAINTAINERS | 4 +-
88 files changed, 6041 insertions(+), 5128 deletions(-)
rename Documentation/PCI/{MSI-HOWTO.txt => MSI-HOWTO.rst} (88%)
rename Documentation/PCI/{PCIEBUS-HOWTO.txt => PCIEBUS-HOWTO.rst} (70%)
rename Documentation/PCI/{acpi-info.txt => acpi-info.rst} (97%)
create mode 100644 Documentation/PCI/endpoint/index.rst
rename Documentation/PCI/endpoint/{pci-endpoint-cfs.txt => pci-endpoint-cfs.rst} (64%)
rename Documentation/PCI/endpoint/{pci-endpoint.txt => pci-endpoint.rst} (82%)
rename Documentation/PCI/endpoint/{pci-test-function.txt => pci-test-function.rst} (84%)
rename Documentation/PCI/endpoint/{pci-test-howto.txt => pci-test-howto.rst} (78%)
create mode 100644 Documentation/PCI/index.rst
rename Documentation/PCI/{pci-error-recovery.txt => pci-error-recovery.rst} (80%)
rename Documentation/PCI/{pci-iov-howto.txt => pci-iov-howto.rst} (63%)
rename Documentation/PCI/{pci.txt => pci.rst} (78%)
rename Documentation/PCI/{pcieaer-howto.txt => pcieaer-howto.rst} (81%)
delete mode 100644 Documentation/acpi/aml-debugger.txt
delete mode 100644 Documentation/acpi/apei/output_format.txt
delete mode 100644 Documentation/acpi/i2c-muxes.txt
delete mode 100644 Documentation/acpi/initrd_table_override.txt
delete mode 100644 Documentation/acpi/method-customizing.txt
delete mode 100644 Documentation/acpi/method-tracing.txt
delete mode 100644 Documentation/acpi/ssdt-overlays.txt
rename Documentation/{acpi/cppc_sysfs.txt => admin-guide/acpi/cppc_sysfs.rst} (51%)
rename Documentation/{acpi/dsdt-override.txt => admin-guide/acpi/dsdt-override.rst} (56%)
create mode 100644 Documentation/admin-guide/acpi/index.rst
create mode 100644 Documentation/admin-guide/acpi/initrd_table_override.rst
create mode 100644 Documentation/admin-guide/acpi/ssdt-overlays.rst
create mode 100644 Documentation/driver-api/acpi/index.rst
rename Documentation/{acpi/linuxized-acpica.txt => driver-api/acpi/linuxized-acpica.rst} (78%)
rename Documentation/{acpi/scan_handlers.txt => driver-api/acpi/scan_handlers.rst} (90%)
rename Documentation/{acpi/DSD-properties-rules.txt => firmware-guide/acpi/DSD-properties-rules.rst} (88%)
rename Documentation/{acpi/acpi-lid.txt => firmware-guide/acpi/acpi-lid.rst} (77%)
create mode 100644 Documentation/firmware-guide/acpi/aml-debugger.rst
rename Documentation/{acpi/apei/einj.txt => firmware-guide/acpi/apei/einj.rst} (67%)
create mode 100644 Documentation/firmware-guide/acpi/apei/output_format.rst
rename Documentation/{acpi/debug.txt => firmware-guide/acpi/debug.rst} (91%)
rename Documentation/{acpi/dsd/data-node-references.txt => firmware-guide/acpi/dsd/data-node-references.rst} (79%)
rename Documentation/{acpi/dsd/graph.txt => firmware-guide/acpi/dsd/graph.rst} (56%)
rename Documentation/{acpi/enumeration.txt => firmware-guide/acpi/enumeration.rst} (87%)
rename Documentation/{acpi/gpio-properties.txt => firmware-guide/acpi/gpio-properties.rst} (81%)
create mode 100644 Documentation/firmware-guide/acpi/i2c-muxes.rst
create mode 100644 Documentation/firmware-guide/acpi/index.rst
rename Documentation/{acpi/lpit.txt => firmware-guide/acpi/lpit.rst} (68%)
create mode 100644 Documentation/firmware-guide/acpi/method-customizing.rst
create mode 100644 Documentation/firmware-guide/acpi/method-tracing.rst
rename Documentation/{acpi/namespace.txt => firmware-guide/acpi/namespace.rst} (54%)
rename Documentation/{acpi/osi.txt => firmware-guide/acpi/osi.rst} (97%)
rename Documentation/{acpi/video_extension.txt => firmware-guide/acpi/video_extension.rst} (79%)
create mode 100644 Documentation/firmware-guide/index.rst
rename Documentation/x86/{amd-memory-encryption.txt => amd-memory-encryption.rst} (94%)
create mode 100644 Documentation/x86/boot.rst
delete mode 100644 Documentation/x86/boot.txt
create mode 100644 Documentation/x86/earlyprintk.rst
delete mode 100644 Documentation/x86/earlyprintk.txt
rename Documentation/x86/{entry_64.txt => entry_64.rst} (95%)
rename Documentation/x86/{exception-tables.txt => exception-tables.rst} (67%)
rename Documentation/x86/i386/{IO-APIC.txt => IO-APIC.rst} (93%)
create mode 100644 Documentation/x86/i386/index.rst
create mode 100644 Documentation/x86/index.rst
rename Documentation/x86/{intel_mpx.txt => intel_mpx.rst} (75%)
rename Documentation/x86/{kernel-stacks => kernel-stacks.rst} (92%)
rename Documentation/x86/{microcode.txt => microcode.rst} (81%)
create mode 100644 Documentation/x86/mtrr.rst
delete mode 100644 Documentation/x86/mtrr.txt
rename Documentation/x86/{orc-unwinder.txt => orc-unwinder.rst} (93%)
create mode 100644 Documentation/x86/pat.rst
delete mode 100644 Documentation/x86/pat.txt
rename Documentation/x86/{protection-keys.txt => protection-keys.rst} (83%)
rename Documentation/x86/{pti.txt => pti.rst} (95%)
rename Documentation/x86/{resctrl_ui.txt => resctrl_ui.rst} (68%)
rename Documentation/x86/{tlb.txt => tlb.rst} (81%)
create mode 100644 Documentation/x86/topology.rst
delete mode 100644 Documentation/x86/topology.txt
rename Documentation/x86/{usb-legacy-support.txt => usb-legacy-support.rst} (92%)
rename Documentation/x86/x86_64/{5level-paging.txt => 5level-paging.rst} (91%)
create mode 100644 Documentation/x86/x86_64/boot-options.rst
delete mode 100644 Documentation/x86/x86_64/boot-options.txt
rename Documentation/x86/x86_64/{cpu-hotplug-spec => cpu-hotplug-spec.rst} (88%)
rename Documentation/x86/x86_64/{fake-numa-for-cpusets => fake-numa-for-cpusets.rst} (90%)
create mode 100644 Documentation/x86/x86_64/index.rst
rename Documentation/x86/x86_64/{machinecheck => machinecheck.rst} (92%)
create mode 100644 Documentation/x86/x86_64/mm.rst
delete mode 100644 Documentation/x86/x86_64/mm.txt
rename Documentation/x86/x86_64/{uefi.txt => uefi.rst} (79%)
create mode 100644 Documentation/x86/zero-page.rst
delete mode 100644 Documentation/x86/zero-page.txt
--
2.20.1
^ permalink raw reply
* [PATCH v4 01/63] Documentation: add Linux ACPI to Sphinx TOC tree
From: Changbin Du @ 2019-04-23 16:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: fenghua.yu, mchehab+samsung, linux-doc, linux-pci, linux-gpio,
x86, rjw, linux-kernel, linux-acpi, mingo, Bjorn Helgaas, tglx,
linuxppc-dev, Changbin Du
In-Reply-To: <20190423162932.21428-1-changbin.du@gmail.com>
Add below index.rst files for ACPI subsystem. More docs will be added later.
o admin-guide/acpi/index.rst
o driver-api/acpi/index.rst
o firmware-guide/index.rst
Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
Documentation/admin-guide/acpi/index.rst | 10 ++++++++++
Documentation/admin-guide/index.rst | 1 +
Documentation/driver-api/acpi/index.rst | 7 +++++++
Documentation/driver-api/index.rst | 1 +
Documentation/firmware-guide/acpi/index.rst | 9 +++++++++
Documentation/firmware-guide/index.rst | 13 +++++++++++++
Documentation/index.rst | 10 ++++++++++
7 files changed, 51 insertions(+)
create mode 100644 Documentation/admin-guide/acpi/index.rst
create mode 100644 Documentation/driver-api/acpi/index.rst
create mode 100644 Documentation/firmware-guide/acpi/index.rst
create mode 100644 Documentation/firmware-guide/index.rst
diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst
new file mode 100644
index 000000000000..3e041206089d
--- /dev/null
+++ b/Documentation/admin-guide/acpi/index.rst
@@ -0,0 +1,10 @@
+============
+ACPI Support
+============
+
+Here we document in detail how to interact with various mechanisms in
+the Linux ACPI support.
+
+.. toctree::
+ :maxdepth: 1
+
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 0a491676685e..5b8286fdd91b 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -77,6 +77,7 @@ configure specific aspects of kernel behavior to your liking.
LSM/index
mm/index
perf-security
+ acpi/index
.. only:: subproject and html
diff --git a/Documentation/driver-api/acpi/index.rst b/Documentation/driver-api/acpi/index.rst
new file mode 100644
index 000000000000..898b0c60671a
--- /dev/null
+++ b/Documentation/driver-api/acpi/index.rst
@@ -0,0 +1,7 @@
+============
+ACPI Support
+============
+
+.. toctree::
+ :maxdepth: 2
+
diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst
index c0b600ed9961..aa87075c7846 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -56,6 +56,7 @@ available subsections can be seen below.
slimbus
soundwire/index
fpga/index
+ acpi/index
.. only:: subproject and html
diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
new file mode 100644
index 000000000000..0ec7d072ba22
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+ACPI Support
+============
+
+.. toctree::
+ :maxdepth: 1
+
diff --git a/Documentation/firmware-guide/index.rst b/Documentation/firmware-guide/index.rst
new file mode 100644
index 000000000000..5355784ca0a2
--- /dev/null
+++ b/Documentation/firmware-guide/index.rst
@@ -0,0 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================
+The Linux kernel firmware guide
+===============================
+
+This section describes the ACPI subsystem in Linux from firmware perspective.
+
+.. toctree::
+ :maxdepth: 1
+
+ acpi/index
+
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 80a421cb935e..fdfa85c56a50 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -35,6 +35,16 @@ trying to get it to work optimally on a given system.
admin-guide/index
+Firmware-related documentation
+------------------------------
+The following holds information on the kernel's expectations regarding the
+platform firmwares.
+
+.. toctree::
+ :maxdepth: 2
+
+ firmware-guide/index
+
Application-developer documentation
-----------------------------------
--
2.20.1
^ permalink raw reply related
* [PATCH v4 02/63] Documentation: ACPI: move namespace.txt to firmware-guide/acpi and convert to reST
From: Changbin Du @ 2019-04-23 16:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: fenghua.yu, mchehab+samsung, linux-doc, linux-pci, linux-gpio,
x86, rjw, linux-kernel, linux-acpi, mingo, Bjorn Helgaas, tglx,
linuxppc-dev, Changbin Du
In-Reply-To: <20190423162932.21428-1-changbin.du@gmail.com>
This converts the plain text documentation to reStructuredText format and
add it to Sphinx TOC tree. No essential content change.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../acpi/namespace.rst} | 310 +++++++++---------
2 files changed, 161 insertions(+), 150 deletions(-)
rename Documentation/{acpi/namespace.txt => firmware-guide/acpi/namespace.rst} (54%)
diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
index 0ec7d072ba22..210ad8acd6df 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -7,3 +7,4 @@ ACPI Support
.. toctree::
:maxdepth: 1
+ namespace
diff --git a/Documentation/acpi/namespace.txt b/Documentation/firmware-guide/acpi/namespace.rst
similarity index 54%
rename from Documentation/acpi/namespace.txt
rename to Documentation/firmware-guide/acpi/namespace.rst
index 1860cb3865c6..443f0e5d0617 100644
--- a/Documentation/acpi/namespace.txt
+++ b/Documentation/firmware-guide/acpi/namespace.rst
@@ -1,85 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===================================================
ACPI Device Tree - Representation of ACPI Namespace
+===================================================
+
+:Copyright: |copy| 2013, Intel Corporation
+
+:Author: Lv Zheng <lv.zheng@intel.com>
+
+:Abstract: The Linux ACPI subsystem converts ACPI namespace objects into a Linux
+ device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
+ receiving ACPI hotplug notification events. For each device object
+ in this hierarchy there is a corresponding symbolic link in the
+ /sys/bus/acpi/devices.
+ This document illustrates the structure of the ACPI device tree.
+
+:Credit: Thanks for the help from Zhang Rui <rui.zhang@intel.com> and
+ Rafael J.Wysocki <rafael.j.wysocki@intel.com>.
+
+
+ACPI Definition Blocks
+======================
+
+The ACPI firmware sets up RSDP (Root System Description Pointer) in the
+system memory address space pointing to the XSDT (Extended System
+Description Table). The XSDT always points to the FADT (Fixed ACPI
+Description Table) using its first entry, the data within the FADT
+includes various fixed-length entries that describe fixed ACPI features
+of the hardware. The FADT contains a pointer to the DSDT
+(Differentiated System Descripition Table). The XSDT also contains
+entries pointing to possibly multiple SSDTs (Secondary System
+Description Table).
+
+The DSDT and SSDT data is organized in data structures called definition
+blocks that contain definitions of various objects, including ACPI
+control methods, encoded in AML (ACPI Machine Language). The data block
+of the DSDT along with the contents of SSDTs represents a hierarchical
+data structure called the ACPI namespace whose topology reflects the
+structure of the underlying hardware platform.
+
+The relationships between ACPI System Definition Tables described above
+are illustrated in the following diagram::
+
+ +---------+ +-------+ +--------+ +------------------------+
+ | RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
+ +---------+ | +-------+ | +--------+ +-|->| DSDT | |
+ | Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
+ +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
+ | Pointer |-+ | ..... | | ...... | | +-------------------+ |
+ +---------+ +-------+ +--------+ | +-------------------+ |
+ | Entry |------------------|->| SSDT | |
+ +- - - -+ | +-------------------| |
+ | Entry | - - - - - - - -+ | | Definition Blocks | |
+ +- - - -+ | | +-------------------+ |
+ | | +- - - - - - - - - -+ |
+ +-|->| SSDT | |
+ | +-------------------+ |
+ | | Definition Blocks | |
+ | +- - - - - - - - - -+ |
+ +------------------------+
+ |
+ OSPM Loading |
+ \|/
+ +----------------+
+ | ACPI Namespace |
+ +----------------+
+
+ Figure 1. ACPI Definition Blocks
+
+.. note:: RSDP can also contain a pointer to the RSDT (Root System
+ Description Table). Platforms provide RSDT to enable
+ compatibility with ACPI 1.0 operating systems. The OS is expected
+ to use XSDT, if present.
+
+
+Example ACPI Namespace
+======================
+
+All definition blocks are loaded into a single namespace. The namespace
+is a hierarchy of objects identified by names and paths.
+The following naming conventions apply to object names in the ACPI
+namespace:
-Copyright (C) 2013, Intel Corporation
-Author: Lv Zheng <lv.zheng@intel.com>
-
-
-Abstract:
-
-The Linux ACPI subsystem converts ACPI namespace objects into a Linux
-device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
-receiving ACPI hotplug notification events. For each device object in this
-hierarchy there is a corresponding symbolic link in the
-/sys/bus/acpi/devices.
-This document illustrates the structure of the ACPI device tree.
-
-
-Credit:
-
-Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
-Wysocki <rafael.j.wysocki@intel.com>.
-
-
-1. ACPI Definition Blocks
-
- The ACPI firmware sets up RSDP (Root System Description Pointer) in the
- system memory address space pointing to the XSDT (Extended System
- Description Table). The XSDT always points to the FADT (Fixed ACPI
- Description Table) using its first entry, the data within the FADT
- includes various fixed-length entries that describe fixed ACPI features
- of the hardware. The FADT contains a pointer to the DSDT
- (Differentiated System Descripition Table). The XSDT also contains
- entries pointing to possibly multiple SSDTs (Secondary System
- Description Table).
-
- The DSDT and SSDT data is organized in data structures called definition
- blocks that contain definitions of various objects, including ACPI
- control methods, encoded in AML (ACPI Machine Language). The data block
- of the DSDT along with the contents of SSDTs represents a hierarchical
- data structure called the ACPI namespace whose topology reflects the
- structure of the underlying hardware platform.
-
- The relationships between ACPI System Definition Tables described above
- are illustrated in the following diagram.
-
- +---------+ +-------+ +--------+ +------------------------+
- | RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
- +---------+ | +-------+ | +--------+ +-|->| DSDT | |
- | Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
- +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
- | Pointer |-+ | ..... | | ...... | | +-------------------+ |
- +---------+ +-------+ +--------+ | +-------------------+ |
- | Entry |------------------|->| SSDT | |
- +- - - -+ | +-------------------| |
- | Entry | - - - - - - - -+ | | Definition Blocks | |
- +- - - -+ | | +-------------------+ |
- | | +- - - - - - - - - -+ |
- +-|->| SSDT | |
- | +-------------------+ |
- | | Definition Blocks | |
- | +- - - - - - - - - -+ |
- +------------------------+
- |
- OSPM Loading |
- \|/
- +----------------+
- | ACPI Namespace |
- +----------------+
-
- Figure 1. ACPI Definition Blocks
-
- NOTE: RSDP can also contain a pointer to the RSDT (Root System
- Description Table). Platforms provide RSDT to enable
- compatibility with ACPI 1.0 operating systems. The OS is expected
- to use XSDT, if present.
-
-
-2. Example ACPI Namespace
-
- All definition blocks are loaded into a single namespace. The namespace
- is a hierarchy of objects identified by names and paths.
- The following naming conventions apply to object names in the ACPI
- namespace:
1. All names are 32 bits long.
2. The first byte of a name must be one of 'A' - 'Z', '_'.
3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
@@ -91,7 +94,7 @@ Wysocki <rafael.j.wysocki@intel.com>.
(i.e. names prepended with '^' are relative to the parent of the
current namespace node).
- The figure below shows an example ACPI namespace.
+The figure below shows an example ACPI namespace::
+------+
| \ | Root
@@ -184,19 +187,20 @@ Wysocki <rafael.j.wysocki@intel.com>.
Figure 2. Example ACPI Namespace
-3. Linux ACPI Device Objects
+Linux ACPI Device Objects
+=========================
- The Linux kernel's core ACPI subsystem creates struct acpi_device
- objects for ACPI namespace objects representing devices, power resources
- processors, thermal zones. Those objects are exported to user space via
- sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
- format of their names is <bus_id:instance>, where 'bus_id' refers to the
- ACPI namespace representation of the given object and 'instance' is used
- for distinguishing different object of the same 'bus_id' (it is
- two-digit decimal representation of an unsigned integer).
+The Linux kernel's core ACPI subsystem creates struct acpi_device
+objects for ACPI namespace objects representing devices, power resources
+processors, thermal zones. Those objects are exported to user space via
+sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
+format of their names is <bus_id:instance>, where 'bus_id' refers to the
+ACPI namespace representation of the given object and 'instance' is used
+for distinguishing different object of the same 'bus_id' (it is
+two-digit decimal representation of an unsigned integer).
- The value of 'bus_id' depends on the type of the object whose name it is
- part of as listed in the table below.
+The value of 'bus_id' depends on the type of the object whose name it is
+part of as listed in the table below::
+---+-----------------+-------+----------+
| | Object/Feature | Table | bus_id |
@@ -226,10 +230,11 @@ Wysocki <rafael.j.wysocki@intel.com>.
Table 1. ACPI Namespace Objects Mapping
- The following rules apply when creating struct acpi_device objects on
- the basis of the contents of ACPI System Description Tables (as
- indicated by the letter in the first column and the notation in the
- second column of the table above):
+The following rules apply when creating struct acpi_device objects on
+the basis of the contents of ACPI System Description Tables (as
+indicated by the letter in the first column and the notation in the
+second column of the table above):
+
N:
The object's source is an ACPI namespace node (as indicated by the
named object's type in the second column). In that case the object's
@@ -249,13 +254,14 @@ Wysocki <rafael.j.wysocki@intel.com>.
struct acpi_device object with LNXVIDEO 'bus_id' will be created for
it.
- The third column of the above table indicates which ACPI System
- Description Tables contain information used for the creation of the
- struct acpi_device objects represented by the given row (xSDT means DSDT
- or SSDT).
+The third column of the above table indicates which ACPI System
+Description Tables contain information used for the creation of the
+struct acpi_device objects represented by the given row (xSDT means DSDT
+or SSDT).
+
+The forth column of the above table indicates the 'bus_id' generation
+rule of the struct acpi_device object:
- The forth column of the above table indicates the 'bus_id' generation
- rule of the struct acpi_device object:
_HID:
_HID in the last column of the table means that the object's bus_id
is derived from the _HID/_CID identification objects present under
@@ -275,45 +281,47 @@ Wysocki <rafael.j.wysocki@intel.com>.
object's bus_id.
-4. Linux ACPI Physical Device Glue
-
- ACPI device (i.e. struct acpi_device) objects may be linked to other
- objects in the Linux' device hierarchy that represent "physical" devices
- (for example, devices on the PCI bus). If that happens, it means that
- the ACPI device object is a "companion" of a device otherwise
- represented in a different way and is used (1) to provide configuration
- information on that device which cannot be obtained by other means and
- (2) to do specific things to the device with the help of its ACPI
- control methods. One ACPI device object may be linked this way to
- multiple "physical" devices.
-
- If an ACPI device object is linked to a "physical" device, its sysfs
- directory contains the "physical_node" symbolic link to the sysfs
- directory of the target device object. In turn, the target device's
- sysfs directory will then contain the "firmware_node" symbolic link to
- the sysfs directory of the companion ACPI device object.
- The linking mechanism relies on device identification provided by the
- ACPI namespace. For example, if there's an ACPI namespace object
- representing a PCI device (i.e. a device object under an ACPI namespace
- object representing a PCI bridge) whose _ADR returns 0x00020000 and the
- bus number of the parent PCI bridge is 0, the sysfs directory
- representing the struct acpi_device object created for that ACPI
- namespace object will contain the 'physical_node' symbolic link to the
- /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
- corresponding PCI device.
-
- The linking mechanism is generally bus-specific. The core of its
- implementation is located in the drivers/acpi/glue.c file, but there are
- complementary parts depending on the bus types in question located
- elsewhere. For example, the PCI-specific part of it is located in
- drivers/pci/pci-acpi.c.
-
-
-5. Example Linux ACPI Device Tree
-
- The sysfs hierarchy of struct acpi_device objects corresponding to the
- example ACPI namespace illustrated in Figure 2 with the addition of
- fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
+Linux ACPI Physical Device Glue
+===============================
+
+ACPI device (i.e. struct acpi_device) objects may be linked to other
+objects in the Linux' device hierarchy that represent "physical" devices
+(for example, devices on the PCI bus). If that happens, it means that
+the ACPI device object is a "companion" of a device otherwise
+represented in a different way and is used (1) to provide configuration
+information on that device which cannot be obtained by other means and
+(2) to do specific things to the device with the help of its ACPI
+control methods. One ACPI device object may be linked this way to
+multiple "physical" devices.
+
+If an ACPI device object is linked to a "physical" device, its sysfs
+directory contains the "physical_node" symbolic link to the sysfs
+directory of the target device object. In turn, the target device's
+sysfs directory will then contain the "firmware_node" symbolic link to
+the sysfs directory of the companion ACPI device object.
+The linking mechanism relies on device identification provided by the
+ACPI namespace. For example, if there's an ACPI namespace object
+representing a PCI device (i.e. a device object under an ACPI namespace
+object representing a PCI bridge) whose _ADR returns 0x00020000 and the
+bus number of the parent PCI bridge is 0, the sysfs directory
+representing the struct acpi_device object created for that ACPI
+namespace object will contain the 'physical_node' symbolic link to the
+/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
+corresponding PCI device.
+
+The linking mechanism is generally bus-specific. The core of its
+implementation is located in the drivers/acpi/glue.c file, but there are
+complementary parts depending on the bus types in question located
+elsewhere. For example, the PCI-specific part of it is located in
+drivers/pci/pci-acpi.c.
+
+
+Example Linux ACPI Device Tree
+=================================
+
+The sysfs hierarchy of struct acpi_device objects corresponding to the
+example ACPI namespace illustrated in Figure 2 with the addition of
+fixed PWR_BUTTON/SLP_BUTTON devices is shown below::
+--------------+---+-----------------+
| LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
@@ -377,12 +385,14 @@ Wysocki <rafael.j.wysocki@intel.com>.
Figure 3. Example Linux ACPI Device Tree
- NOTE: Each node is represented as "object/path/modalias", where:
- 1. 'object' is the name of the object's directory in sysfs.
- 2. 'path' is the ACPI namespace path of the corresponding
- ACPI namespace object, as returned by the object's 'path'
- sysfs attribute.
- 3. 'modalias' is the value of the object's 'modalias' sysfs
- attribute (as described earlier in this document).
- NOTE: N/A indicates the device object does not have the 'path' or the
- 'modalias' attribute.
+.. note:: Each node is represented as "object/path/modalias", where:
+
+ 1. 'object' is the name of the object's directory in sysfs.
+ 2. 'path' is the ACPI namespace path of the corresponding
+ ACPI namespace object, as returned by the object's 'path'
+ sysfs attribute.
+ 3. 'modalias' is the value of the object's 'modalias' sysfs
+ attribute (as described earlier in this document).
+
+.. note:: N/A indicates the device object does not have the 'path' or the
+ 'modalias' attribute.
--
2.20.1
^ permalink raw reply related
* [PATCH v4 03/63] Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST
From: Changbin Du @ 2019-04-23 16:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: fenghua.yu, mchehab+samsung, linux-doc, linux-pci, linux-gpio,
x86, rjw, linux-kernel, linux-acpi, mingo, Bjorn Helgaas, tglx,
linuxppc-dev, Changbin Du
In-Reply-To: <20190423162932.21428-1-changbin.du@gmail.com>
This converts the plain text documentation to reStructuredText format and
add it to Sphinx TOC tree. No essential content change.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
---
.../acpi/enumeration.rst} | 135 ++++++++++--------
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 74 insertions(+), 62 deletions(-)
rename Documentation/{acpi/enumeration.txt => firmware-guide/acpi/enumeration.rst} (87%)
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/firmware-guide/acpi/enumeration.rst
similarity index 87%
rename from Documentation/acpi/enumeration.txt
rename to Documentation/firmware-guide/acpi/enumeration.rst
index 7bcf9c3d9fbe..ce755e963714 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/firmware-guide/acpi/enumeration.rst
@@ -1,5 +1,9 @@
-ACPI based device enumeration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================
+ACPI Based Device Enumeration
+=============================
+
ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus,
SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave
devices behind serial bus controllers.
@@ -11,12 +15,12 @@ that are accessed through memory-mapped registers.
In order to support this and re-use the existing drivers as much as
possible we decided to do following:
- o Devices that have no bus connector resource are represented as
- platform devices.
+ - Devices that have no bus connector resource are represented as
+ platform devices.
- o Devices behind real busses where there is a connector resource
- are represented as struct spi_device or struct i2c_device
- (standard UARTs are not busses so there is no struct uart_device).
+ - Devices behind real busses where there is a connector resource
+ are represented as struct spi_device or struct i2c_device
+ (standard UARTs are not busses so there is no struct uart_device).
As both ACPI and Device Tree represent a tree of devices (and their
resources) this implementation follows the Device Tree way as much as
@@ -31,7 +35,8 @@ enumerated from ACPI namespace. This handle can be used to extract other
device-specific configuration. There is an example of this below.
Platform bus support
-~~~~~~~~~~~~~~~~~~~~
+====================
+
Since we are using platform devices to represent devices that are not
connected to any physical bus we only need to implement a platform driver
for the device and add supported ACPI IDs. If this same IP-block is used on
@@ -39,7 +44,7 @@ some other non-ACPI platform, the driver might work out of the box or needs
some minor changes.
Adding ACPI support for an existing driver should be pretty
-straightforward. Here is the simplest example:
+straightforward. Here is the simplest example::
#ifdef CONFIG_ACPI
static const struct acpi_device_id mydrv_acpi_match[] = {
@@ -61,12 +66,13 @@ configuring GPIOs it can get its ACPI handle and extract this information
from ACPI tables.
DMA support
-~~~~~~~~~~~
+===========
+
DMA controllers enumerated via ACPI should be registered in the system to
provide generic access to their resources. For example, a driver that would
like to be accessible to slave devices via generic API call
dma_request_slave_channel() must register itself at the end of the probe
-function like this:
+function like this::
err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
/* Handle the error if it's not a case of !CONFIG_ACPI */
@@ -74,7 +80,7 @@ function like this:
and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
is enough) which converts the FixedDMA resource provided by struct
acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
-could look like:
+could look like::
#ifdef CONFIG_ACPI
struct filter_args {
@@ -114,7 +120,7 @@ provided by struct acpi_dma.
Clients must call dma_request_slave_channel() with the string parameter that
corresponds to a specific FixedDMA resource. By default "tx" means the first
entry of the FixedDMA resource array, "rx" means the second entry. The table
-below shows a layout:
+below shows a layout::
Device (I2C0)
{
@@ -138,12 +144,13 @@ acpi_dma_request_slave_chan_by_index() directly and therefore choose the
specific FixedDMA resource by its index.
SPI serial bus support
-~~~~~~~~~~~~~~~~~~~~~~
+======================
+
Slave devices behind SPI bus have SpiSerialBus resource attached to them.
This is extracted automatically by the SPI core and the slave devices are
enumerated once spi_register_master() is called by the bus driver.
-Here is what the ACPI namespace for a SPI slave might look like:
+Here is what the ACPI namespace for a SPI slave might look like::
Device (EEP0)
{
@@ -163,7 +170,7 @@ Here is what the ACPI namespace for a SPI slave might look like:
The SPI device drivers only need to add ACPI IDs in a similar way than with
the platform device drivers. Below is an example where we add ACPI support
-to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
+to at25 SPI eeprom driver (this is meant for the above ACPI snippet)::
#ifdef CONFIG_ACPI
static const struct acpi_device_id at25_acpi_match[] = {
@@ -182,7 +189,7 @@ to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
Note that this driver actually needs more information like page size of the
eeprom etc. but at the time writing this there is no standard way of
-passing those. One idea is to return this in _DSM method like:
+passing those. One idea is to return this in _DSM method like::
Device (EEP0)
{
@@ -202,7 +209,7 @@ passing those. One idea is to return this in _DSM method like:
}
Then the at25 SPI driver can get this configuration by calling _DSM on its
-ACPI handle like:
+ACPI handle like::
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
@@ -220,14 +227,15 @@ ACPI handle like:
kfree(output.pointer);
I2C serial bus support
-~~~~~~~~~~~~~~~~~~~~~~
+======================
+
The slaves behind I2C bus controller only need to add the ACPI IDs like
with the platform and SPI drivers. The I2C core automatically enumerates
any slave devices behind the controller device once the adapter is
registered.
Below is an example of how to add ACPI support to the existing mpu3050
-input driver:
+input driver::
#ifdef CONFIG_ACPI
static const struct acpi_device_id mpu3050_acpi_match[] = {
@@ -251,56 +259,57 @@ input driver:
};
GPIO support
-~~~~~~~~~~~~
+============
+
ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
and GpioInt. These resources can be used to pass GPIO numbers used by
the device to the driver. ACPI 5.1 extended this with _DSD (Device
Specific Data) which made it possible to name the GPIOs among other things.
-For example:
+For example::
-Device (DEV)
-{
- Method (_CRS, 0, NotSerialized)
+ Device (DEV)
{
- Name (SBUF, ResourceTemplate()
+ Method (_CRS, 0, NotSerialized)
{
- ...
- // Used to power on/off the device
- GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
- IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
- 0x00, ResourceConsumer,,)
+ Name (SBUF, ResourceTemplate()
{
- // Pin List
- 0x0055
- }
+ ...
+ // Used to power on/off the device
+ GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
+ IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
+ 0x00, ResourceConsumer,,)
+ {
+ // Pin List
+ 0x0055
+ }
+
+ // Interrupt for the device
+ GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
+ 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
+ {
+ // Pin list
+ 0x0058
+ }
+
+ ...
- // Interrupt for the device
- GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
- 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
- {
- // Pin list
- 0x0058
}
- ...
-
+ Return (SBUF)
}
- Return (SBUF)
- }
-
- // ACPI 5.1 _DSD used for naming the GPIOs
- Name (_DSD, Package ()
- {
- ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
- Package ()
+ // ACPI 5.1 _DSD used for naming the GPIOs
+ Name (_DSD, Package ()
{
- Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
- Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
- }
- })
- ...
+ ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+ Package ()
+ {
+ Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
+ Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
+ }
+ })
+ ...
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
@@ -310,7 +319,7 @@ There is a standard GPIO API for that and is documented in
Documentation/gpio/.
In the above example we can get the corresponding two GPIO descriptors with
-a code like this:
+a code like this::
#include <linux/gpio/consumer.h>
...
@@ -334,21 +343,22 @@ See Documentation/acpi/gpio-properties.txt for more information about the
_DSD binding related to GPIOs.
MFD devices
-~~~~~~~~~~~
+===========
+
The MFD devices register their children as platform devices. For the child
devices there needs to be an ACPI handle that they can use to reference
parts of the ACPI namespace that relate to them. In the Linux MFD subsystem
we provide two ways:
- o The children share the parent ACPI handle.
- o The MFD cell can specify the ACPI id of the device.
+ - The children share the parent ACPI handle.
+ - The MFD cell can specify the ACPI id of the device.
For the first case, the MFD drivers do not need to do anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
If the ACPI namespace has a device that we can match using an ACPI id or ACPI
-adr, the cell should be set like:
+adr, the cell should be set like::
static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
.pnpid = "XYZ0001",
@@ -366,7 +376,8 @@ the MFD device and if found, that ACPI companion device is bound to the
resulting child platform device.
Device Tree namespace link device ID
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+====================================
+
The Device Tree protocol uses device identification based on the "compatible"
property whose value is a string or an array of strings recognized as device
identifiers by drivers and the driver core. The set of all those strings may be
@@ -423,4 +434,4 @@ the _DSD of the device object itself or the _DSD of its ancestor in the
Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible"
property returned by it is meaningless.
-Refer to DSD-properties-rules.txt for more information.
+Refer to :doc:`DSD-properties-rules` for more information.
diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst
index 210ad8acd6df..99677c73f1fb 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -8,3 +8,4 @@ ACPI Support
:maxdepth: 1
namespace
+ enumeration
--
2.20.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