BUG: crash in __tlb_remove_page_size with STRICT_KERNEL_RWX on BOOK3S_32
Hi! Commit 63b2bc61956 aka "powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX" caused my old powerbook to crash under I/O. After "dd if=/dev/hda of=/null" the crash happens in seconds. Reverting the commit helps, as well as disabling STRICT_KERNEL_RWX. Unfortunately, I was unable to capture the oops via the usb serial console, as it stuck right after the first "BUG: Unable to handle kernel data access at 0xe0c29000" message. Oops screenshot: http://aargh.no-ip.org/oops.jpg
Re: [alsa-devel] [PATCH] ASoC: fsl_sai: Add missing return 0 in remove()
On Fri, Apr 26, 2019 at 6:22 AM Nicolin Chen wrote:
>
> Build warning being reported:
> sound/soc/fsl/fsl_sai.c: In function 'fsl_sai_remove':
> sound/soc/fsl/fsl_sai.c:921:1: warning: no return statement in
> function returning non-void [-Wreturn-type]
>
> So this patch just adds a "return 0" to fix it.
>
> Fixes: 812ad463e089 ("ASoC: fsl_sai: Add support for runtime pm")
> Reported-by: Stephen Rothwell
> Signed-off-by: Nicolin Chen
Reviewed-by: Daniel Baluta
Thanks Nicolin!
> ---
> sound/soc/fsl/fsl_sai.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index 26c27dc..8593269 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -918,6 +918,8 @@ static int fsl_sai_probe(struct platform_device *pdev)
> static int fsl_sai_remove(struct platform_device *pdev)
> {
> pm_runtime_disable(>dev);
> +
> + return 0;
> }
>
> static const struct of_device_id fsl_sai_ids[] = {
> --
> 2.7.4
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Re: [PATCH v3 5/6] powerpc/mm: Reduce memory usage for mm_context_t for radix
Christophe Leroy writes: > Le 17/04/2019 à 15:03, Aneesh Kumar K.V a écrit : >> Currently, our mm_context_t on book3s64 include all hash specific >> context details like slice mask and subpage protection details. We >> can skip allocating these with radix translation. This will help us to save >> 8K per mm_context with radix translation. >> >> With the patch applied we have >> >> sizeof(mm_context_t) = 136 >> sizeof(struct hash_mm_context) = 8288 >> >> Signed-off-by: Aneesh Kumar K.V >> --- >> arch/powerpc/include/asm/book3s/64/mmu-hash.h | 33 - >> arch/powerpc/include/asm/book3s/64/mmu.h | 49 +-- >> arch/powerpc/kernel/setup-common.c| 6 +++ >> arch/powerpc/mm/hash_utils_64.c | 4 +- >> arch/powerpc/mm/mmu_context_book3s64.c| 16 +- >> 5 files changed, 68 insertions(+), 40 deletions(-) >> > > [...] > >> diff --git a/arch/powerpc/kernel/setup-common.c >> b/arch/powerpc/kernel/setup-common.c >> index a07de8608484..21b1ce200b22 100644 >> --- a/arch/powerpc/kernel/setup-common.c >> +++ b/arch/powerpc/kernel/setup-common.c >> @@ -947,6 +947,12 @@ void __init setup_arch(char **cmdline_p) >> init_mm.end_data = (unsigned long) _edata; >> init_mm.brk = klimit; >> >> +#ifdef CONFIG_PPC_MM_SLICES >> +#if defined(CONFIG_PPC_8xx) >> +init_mm.context.slb_addr_limit = DEFAULT_MAP_WINDOW; >> +#endif >> +#endif >> + > > In the previous patch, you moved the above into early_init_mmu(). Why > bringing it back here ? > Rebase error. I see that you have sent a series to handle this. Thanks -aneesh
Re: [PATCH v2 3/5] kernel/cpu: Allow non-zero CPU to be primary for suspend / kexec freeze
Peter Zijlstra's on April 25, 2019 10:02 pm: > On Thu, Apr 11, 2019 at 01:34:46PM +1000, Nicholas Piggin wrote: >> This patch provides an arch option, ARCH_SUSPEND_NONZERO_CPU, to >> opt-in to allowing suspend to occur on one of the housekeeping CPUs >> rather than hardcoded CPU0. >> >> This will allow CPU0 to be a nohz_full CPU with a later change. >> >> It may be possible for platforms with hardware/firmware restrictions >> on suspend/wake effectively support this by handing off the final >> stage to CPU0 when kernel housekeeping is no longer required. Another >> option is to make housekeeping / nohz_full mask dynamic at runtime, >> but the complexity could not be justified at this time. > > Should we not tie this into whatever already allows an achitecture to > hotplug CPU-0? For instance, x86 default disallows this but has > cpu0_hotpluggable to allow this. I didn't know about that option, but I see it still has the suspend / hibernate restriction though, which is what this patch is breaking from. If we are to prevent suspend completely at boot time, then it's no problem to run cpu0 with nohz_full, but TPTB decided that's a bad thing. But I have no problem with an arch adding another boot time option or hook into cpu0_hotpluggable that allows you to force nohz_full. > Presumably POWER already allows hotplugging CPU-0 ? Yeah it does. Suspend in pseries is actually really just used for some proprietary hypervisor partition migration scheme where you suspend, image gets saved, then resume it somewhere else. So that's easy, it's just a hypercall that appears to return exactly as it was called. No restriction on CPU number. Thanks, Nick
Re: powerpc hugepage leak caused by 576ed913 "block: use bio_add_page in bio_iov_iter_get_pages"
On Fri, Apr 26, 2019 at 11:05:17AM +1000, David Gibson wrote: > On Thu, Apr 25, 2019 at 08:19:58AM +0200, Christoph Hellwig wrote: > > Just curious: What exact trees do you see this with? This area > > changed a lot with the multipage bvec support, and subsequent fixes. > > So, I tried it with 576ed913 itself and with 576ed913^ to verify that > it didn't happen there. The problem also occurred with Linus' tree as > of when I started bisecting, which appears to have been 444fe991. > Actually, come to that, here's the whole bisect log in case it's > helpful: > > # git bisect log > git bisect start > # good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14 > git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4 > # bad: [444fe991353987c1c9bc5ab1f903d01f1b4ad415] Merge tag > 'riscv-for-linus-5.1-rc6' of > git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux > git bisect bad 444fe991353987c1c9bc5ab1f903d01f1b4ad415 > # good: [399c4129eba6145924ab90363352b7bdcd554751] Merge tag > 'pxa-for-4.19-dma_slave_map' of https://github.com/rjarzmik/linux > git bisect good 399c4129eba6145924ab90363352b7bdcd554751 > # bad: [73b6f96cbc0162787bcbdac5f538167084c8d605] Merge branch > 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes > git bisect bad 73b6f96cbc0162787bcbdac5f538167084c8d605 > # good: [85a585918fb4122ad26b6febaec5c3c90bf2535c] Merge tag > 'loadpin-security-next' of > https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next-loadpin > git bisect good 85a585918fb4122ad26b6febaec5c3c90bf2535c > # bad: [3acbd2de6bc3af215c6ed7732dfc097d1e238503] Merge tag 'sound-4.20-rc1' > of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound > git bisect bad 3acbd2de6bc3af215c6ed7732dfc097d1e238503 > # good: [8f18da47211554f1ef674fef627c05f23b75a8e0] Merge branch 'master' of > git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next > git bisect good 8f18da47211554f1ef674fef627c05f23b75a8e0 > # bad: [0d1b82cd8ac2e8856ae9045c97782ac1c359929c] Merge branch > 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad 0d1b82cd8ac2e8856ae9045c97782ac1c359929c > # bad: [1650ac53066577a5e83fe3e9d992c9311597ff8c] Merge tag 'mmc-v4.20' of > git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc > git bisect bad 1650ac53066577a5e83fe3e9d992c9311597ff8c > # bad: [6ab9e09238fdfd742fe23b81e2d385a1cab49d9b] Merge tag > 'for-4.20/block-20181021' of git://git.kernel.dk/linux-block > git bisect bad 6ab9e09238fdfd742fe23b81e2d385a1cab49d9b > # good: [528985117126f11beea339cf39120ee99da04cd2] Merge tag 'arm64-upstream' > of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux > git bisect good 528985117126f11beea339cf39120ee99da04cd2 > # bad: [2cf99bbd106f89fc72f778e8ad9d5538f1ef939b] lightnvm: pblk: add helpers > for chunk addresses > git bisect bad 2cf99bbd106f89fc72f778e8ad9d5538f1ef939b > # bad: [33b14f67a4e1eabd219fd6543da8f15ed86b641c] nvme: register ns_id > attributes as default sysfs groups > git bisect bad 33b14f67a4e1eabd219fd6543da8f15ed86b641c > # bad: [27ca1d4ed04ea29dc77b47190a3cc82697023e76] block: move > req_gap_back_merge to blk.h > git bisect bad 27ca1d4ed04ea29dc77b47190a3cc82697023e76 > # bad: [07b05bcc3213ac9f8c28c9d835b4bf3d5798cc60] blkcg: convert > blkg_lookup_create to find closest blkg > git bisect bad 07b05bcc3213ac9f8c28c9d835b4bf3d5798cc60 > # good: [cbeb869a3d1110450186b738199963c5e68c2a71] block, bfq: correctly > charge and reset entity service in all cases > git bisect good cbeb869a3d1110450186b738199963c5e68c2a71 > # bad: [576ed9135489c723fb39b97c4e2c73428d06dd78] block: use bio_add_page in > bio_iov_iter_get_pages > git bisect bad 576ed9135489c723fb39b97c4e2c73428d06dd78 > # good: [c8765de0adfcaaf4ffb2d951e07444f00ffa9453] blok, bfq: do not plug I/O > if all queues are weight-raised > git bisect good c8765de0adfcaaf4ffb2d951e07444f00ffa9453 > # first bad commit: [576ed9135489c723fb39b97c4e2c73428d06dd78] block: use > bio_add_page in bio_iov_iter_get_pages > > The problem also occurred with the RHEL8 downstream kernel tree. > That's based on 4.18, but has 576ed913 backported. > > > So I'd be really curious if it can be reproduced with Jens' latest > > block for-5.2 tree (which should be in latest linux-next). > > I'll see if I can try that when I next get access to the machine. Ok, I've now had a chance to test the next-20190423 tree. I can still reproduce the problem: in fact it is substantially worse, and somewhat more consistent. Previously I usually lost 2-3 hugepages per run, though I'd occasionally seen other values between 0 and 8. With the next tree, I lost 46 hugepages on most runs, though I also saw 45 and 48 occasionally. Hope this is illuminating. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_!
[PATCH] ASoC: fsl_sai: Add missing return 0 in remove()
Build warning being reported:
sound/soc/fsl/fsl_sai.c: In function 'fsl_sai_remove':
sound/soc/fsl/fsl_sai.c:921:1: warning: no return statement in
function returning non-void [-Wreturn-type]
So this patch just adds a "return 0" to fix it.
Fixes: 812ad463e089 ("ASoC: fsl_sai: Add support for runtime pm")
Reported-by: Stephen Rothwell
Signed-off-by: Nicolin Chen
---
sound/soc/fsl/fsl_sai.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 26c27dc..8593269 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -918,6 +918,8 @@ static int fsl_sai_probe(struct platform_device *pdev)
static int fsl_sai_remove(struct platform_device *pdev)
{
pm_runtime_disable(>dev);
+
+ return 0;
}
static const struct of_device_id fsl_sai_ids[] = {
--
2.7.4
Re: powerpc hugepage leak caused by 576ed913 "block: use bio_add_page in bio_iov_iter_get_pages"
On Thu, Apr 25, 2019 at 08:19:58AM +0200, Christoph Hellwig wrote: > Just curious: What exact trees do you see this with? This area > changed a lot with the multipage bvec support, and subsequent fixes. So, I tried it with 576ed913 itself and with 576ed913^ to verify that it didn't happen there. The problem also occurred with Linus' tree as of when I started bisecting, which appears to have been 444fe991. Actually, come to that, here's the whole bisect log in case it's helpful: # git bisect log git bisect start # good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14 git bisect good bebc6082da0a9f5d47a1ea2edc099bf671058bd4 # bad: [444fe991353987c1c9bc5ab1f903d01f1b4ad415] Merge tag 'riscv-for-linus-5.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux git bisect bad 444fe991353987c1c9bc5ab1f903d01f1b4ad415 # good: [399c4129eba6145924ab90363352b7bdcd554751] Merge tag 'pxa-for-4.19-dma_slave_map' of https://github.com/rjarzmik/linux git bisect good 399c4129eba6145924ab90363352b7bdcd554751 # bad: [73b6f96cbc0162787bcbdac5f538167084c8d605] Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes git bisect bad 73b6f96cbc0162787bcbdac5f538167084c8d605 # good: [85a585918fb4122ad26b6febaec5c3c90bf2535c] Merge tag 'loadpin-security-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into next-loadpin git bisect good 85a585918fb4122ad26b6febaec5c3c90bf2535c # bad: [3acbd2de6bc3af215c6ed7732dfc097d1e238503] Merge tag 'sound-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 3acbd2de6bc3af215c6ed7732dfc097d1e238503 # good: [8f18da47211554f1ef674fef627c05f23b75a8e0] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next git bisect good 8f18da47211554f1ef674fef627c05f23b75a8e0 # bad: [0d1b82cd8ac2e8856ae9045c97782ac1c359929c] Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad 0d1b82cd8ac2e8856ae9045c97782ac1c359929c # bad: [1650ac53066577a5e83fe3e9d992c9311597ff8c] Merge tag 'mmc-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc git bisect bad 1650ac53066577a5e83fe3e9d992c9311597ff8c # bad: [6ab9e09238fdfd742fe23b81e2d385a1cab49d9b] Merge tag 'for-4.20/block-20181021' of git://git.kernel.dk/linux-block git bisect bad 6ab9e09238fdfd742fe23b81e2d385a1cab49d9b # good: [528985117126f11beea339cf39120ee99da04cd2] Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux git bisect good 528985117126f11beea339cf39120ee99da04cd2 # bad: [2cf99bbd106f89fc72f778e8ad9d5538f1ef939b] lightnvm: pblk: add helpers for chunk addresses git bisect bad 2cf99bbd106f89fc72f778e8ad9d5538f1ef939b # bad: [33b14f67a4e1eabd219fd6543da8f15ed86b641c] nvme: register ns_id attributes as default sysfs groups git bisect bad 33b14f67a4e1eabd219fd6543da8f15ed86b641c # bad: [27ca1d4ed04ea29dc77b47190a3cc82697023e76] block: move req_gap_back_merge to blk.h git bisect bad 27ca1d4ed04ea29dc77b47190a3cc82697023e76 # bad: [07b05bcc3213ac9f8c28c9d835b4bf3d5798cc60] blkcg: convert blkg_lookup_create to find closest blkg git bisect bad 07b05bcc3213ac9f8c28c9d835b4bf3d5798cc60 # good: [cbeb869a3d1110450186b738199963c5e68c2a71] block, bfq: correctly charge and reset entity service in all cases git bisect good cbeb869a3d1110450186b738199963c5e68c2a71 # bad: [576ed9135489c723fb39b97c4e2c73428d06dd78] block: use bio_add_page in bio_iov_iter_get_pages git bisect bad 576ed9135489c723fb39b97c4e2c73428d06dd78 # good: [c8765de0adfcaaf4ffb2d951e07444f00ffa9453] blok, bfq: do not plug I/O if all queues are weight-raised git bisect good c8765de0adfcaaf4ffb2d951e07444f00ffa9453 # first bad commit: [576ed9135489c723fb39b97c4e2c73428d06dd78] block: use bio_add_page in bio_iov_iter_get_pages The problem also occurred with the RHEL8 downstream kernel tree. That's based on 4.18, but has 576ed913 backported. > So I'd be really curious if it can be reproduced with Jens' latest > block for-5.2 tree (which should be in latest linux-next). I'll see if I can try that when I next get access to the machine. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On Thu, Apr 25, 2019 at 05:33:04PM -0700, Dan Williams wrote: > On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote: > > > > We also call vmf_insert_pfn_pmd() in dax_insert_pfn_mkwrite() -- does > > > > that need to change too? > > > > > > It wasn't clear to me that it was a problem. I think that one already > > > happens to be pmd-aligned. > > > > Why would it need to be? The address is taken from vmf->address and that's > > set up in __handle_mm_fault() like .address = address & PAGE_MASK. So I > > don't see anything forcing PMD alignment of the virtual address... > > True. So now I'm wondering if the masking should be done internal to > the routine. Given it's prefixed vmf_ it seems to imply the api is > prepared to take raw 'struct vm_fault' parameters. I think I'll go > that route unless someone sees a reason to require the caller to > handle this responsibility. The vmf_ prefix was originally used to indicate 'returns a vm_fault_t' instead of 'returns an errno'. That said, I like the interpretation you're coming up with here, and it makes me wonder if we shouldn't change vmf_insert_pfn_pmd() to take (vmf, pfn, write) as arguments instead of separate vma, address & pmd arguments.
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On Thu, Apr 25, 2019 at 12:32 AM Jan Kara wrote: > > On Wed 24-04-19 11:13:48, Dan Williams wrote: > > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote: > > > > > > On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote: > > > > I think unaligned addresses have always been passed to > > > > vmf_insert_pfn_pmd(), but nothing cared until this patch. I *think* > > > > the only change needed is the following, thoughts? > > > > > > > > diff --git a/fs/dax.c b/fs/dax.c > > > > index ca0671d55aa6..82aee9a87efa 100644 > > > > --- a/fs/dax.c > > > > +++ b/fs/dax.c > > > > @@ -1560,7 +1560,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct > > > > vm_fault *vmf, pfn_t *pfnp, > > > > } > > > > > > > > trace_dax_pmd_insert_mapping(inode, vmf, PMD_SIZE, pfn, > > > > entry); > > > > - result = vmf_insert_pfn_pmd(vma, vmf->address, > > > > vmf->pmd, pfn, > > > > + result = vmf_insert_pfn_pmd(vma, pmd_addr, vmf->pmd, > > > > pfn, > > > > write); > > > > > > We also call vmf_insert_pfn_pmd() in dax_insert_pfn_mkwrite() -- does > > > that need to change too? > > > > It wasn't clear to me that it was a problem. I think that one already > > happens to be pmd-aligned. > > Why would it need to be? The address is taken from vmf->address and that's > set up in __handle_mm_fault() like .address = address & PAGE_MASK. So I > don't see anything forcing PMD alignment of the virtual address... True. So now I'm wondering if the masking should be done internal to the routine. Given it's prefixed vmf_ it seems to imply the api is prepared to take raw 'struct vm_fault' parameters. I think I'll go that route unless someone sees a reason to require the caller to handle this responsibility.
Re: [PATCH v2] powerpc/pseries: Use correct event modifier in rtas_parse_epow_errlog()
On 04/23/2019 07:17 PM, Yue Haibing wrote:
> From: YueHaibing
>
> rtas_parse_epow_errlog() should pass 'modifier' to
> handle_system_shutdown, because event modifier only use
> bottom 4 bits.
>
> Fixes: 55fc0c561742 ("powerpc/pseries: Parse and handle EPOW interrupts")
> Signed-off-by: YueHaibing
> ---
Reviewed-by: Tyrel Datwyler
> v2: fix compile issue by 'event_modifier'-->'modifier'
> ---
> arch/powerpc/platforms/pseries/ras.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/ras.c
> b/arch/powerpc/platforms/pseries/ras.c
> index c97d153..744604d 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -285,7 +285,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log
> *log)
> break;
>
> case EPOW_SYSTEM_SHUTDOWN:
> - handle_system_shutdown(epow_log->event_modifier);
> + handle_system_shutdown(modifier);
> break;
>
> case EPOW_SYSTEM_HALT:
>
Re: [PATCH v10 14/18] drivers/clocksource: timer-fsl-ftm: use common header for FlexTimer #defines
On 02/04/2019 08:30, William Breathitt Gray wrote:
> From: Patrick Havelange
>
> Common #defines have been moved to "linux/fsl/ftm.h". Thus making use of
> this file.
> Also FTM_SC_CLK_SHIFT has been renamed to FTM_SC_CLK_MASK_SHIFT.
>
> Reviewed-by: Esben Haabendal
> Signed-off-by: Patrick Havelange
> Signed-off-by: William Breathitt Gray
Please, do pick my Acked-by from V2.
> ---
> drivers/clocksource/timer-fsl-ftm.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clocksource/timer-fsl-ftm.c
> b/drivers/clocksource/timer-fsl-ftm.c
> index 846d18daf893..e1c34b2f53a5 100644
> --- a/drivers/clocksource/timer-fsl-ftm.c
> +++ b/drivers/clocksource/timer-fsl-ftm.c
> @@ -19,20 +19,9 @@
> #include
> #include
> #include
> +#include
>
> -#define FTM_SC 0x00
> -#define FTM_SC_CLK_SHIFT 3
> -#define FTM_SC_CLK_MASK (0x3 << FTM_SC_CLK_SHIFT)
> -#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_SHIFT)
> -#define FTM_SC_PS_MASK 0x7
> -#define FTM_SC_TOIE BIT(6)
> -#define FTM_SC_TOF BIT(7)
> -
> -#define FTM_CNT 0x04
> -#define FTM_MOD 0x08
> -#define FTM_CNTIN0x4C
> -
> -#define FTM_PS_MAX 7
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_MASK_SHIFT)
>
> struct ftm_clock_device {
> void __iomem *clksrc_base;
>
--
Facebook |
Twitter |
[PATCH] KVM: PPC: Book3S HV: smb->smp comment fixup
I made the same typo when trying to grep for uses of smp_wmb and figured I might as well fix it. Signed-off-by: Palmer Dabbelt --- arch/powerpc/kvm/book3s_hv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index 06964350b97a..842ab9511b54 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -749,7 +749,7 @@ static bool kvmppc_doorbell_pending(struct kvm_vcpu *vcpu) /* * Ensure that the read of vcore->dpdes comes after the read * of vcpu->doorbell_request. This barrier matches the -* smb_wmb() in kvmppc_guest_entry_inject(). +* smp_wmb() in kvmppc_guest_entry_inject(). */ smp_rmb(); vc = vcpu->arch.vcore; -- 2.21.0
Re: [PATCH v10 00/18] Introduce the Counter subsystem
On Sun, Apr 07, 2019 at 03:25:50PM +0100, Jonathan Cameron wrote: > On Tue, 2 Apr 2019 15:30:35 +0900 > William Breathitt Gray wrote: > > > Changes in v10: > > - Fix minor typographical errors in documentation > > - Merge the FlexTimer Module Quadrature decoder counter driver patches > > > > This revision is functionally identical to the last; changes in this > > version were made to fix minor typos in the documentation files and also > > to pull in the new FTM quadrature decoder counter driver. > > > > The Generic Counter API has been and is still in a feature freeze until > > it is merged into the mainline. The following features will be > > investigated after the merge: interrupt support for counter devices, and > > a character device interface for low-latency applications. > > Hi William / al, > > So the question is how to move this forwards? I'm happy with how it turned > out and the existing drivers we had in IIO are a lot cleaner under > the counter subsystem (other than the backwards compatibility for those that > ever existed in IIO). For those not following closely the situation is: I've now sucked this into my staging-testing branch and if 0-day is fine with it, I'll merge it to staging-next in a day or so. This way you can build on it for any iio drivers that might be coming. I do have reservations about that one sysfs file that is multi-line, and I think it will come to bite you in the end over time, so I reserve the right to say "I told you so" when that happens... But, I don't have a better answer for it now, so don't really worry about it :) thanks, greg k-h
Applied "ASoC: fsl_sai: Update is_slave_mode with correct value" to the asoc tree
The patch ASoC: fsl_sai: Update is_slave_mode with correct value has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From ddb351145a967ee791a0fb0156852ec2fcb746ba Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Sun, 21 Apr 2019 19:39:08 + Subject: [PATCH] ASoC: fsl_sai: Update is_slave_mode with correct value is_slave_mode defaults to false because sai structure that contains it is kzalloc'ed. Anyhow, if we decide to set the following configuration SAI slave -> SAI master, is_slave_mode will remain set on true although SAI being master it should be set to false. Fix this by updating is_slave_mode for each call of fsl_sai_set_dai_fmt. Signed-off-by: Daniel Baluta Acked-by: Nicolin Chen Signed-off-by: Mark Brown --- sound/soc/fsl/fsl_sai.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index db9e0872f73d..7549b74e464e 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -268,12 +268,14 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai *cpu_dai, case SND_SOC_DAIFMT_CBS_CFS: val_cr2 |= FSL_SAI_CR2_BCD_MSTR; val_cr4 |= FSL_SAI_CR4_FSD_MSTR; + sai->is_slave_mode = false; break; case SND_SOC_DAIFMT_CBM_CFM: sai->is_slave_mode = true; break; case SND_SOC_DAIFMT_CBS_CFM: val_cr2 |= FSL_SAI_CR2_BCD_MSTR; + sai->is_slave_mode = false; break; case SND_SOC_DAIFMT_CBM_CFS: val_cr4 |= FSL_SAI_CR4_FSD_MSTR; -- 2.20.1
Applied "ASoC: fsl_sai: Update is_slave_mode with correct value" to the asoc tree
The patch ASoC: fsl_sai: Update is_slave_mode with correct value has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From ddb351145a967ee791a0fb0156852ec2fcb746ba Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Sun, 21 Apr 2019 19:39:08 + Subject: [PATCH] ASoC: fsl_sai: Update is_slave_mode with correct value is_slave_mode defaults to false because sai structure that contains it is kzalloc'ed. Anyhow, if we decide to set the following configuration SAI slave -> SAI master, is_slave_mode will remain set on true although SAI being master it should be set to false. Fix this by updating is_slave_mode for each call of fsl_sai_set_dai_fmt. Signed-off-by: Daniel Baluta Acked-by: Nicolin Chen Signed-off-by: Mark Brown --- sound/soc/fsl/fsl_sai.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c index db9e0872f73d..7549b74e464e 100644 --- a/sound/soc/fsl/fsl_sai.c +++ b/sound/soc/fsl/fsl_sai.c @@ -268,12 +268,14 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai *cpu_dai, case SND_SOC_DAIFMT_CBS_CFS: val_cr2 |= FSL_SAI_CR2_BCD_MSTR; val_cr4 |= FSL_SAI_CR4_FSD_MSTR; + sai->is_slave_mode = false; break; case SND_SOC_DAIFMT_CBM_CFM: sai->is_slave_mode = true; break; case SND_SOC_DAIFMT_CBS_CFM: val_cr2 |= FSL_SAI_CR2_BCD_MSTR; + sai->is_slave_mode = false; break; case SND_SOC_DAIFMT_CBM_CFS: val_cr4 |= FSL_SAI_CR4_FSD_MSTR; -- 2.20.1
Re: [PATCH v4 38/63] Documentation: x86: convert boot.txt to reST
On Wed, Apr 24, 2019 at 02:36:44PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 24 Apr 2019 00:29:07 +0800 > Changbin Du escreveu: > > > 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 > > --- > > Documentation/x86/boot.rst | 1205 +++ > > Documentation/x86/boot.txt | 1130 > > Documentation/x86/index.rst |2 + > > 3 files changed, 1207 insertions(+), 1130 deletions(-) > > create mode 100644 Documentation/x86/boot.rst > > delete mode 100644 Documentation/x86/boot.txt > > > > diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst > > new file mode 100644 > > index ..9f55e832bc47 > > --- /dev/null > > +++ b/Documentation/x86/boot.rst > > @@ -0,0 +1,1205 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +=== > > +The Linux/x86 Boot Protocol > > +=== > > + > > +On the x86 platform, the Linux kernel uses a rather complicated boot > > +convention. This has evolved partially due to historical aspects, as > > +well as the desire in the early days to have the kernel itself be a > > +bootable image, the complicated PC memory model and due to changed > > +expectations in the PC industry caused by the effective demise of > > +real-mode DOS as a mainstream operating system. > > + > > +Currently, the following versions of the Linux/x86 boot protocol exist. > > + > > +Old kernels: > > + zImage/Image support only. Some very early kernels > > + may not even support a command line. > > + > > +Protocol 2.00: > > + (Kernel 1.3.73) Added bzImage and initrd support, as > > + well as a formalized way to communicate between the > > + boot loader and the kernel. setup.S made relocatable, > > + although the traditional setup area still assumed writable. > > + > > +Protocol 2.01: > > + (Kernel 1.3.76) Added a heap overrun warning. > > + > > +Protocol 2.02: > > + (Kernel 2.4.0-test3-pre3) New command line protocol. > > + Lower the conventional memory ceiling. No overwrite > > + of the traditional setup area, thus making booting > > + safe for systems which use the EBDA from SMM or 32-bit > > + BIOS entry points. zImage deprecated but still supported. > > + > > +Protocol 2.03: > > + (Kernel 2.4.18-pre1) Explicitly makes the highest possible > > + initrd address available to the bootloader. > > + > > +Protocol 2.04: > > + (Kernel 2.6.14) Extend the syssize field to four bytes. > > + > > +Protocol 2.05: > > + (Kernel 2.6.20) Make protected mode kernel relocatable. > > + Introduce relocatable_kernel and kernel_alignment fields. > > + > > +Protocol 2.06: > > + (Kernel 2.6.22) Added a field that contains the size of > > + the boot command line. > > + > > +Protocol 2.07: > > + (Kernel 2.6.24) Added paravirtualised boot protocol. > > + Introduced hardware_subarch and hardware_subarch_data > > + and KEEP_SEGMENTS flag in load_flags. > > + > > +Protocol 2.08: > > + (Kernel 2.6.26) Added crc32 checksum and ELF format > > + payload. Introduced payload_offset and payload_length > > + fields to aid in locating the payload. > > + > > +Protocol 2.09: > > + (Kernel 2.6.26) Added a field of 64-bit physical > > + pointer to single linked list of struct setup_data. > > + > > +Protocol 2.10: > > + (Kernel 2.6.31) Added a protocol for relaxed alignment > > + beyond the kernel_alignment added, new init_size and > > + pref_address fields. Added extended boot loader IDs. > > + > > +Protocol 2.11: > > + (Kernel 3.6) Added a field for offset of EFI handover > > + protocol entry point. > > + > > +Protocol 2.12: > > + (Kernel 3.8) Added the xloadflags field and extension fields > > + to struct boot_params for loading bzImage and ramdisk > > + above 4G in 64bit. > > This is a side node, but you should really try to avoid replacing too > many lines, as it makes a lot harder for reviewers for no good reason. > > For example, this is the way I would convert this changelog table: > > > @@ -10,6 +11,7 @@ real-mode DOS as a mainstream operating system. > > Currently, the following versions of the Linux/x86 boot protocol exist. > > +=== > === > Old kernels: zImage/Image support only. Some very early kernels > may not even support a command line. > > @@ -64,33 +66,35 @@ Protocol 2.12: (Kernel 3.8) Added the xloadflags > field and extension fields > Protocol 2.13: (Kernel 3.14) Support 32- and 64-bit flags being set in > xloadflags to support booting a 64-bit kernel from 32-bit > EFI > +=== > === > > > This is simple enough, preserves the original author's intent and > makes a lot easier for reviewers to check what you changed. > much
Re: [PATCH v2 3/4] powerpc/boot: Add bzip2 support for uImage
On 04/25/2019 02:37 PM, Adam Borowski wrote: On Tue, Apr 23, 2019 at 02:20:43PM +, Christophe Leroy wrote: This patch allows to generate bzip2 compressed uImage Please don't add bzip2 support, that's a waste of your time as we're trying to remove it kernel-wide. There's a patchset to retire compressors beaten by alternatives on the whole speed-to-size curve; reposting it is overdue. It does: * add ZSTD (fast and strong) * remove BZIP2 (obsolete, only user in kernel) * remove LZMA (redundant with XZ, uses a private copy of its library) * makes Kconfig prose talk badly about LZO (used elsewhere in the kernel) I believe only three compressors are worth using here: XZ, ZSTD, LZ4. GZIP must stay because of ubiquitous support, the rest should go. Ok. Initially the purpose was to add lzma, then I took the opportunity to add all compressors supported by u-boot uImage files which are 'none, bzip2, gzip, lzma, lzo': [root@po16846vm linux-powerpc]# mkimage -C -h Invalid Compression Type - valid names are: none, bzip2, gzip, lzma, lzo Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image So I can leave bzip2 aside. xz, zstd and lz4 are not supported by the uImage format as far as I know so we have to keep lzma which gives a far better compression ratio than gzip (gzipped uImage don't fit in my board's NOR Flash while lzmaed uImage does). Christophe --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -199,6 +199,7 @@ config PPC + select HAVE_KERNEL_BZIP2if DEFAULT_UIMAGE --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -23,6 +23,7 @@ all: $(obj)/zImage +compress-$(CONFIG_KERNEL_BZIP2) := CONFIG_KERNEL_BZIP2 @@ -259,6 +260,7 @@ endif +compressor-$(CONFIG_KERNEL_BZIP2) := bz2 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -137,7 +137,7 @@ while [ "$#" -gt 0 ]; do -[ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "none" ] || usage +[ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "bz2" -o "$1" != "none" ] || usage @@ -149,6 +149,9 @@ while [ "$#" -gt 0 ]; do + if [ $uboot_comp = "bz2" ]; then + uboot_comp=bzip2 + fi @@ -377,6 +380,9 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel +.bz2) +bzip2 -f "$vmz.$$" + ;; Meow!
Re: [PATCH v4 25/63] Documentation: add Linux PCI to Sphinx TOC tree
On Wed, Apr 24, 2019 at 12:03:43PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 24 Apr 2019 00:28:54 +0800 > Changbin Du escreveu: > > > Add a index.rst for PCI subsystem. More docs will be added later. > > > > Signed-off-by: Changbin Du > > Acked-by: Bjorn Helgaas > > --- > > Documentation/PCI/index.rst | 9 + > > On a past discussion at docs ML, we've agreed to use lowercase for new > stuff. My suggestion here would be to use lowercase for "pci". > > Also, there's already a pci directory under driver-api, added on this > commit: > > commit fcc78f9c22474d60c65d522e50ea07006ec1b9fc > Author: Logan Gunthorpe > Date: Thu Oct 4 15:27:39 2018 -0600 > > docs-rst: Add a new directory for PCI documentation > > I would just add a new section at Documentation/driver-api/pci/index.rst > with something like: > > Legacy PCI documentation > > > .. note:: > > The files here were written a long time ago and need some serious > work. Use their contents with caution. > > .. toctree:: > :maxdepth: 1 > > > > And add those documents from Documentation/PCI into it. > Bjorn, Jonathan, Do you agree with this? By this all Documentation/PCI/* will be moved to Documentation/driver-api/pci. > > Thanks, > Mauro -- Cheers, Changbin Du
[PATCH v6 24/24] Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../acpi/video_extension.rst} | 85 +++
2 files changed, 52 insertions(+), 34 deletions(-)
rename Documentation/{acpi/video_extension.txt =>
firmware-guide/acpi/video_extension.rst} (68%)
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index 0e60f4b7129a..ae609eec4679 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -23,3 +23,4 @@ ACPI Support
i2c-muxes
acpi-lid
lpit
+ video_extension
diff --git a/Documentation/acpi/video_extension.txt
b/Documentation/firmware-guide/acpi/video_extension.rst
similarity index 68%
rename from Documentation/acpi/video_extension.txt
rename to Documentation/firmware-guide/acpi/video_extension.rst
index 79bf6a4921be..932fb47342a7 100644
--- a/Documentation/acpi/video_extension.txt
+++ b/Documentation/firmware-guide/acpi/video_extension.rst
@@ -1,5 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
ACPI video extensions
-~
+=
This driver implement the ACPI Extensions For Display Adapters for
integrated graphics devices on motherboard, as specified in ACPI 2.0
@@ -8,9 +11,12 @@ defining the video POST device, retrieving EDID information
or to
setup a video output, etc. Note that this is an ref. implementation
only. It may or may not work for your integrated video device.
-The ACPI video driver does 3 things regarding backlight control:
+The ACPI video driver exports the backlight control via a sysfs interface,
+notifies userspace with events and changes the backlight level via ACPI
+firmware, as detailed at the following chapters:
-1 Export a sysfs interface for user space to control backlight level
+Export a sysfs interface for user space to control backlight level
+==
If the ACPI table has a video device, and acpi_backlight=vendor kernel
command line is not present, the driver will register a backlight device
@@ -22,36 +28,41 @@ The backlight sysfs interface has a standard definition
here:
Documentation/ABI/stable/sysfs-class-backlight.
And what ACPI video driver does is:
-actual_brightness: on read, control method _BQC will be evaluated to
-get the brightness level the firmware thinks it is at;
-bl_power: not implemented, will set the current brightness instead;
-brightness: on write, control method _BCM will run to set the requested
-brightness level;
-max_brightness: Derived from the _BCL package(see below);
-type: firmware
+
+actual_brightness:
+ on read, control method _BQC will be evaluated to
+ get the brightness level the firmware thinks it is at;
+bl_power:
+ not implemented, will set the current brightness instead;
+brightness:
+ on write, control method _BCM will run to set the requested brightness level;
+max_brightness:
+ Derived from the _BCL package(see below);
+type:
+ firmware
Note that ACPI video backlight driver will always use index for
brightness, actual_brightness and max_brightness. So if we have
-the following _BCL package:
+the following _BCL package::
-Method (_BCL, 0, NotSerialized)
-{
- Return (Package (0x0C)
+ Method (_BCL, 0, NotSerialized)
{
- 0x64,
- 0x32,
- 0x0A,
- 0x14,
- 0x1E,
- 0x28,
- 0x32,
- 0x3C,
- 0x46,
- 0x50,
- 0x5A,
- 0x64
- })
-}
+ Return (Package (0x0C)
+ {
+ 0x64,
+ 0x32,
+ 0x0A,
+ 0x14,
+ 0x1E,
+ 0x28,
+ 0x32,
+ 0x3C,
+ 0x46,
+ 0x50,
+ 0x5A,
+ 0x64
+ })
+ }
The first two levels are for when laptop are on AC or on battery and are
not used by Linux currently. The remaining 10 levels are supported levels
@@ -62,13 +73,15 @@ as a "brightness level" indicator. Thus from the user space
perspective
the range of available brightness levels is from 0 to 9 (max_brightness)
inclusive.
-2 Notify user space about hotkey event
+Notify user space about hotkey event
+
There are generally two cases for hotkey event reporting:
+
i) For some laptops, when user presses the hotkey, a scancode will be
generated and sent to user space through the input device created by
the keyboard driver as a key type input event, with proper remap,
[PATCH v6 23/24] Documentation: ACPI: move ssdt-overlays.txt to admin-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/acpi/ssdt-overlays.txt | 172 -
Documentation/admin-guide/acpi/index.rst | 1 +
.../admin-guide/acpi/ssdt-overlays.rst| 180 ++
3 files changed, 181 insertions(+), 172 deletions(-)
delete mode 100644 Documentation/acpi/ssdt-overlays.txt
create mode 100644 Documentation/admin-guide/acpi/ssdt-overlays.rst
diff --git a/Documentation/acpi/ssdt-overlays.txt
b/Documentation/acpi/ssdt-overlays.txt
deleted file mode 100644
index 5ae13f161ea2..
--- a/Documentation/acpi/ssdt-overlays.txt
+++ /dev/null
@@ -1,172 +0,0 @@
-
-In order to support ACPI open-ended hardware configurations (e.g. development
-boards) we need a way to augment the ACPI configuration provided by the
firmware
-image. A common example is connecting sensors on I2C / SPI buses on development
-boards.
-
-Although this can be accomplished by creating a kernel platform driver or
-recompiling the firmware image with updated ACPI tables, neither is practical:
-the former proliferates board specific kernel code while the latter requires
-access to firmware tools which are often not publicly available.
-
-Because ACPI supports external references in AML code a more practical
-way to augment firmware ACPI configuration is by dynamically loading
-user defined SSDT tables that contain the board specific information.
-
-For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the
-Minnowboard MAX development board exposed via the LSE connector [1], the
-following ASL code can be used:
-
-DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x0003)
-{
-External (\_SB.I2C6, DeviceObj)
-
-Scope (\_SB.I2C6)
-{
-Device (STAC)
-{
-Name (_ADR, Zero)
-Name (_HID, "BMA222E")
-
-Method (_CRS, 0, Serialized)
-{
-Name (RBUF, ResourceTemplate ()
-{
-I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
- AddressingMode7Bit, "\\_SB.I2C6", 0x00,
- ResourceConsumer, ,)
-GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x,
- "\\_SB.GPO2", 0x00, ResourceConsumer, , )
-{ // Pin list
-0
-}
-})
-Return (RBUF)
-}
-}
-}
-}
-
-which can then be compiled to AML binary format:
-
-$ iasl minnowmax.asl
-
-Intel ACPI Component Architecture
-ASL Optimizing Compiler version 20140214-64 [Mar 29 2014]
-Copyright (c) 2000 - 2014 Intel Corporation
-
-ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords
-AML Output:minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes
-
-[1]
http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29
-
-The resulting AML code can then be loaded by the kernel using one of the
methods
-below.
-
-== Loading ACPI SSDTs from initrd ==
-
-This option allows loading of user defined SSDTs from initrd and it is useful
-when the system does not support EFI or when there is not enough EFI storage.
-
-It works in a similar way with initrd based ACPI tables override/upgrade: SSDT
-aml code must be placed in the first, uncompressed, initrd under the
-"kernel/firmware/acpi" path. Multiple files can be used and this will translate
-in loading multiple tables. Only SSDT and OEM tables are allowed. See
-initrd_table_override.txt for more details.
-
-Here is an example:
-
-# Add the raw ACPI tables to an uncompressed cpio archive.
-# They must be put into a /kernel/firmware/acpi directory inside the
-# cpio archive.
-# The uncompressed cpio archive must be the first.
-# Other, typically compressed cpio archives, must be
-# concatenated on top of the uncompressed one.
-mkdir -p kernel/firmware/acpi
-cp ssdt.aml kernel/firmware/acpi
-
-# Create the uncompressed cpio archive and concatenate the original initrd
-# on top:
-find kernel | cpio -H newc --create > /boot/instrumented_initrd
-cat /boot/initrd >>/boot/instrumented_initrd
-
-== Loading ACPI SSDTs from EFI variables ==
-
-This is the preferred method, when EFI is supported on the platform, because it
-allows a persistent, OS independent way of storing the user defined SSDTs.
There
-is also work underway to implement EFI support for loading user defined SSDTs
-and using this method will make it easier to convert to the EFI loading
-mechanism when that will arrive.
-
-In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line
-parameter can be used. The argument for the option is the variable name to
-use. If there are multiple variables with the same name but with different
-vendor
[PATCH v6 22/24] Documentation: ACPI: move lpit.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/firmware-guide/acpi/index.rst| 1 +
.../lpit.txt => firmware-guide/acpi/lpit.rst} | 18 +-
2 files changed, 14 insertions(+), 5 deletions(-)
rename Documentation/{acpi/lpit.txt => firmware-guide/acpi/lpit.rst} (68%)
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index fca854f017d8..0e60f4b7129a 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -22,3 +22,4 @@ ACPI Support
gpio-properties
i2c-muxes
acpi-lid
+ lpit
diff --git a/Documentation/acpi/lpit.txt
b/Documentation/firmware-guide/acpi/lpit.rst
similarity index 68%
rename from Documentation/acpi/lpit.txt
rename to Documentation/firmware-guide/acpi/lpit.rst
index b426398d2e97..aca928fab027 100644
--- a/Documentation/acpi/lpit.txt
+++ b/Documentation/firmware-guide/acpi/lpit.rst
@@ -1,3 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Low Power Idle Table (LPIT)
+===
+
To enumerate platform Low Power Idle states, Intel platforms are using
“Low Power Idle Table” (LPIT). More details about this table can be
downloaded from:
@@ -8,13 +14,15 @@ Residencies for each low power state can be read via FFH
On platforms supporting S0ix sleep states, there can be two types of
residencies:
-- CPU PKG C10 (Read via FFH interface)
-- Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface)
+
+ - CPU PKG C10 (Read via FFH interface)
+ - Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface)
The following attributes are added dynamically to the cpuidle
-sysfs attribute group:
- /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
- /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
+sysfs attribute group::
+
+ /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
+ /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
The "low_power_idle_cpu_residency_us" attribute shows time spent
by the CPU package in PKG C10
--
2.20.1
[PATCH v6 21/24] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
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
---
.../acpi/cppc_sysfs.rst} | 71 ++-
Documentation/admin-guide/acpi/index.rst | 1 +
2 files changed, 40 insertions(+), 32 deletions(-)
rename Documentation/{acpi/cppc_sysfs.txt => admin-guide/acpi/cppc_sysfs.rst}
(51%)
diff --git a/Documentation/acpi/cppc_sysfs.txt
b/Documentation/admin-guide/acpi/cppc_sysfs.rst
similarity index 51%
rename from Documentation/acpi/cppc_sysfs.txt
rename to Documentation/admin-guide/acpi/cppc_sysfs.rst
index f20fb445135d..a4b99afbe331 100644
--- a/Documentation/acpi/cppc_sysfs.txt
+++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst
@@ -1,5 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
- Collaborative Processor Performance Control (CPPC)
+==
+Collaborative Processor Performance Control (CPPC)
+==
+
+CPPC
+
CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
performance of a logical processor on a contigious and abstract performance
@@ -10,31 +16,28 @@ For more details on CPPC please refer to the ACPI
specification at:
http://uefi.org/specifications
-Some of the CPPC registers are exposed via sysfs under:
-
-/sys/devices/system/cpu/cpuX/acpi_cppc/
-
-for each cpu X
+Some of the CPPC registers are exposed via sysfs under::
-
+ /sys/devices/system/cpu/cpuX/acpi_cppc/
-$ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/
-/sys/devices/system/cpu/cpu0/acpi_cppc/:
-total 0
--r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs
--r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf
--r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq
--r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf
--r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf
--r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq
--r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf
--r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf
--r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time
+for each cpu X::
-
+ $ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/
+ /sys/devices/system/cpu/cpu0/acpi_cppc/:
+ total 0
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf
+ -r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time
* highest_perf : Highest performance of this processor (abstract scale).
-* nominal_perf : Highest sustained performance of this processor (abstract
scale).
+* nominal_perf : Highest sustained performance of this processor
+ (abstract scale).
* lowest_nonlinear_perf : Lowest performance of this processor with nonlinear
power savings (abstract scale).
* lowest_perf : Lowest performance of this processor (abstract scale).
@@ -48,22 +51,26 @@ total 0
* feedback_ctrs : Includes both Reference and delivered performance counter.
Reference counter ticks up proportional to processor's reference performance.
Delivered counter ticks up proportional to processor's delivered performance.
-* wraparound_time: Minimum time for the feedback counters to wraparound
(seconds).
+* wraparound_time: Minimum time for the feedback counters to wraparound
+ (seconds).
* reference_perf : Performance level at which reference performance counter
accumulates (abstract scale).
-
- Computing Average Delivered Performance
+Computing Average Delivered Performance
+===
+
+Below describes the steps to compute the average performance delivered by
+taking two different snapshots of feedback counters at time T1 and T2.
+
+ T1: Read feedback_ctrs as fbc_t1
+ Wait or run some workload
-Below describes the steps to compute the average performance delivered by
taking
-two different snapshots of feedback counters at time T1 and T2.
+ T2: Read feedback_ctrs as fbc_t2
-T1: Read feedback_ctrs as fbc_t1
-Wait or run some workload
-T2: Read feedback_ctrs as fbc_t2
+::
-delivered_counter_delta = fbc_t2[del] - fbc_t1[del]
-reference_counter_delta = fbc_t2[ref] - fbc_t1[ref]
+ delivered_counter_delta = fbc_t2[del] - fbc_t1[del]
+ reference_counter_delta = fbc_t2[ref] - fbc_t1[ref]
-delivered_perf = (refernce_perf x
[PATCH v6 20/24] Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/apei/einj.rst} | 94 ++-
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 52 insertions(+), 43 deletions(-)
rename Documentation/{acpi/apei/einj.txt => firmware-guide/acpi/apei/einj.rst}
(67%)
diff --git a/Documentation/acpi/apei/einj.txt
b/Documentation/firmware-guide/acpi/apei/einj.rst
similarity index 67%
rename from Documentation/acpi/apei/einj.txt
rename to Documentation/firmware-guide/acpi/apei/einj.rst
index e550c8b98139..e588bccf5158 100644
--- a/Documentation/acpi/apei/einj.txt
+++ b/Documentation/firmware-guide/acpi/apei/einj.rst
@@ -1,13 +1,16 @@
- APEI Error INJection
-
+.. SPDX-License-Identifier: GPL-2.0
+
+
+APEI Error INJection
+
EINJ provides a hardware error injection mechanism. It is very useful
for debugging and testing APEI and RAS features in general.
You need to check whether your BIOS supports EINJ first. For that, look
-for early boot messages similar to this one:
+for early boot messages similar to this one::
-ACPI: EINJ 0x7370A000 000150 (v01 INTEL 0001 INTL
0001)
+ ACPI: EINJ 0x7370A000 000150 (v01 INTEL 0001 INTL
0001)
which shows that the BIOS is exposing an EINJ table - it is the
mechanism through which the injection is done.
@@ -23,11 +26,11 @@ order to see the APEI,EINJ,... functionality supported and
exposed by
the BIOS menu.
To use EINJ, make sure the following are options enabled in your kernel
-configuration:
+configuration::
-CONFIG_DEBUG_FS
-CONFIG_ACPI_APEI
-CONFIG_ACPI_APEI_EINJ
+ CONFIG_DEBUG_FS
+ CONFIG_ACPI_APEI
+ CONFIG_ACPI_APEI_EINJ
The EINJ user interface is in /apei/einj.
@@ -37,20 +40,22 @@ The following files belong to it:
This file shows which error types are supported:
+ ===
Error Type Value Error Description
- =
- 0x0001 Processor Correctable
- 0x0002 Processor Uncorrectable non-fatal
- 0x0004 Processor Uncorrectable fatal
- 0x0008 Memory Correctable
- 0x0010 Memory Uncorrectable non-fatal
- 0x0020 Memory Uncorrectable fatal
- 0x0040 PCI Express Correctable
- 0x0080 PCI Express Uncorrectable fatal
- 0x0100 PCI Express Uncorrectable non-fatal
- 0x0200 Platform Correctable
- 0x0400 Platform Uncorrectable non-fatal
- 0x0800 Platform Uncorrectable fatal
+ ===
+ 0x0001Processor Correctable
+ 0x0002Processor Uncorrectable non-fatal
+ 0x0004Processor Uncorrectable fatal
+ 0x0008Memory Correctable
+ 0x0010Memory Uncorrectable non-fatal
+ 0x0020Memory Uncorrectable fatal
+ 0x0040PCI Express Correctable
+ 0x0080PCI Express Uncorrectable fatal
+ 0x0100PCI Express Uncorrectable non-fatal
+ 0x0200Platform Correctable
+ 0x0400Platform Uncorrectable non-fatal
+ 0x0800Platform Uncorrectable fatal
+ ===
The format of the file contents are as above, except present are only
the available error types.
@@ -73,9 +78,12 @@ The following files belong to it:
injection. Value is a bitmask as specified in ACPI5.0 spec for the
SET_ERROR_TYPE_WITH_ADDRESS data structure:
- Bit 0 - Processor APIC field valid (see param3 below).
- Bit 1 - Memory address and mask valid (param1 and param2).
- Bit 2 - PCIe (seg,bus,dev,fn) valid (see param4 below).
+Bit 0
+ Processor APIC field valid (see param3 below).
+Bit 1
+ Memory address and mask valid (param1 and param2).
+Bit 2
+ PCIe (seg,bus,dev,fn) valid (see param4 below).
If set to zero, legacy behavior is mimicked where the type of
injection specifies just one bit set, and param1 is multiplexed.
@@ -121,7 +129,7 @@ BIOS versions based on the ACPI 5.0 specification have more
control over
the target of the injection. For processor-related errors (type 0x1, 0x2
and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and
param2 for bit 1) so that you have more information added to the error
-signature being injected. The actual data passed is this:
+signature being injected. The actual data passed is this::
memory_address = param1;
memory_address_range = param2;
@@ -131,7 +139,7 @@ signature being injected. The actual data passed is this:
For memory errors
[PATCH v6 19/24] Documentation: ACPI: move apei/output_format.txt to firmware-guide/acpi and convert to reST
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 Reviewed-by: Mauro Carvalho Chehab --- Documentation/acpi/apei/output_format.txt | 147 - .../acpi/apei/output_format.rst | 150 ++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 151 insertions(+), 147 deletions(-) delete mode 100644 Documentation/acpi/apei/output_format.txt create mode 100644 Documentation/firmware-guide/acpi/apei/output_format.rst diff --git a/Documentation/acpi/apei/output_format.txt b/Documentation/acpi/apei/output_format.txt deleted file mode 100644 index 0c49c197c47a.. --- a/Documentation/acpi/apei/output_format.txt +++ /dev/null @@ -1,147 +0,0 @@ - APEI output format - ~~ - -APEI uses printk as hardware error reporting interface, the output -format is as follow. - - := -APEI generic hardware error status -severity: , -section: , severity: , -flags: - -fru_id: -fru_text: -section_type: - - -* := recoverable | fatal | corrected | info - -# := -[primary][, containment warning][, reset][, threshold exceeded]\ -[, resource not accessible][, latent error] - - := generic processor error | memory error | \ -PCIe error | unknown, - - := - | | \ - | - - := -[processor_type: , ] -[processor_isa: , ] -[error_type: -] -[operation: , ] -[flags: -] -[level: ] -[version_info: ] -[processor_id: ] -[target_address: ] -[requestor_id: ] -[responder_id: ] -[IP: ] - -* := IA32/X64 | IA64 - -* := IA32 | IA64 | X64 - -# := -[cache error][, TLB error][, bus error][, micro-architectural error] - -* := unknown or generic | data read | data write | \ -instruction execution - -# := -[restartable][, precise IP][, overflow][, corrected] - - := -[error_status: ] -[physical_address: ] -[physical_address_mask: ] -[node: ] -[card: ] -[module: ] -[bank: ] -[device: ] -[row: ] -[column: ] -[bit_position: ] -[requestor_id: ] -[responder_id: ] -[target_id: ] -[error_type: , ] - -* := -unknown | no error | single-bit ECC | multi-bit ECC | \ -single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ -target abort | parity error | watchdog timeout | invalid address | \ -mirror Broken | memory sparing | scrub corrected error | \ -scrub uncorrected error - - := -[port_type: , ] -[version: .] -[command: , status: ] -[device_id: ::. -slot: -secondary_bus: -vendor_id: , device_id: -class_code: ] -[serial number: , ] -[bridge: secondary_status: , control: ] -[aer_status: , aer_mask: - -[aer_uncor_severity: ] -aer_layer=, aer_agent= -aer_tlp_header:] - -* := PCIe end point | legacy PCI end point | \ -unknown | unknown | root port | upstream switch port | \ -downstream switch port | PCIe to PCI/PCI-X bridge | \ -PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ -root complex event collector - -if section severity is fatal or recoverable -# := -unknown | unknown | unknown | unknown | Data Link Protocol | \ -unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ -Poisoned TLP | Flow Control Protocol | Completion Timeout | \ -Completer Abort | Unexpected Completion | Receiver Overflow | \ -Malformed TLP | ECRC | Unsupported Request -else -# := -Receiver Error | unknown | unknown | unknown | unknown | unknown | \ -Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ -Replay Timer Timeout | Advisory Non-Fatal -fi - - := -Physical Layer | Data Link Layer | Transaction Layer - - := -Receiver ID | Requester ID | Completer ID | Transmitter ID - -Where, [] designate corresponding content is optional - -All description with * has the following format: - -field: , - -Where value of should be the position of "string" in description. Otherwise, will be "unknown". - -All description with # has the following format: - -field: - - -Where each string in corresponding to one set bit of -. The bit position is the position of "string" in description. - -For more detailed explanation of every field, please refer to UEFI -specification version 2.3 or later, section Appendix N: Common -Platform Error Record. diff --git a/Documentation/firmware-guide/acpi/apei/output_format.rst b/Documentation/firmware-guide/acpi/apei/output_format.rst new file mode 100644 index ..c2e7ebddb529 --- /dev/null +++ b/Documentation/firmware-guide/acpi/apei/output_format.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: GPL-2.0 + +== +APEI output format +== + +APEI uses printk as hardware error reporting interface, the output +format is as follow:: + + := +APEI generic hardware error status +severity: , +section: , severity: , +flags: + +fru_id: +fru_text: +section_type: + + +* := recoverable | fatal | corrected | info + +# := +
[PATCH v6 18/24] Documentation: ACPI: move aml-debugger.txt to firmware-guide/acpi and convert to reST
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 Reviewed-by: Mauro Carvalho Chehab --- Documentation/acpi/aml-debugger.txt | 66 .../firmware-guide/acpi/aml-debugger.rst | 75 +++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 76 insertions(+), 66 deletions(-) delete mode 100644 Documentation/acpi/aml-debugger.txt create mode 100644 Documentation/firmware-guide/acpi/aml-debugger.rst diff --git a/Documentation/acpi/aml-debugger.txt b/Documentation/acpi/aml-debugger.txt deleted file mode 100644 index 75ebeb64ab29.. --- a/Documentation/acpi/aml-debugger.txt +++ /dev/null @@ -1,66 +0,0 @@ -The AML Debugger - -Copyright (C) 2016, Intel Corporation -Author: Lv Zheng - - -This document describes the usage of the AML debugger embedded in the Linux -kernel. - -1. Build the debugger - - The following kernel configuration items are required to enable the AML - debugger interface from the Linux kernel: - - CONFIG_ACPI_DEBUGGER=y - CONFIG_ACPI_DEBUGGER_USER=m - - The userspace utilities can be built from the kernel source tree using - the following commands: - - $ cd tools - $ make acpi - - The resultant userspace tool binary is then located at: - - tools/power/acpi/acpidbg - - It can be installed to system directories by running "make install" (as a - sufficiently privileged user). - -2. Start the userspace debugger interface - - After booting the kernel with the debugger built-in, the debugger can be - started by using the following commands: - - # mount -t debugfs none /sys/kernel/debug - # modprobe acpi_dbg - # tools/power/acpi/acpidbg - - That spawns the interactive AML debugger environment where you can execute - debugger commands. - - The commands are documented in the "ACPICA Overview and Programmer Reference" - that can be downloaded from - - https://acpica.org/documentation - - The detailed debugger commands reference is located in Chapter 12 "ACPICA - Debugger Reference". The "help" command can be used for a quick reference. - -3. Stop the userspace debugger interface - - The interactive debugger interface can be closed by pressing Ctrl+C or using - the "quit" or "exit" commands. When finished, unload the module with: - - # rmmod acpi_dbg - - The module unloading may fail if there is an acpidbg instance running. - -4. Run the debugger in a script - - It may be useful to run the AML debugger in a test script. "acpidbg" supports - this in a special "batch" mode. For example, the following command outputs - the entire ACPI namespace: - - # acpidbg -b "namespace" diff --git a/Documentation/firmware-guide/acpi/aml-debugger.rst b/Documentation/firmware-guide/acpi/aml-debugger.rst new file mode 100644 index ..a889d43bc6c5 --- /dev/null +++ b/Documentation/firmware-guide/acpi/aml-debugger.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + + +The AML Debugger + + +:Copyright: |copy| 2016, Intel Corporation +:Author: Lv Zheng + + +This document describes the usage of the AML debugger embedded in the Linux +kernel. + +1. Build the debugger += + +The following kernel configuration items are required to enable the AML +debugger interface from the Linux kernel:: + + CONFIG_ACPI_DEBUGGER=y + CONFIG_ACPI_DEBUGGER_USER=m + +The userspace utilities can be built from the kernel source tree using +the following commands:: + + $ cd tools + $ make acpi + +The resultant userspace tool binary is then located at:: + + tools/power/acpi/acpidbg + +It can be installed to system directories by running "make install" (as a +sufficiently privileged user). + +2. Start the userspace debugger interface += + +After booting the kernel with the debugger built-in, the debugger can be +started by using the following commands:: + + # mount -t debugfs none /sys/kernel/debug + # modprobe acpi_dbg + # tools/power/acpi/acpidbg + +That spawns the interactive AML debugger environment where you can execute +debugger commands. + +The commands are documented in the "ACPICA Overview and Programmer Reference" +that can be downloaded from + +https://acpica.org/documentation + +The detailed debugger commands reference is located in Chapter 12 "ACPICA +Debugger Reference". The "help" command can be used for a quick reference. + +3. Stop the userspace debugger interface + + +The interactive debugger interface can be closed by pressing Ctrl+C or using +the "quit" or "exit" commands. When finished, unload the module with:: + + # rmmod acpi_dbg + +The module unloading may fail if there is an acpidbg instance running. + +4. Run the debugger in a script +=== + +It may be useful to run
[PATCH v6 17/24] Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi and convert to rsST
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 Reviewed-by: Mauro Carvalho Chehab --- Documentation/acpi/method-tracing.txt | 192 -- Documentation/firmware-guide/acpi/index.rst | 1 + .../firmware-guide/acpi/method-tracing.rst| 238 ++ 3 files changed, 239 insertions(+), 192 deletions(-) delete mode 100644 Documentation/acpi/method-tracing.txt create mode 100644 Documentation/firmware-guide/acpi/method-tracing.rst diff --git a/Documentation/acpi/method-tracing.txt b/Documentation/acpi/method-tracing.txt deleted file mode 100644 index 0aba14c8f459.. --- a/Documentation/acpi/method-tracing.txt +++ /dev/null @@ -1,192 +0,0 @@ -ACPICA Trace Facility - -Copyright (C) 2015, Intel Corporation -Author: Lv Zheng - - -Abstract: - -This document describes the functions and the interfaces of the method -tracing facility. - -1. Functionalities and usage examples: - - ACPICA provides method tracing capability. And two functions are - currently implemented using this capability. - - A. Log reducer - ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is - enabled. The debugging messages which are deployed via - ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component - level (known as debug layer, configured via - /sys/module/acpi/parameters/debug_layer) and per-type level (known as - debug level, configured via /sys/module/acpi/parameters/debug_level). - - But when the particular layer/level is applied to the control method - evaluations, the quantity of the debugging outputs may still be too - large to be put into the kernel log buffer. The idea thus is worked out - to only enable the particular debug layer/level (normally more detailed) - logs when the control method evaluation is started, and disable the - detailed logging when the control method evaluation is stopped. - - The following command examples illustrate the usage of the "log reducer" - functionality: - a. Filter out the debug layer/level matched logs when control methods - are being evaluated: - # cd /sys/module/acpi/parameters - # echo "0x" > trace_debug_layer - # echo "0x" > trace_debug_level - # echo "enable" > trace_state - b. Filter out the debug layer/level matched logs when the specified - control method is being evaluated: - # cd /sys/module/acpi/parameters - # echo "0x" > trace_debug_layer - # echo "0x" > trace_debug_level - # echo "\..." > trace_method_name - # echo "method" > /sys/module/acpi/parameters/trace_state - c. Filter out the debug layer/level matched logs when the specified - control method is being evaluated for the first time: - # cd /sys/module/acpi/parameters - # echo "0x" > trace_debug_layer - # echo "0x" > trace_debug_level - # echo "\..." > trace_method_name - # echo "method-once" > /sys/module/acpi/parameters/trace_state - Where: - 0x/0x: Refer to Documentation/acpi/debug.txt for -possible debug layer/level masking values. - \...: Full path of a control method that can be found - in the ACPI namespace. It needn't be an entry - of a control method evaluation. - - B. AML tracer - - There are special log entries added by the method tracing facility at - the "trace points" the AML interpreter starts/stops to execute a control - method, or an AML opcode. Note that the format of the log entries are - subject to change: - [0.186427] exdebug-0398 ex_trace_point: Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. - [0.186630] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905c88:If] execution. - [0.186820] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905cc0:LEqual] execution. - [0.187010] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905a20:-NamePath-] execution. - [0.187214] exdebug-0398 ex_trace_point: Opcode End [0xf5905a20:-NamePath-] execution. - [0.187407] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905f60:One] execution. - [0.187594] exdebug-0398 ex_trace_point: Opcode End [0xf5905f60:One] execution. - [0.187789] exdebug-0398 ex_trace_point: Opcode End [0xf5905cc0:LEqual] execution. - [0.187980] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905cc0:Return] execution. - [0.188146] exdebug-0398 ex_trace_point: Opcode Begin [0xf5905f60:One] execution. - [0.188334] exdebug-0398 ex_trace_point: Opcode End [0xf5905f60:One] execution. - [0.188524] exdebug-0398 ex_trace_point
[PATCH v6 16/24] Documentation: ACPI: move debug.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/debug.rst} | 31 ++-
Documentation/firmware-guide/acpi/index.rst | 3 +-
2 files changed, 19 insertions(+), 15 deletions(-)
rename Documentation/{acpi/debug.txt => firmware-guide/acpi/debug.rst} (91%)
diff --git a/Documentation/acpi/debug.txt
b/Documentation/firmware-guide/acpi/debug.rst
similarity index 91%
rename from Documentation/acpi/debug.txt
rename to Documentation/firmware-guide/acpi/debug.rst
index 65bf47c46b6d..1a152dd1d765 100644
--- a/Documentation/acpi/debug.txt
+++ b/Documentation/firmware-guide/acpi/debug.rst
@@ -1,18 +1,21 @@
- ACPI Debug Output
+.. SPDX-License-Identifier: GPL-2.0
+=
+ACPI Debug Output
+=
The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug
output. This document describes how to use this facility.
Compile-time configuration
---
+==
ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config
option is turned off, the debug messages are not even built into the
kernel.
Boot- and run-time configuration
-
+
When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages
you're interested in. At boot-time, use the acpi.debug_layer and
@@ -21,7 +24,7 @@ debug_layer and debug_level files in
/sys/module/acpi/parameters/ to control
the debug messages.
debug_layer (component)
+===
The "debug_layer" is a mask that selects components of interest, e.g., a
specific driver or part of the ACPI interpreter. To build the debug_layer
@@ -33,7 +36,7 @@ to /sys/module/acpi/parameters/debug_layer.
The possible components are defined in include/acpi/acoutput.h and
include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer
-shows the supported mask values, currently these:
+shows the supported mask values, currently these::
ACPI_UTILITIES 0x0001
ACPI_HARDWARE 0x0002
@@ -65,7 +68,7 @@ shows the supported mask values, currently these:
ACPI_PROCESSOR_COMPONENT0x2000
debug_level
+===
The "debug_level" is a mask that selects different types of messages, e.g.,
those related to initialization, method execution, informational messages, etc.
@@ -81,7 +84,7 @@ to /sys/module/acpi/parameters/debug_level.
The possible levels are defined in include/acpi/acoutput.h. Reading
/sys/module/acpi/parameters/debug_level shows the supported mask values,
-currently these:
+currently these::
ACPI_LV_INIT0x0001
ACPI_LV_DEBUG_OBJECT0x0002
@@ -113,9 +116,9 @@ currently these:
ACPI_LV_EVENTS 0x8000
Examples
-
+
-For example, drivers/acpi/bus.c contains this:
+For example, drivers/acpi/bus.c contains this::
#define _COMPONENT ACPI_BUS_COMPONENT
...
@@ -127,22 +130,22 @@ statement uses ACPI_DB_INFO, which is macro based on the
ACPI_LV_INFO
definition.)
Enable all AML "Debug" output (stores to the Debug object while interpreting
-AML) during boot:
+AML) during boot::
acpi.debug_layer=0x acpi.debug_level=0x2
-Enable PCI and PCI interrupt routing debug messages:
+Enable PCI and PCI interrupt routing debug messages::
acpi.debug_layer=0x40 acpi.debug_level=0x4
-Enable all ACPI hardware-related messages:
+Enable all ACPI hardware-related messages::
acpi.debug_layer=0x2 acpi.debug_level=0x
-Enable all ACPI_DB_INFO messages after boot:
+Enable all ACPI_DB_INFO messages after boot::
# echo 0x4 > /sys/module/acpi/parameters/debug_level
-Show all valid component values:
+Show all valid component values::
# cat /sys/module/acpi/parameters/debug_layer
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index 6d4e0df4f063..a45fea11f998 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -14,6 +14,7 @@ ACPI Support
osi
method-customizing
DSD-properties-rules
+ debug
gpio-properties
i2c-muxes
- acpi-lid
\ No newline at end of file
+ acpi-lid
--
2.20.1
[PATCH v6 15/24] Documentation: ACPI: move dsd/data-node-references.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/dsd/data-node-references.rst}| 36 ++-
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 21 insertions(+), 16 deletions(-)
rename Documentation/{acpi/dsd/data-node-references.txt =>
firmware-guide/acpi/dsd/data-node-references.rst} (71%)
diff --git a/Documentation/acpi/dsd/data-node-references.txt
b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
similarity index 71%
rename from Documentation/acpi/dsd/data-node-references.txt
rename to Documentation/firmware-guide/acpi/dsd/data-node-references.rst
index c3871565c8cf..1351984e767c 100644
--- a/Documentation/acpi/dsd/data-node-references.txt
+++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
@@ -1,9 +1,12 @@
-Copyright (C) 2018 Intel Corporation
-Author: Sakari Ailus
-
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+===
Referencing hierarchical data nodes
+===
+
+:Copyright: |copy| 2018 Intel Corporation
+:Author: Sakari Ailus
ACPI in general allows referring to device objects in the tree only.
Hierarchical data extension nodes may not be referred to directly, hence this
@@ -28,13 +31,14 @@ extension key.
Example
+===
- In the ASL snippet below, the "reference" _DSD property [2] contains a
- device object reference to DEV0 and under that device object, a
- hierarchical data extension key "node@1" referring to the NOD1 object
- and lastly, a hierarchical data extension key "anothernode" referring to
- the ANOD object which is also the final target node of the reference.
+In the ASL snippet below, the "reference" _DSD property [2] contains a
+device object reference to DEV0 and under that device object, a
+hierarchical data extension key "node@1" referring to the NOD1 object
+and lastly, a hierarchical data extension key "anothernode" referring to
+the ANOD object which is also the final target node of the reference.
+::
Device (DEV0)
{
@@ -75,15 +79,15 @@ Example
})
}
-Please also see a graph example in graph.txt .
+Please also see a graph example in :doc:`graph`.
References
---
+==
[1] Hierarchical Data Extension UUID For _DSD.
-
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
-referenced 2018-07-17.
+,
+referenced 2018-07-17.
[2] Device Properties UUID For _DSD.
-
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
-referenced 2016-10-04.
+,
+referenced 2016-10-04.
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index f81cfbcb6878..6d4e0df4f063 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -9,6 +9,7 @@ ACPI Support
namespace
dsd/graph
+ dsd/data-node-references
enumeration
osi
method-customizing
--
2.20.1
[PATCH v6 14/24] Documentation: ACPI: move dsd/graph.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/dsd/graph.rst} | 157 +-
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 81 insertions(+), 77 deletions(-)
rename Documentation/{acpi/dsd/graph.txt => firmware-guide/acpi/dsd/graph.rst}
(56%)
diff --git a/Documentation/acpi/dsd/graph.txt
b/Documentation/firmware-guide/acpi/dsd/graph.rst
similarity index 56%
rename from Documentation/acpi/dsd/graph.txt
rename to Documentation/firmware-guide/acpi/dsd/graph.rst
index b9ce910781dc..e0baed35b037 100644
--- a/Documentation/acpi/dsd/graph.txt
+++ b/Documentation/firmware-guide/acpi/dsd/graph.rst
@@ -1,8 +1,11 @@
-Graphs
+.. SPDX-License-Identifier: GPL-2.0
+==
+Graphs
+==
_DSD
-
+
_DSD (Device Specific Data) [7] is a predefined ACPI device
configuration object that can be used to convey information on
@@ -30,7 +33,7 @@ hierarchical data extension array on each depth.
Ports and endpoints
+===
The port and endpoint concepts are very similar to those in Devicetree
[3]. A port represents an interface in a device, and an endpoint
@@ -38,9 +41,9 @@ represents a connection to that interface.
All port nodes are located under the device's "_DSD" node in the hierarchical
data extension tree. The data extension related to each port node must begin
-with "port" and must be followed by the "@" character and the number of the
port
-as its key. The target object it refers to should be called "PRTX", where "X"
is
-the number of the port. An example of such a package would be:
+with "port" and must be followed by the "@" character and the number of the
+port as its key. The target object it refers to should be called "PRTX", where
+"X" is the number of the port. An example of such a package would be::
Package() { "port@4", PRT4 }
@@ -49,7 +52,7 @@ data extension key of the endpoint nodes must begin with
"endpoint" and must be followed by the "@" character and the number of the
endpoint. The object it refers to should be called "EPXY", where "X" is the
number of the port and "Y" is the number of the endpoint. An example of such a
-package would be:
+package would be::
Package() { "endpoint@0", EP40 }
@@ -62,85 +65,85 @@ of that port shall be zero. Similarly, if a port may only
have a single
endpoint, the number of that endpoint shall be zero.
The endpoint reference uses property extension with "remote-endpoint" property
-name followed by a reference in the same package. Such references consist of
the
+name followed by a reference in the same package. Such references consist of
the remote device reference, the first package entry of the port data extension
reference under the device and finally the first package entry of the endpoint
-data extension reference under the port. Individual references thus appear as:
+data extension reference under the port. Individual references thus appear as::
Package() { device, "port@X", "endpoint@Y" }
-In the above example, "X" is the number of the port and "Y" is the number of
the
-endpoint.
+In the above example, "X" is the number of the port and "Y" is the number of
+the endpoint.
The references to endpoints must be always done both ways, to the
remote endpoint and back from the referred remote endpoint node.
-A simple example of this is show below:
+A simple example of this is show below::
Scope (\_SB.PCI0.I2C2)
{
- Device (CAM0)
- {
- Name (_DSD, Package () {
- ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
- Package () {
- Package () { "compatible", Package () { "nokia,smia" } },
- },
- ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
- Package () {
- Package () { "port@0", PRT0 },
- }
- })
- Name (PRT0, Package() {
- ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
- Package () {
- Package () { "reg", 0 },
- },
- ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
- Package () {
- Package () { "endpoint@0", EP00 },
- }
- })
- Name (EP00, Package() {
- ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
- Package () {
- Package () { "reg", 0 },
- Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP,
"port@4", "endpoint@0" } },
- }
- })
- }
+Device (CAM0)
+{
+Name (_DSD, Package () {
+ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+Package () {
+Package () { "compatible",
[PATCH v6 13/24] Documentation: ACPI: move acpi-lid.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/acpi-lid.rst}| 40 ++-
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 30 insertions(+), 11 deletions(-)
rename Documentation/{acpi/acpi-lid.txt => firmware-guide/acpi/acpi-lid.rst}
(86%)
diff --git a/Documentation/acpi/acpi-lid.txt
b/Documentation/firmware-guide/acpi/acpi-lid.rst
similarity index 86%
rename from Documentation/acpi/acpi-lid.txt
rename to Documentation/firmware-guide/acpi/acpi-lid.rst
index effe7af3a5af..874ce0ed340d 100644
--- a/Documentation/acpi/acpi-lid.txt
+++ b/Documentation/firmware-guide/acpi/acpi-lid.rst
@@ -1,13 +1,18 @@
-Special Usage Model of the ACPI Control Method Lid Device
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
-Copyright (C) 2016, Intel Corporation
-Author: Lv Zheng
+=
+Special Usage Model of the ACPI Control Method Lid Device
+=
+:Copyright: |copy| 2016, Intel Corporation
-Abstract:
+:Author: Lv Zheng
-Platforms containing lids convey lid state (open/close) to OSPMs using a
-control method lid device. To implement this, the AML tables issue
+Abstract
+
+Platforms containing lids convey lid state (open/close) to OSPMs
+using a control method lid device. To implement this, the AML tables issue
Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
changed. The _LID control method for the lid device must be implemented to
report the "current" state of the lid as either "opened" or "closed".
@@ -19,7 +24,8 @@ taken into account. This document describes the restrictions
and the
expections of the Linux ACPI lid device driver.
-1. Restrictions of the returning value of the _LID control method
+Restrictions of the returning value of the _LID control method
+==
The _LID control method is described to return the "current" lid state.
However the word of "current" has ambiguity, some buggy AML tables return
@@ -30,7 +36,8 @@ initial returning value. When the AML tables implement this
control method
with cached value, the initial returning value is likely not reliable.
There are platforms always retun "closed" as initial lid state.
-2. Restrictions of the lid state change notifications
+Restrictions of the lid state change notifications
+==
There are buggy AML tables never notifying when the lid device state is
changed to "opened". Thus the "opened" notification is not guaranteed. But
@@ -39,18 +46,22 @@ state is changed to "closed". The "closed" notification is
normally used to
trigger some system power saving operations on Windows. Since it is fully
tested, it is reliable from all AML tables.
-3. Expections for the userspace users of the ACPI lid device driver
+Expections for the userspace users of the ACPI lid device driver
+
The ACPI button driver exports the lid state to the userspace via the
-following file:
+following file::
+
/proc/acpi/button/lid/LID0/state
+
This file actually calls the _LID control method described above. And given
the previous explanation, it is not reliable enough on some platforms. So
it is advised for the userspace program to not to solely rely on this file
to determine the actual lid state.
The ACPI button driver emits the following input event to the userspace:
- SW_LID
+ * SW_LID
+
The ACPI lid device driver is implemented to try to deliver the platform
triggered events to the userspace. However, given the fact that the buggy
firmware cannot make sure "opened"/"closed" events are paired, the ACPI
@@ -59,20 +70,25 @@ button driver uses the following 3 modes in order not to
trigger issues.
If the userspace hasn't been prepared to ignore the unreliable "opened"
events and the unreliable initial state notification, Linux users can use
the following kernel parameters to handle the possible issues:
+
A. button.lid_init_state=method:
When this option is specified, the ACPI button driver reports the
initial lid state using the returning value of the _LID control method
and whether the "opened"/"closed" events are paired fully relies on the
firmware implementation.
+
This option can be used to fix some platforms where the returning value
of the _LID control method is reliable but the initial lid state
notification is missing.
+
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
+
B. button.lid_init_state=open:
When this option is specified, the ACPI button driver always reports the
initial lid state as
[PATCH v6 12/24] Documentation: ACPI: move i2c-muxes.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/acpi/i2c-muxes.txt | 58 --
.../firmware-guide/acpi/i2c-muxes.rst | 61 +++
Documentation/firmware-guide/acpi/index.rst | 3 +-
3 files changed, 63 insertions(+), 59 deletions(-)
delete mode 100644 Documentation/acpi/i2c-muxes.txt
create mode 100644 Documentation/firmware-guide/acpi/i2c-muxes.rst
diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt
deleted file mode 100644
index 9fcc4f0b885e..
--- a/Documentation/acpi/i2c-muxes.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-ACPI I2C Muxes
---
-
-Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
-Device () scope per mux channel.
-
-Consider this topology:
-
-+--+ +--+
-| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
-| | | 0x70 |--CH01--> i2c client B (0x50)
-+--+ +--+
-
-which corresponds to the following ASL:
-
-Device (SMB1)
-{
-Name (_HID, ...)
-Device (MUX0)
-{
-Name (_HID, ...)
-Name (_CRS, ResourceTemplate () {
-I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^SMB1", 0x00,
- ResourceConsumer,,)
-}
-
-Device (CH00)
-{
-Name (_ADR, 0)
-
-Device (CLIA)
-{
-Name (_HID, ...)
-Name (_CRS, ResourceTemplate () {
-I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^CH00", 0x00,
- ResourceConsumer,,)
-}
-}
-}
-
-Device (CH01)
-{
-Name (_ADR, 1)
-
-Device (CLIB)
-{
-Name (_HID, ...)
-Name (_CRS, ResourceTemplate () {
-I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
- AddressingMode7Bit, "^CH01", 0x00,
- ResourceConsumer,,)
-}
-}
-}
-}
-}
diff --git a/Documentation/firmware-guide/acpi/i2c-muxes.rst
b/Documentation/firmware-guide/acpi/i2c-muxes.rst
new file mode 100644
index ..3a8997ccd7c4
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/i2c-muxes.rst
@@ -0,0 +1,61 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+ACPI I2C Muxes
+==
+
+Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
+Device () scope per mux channel.
+
+Consider this topology::
+
++--+ +--+
+| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
+| | | 0x70 |--CH01--> i2c client B (0x50)
++--+ +--+
+
+which corresponds to the following ASL::
+
+Device (SMB1)
+{
+Name (_HID, ...)
+Device (MUX0)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
+AddressingMode7Bit, "^SMB1", 0x00,
+ResourceConsumer,,)
+}
+
+Device (CH00)
+{
+Name (_ADR, 0)
+
+Device (CLIA)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+AddressingMode7Bit, "^CH00", 0x00,
+ResourceConsumer,,)
+}
+}
+}
+
+Device (CH01)
+{
+Name (_ADR, 1)
+
+Device (CLIB)
+{
+Name (_HID, ...)
+Name (_CRS, ResourceTemplate () {
+I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
+AddressingMode7Bit, "^CH01", 0x00,
+ResourceConsumer,,)
+}
+}
+}
+}
+}
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index d1d069b26bbc..1c89888f6ee8 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -12,4 +12,5 @@ ACPI Support
osi
method-customizing
DSD-properties-rules
- gpio-properties
\ No newline at end of file
+ gpio-properties
+ i2c-muxes
--
2.20.1
[PATCH v6 11/24] Documentation: ACPI: move dsdt-override.txt to admin-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/dsdt-override.rst} | 8 +++-
Documentation/admin-guide/acpi/index.rst | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
rename Documentation/{acpi/dsdt-override.txt =>
admin-guide/acpi/dsdt-override.rst} (56%)
diff --git a/Documentation/acpi/dsdt-override.txt
b/Documentation/admin-guide/acpi/dsdt-override.rst
similarity index 56%
rename from Documentation/acpi/dsdt-override.txt
rename to Documentation/admin-guide/acpi/dsdt-override.rst
index 784841caa6e6..50bd7f194bf4 100644
--- a/Documentation/acpi/dsdt-override.txt
+++ b/Documentation/admin-guide/acpi/dsdt-override.rst
@@ -1,6 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Overriding DSDT
+===
+
Linux supports a method of overriding the BIOS DSDT:
-CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
+CONFIG_ACPI_CUSTOM_DSDT - builds the image into the kernel.
When to use this method is described in detail on the
Linux/ACPI home page:
diff --git a/Documentation/admin-guide/acpi/index.rst
b/Documentation/admin-guide/acpi/index.rst
index 09e4e81e4fb7..d68e9914c5ff 100644
--- a/Documentation/admin-guide/acpi/index.rst
+++ b/Documentation/admin-guide/acpi/index.rst
@@ -9,3 +9,4 @@ the Linux ACPI support.
:maxdepth: 1
initrd_table_override
+ dsdt-override
--
2.20.1
[PATCH v6 10/24] Documentation: ACPI: move initrd_table_override.txt to admin-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/acpi/initrd_table_override.txt | 111 -
Documentation/admin-guide/acpi/index.rst | 1 +
.../acpi/initrd_table_override.rst| 115 ++
3 files changed, 116 insertions(+), 111 deletions(-)
delete mode 100644 Documentation/acpi/initrd_table_override.txt
create mode 100644 Documentation/admin-guide/acpi/initrd_table_override.rst
diff --git a/Documentation/acpi/initrd_table_override.txt
b/Documentation/acpi/initrd_table_override.txt
deleted file mode 100644
index 30437a6db373..
--- a/Documentation/acpi/initrd_table_override.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-Upgrading ACPI tables via initrd
-
-
-1) Introduction (What is this about)
-2) What is this for
-3) How does it work
-4) References (Where to retrieve userspace tools)
-
-1) What is this about
--
-
-If the ACPI_TABLE_UPGRADE compile option is true, it is possible to
-upgrade the ACPI execution environment that is defined by the ACPI tables
-via upgrading the ACPI tables provided by the BIOS with an instrumented,
-modified, more recent version one, or installing brand new ACPI tables.
-
-When building initrd with kernel in a single image, option
-ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD should also be true for this
-feature to work.
-
-For a full list of ACPI tables that can be upgraded/installed, take a look
-at the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in
-drivers/acpi/tables.c.
-All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
-be overridable, except:
- - ACPI_SIG_RSDP (has a signature of 6 bytes)
- - ACPI_SIG_FACS (does not have an ordinary ACPI table header)
-Both could get implemented as well.
-
-
-2) What is this for
-
-Complain to your platform/BIOS vendor if you find a bug which is so severe
-that a workaround is not accepted in the Linux kernel. And this facility
-allows you to upgrade the buggy tables before your platform/BIOS vendor
-releases an upgraded BIOS binary.
-
-This facility can be used by platform/BIOS vendors to provide a Linux
-compatible environment without modifying the underlying platform firmware.
-
-This facility also provides a powerful feature to easily debug and test
-ACPI BIOS table compatibility with the Linux kernel by modifying old
-platform provided ACPI tables or inserting new ACPI tables.
-
-It can and should be enabled in any kernel because there is no functional
-change with not instrumented initrds.
-
-
-3) How does it work
-
-# Extract the machine's ACPI tables:
-cd /tmp
-acpidump >acpidump
-acpixtract -a acpidump
-# Disassemble, modify and recompile them:
-iasl -d *.dat
-# For example add this statement into a _PRT (PCI Routing Table) function
-# of the DSDT:
-Store("HELLO WORLD", debug)
-# And increase the OEM Revision. For example, before modification:
-DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x)
-# After modification:
-DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x0001)
-iasl -sa dsdt.dsl
-# Add the raw ACPI tables to an uncompressed cpio archive.
-# They must be put into a /kernel/firmware/acpi directory inside the cpio
-# archive. Note that if the table put here matches a platform table
-# (similar Table Signature, and similar OEMID, and similar OEM Table ID)
-# with a more recent OEM Revision, the platform table will be upgraded by
-# this table. If the table put here doesn't match a platform table
-# (dissimilar Table Signature, or dissimilar OEMID, or dissimilar OEM Table
-# ID), this table will be appended.
-mkdir -p kernel/firmware/acpi
-cp dsdt.aml kernel/firmware/acpi
-# A maximum of "NR_ACPI_INITRD_TABLES (64)" tables are currently allowed
-# (see osl.c):
-iasl -sa facp.dsl
-iasl -sa ssdt1.dsl
-cp facp.aml kernel/firmware/acpi
-cp ssdt1.aml kernel/firmware/acpi
-# The uncompressed cpio archive must be the first. Other, typically
-# compressed cpio archives, must be concatenated on top of the uncompressed
-# one. Following command creates the uncompressed cpio archive and
-# concatenates the original initrd on top:
-find kernel | cpio -H newc --create > /boot/instrumented_initrd
-cat /boot/initrd >>/boot/instrumented_initrd
-# reboot with increased acpi debug level, e.g. boot params:
-acpi.debug_level=0x2 acpi.debug_layer=0x
-# and check your syslog:
-[1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
-[1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD"
-
-iasl is able to disassemble and recompile quite a lot different,
-also static ACPI tables.
-
-
-4) Where to retrieve userspace tools
-
-
-iasl and acpixtract are part of Intel's ACPICA project:
-http://acpica.org/
-and should be
[PATCH v6 09/24] Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/acpi/method-customizing.txt | 73 ---
Documentation/firmware-guide/acpi/index.rst | 3 +-
.../acpi/method-customizing.rst | 89 +++
3 files changed, 91 insertions(+), 74 deletions(-)
delete mode 100644 Documentation/acpi/method-customizing.txt
create mode 100644 Documentation/firmware-guide/acpi/method-customizing.rst
diff --git a/Documentation/acpi/method-customizing.txt
b/Documentation/acpi/method-customizing.txt
deleted file mode 100644
index 7235da975f23..
--- a/Documentation/acpi/method-customizing.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Linux ACPI Custom Control Method How To
-===
-
-Written by Zhang Rui
-
-
-Linux supports customizing ACPI control methods at runtime.
-
-Users can use this to
-1. override an existing method which may not work correctly,
- or just for debugging purposes.
-2. insert a completely new method in order to create a missing
- method such as _OFF, _ON, _STA, _INI, etc.
-For these cases, it is far simpler to dynamically install a single
-control method rather than override the entire DSDT, because kernel
-rebuild/reboot is not needed and test result can be got in minutes.
-
-Note: Only ACPI METHOD can be overridden, any other object types like
- "Device", "OperationRegion", are not recognized. Methods
- declared inside scope operators are also not supported.
-Note: The same ACPI control method can be overridden for many times,
- and it's always the latest one that used by Linux/kernel.
-Note: To get the ACPI debug object output (Store (, Debug)),
- please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output".
-
-1. override an existing method
- a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT,
- just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat"
- b) disassemble the table by running "iasl -d dsdt.dat".
- c) rewrite the ASL code of the method and save it in a new file,
- d) package the new file (psr.asl) to an ACPI table format.
- Here is an example of a customized \_SB._AC._PSR method,
-
- DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715)
- {
- Method (\_SB_.AC._PSR, 0, NotSerialized)
- {
- Store ("In AC _PSR", Debug)
- Return (ACON)
- }
- }
- Note that the full pathname of the method in ACPI namespace
- should be used.
- e) assemble the file to generate the AML code of the method.
- e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result)
- If parameter "-vw 6084" is not supported by your iASL compiler,
- please try a newer version.
- f) mount debugfs by "mount -t debugfs none /sys/kernel/debug"
- g) override the old method via the debugfs by running
- "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method"
-
-2. insert a new method
- This is easier than overriding an existing method.
- We just need to create the ASL code of the method we want to
- insert and then follow the step c) ~ g) in section 1.
-
-3. undo your changes
- The "undo" operation is not supported for a new inserted method
- right now, i.e. we can not remove a method currently.
- For an overridden method, in order to undo your changes, please
- save a copy of the method original ASL code in step c) section 1,
- and redo step c) ~ g) to override the method with the original one.
-
-
-Note: We can use a kernel with multiple custom ACPI method running,
- But each individual write to debugfs can implement a SINGLE
- method override. i.e. if we want to insert/override multiple
- ACPI methods, we need to redo step c) ~ g) for multiple times.
-
-Note: Be aware that root can mis-use this driver to modify arbitrary
- memory and gain additional rights, if root's privileges got
- restricted (for example if root is not allowed to load additional
- modules after boot).
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index 61d67763851b..d1d069b26bbc 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -10,5 +10,6 @@ ACPI Support
namespace
enumeration
osi
+ method-customizing
DSD-properties-rules
- gpio-properties
+ gpio-properties
\ No newline at end of file
diff --git a/Documentation/firmware-guide/acpi/method-customizing.rst
b/Documentation/firmware-guide/acpi/method-customizing.rst
new file mode 100644
index ..de3ebcaed4cf
--- /dev/null
+++ b/Documentation/firmware-guide/acpi/method-customizing.rst
@@ -0,0 +1,89 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Linux ACPI Custom Control Method How To
[PATCH v6 08/24] Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/gpio-properties.rst} | 78 +++
Documentation/firmware-guide/acpi/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 46 insertions(+), 35 deletions(-)
rename Documentation/{acpi/gpio-properties.txt =>
firmware-guide/acpi/gpio-properties.rst} (81%)
diff --git a/Documentation/acpi/gpio-properties.txt
b/Documentation/firmware-guide/acpi/gpio-properties.rst
similarity index 81%
rename from Documentation/acpi/gpio-properties.txt
rename to Documentation/firmware-guide/acpi/gpio-properties.rst
index 88c65cb5bf0a..bb6d74f23ee0 100644
--- a/Documentation/acpi/gpio-properties.txt
+++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
@@ -1,5 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
_DSD Device Properties Related to GPIO
---
+==
With the release of ACPI 5.1, the _DSD configuration object finally
allows names to be given to GPIOs (and other things as well) returned
@@ -8,7 +11,7 @@ the corresponding GPIO, which is pretty error prone (it
depends on
the _CRS output ordering, for example).
With _DSD we can now query GPIOs using a name instead of an integer
-index, like the ASL example below shows:
+index, like the ASL example below shows::
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
@@ -34,15 +37,19 @@ index, like the ASL example below shows:
})
}
-The format of the supported GPIO property is:
+The format of the supported GPIO property is::
Package () { "name", Package () { ref, index, pin, active_low }}
- ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
-typically this is the device itself (BTH in our case).
- index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
- pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
- active_low - If 1 the GPIO is marked as active_low.
+ref
+ The device that has _CRS containing GpioIo()/GpioInt() resources,
+ typically this is the device itself (BTH in our case).
+index
+ Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
+pin
+ Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
+active_low
+ If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have a field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
@@ -55,7 +62,7 @@ It is possible to leave holes in the array of GPIOs. This is
useful in
cases like with SPI host controllers where some chip selects may be
implemented as GPIOs and some as native signals. For example a SPI host
controller can have chip selects 0 and 2 implemented as GPIOs and 1 as
-native:
+native::
Package () {
"cs-gpios",
@@ -67,7 +74,7 @@ native:
}
Other supported properties
---
+==
Following Device Tree compatible device properties are also supported by
_DSD device properties for GPIO controllers:
@@ -78,7 +85,7 @@ _DSD device properties for GPIO controllers:
- input
- line-name
-Example:
+Example::
Name (_DSD, Package () {
// _DSD Hierarchical Properties Extension UUID
@@ -100,7 +107,7 @@ Example:
- gpio-line-names
-Example:
+Example::
Package () {
"gpio-line-names",
@@ -114,7 +121,7 @@ See Documentation/devicetree/bindings/gpio/gpio.txt for
more information
about these properties.
ACPI GPIO Mappings Provided by Drivers
---
+==
There are systems in which the ACPI tables do not contain _DSD but provide _CRS
with GpioIo()/GpioInt() resources and device drivers still need to work with
@@ -139,16 +146,16 @@ line in that resource starting from zero, and the
active-low flag for that line,
respectively, in analogy with the _DSD GPIO property format specified above.
For the example Bluetooth device discussed previously the data structures in
-question would look like this:
+question would look like this::
-static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
-static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
+ static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
+ static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
-static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
- { "reset-gpios", _gpio, 1 },
- { "shutdown-gpios", _gpio, 1 },
- { },
-};
+ static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
+{ "reset-gpios", _gpio, 1 },
+{ "shutdown-gpios", _gpio, 1 },
+{ },
+ };
Next, the mapping table needs to be passed as the second
[PATCH v6 07/24] Documentation: ACPI: move DSD-properties-rules.txt to firmware-guide/acpi and covert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../acpi/DSD-properties-rules.rst}| 21 +++
Documentation/firmware-guide/acpi/index.rst | 1 +
2 files changed, 13 insertions(+), 9 deletions(-)
rename Documentation/{acpi/DSD-properties-rules.txt =>
firmware-guide/acpi/DSD-properties-rules.rst} (88%)
diff --git a/Documentation/acpi/DSD-properties-rules.txt
b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst
similarity index 88%
rename from Documentation/acpi/DSD-properties-rules.txt
rename to Documentation/firmware-guide/acpi/DSD-properties-rules.rst
index 3e4862bdad98..4306f29b6103 100644
--- a/Documentation/acpi/DSD-properties-rules.txt
+++ b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst
@@ -1,8 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
_DSD Device Properties Usage Rules
---
+==
Properties, Property Sets and Property Subsets
---
+==
The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1,
allows any type of device configuration data to be provided via the ACPI
@@ -18,7 +21,7 @@ specific type) associated with it.
In the ACPI _DSD context it is an element of the sub-package following the
generic Device Properties UUID in the _DSD return package as specified in the
-Device Properties UUID definition document [1].
+Device Properties UUID definition document [1]_.
It also may be regarded as the definition of a key and the associated data type
that can be returned by _DSD in the Device Properties UUID sub-package for a
@@ -33,14 +36,14 @@ Property subsets are nested collections of properties.
Each of them is
associated with an additional key (name) allowing the subset to be referred
to as a whole (and to be treated as a separate entity). The canonical
representation of property subsets is via the mechanism specified in the
-Hierarchical Properties Extension UUID definition document [2].
+Hierarchical Properties Extension UUID definition document [2]_.
Property sets may be hierarchical. That is, a property set may contain
multiple property subsets that each may contain property subsets of its
own and so on.
General Validity Rule for Property Sets
+===
Valid property sets must follow the guidance given by the Device Properties
UUID
definition document [1].
@@ -73,7 +76,7 @@ suitable for the ACPI environment and consequently they
cannot belong to a valid
property set.
Property Sets and Device Tree Bindings
---
+==
It often is useful to make _DSD return property sets that follow Device Tree
bindings.
@@ -91,7 +94,7 @@ expected to automatically work in the ACPI environment
regardless of their
contents.
References
---
+==
-[1]
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
-[2]
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
+.. [1]
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
+.. [2]
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index 868bd25a3398..0e05b843521c 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -10,3 +10,4 @@ ACPI Support
namespace
enumeration
osi
+ DSD-properties-rules
--
2.20.1
[PATCH v6 06/24] Documentation: ACPI: move scan_handlers.txt to driver-api/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/driver-api/acpi/index.rst | 1 +
.../acpi/scan_handlers.rst} | 24 ---
2 files changed, 16 insertions(+), 9 deletions(-)
rename Documentation/{acpi/scan_handlers.txt =>
driver-api/acpi/scan_handlers.rst} (90%)
diff --git a/Documentation/driver-api/acpi/index.rst
b/Documentation/driver-api/acpi/index.rst
index 12649947b19b..ace0008e54c2 100644
--- a/Documentation/driver-api/acpi/index.rst
+++ b/Documentation/driver-api/acpi/index.rst
@@ -6,3 +6,4 @@ ACPI Support
:maxdepth: 2
linuxized-acpica
+ scan_handlers
diff --git a/Documentation/acpi/scan_handlers.txt
b/Documentation/driver-api/acpi/scan_handlers.rst
similarity index 90%
rename from Documentation/acpi/scan_handlers.txt
rename to Documentation/driver-api/acpi/scan_handlers.rst
index 3246ccf15992..7a197b3a33fc 100644
--- a/Documentation/acpi/scan_handlers.txt
+++ b/Documentation/driver-api/acpi/scan_handlers.rst
@@ -1,7 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+
+==
ACPI Scan Handlers
+==
+
+:Copyright: |copy| 2012, Intel Corporation
-Copyright (C) 2012, Intel Corporation
-Author: Rafael J. Wysocki
+:Author: Rafael J. Wysocki
During system initialization and ACPI-based device hot-add, the ACPI namespace
is scanned in search of device objects that generally represent various pieces
@@ -30,14 +36,14 @@ to configure that link so that the kernel can use it.
Those additional configuration tasks usually depend on the type of the hardware
component represented by the given device node which can be determined on the
basis of the device node's hardware ID (HID). They are performed by objects
-called ACPI scan handlers represented by the following structure:
+called ACPI scan handlers represented by the following structure::
-struct acpi_scan_handler {
- const struct acpi_device_id *ids;
- struct list_head list_node;
- int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
- void (*detach)(struct acpi_device *dev);
-};
+ struct acpi_scan_handler {
+ const struct acpi_device_id *ids;
+ struct list_head list_node;
+ int (*attach)(struct acpi_device *dev, const struct
acpi_device_id *id);
+ void (*detach)(struct acpi_device *dev);
+ };
where ids is the list of IDs of device nodes the given handler is supposed to
take care of, list_node is the hook to the global list of ACPI scan handlers
--
2.20.1
[PATCH v6 05/24] Documentation: ACPI: move linuxized-acpica.txt to driver-api/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/driver-api/acpi/index.rst | 1 +
.../acpi/linuxized-acpica.rst}| 109 ++
2 files changed, 64 insertions(+), 46 deletions(-)
rename Documentation/{acpi/linuxized-acpica.txt =>
driver-api/acpi/linuxized-acpica.rst} (80%)
diff --git a/Documentation/driver-api/acpi/index.rst
b/Documentation/driver-api/acpi/index.rst
index 898b0c60671a..12649947b19b 100644
--- a/Documentation/driver-api/acpi/index.rst
+++ b/Documentation/driver-api/acpi/index.rst
@@ -5,3 +5,4 @@ ACPI Support
.. toctree::
:maxdepth: 2
+ linuxized-acpica
diff --git a/Documentation/acpi/linuxized-acpica.txt
b/Documentation/driver-api/acpi/linuxized-acpica.rst
similarity index 80%
rename from Documentation/acpi/linuxized-acpica.txt
rename to Documentation/driver-api/acpi/linuxized-acpica.rst
index 3ad7b0dfb083..0ca8f1538519 100644
--- a/Documentation/acpi/linuxized-acpica.txt
+++ b/Documentation/driver-api/acpi/linuxized-acpica.rst
@@ -1,31 +1,37 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+
+
Linuxized ACPICA - Introduction to ACPICA Release Automation
+
-Copyright (C) 2013-2016, Intel Corporation
-Author: Lv Zheng
+:Copyright: |copy| 2013-2016, Intel Corporation
+:Author: Lv Zheng
-Abstract:
+Abstract
+
This document describes the ACPICA project and the relationship between
ACPICA and Linux. It also describes how ACPICA code in drivers/acpi/acpica,
include/acpi and tools/power/acpi is automatically updated to follow the
upstream.
+ACPICA Project
+==
-1. ACPICA Project
-
- The ACPI Component Architecture (ACPICA) project provides an operating
- system (OS)-independent reference implementation of the Advanced
- Configuration and Power Interface Specification (ACPI). It has been
- adapted by various host OSes. By directly integrating ACPICA, Linux can
- also benefit from the application experiences of ACPICA from other host
- OSes.
+The ACPI Component Architecture (ACPICA) project provides an operating
+system (OS)-independent reference implementation of the Advanced
+Configuration and Power Interface Specification (ACPI). It has been
+adapted by various host OSes. By directly integrating ACPICA, Linux can
+also benefit from the application experiences of ACPICA from other host
+OSes.
- The homepage of ACPICA project is: www.acpica.org, it is maintained and
- supported by Intel Corporation.
+The homepage of ACPICA project is: www.acpica.org, it is maintained and
+supported by Intel Corporation.
- The following figure depicts the Linux ACPI subsystem where the ACPICA
- adaptation is included:
+The following figure depicts the Linux ACPI subsystem where the ACPICA
+adaptation is included::
+-+
| |
@@ -71,21 +77,27 @@ upstream.
Figure 1. Linux ACPI Software Components
- NOTE:
+.. note::
A. OS Service Layer - Provided by Linux to offer OS dependent
implementation of the predefined ACPICA interfaces (acpi_os_*).
+ ::
+
include/acpi/acpiosxf.h
drivers/acpi/osl.c
include/acpi/platform
include/asm/acenv.h
B. ACPICA Functionality - Released from ACPICA code base to offer
OS independent implementation of the ACPICA interfaces (acpi_*).
+ ::
+
drivers/acpi/acpica
include/acpi/ac*.h
tools/power/acpi
C. Linux/ACPI Functionality - Providing Linux specific ACPI
functionality to the other Linux kernel subsystems and user space
programs.
+ ::
+
drivers/acpi
include/linux/acpi.h
include/linux/acpi*.h
@@ -95,24 +107,27 @@ upstream.
ACPI subsystem to offer architecture specific implementation of the
ACPI interfaces. They are Linux specific components and are out of
the scope of this document.
+ ::
+
include/asm/acpi.h
include/asm/acpi*.h
arch/*/acpi
-2. ACPICA Release
+ACPICA Release
+==
- The ACPICA project maintains its code base at the following repository URL:
- https://github.com/acpica/acpica.git. As a rule, a release is made every
- month.
+The ACPICA project maintains its code base at the following repository URL:
+https://github.com/acpica/acpica.git. As a rule, a release is made every
+month.
- As the coding style adopted by the ACPICA project is not acceptable by
- Linux, there is a release process to convert the ACPICA git commits into
- Linux patches. The patches generated by this process are
[PATCH v6 04/24] Documentation: ACPI: move osi.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../{acpi/osi.txt => firmware-guide/acpi/osi.rst} | 15 +--
2 files changed, 10 insertions(+), 6 deletions(-)
rename Documentation/{acpi/osi.txt => firmware-guide/acpi/osi.rst} (97%)
diff --git a/Documentation/firmware-guide/acpi/index.rst
b/Documentation/firmware-guide/acpi/index.rst
index 99677c73f1fb..868bd25a3398 100644
--- a/Documentation/firmware-guide/acpi/index.rst
+++ b/Documentation/firmware-guide/acpi/index.rst
@@ -9,3 +9,4 @@ ACPI Support
namespace
enumeration
+ osi
diff --git a/Documentation/acpi/osi.txt
b/Documentation/firmware-guide/acpi/osi.rst
similarity index 97%
rename from Documentation/acpi/osi.txt
rename to Documentation/firmware-guide/acpi/osi.rst
index 50cde0ceb9b0..29e9ef79ebc0 100644
--- a/Documentation/acpi/osi.txt
+++ b/Documentation/firmware-guide/acpi/osi.rst
@@ -1,5 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
ACPI _OSI and _REV methods
---
+==
An ACPI BIOS can use the "Operating System Interfaces" method (_OSI)
to find out what the operating system supports. Eg. If BIOS
@@ -14,7 +17,7 @@ This document explains how and why the BIOS and Linux should
use these methods.
It also explains how and why they are widely misused.
How to use _OSI
+===
Linux runs on two groups of machines -- those that are tested by the OEM
to be compatible with Linux, and those that were never tested with Linux,
@@ -62,7 +65,7 @@ the string when that support is added to the kernel.
That was easy. Read on, to find out how to do it wrong.
Before _OSI, there was _OS
---
+==
ACPI 1.0 specified "_OS" as an
"object that evaluates to a string that identifies the operating system."
@@ -96,7 +99,7 @@ That is the *only* viable strategy, as that is what modern
Windows does,
and so doing otherwise could steer the BIOS down an untested path.
_OSI is born, and immediately misused
---
+=
With _OSI, the *BIOS* provides the string describing an interface,
and asks the OS: "YES/NO, are you compatible with this interface?"
@@ -144,7 +147,7 @@ catastrophic failure resulting from the BIOS taking paths
that
were never validated under *any* OS.
Do not use _REV
+===
Since _OSI("Linux") went away, some BIOS writers used _REV
to support Linux and Windows differences in the same BIOS.
@@ -164,7 +167,7 @@ from mid-2015 onward. The ACPI specification will also be
updated
to reflect that _REV is deprecated, and always returns 2.
Apple Mac and _OSI("Darwin")
-
+
On Apple's Mac platforms, the ACPI BIOS invokes _OSI("Darwin")
to determine if the machine is running Apple OSX.
--
2.20.1
[PATCH v6 03/24] Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
.../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
[PATCH v6 02/24] Documentation: ACPI: move namespace.txt to firmware-guide/acpi and convert to reST
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
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../acpi/namespace.rst} | 294 +-
2 files changed, 154 insertions(+), 141 deletions(-)
rename Documentation/{acpi/namespace.txt => firmware-guide/acpi/namespace.rst}
(56%)
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 56%
rename from Documentation/acpi/namespace.txt
rename to Documentation/firmware-guide/acpi/namespace.rst
index 1860cb3865c6..835521baeb89 100644
--- a/Documentation/acpi/namespace.txt
+++ b/Documentation/firmware-guide/acpi/namespace.rst
@@ -1,85 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+
+===
ACPI Device Tree - Representation of ACPI Namespace
+===
-Copyright (C) 2013, Intel Corporation
-Author: Lv Zheng
+:Copyright: |copy| 2013, Intel Corporation
+:Author: Lv Zheng
-Abstract:
+:Credit: Thanks for the help from Zhang Rui and
+ Rafael J.Wysocki .
+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
+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.
+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
[PATCH v6 01/24] Documentation: add Linux ACPI to Sphinx TOC tree
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 Reviewed-by: Mauro Carvalho Chehab --- 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 ..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 ..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 ..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 ..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
[PATCH v6 00/24] Include linux ACPI docs into Sphinx TOC tree
Hi 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. 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 For you to preview, please visit below url: http://www.bytemem.com:8080/kernel-doc/index.html Many thanks for all the comments! v6: add a missed patch. v5: Fix all comments from Mauro. Thanks for your careful review! Changbin Du (24): 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/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| 115 +++ .../admin-guide/acpi/ssdt-overlays.rst| 180 +++ Documentation/admin-guide/index.rst | 1 + Documentation/driver-api/acpi/index.rst | 9 + .../acpi/linuxized-acpica.rst}| 109 --- .../acpi/scan_handlers.rst} | 24 +- Documentation/driver-api/index.rst| 1 + .../acpi/DSD-properties-rules.rst}| 21 +- .../acpi/acpi-lid.rst}| 40 ++- .../firmware-guide/acpi/aml-debugger.rst | 75 + .../acpi/apei/einj.rst} | 94 +++--- .../acpi/apei/output_format.rst | 150 + .../acpi/debug.rst} | 31 +- .../acpi/dsd/data-node-references.rst}| 36 ++- .../acpi/dsd/graph.rst} | 157 +- .../acpi/enumeration.rst} | 135 .../acpi/gpio-properties.rst} | 78 +++--
Re: [PATCH v5 00/23] Include linux ACPI docs into Sphinx TOC tree
On Thu, Apr 25, 2019 at 10:44:14AM +0200, Rafael J. Wysocki wrote: > .On Wed, Apr 24, 2019 at 7:54 PM Changbin Du wrote: > > > > Hi 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. > > > > 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/ > > I'd like to queue up this series, but it is missing a patch to create > Documentation/firmware-guide/acpi/index.rst. > > Care to provide one? oops, the first patch is missed. Let me add it next. -- Cheers, Changbin Du
Re: [PATCH v2 3/4] powerpc/boot: Add bzip2 support for uImage
On Tue, Apr 23, 2019 at 02:20:43PM +, Christophe Leroy wrote: > This patch allows to generate bzip2 compressed uImage Please don't add bzip2 support, that's a waste of your time as we're trying to remove it kernel-wide. There's a patchset to retire compressors beaten by alternatives on the whole speed-to-size curve; reposting it is overdue. It does: * add ZSTD (fast and strong) * remove BZIP2 (obsolete, only user in kernel) * remove LZMA (redundant with XZ, uses a private copy of its library) * makes Kconfig prose talk badly about LZO (used elsewhere in the kernel) I believe only three compressors are worth using here: XZ, ZSTD, LZ4. GZIP must stay because of ubiquitous support, the rest should go. > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -199,6 +199,7 @@ config PPC > + select HAVE_KERNEL_BZIP2if DEFAULT_UIMAGE > --- a/arch/powerpc/boot/Makefile > +++ b/arch/powerpc/boot/Makefile > @@ -23,6 +23,7 @@ all: $(obj)/zImage > +compress-$(CONFIG_KERNEL_BZIP2) := CONFIG_KERNEL_BZIP2 > @@ -259,6 +260,7 @@ endif > +compressor-$(CONFIG_KERNEL_BZIP2) := bz2 > --- a/arch/powerpc/boot/wrapper > +++ b/arch/powerpc/boot/wrapper > @@ -137,7 +137,7 @@ while [ "$#" -gt 0 ]; do > -[ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "none" ] > || usage > +[ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "bz2" -o > "$1" != "none" ] || usage > @@ -149,6 +149,9 @@ while [ "$#" -gt 0 ]; do > + if [ $uboot_comp = "bz2" ]; then > + uboot_comp=bzip2 > + fi > @@ -377,6 +380,9 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o > "$vmz$compression" -ot "$kernel > +.bz2) > +bzip2 -f "$vmz.$$" > + ;; Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
[PATCH v2 11/11] powerpc/mm: drop slice DEBUG
slice is now an improved functionnality. Drop the DEBUG stuff.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/slice.c | 62 -
1 file changed, 4 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 97fbf7b54422..a9d803738b65 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -41,28 +41,6 @@
static DEFINE_SPINLOCK(slice_convert_lock);
-#ifdef DEBUG
-int _slice_debug = 1;
-
-static void slice_print_mask(const char *label, const struct slice_mask *mask)
-{
- if (!_slice_debug)
- return;
- pr_devel("%s low_slice: %*pbl\n", label,
- (int)SLICE_NUM_LOW, >low_slices);
- pr_devel("%s high_slice: %*pbl\n", label,
- (int)SLICE_NUM_HIGH, mask->high_slices);
-}
-
-#define slice_dbg(fmt...) do { if (_slice_debug) pr_devel(fmt); } while (0)
-
-#else
-
-static void slice_print_mask(const char *label, const struct slice_mask *mask)
{}
-#define slice_dbg(fmt...)
-
-#endif
-
static inline bool slice_addr_is_low(unsigned long addr)
{
u64 tmp = (u64)addr;
@@ -207,9 +185,6 @@ static void slice_convert(struct mm_struct *mm,
unsigned long i, flags;
int old_psize;
- slice_dbg("slice_convert(mm=%p, psize=%d)\n", mm, psize);
- slice_print_mask(" mask", mask);
-
psize_mask = slice_mask_for_size(>context, psize);
/* We need to use a spinlock here to protect against
@@ -255,10 +230,6 @@ static void slice_convert(struct mm_struct *mm,
(((unsigned long)psize) << (mask_index * 4));
}
- slice_dbg(" lsps=%lx, hsps=%lx\n",
- (unsigned long)mm_ctx_low_slices(>context),
- (unsigned long)mm_ctx_high_slices(>context));
-
spin_unlock_irqrestore(_convert_lock, flags);
copro_flush_all_slbs(mm);
@@ -485,14 +456,9 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
BUG_ON(mm_ctx_slb_addr_limit(>context) == 0);
VM_BUG_ON(radix_enabled());
- slice_dbg("slice_get_unmapped_area(mm=%p, psize=%d...\n", mm, psize);
- slice_dbg(" addr=%lx, len=%lx, flags=%lx, topdown=%d\n",
- addr, len, flags, topdown);
-
/* If hint, make sure it matches our alignment restrictions */
if (!fixed && addr) {
addr = _ALIGN_UP(addr, page_size);
- slice_dbg(" aligned addr=%lx\n", addr);
/* Ignore hint if it's too large or overlaps a VMA */
if (addr > high_limit - len || addr < mmap_min_addr ||
!slice_area_is_free(mm, addr, len))
@@ -538,17 +504,12 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
slice_copy_mask(_mask, maskp);
}
- slice_print_mask(" good_mask", _mask);
- if (compat_maskp)
- slice_print_mask(" compat_mask", compat_maskp);
-
/* First check hint if it's valid or if we have MAP_FIXED */
if (addr != 0 || fixed) {
/* Check if we fit in the good mask. If we do, we just return,
* nothing else to do
*/
if (slice_check_range_fits(mm, _mask, addr, len)) {
- slice_dbg(" fits good !\n");
newaddr = addr;
goto return_addr;
}
@@ -558,13 +519,10 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
*/
newaddr = slice_find_area(mm, len, _mask,
psize, topdown, high_limit);
- if (newaddr != -ENOMEM) {
- /* Found within the good mask, we don't have to setup,
-* we thus return directly
-*/
- slice_dbg(" found area at 0x%lx\n", newaddr);
+
+ /* Found within good mask, don't have to setup, thus return
directly */
+ if (newaddr != -ENOMEM)
goto return_addr;
- }
}
/*
* We don't fit in the good mask, check what other slices are
@@ -572,11 +530,9 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
*/
slice_mask_for_free(mm, _mask, high_limit);
slice_or_mask(_mask, _mask, _mask);
- slice_print_mask(" potential", _mask);
if (addr != 0 || fixed) {
if (slice_check_range_fits(mm, _mask, addr, len)) {
- slice_dbg(" fits potential !\n");
newaddr = addr;
goto convert;
}
@@ -586,18 +542,14 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
if (fixed)
return -EBUSY;
- slice_dbg(" search...\n");
-
/*
[PATCH v2 07/11] powerpc/mm: remove a couple of #ifdef CONFIG_PPC_64K_PAGES in mm/slice.c
This patch replaces a couple of #ifdef CONFIG_PPC_64K_PAGES
by IS_ENABLED(CONFIG_PPC_64K_PAGES) to improve code maintainability.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/slice.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 840c4118a185..ace97d953040 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -606,14 +606,13 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
newaddr = slice_find_area(mm, len, _mask,
psize, topdown, high_limit);
-#ifdef CONFIG_PPC_64K_PAGES
- if (newaddr == -ENOMEM && psize == MMU_PAGE_64K) {
+ if (IS_ENABLED(CONFIG_PPC_64K_PAGES) && newaddr == -ENOMEM &&
+ psize == MMU_PAGE_64K) {
/* retry the search with 4k-page slices included */
slice_or_mask(_mask, _mask, compat_maskp);
newaddr = slice_find_area(mm, len, _mask,
psize, topdown, high_limit);
}
-#endif
if (newaddr == -ENOMEM)
return -ENOMEM;
@@ -784,9 +783,9 @@ int slice_is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,
VM_BUG_ON(radix_enabled());
maskp = slice_mask_for_size(>context, psize);
-#ifdef CONFIG_PPC_64K_PAGES
+
/* We need to account for 4k slices too */
- if (psize == MMU_PAGE_64K) {
+ if (IS_ENABLED(CONFIG_PPC_64K_PAGES) && psize == MMU_PAGE_64K) {
const struct slice_mask *compat_maskp;
struct slice_mask available;
@@ -794,7 +793,6 @@ int slice_is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,
slice_or_mask(, maskp, compat_maskp);
return !slice_check_range_fits(mm, , addr, len);
}
-#endif
return !slice_check_range_fits(mm, maskp, addr, len);
}
--
2.13.3
[PATCH v2 09/11] powerpc/mm: define get_slice_psize() all the time
get_slice_psize() can be defined regardless of CONFIG_PPC_MM_SLICES
to avoid ifdefs
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/slice.h | 5 +
arch/powerpc/mm/hugetlbpage.c| 4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/slice.h b/arch/powerpc/include/asm/slice.h
index be8af667098f..c6f466f4c241 100644
--- a/arch/powerpc/include/asm/slice.h
+++ b/arch/powerpc/include/asm/slice.h
@@ -36,6 +36,11 @@ void slice_setup_new_exec(void);
static inline void slice_init_new_context_exec(struct mm_struct *mm) {}
+static inline unsigned int get_slice_psize(struct mm_struct *mm, unsigned long
addr)
+{
+ return 0;
+}
+
#endif /* CONFIG_PPC_MM_SLICES */
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 9e732bb2c84a..5f67e7a4d1cc 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -578,14 +578,12 @@ unsigned long hugetlb_get_unmapped_area(struct file
*file, unsigned long addr,
unsigned long vma_mmu_pagesize(struct vm_area_struct *vma)
{
-#ifdef CONFIG_PPC_MM_SLICES
/* With radix we don't use slice, so derive it from vma*/
- if (!radix_enabled()) {
+ if (IS_ENABLED(CONFIG_PPC_MM_SLICES) && !radix_enabled()) {
unsigned int psize = get_slice_psize(vma->vm_mm, vma->vm_start);
return 1UL << mmu_psize_to_shift(psize);
}
-#endif
return vma_kernel_pagesize(vma);
}
--
2.13.3
[PATCH v2 10/11] powerpc/mm: define subarch SLB_ADDR_LIMIT_DEFAULT
This patch defines a subarch specific SLB_ADDR_LIMIT_DEFAULT
to remove the #ifdefs around the setup of mm->context.slb_addr_limit
It also generalises the use of mm_ctx_set_slb_addr_limit() helper.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/slice.h | 2 ++
arch/powerpc/include/asm/nohash/32/slice.h | 2 ++
arch/powerpc/mm/hash_utils_64.c| 2 +-
arch/powerpc/mm/slice.c| 6 +-
arch/powerpc/mm/tlb_nohash.c | 4 +---
5 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/slice.h
b/arch/powerpc/include/asm/book3s/64/slice.h
index 062e11136e9c..f0d3194ba41b 100644
--- a/arch/powerpc/include/asm/book3s/64/slice.h
+++ b/arch/powerpc/include/asm/book3s/64/slice.h
@@ -11,4 +11,6 @@
#define SLICE_NUM_HIGH (H_PGTABLE_RANGE >> SLICE_HIGH_SHIFT)
#define GET_HIGH_SLICE_INDEX(addr) ((addr) >> SLICE_HIGH_SHIFT)
+#define SLB_ADDR_LIMIT_DEFAULT DEFAULT_MAP_WINDOW_USER64
+
#endif /* _ASM_POWERPC_BOOK3S_64_SLICE_H */
diff --git a/arch/powerpc/include/asm/nohash/32/slice.h
b/arch/powerpc/include/asm/nohash/32/slice.h
index 777d62e40ac0..39eb0154ae2d 100644
--- a/arch/powerpc/include/asm/nohash/32/slice.h
+++ b/arch/powerpc/include/asm/nohash/32/slice.h
@@ -13,6 +13,8 @@
#define SLICE_NUM_HIGH 0ul
#define GET_HIGH_SLICE_INDEX(addr) (addr & 0)
+#define SLB_ADDR_LIMIT_DEFAULT DEFAULT_MAP_WINDOW
+
#endif /* CONFIG_PPC_MM_SLICES */
#endif /* _ASM_POWERPC_NOHASH_32_SLICE_H */
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f727197de713..884246e3bf0b 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1050,7 +1050,7 @@ void __init hash__early_init_mmu(void)
htab_initialize();
init_mm.context.hash_context = _hash_mm_context;
- init_mm.context.hash_context->slb_addr_limit =
DEFAULT_MAP_WINDOW_USER64;
+ mm_ctx_set_slb_addr_limit(_mm.context, SLB_ADDR_LIMIT_DEFAULT);
pr_info("Initializing hash mmu with SLB\n");
/* Initialize SLB management */
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index ace97d953040..97fbf7b54422 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -704,11 +704,7 @@ void slice_init_new_context_exec(struct mm_struct *mm)
* case of fork it is just inherited from the mm being
* duplicated.
*/
-#ifdef CONFIG_PPC64
- mm_ctx_set_slb_addr_limit(>context, DEFAULT_MAP_WINDOW_USER64);
-#else
- mm->context.slb_addr_limit = DEFAULT_MAP_WINDOW;
-#endif
+ mm_ctx_set_slb_addr_limit(>context, SLB_ADDR_LIMIT_DEFAULT);
mm_ctx_set_user_psize(>context, psize);
/*
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index 088e0a6b5ade..ba4bff11191f 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -802,9 +802,7 @@ void __init early_init_mmu(void)
#endif
#ifdef CONFIG_PPC_MM_SLICES
-#if defined(CONFIG_PPC_8xx)
- init_mm.context.slb_addr_limit = DEFAULT_MAP_WINDOW;
-#endif
+ mm_ctx_set_slb_addr_limit(_mm.context, SLB_ADDR_LIMIT_DEFAULT);
#endif
}
#endif /* CONFIG_PPC64 */
--
2.13.3
[PATCH v2 05/11] powerpc/mm: get rid of mm_ctx_slice_mask_xxx()
Now that slice_mask_for_size() is in mmu.h, the mm_ctx_slice_mask_xxx()
are not needed anymore, so drop them. Note that the 8xx ones where
not used anyway.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/mmu.h | 32
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 17 ---
2 files changed, 4 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
b/arch/powerpc/include/asm/book3s/64/mmu.h
index ad00355f874f..e3d7f1404e20 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -179,45 +179,21 @@ static inline void mm_ctx_set_slb_addr_limit(mm_context_t
*ctx, unsigned long li
ctx->hash_context->slb_addr_limit = limit;
}
-#ifdef CONFIG_PPC_64K_PAGES
-static inline struct slice_mask *mm_ctx_slice_mask_64k(mm_context_t *ctx)
-{
- return >hash_context->mask_64k;
-}
-#endif
-
-static inline struct slice_mask *mm_ctx_slice_mask_4k(mm_context_t *ctx)
-{
- return >hash_context->mask_4k;
-}
-
-#ifdef CONFIG_HUGETLB_PAGE
-static inline struct slice_mask *mm_ctx_slice_mask_16m(mm_context_t *ctx)
-{
- return >hash_context->mask_16m;
-}
-
-static inline struct slice_mask *mm_ctx_slice_mask_16g(mm_context_t *ctx)
-{
- return >hash_context->mask_16g;
-}
-#endif
-
static inline struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int
psize)
{
#ifdef CONFIG_PPC_64K_PAGES
if (psize == MMU_PAGE_64K)
- return mm_ctx_slice_mask_64k();
+ return >hash_context->mask_64k;
#endif
#ifdef CONFIG_HUGETLB_PAGE
if (psize == MMU_PAGE_16M)
- return mm_ctx_slice_mask_16m();
+ return >hash_context->mask_16m;
if (psize == MMU_PAGE_16G)
- return mm_ctx_slice_mask_16g();
+ return >hash_context->mask_16g;
#endif
VM_BUG_ON(psize != MMU_PAGE_4K);
- return mm_ctx_slice_mask_4k();
+ return >hash_context->mask_4k;
}
#ifdef CONFIG_PPC_SUBPAGE_PROT
diff --git a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
index a0f6844a1498..beded4df1f50 100644
--- a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
@@ -255,23 +255,6 @@ static inline void mm_ctx_set_slb_addr_limit(mm_context_t
*ctx, unsigned long li
ctx->slb_addr_limit = limit;
}
-static inline struct slice_mask *mm_ctx_slice_mask_base(mm_context_t *ctx)
-{
- return >mask_base_psize;
-}
-
-#ifdef CONFIG_HUGETLB_PAGE
-static inline struct slice_mask *mm_ctx_slice_mask_512k(mm_context_t *ctx)
-{
- return >mask_512k;
-}
-
-static inline struct slice_mask *mm_ctx_slice_mask_8m(mm_context_t *ctx)
-{
- return >mask_8m;
-}
-#endif
-
static inline struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int
psize)
{
#ifdef CONFIG_HUGETLB_PAGE
--
2.13.3
[PATCH v2 08/11] powerpc/8xx: get rid of #ifdef CONFIG_HUGETLB_PAGE for slices
The 8xx only selects CONFIG_PPC_MM_SLICES when CONFIG_HUGETLB_PAGE
is set.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 4
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
index beded4df1f50..0224fc7633b0 100644
--- a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
@@ -216,10 +216,8 @@ typedef struct {
unsigned char high_slices_psize[0];
unsigned long slb_addr_limit;
struct slice_mask mask_base_psize; /* 4k or 16k */
-# ifdef CONFIG_HUGETLB_PAGE
struct slice_mask mask_512k;
struct slice_mask mask_8m;
-# endif
#endif
void *pte_frag;
} mm_context_t;
@@ -257,12 +255,10 @@ static inline void mm_ctx_set_slb_addr_limit(mm_context_t
*ctx, unsigned long li
static inline struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int
psize)
{
-#ifdef CONFIG_HUGETLB_PAGE
if (psize == MMU_PAGE_512K)
return >mask_512k;
if (psize == MMU_PAGE_8M)
return >mask_8m;
-#endif
VM_BUG_ON(psize != mmu_virtual_psize);
return >mask_base_psize;
--
2.13.3
[PATCH v2 06/11] powerpc/mm: remove unnecessary #ifdef CONFIG_PPC64
For PPC32 that's a noop, gcc should be smart enough to ignore it. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/slice.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c index 31de91b65a64..840c4118a185 100644 --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -118,13 +118,11 @@ static int slice_high_has_vma(struct mm_struct *mm, unsigned long slice) unsigned long start = slice << SLICE_HIGH_SHIFT; unsigned long end = start + (1ul << SLICE_HIGH_SHIFT); -#ifdef CONFIG_PPC64 /* Hack, so that each addresses is controlled by exactly one * of the high or low area bitmaps, the first high area starts * at 4GB, not 0 */ if (start == 0) - start = SLICE_LOW_TOP; -#endif + start = (unsigned long)SLICE_LOW_TOP; return !slice_area_is_free(mm, start, end - start); } -- 2.13.3
[PATCH v2 02/11] powerpc/mm: no slice for nohash/64
Only nohash/32 and book3s/64 support mm slices.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/nohash/64/slice.h | 12
arch/powerpc/include/asm/slice.h | 4 +---
arch/powerpc/platforms/Kconfig.cputype | 4
3 files changed, 5 insertions(+), 15 deletions(-)
delete mode 100644 arch/powerpc/include/asm/nohash/64/slice.h
diff --git a/arch/powerpc/include/asm/nohash/64/slice.h
b/arch/powerpc/include/asm/nohash/64/slice.h
deleted file mode 100644
index ad0d6e3cc1c5..
--- a/arch/powerpc/include/asm/nohash/64/slice.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_POWERPC_NOHASH_64_SLICE_H
-#define _ASM_POWERPC_NOHASH_64_SLICE_H
-
-#ifdef CONFIG_PPC_64K_PAGES
-#define get_slice_psize(mm, addr) MMU_PAGE_64K
-#else /* CONFIG_PPC_64K_PAGES */
-#define get_slice_psize(mm, addr) MMU_PAGE_4K
-#endif /* !CONFIG_PPC_64K_PAGES */
-#define slice_set_user_psize(mm, psize)do { BUG(); } while (0)
-
-#endif /* _ASM_POWERPC_NOHASH_64_SLICE_H */
diff --git a/arch/powerpc/include/asm/slice.h b/arch/powerpc/include/asm/slice.h
index 44816cbc4198..be8af667098f 100644
--- a/arch/powerpc/include/asm/slice.h
+++ b/arch/powerpc/include/asm/slice.h
@@ -4,9 +4,7 @@
#ifdef CONFIG_PPC_BOOK3S_64
#include
-#elif defined(CONFIG_PPC64)
-#include
-#elif defined(CONFIG_PPC_MMU_NOHASH)
+#elif defined(CONFIG_PPC_MMU_NOHASH_32)
#include
#endif
diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index 00b2bb536c74..04915f51f447 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -391,6 +391,10 @@ config PPC_MMU_NOHASH
def_bool y
depends on !PPC_BOOK3S
+config PPC_MMU_NOHASH_32
+ def_bool y
+ depends on PPC_MMU_NOHASH && PPC32
+
config PPC_BOOK3E_MMU
def_bool y
depends on FSL_BOOKE || PPC_BOOK3E
--
2.13.3
[PATCH v2 01/11] powerpc/mm: fix erroneous duplicate slb_addr_limit init
Commit 67fda38f0d68 ("powerpc/mm: Move slb_addr_linit to
early_init_mmu") moved slb_addr_limit init out of setup_arch().
Commit 701101865f5d ("powerpc/mm: Reduce memory usage for mm_context_t
for radix") brought it back into setup_arch() by error.
This patch reverts that erroneous regress.
Fixes: 701101865f5d ("powerpc/mm: Reduce memory usage for mm_context_t for
radix")
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/setup-common.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 1729bf409562..7af085b38cd1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -950,12 +950,6 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_data = (unsigned long) _edata;
init_mm.brk = klimit;
-#ifdef CONFIG_PPC_MM_SLICES
-#if defined(CONFIG_PPC_8xx)
- init_mm.context.slb_addr_limit = DEFAULT_MAP_WINDOW;
-#endif
-#endif
-
#ifdef CONFIG_SPAPR_TCE_IOMMU
mm_iommu_init(_mm);
#endif
--
2.13.3
[PATCH v2 00/11] Reduce ifdef mess in slice.c
This series is a split out of the v1 series "Reduce ifdef mess in hugetlbpage.c and slice.c". It is also rebased after the series from Aneesh to reduce context size for Radix. See http://kisskb.ellerman.id.au/kisskb/branch/chleroy/head/f263887b4ca31f4bb0fe77823e301c28ba27c796/ for wide compilation. Christophe Leroy (11): powerpc/mm: fix erroneous duplicate slb_addr_limit init powerpc/mm: no slice for nohash/64 powerpc/mm: hand a context_t over to slice_mask_for_size() instead of mm_struct powerpc/mm: move slice_mask_for_size() into mmu.h powerpc/mm: get rid of mm_ctx_slice_mask_xxx() powerpc/mm: remove unnecessary #ifdef CONFIG_PPC64 powerpc/mm: remove a couple of #ifdef CONFIG_PPC_64K_PAGES in mm/slice.c powerpc/8xx: get rid of #ifdef CONFIG_HUGETLB_PAGE for slices powerpc/mm: define get_slice_psize() all the time powerpc/mm: define subarch SLB_ADDR_LIMIT_DEFAULT powerpc/mm: drop slice DEBUG arch/powerpc/include/asm/book3s/64/mmu.h | 29 +++--- arch/powerpc/include/asm/book3s/64/slice.h | 2 + arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 51 +-- arch/powerpc/include/asm/nohash/32/slice.h | 2 + arch/powerpc/include/asm/nohash/64/slice.h | 12 --- arch/powerpc/include/asm/slice.h | 9 +- arch/powerpc/kernel/setup-common.c | 6 -- arch/powerpc/mm/hash_utils_64.c | 2 +- arch/powerpc/mm/hugetlbpage.c| 4 +- arch/powerpc/mm/slice.c | 132 --- arch/powerpc/mm/tlb_nohash.c | 4 +- arch/powerpc/platforms/Kconfig.cputype | 4 + 12 files changed, 69 insertions(+), 188 deletions(-) delete mode 100644 arch/powerpc/include/asm/nohash/64/slice.h -- 2.13.3
[PATCH v2 03/11] powerpc/mm: hand a context_t over to slice_mask_for_size() instead of mm_struct
slice_mask_for_size() only uses mm->context, so hand directly a
pointer to the context. This will help moving the function in
subarch mmu.h in the next patch by avoiding having to include
the definition of struct mm_struct
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/slice.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 35b278082391..8eb7e8b09c75 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -151,32 +151,32 @@ static void slice_mask_for_free(struct mm_struct *mm,
struct slice_mask *ret,
}
#ifdef CONFIG_PPC_BOOK3S_64
-static struct slice_mask *slice_mask_for_size(struct mm_struct *mm, int psize)
+static struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int psize)
{
#ifdef CONFIG_PPC_64K_PAGES
if (psize == MMU_PAGE_64K)
- return mm_ctx_slice_mask_64k(>context);
+ return mm_ctx_slice_mask_64k();
#endif
if (psize == MMU_PAGE_4K)
- return mm_ctx_slice_mask_4k(>context);
+ return mm_ctx_slice_mask_4k();
#ifdef CONFIG_HUGETLB_PAGE
if (psize == MMU_PAGE_16M)
- return mm_ctx_slice_mask_16m(>context);
+ return mm_ctx_slice_mask_16m();
if (psize == MMU_PAGE_16G)
- return mm_ctx_slice_mask_16g(>context);
+ return mm_ctx_slice_mask_16g();
#endif
BUG();
}
#elif defined(CONFIG_PPC_8xx)
-static struct slice_mask *slice_mask_for_size(struct mm_struct *mm, int psize)
+static struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int psize)
{
if (psize == mmu_virtual_psize)
- return >context.mask_base_psize;
+ return >mask_base_psize;
#ifdef CONFIG_HUGETLB_PAGE
if (psize == MMU_PAGE_512K)
- return >context.mask_512k;
+ return >mask_512k;
if (psize == MMU_PAGE_8M)
- return >context.mask_8m;
+ return >mask_8m;
#endif
BUG();
}
@@ -246,7 +246,7 @@ static void slice_convert(struct mm_struct *mm,
slice_dbg("slice_convert(mm=%p, psize=%d)\n", mm, psize);
slice_print_mask(" mask", mask);
- psize_mask = slice_mask_for_size(mm, psize);
+ psize_mask = slice_mask_for_size(>context, psize);
/* We need to use a spinlock here to protect against
* concurrent 64k -> 4k demotion ...
@@ -263,7 +263,7 @@ static void slice_convert(struct mm_struct *mm,
/* Update the slice_mask */
old_psize = (lpsizes[index] >> (mask_index * 4)) & 0xf;
- old_mask = slice_mask_for_size(mm, old_psize);
+ old_mask = slice_mask_for_size(>context, old_psize);
old_mask->low_slices &= ~(1u << i);
psize_mask->low_slices |= 1u << i;
@@ -282,7 +282,7 @@ static void slice_convert(struct mm_struct *mm,
/* Update the slice_mask */
old_psize = (hpsizes[index] >> (mask_index * 4)) & 0xf;
- old_mask = slice_mask_for_size(mm, old_psize);
+ old_mask = slice_mask_for_size(>context, old_psize);
__clear_bit(i, old_mask->high_slices);
__set_bit(i, psize_mask->high_slices);
@@ -538,7 +538,7 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
/* First make up a "good" mask of slices that have the right size
* already
*/
- maskp = slice_mask_for_size(mm, psize);
+ maskp = slice_mask_for_size(>context, psize);
/*
* Here "good" means slices that are already the right page size,
@@ -565,7 +565,7 @@ unsigned long slice_get_unmapped_area(unsigned long addr,
unsigned long len,
* a pointer to good mask for the next code to use.
*/
if (IS_ENABLED(CONFIG_PPC_64K_PAGES) && psize == MMU_PAGE_64K) {
- compat_maskp = slice_mask_for_size(mm, MMU_PAGE_4K);
+ compat_maskp = slice_mask_for_size(>context, MMU_PAGE_4K);
if (fixed)
slice_or_mask(_mask, maskp, compat_maskp);
else
@@ -760,7 +760,7 @@ void slice_init_new_context_exec(struct mm_struct *mm)
/*
* Slice mask cache starts zeroed, fill the default size cache.
*/
- mask = slice_mask_for_size(mm, psize);
+ mask = slice_mask_for_size(>context, psize);
mask->low_slices = ~0UL;
if (SLICE_NUM_HIGH)
bitmap_fill(mask->high_slices, SLICE_NUM_HIGH);
@@ -819,14 +819,14 @@ int slice_is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,
VM_BUG_ON(radix_enabled());
- maskp = slice_mask_for_size(mm, psize);
+ maskp = slice_mask_for_size(>context, psize);
#ifdef CONFIG_PPC_64K_PAGES
/* We need to account for 4k slices too */
if (psize == MMU_PAGE_64K) {
const
[PATCH v2 04/11] powerpc/mm: move slice_mask_for_size() into mmu.h
Move slice_mask_for_size() into subarch mmu.h
At the same time, replace BUG() by VM_BUG_ON() as those BUG() are not
there to catch runtime errors but to catch errors during development
cycle only.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/book3s/64/mmu.h | 17 +++
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 42 +++-
arch/powerpc/mm/slice.c | 34 --
3 files changed, 46 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h
b/arch/powerpc/include/asm/book3s/64/mmu.h
index 230a9dec7677..ad00355f874f 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -203,6 +203,23 @@ static inline struct slice_mask
*mm_ctx_slice_mask_16g(mm_context_t *ctx)
}
#endif
+static inline struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int
psize)
+{
+#ifdef CONFIG_PPC_64K_PAGES
+ if (psize == MMU_PAGE_64K)
+ return mm_ctx_slice_mask_64k();
+#endif
+#ifdef CONFIG_HUGETLB_PAGE
+ if (psize == MMU_PAGE_16M)
+ return mm_ctx_slice_mask_16m();
+ if (psize == MMU_PAGE_16G)
+ return mm_ctx_slice_mask_16g();
+#endif
+ VM_BUG_ON(psize != MMU_PAGE_4K);
+
+ return mm_ctx_slice_mask_4k();
+}
+
#ifdef CONFIG_PPC_SUBPAGE_PROT
static inline struct subpage_prot_table *mm_ctx_subpage_prot(mm_context_t *ctx)
{
diff --git a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
index c503e2f05e61..a0f6844a1498 100644
--- a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
@@ -184,7 +184,23 @@
#define LOW_SLICE_ARRAY_SZ SLICE_ARRAY_SIZE
#endif
+#if defined(CONFIG_PPC_4K_PAGES)
+#define mmu_virtual_psize MMU_PAGE_4K
+#elif defined(CONFIG_PPC_16K_PAGES)
+#define mmu_virtual_psize MMU_PAGE_16K
+#define PTE_FRAG_NR4
+#define PTE_FRAG_SIZE_SHIFT12
+#define PTE_FRAG_SIZE (1UL << 12)
+#else
+#error "Unsupported PAGE_SIZE"
+#endif
+
+#define mmu_linear_psize MMU_PAGE_8M
+
#ifndef __ASSEMBLY__
+
+#include
+
struct slice_mask {
u64 low_slices;
DECLARE_BITMAP(high_slices, 0);
@@ -255,6 +271,19 @@ static inline struct slice_mask
*mm_ctx_slice_mask_8m(mm_context_t *ctx)
return >mask_8m;
}
#endif
+
+static inline struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int
psize)
+{
+#ifdef CONFIG_HUGETLB_PAGE
+ if (psize == MMU_PAGE_512K)
+ return >mask_512k;
+ if (psize == MMU_PAGE_8M)
+ return >mask_8m;
+#endif
+ VM_BUG_ON(psize != mmu_virtual_psize);
+
+ return >mask_base_psize;
+}
#endif /* CONFIG_PPC_MM_SLICE */
#define PHYS_IMMR_BASE (mfspr(SPRN_IMMR) & 0xfff8)
@@ -306,17 +335,4 @@ extern s32 patch__itlbmiss_perf, patch__dtlbmiss_perf;
#endif /* !__ASSEMBLY__ */
-#if defined(CONFIG_PPC_4K_PAGES)
-#define mmu_virtual_psize MMU_PAGE_4K
-#elif defined(CONFIG_PPC_16K_PAGES)
-#define mmu_virtual_psize MMU_PAGE_16K
-#define PTE_FRAG_NR4
-#define PTE_FRAG_SIZE_SHIFT12
-#define PTE_FRAG_SIZE (1UL << 12)
-#else
-#error "Unsupported PAGE_SIZE"
-#endif
-
-#define mmu_linear_psize MMU_PAGE_8M
-
#endif /* _ASM_POWERPC_MMU_8XX_H_ */
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index 8eb7e8b09c75..31de91b65a64 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -150,40 +150,6 @@ static void slice_mask_for_free(struct mm_struct *mm,
struct slice_mask *ret,
__set_bit(i, ret->high_slices);
}
-#ifdef CONFIG_PPC_BOOK3S_64
-static struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int psize)
-{
-#ifdef CONFIG_PPC_64K_PAGES
- if (psize == MMU_PAGE_64K)
- return mm_ctx_slice_mask_64k();
-#endif
- if (psize == MMU_PAGE_4K)
- return mm_ctx_slice_mask_4k();
-#ifdef CONFIG_HUGETLB_PAGE
- if (psize == MMU_PAGE_16M)
- return mm_ctx_slice_mask_16m();
- if (psize == MMU_PAGE_16G)
- return mm_ctx_slice_mask_16g();
-#endif
- BUG();
-}
-#elif defined(CONFIG_PPC_8xx)
-static struct slice_mask *slice_mask_for_size(mm_context_t *ctx, int psize)
-{
- if (psize == mmu_virtual_psize)
- return >mask_base_psize;
-#ifdef CONFIG_HUGETLB_PAGE
- if (psize == MMU_PAGE_512K)
- return >mask_512k;
- if (psize == MMU_PAGE_8M)
- return >mask_8m;
-#endif
- BUG();
-}
-#else
-#error "Must define the slice masks for page sizes supported by the platform"
-#endif
-
static bool slice_check_range_fits(struct mm_struct *mm,
const struct slice_mask *available,
unsigned long start, unsigned long len)
--
2.13.3
Re: [PATCH v2 0/5] Allow CPU0 to be nohz full
On Thu, Apr 11, 2019 at 01:34:43PM +1000, Nicholas Piggin wrote: > Since last time, I added a compile time option to opt-out of this > if the platform does not support suspend on non-zero, and tried to > improve legibility of changelogs and explain the justification > better. > > I have been testing this on powerpc/pseries and it seems to work > fine (the firmware call to suspend can be called on any CPU and > resumes where it left off), but not included here because the > code has some bitrot unrelated to this series which I hacked to > fix. I will discuss it and either send an acked patch to go with > this series if it is small, or fix it in powerpc tree. > Rafael, Frederic, any comments?
Re: [PATCH v2 3/5] kernel/cpu: Allow non-zero CPU to be primary for suspend / kexec freeze
On Thu, Apr 11, 2019 at 01:34:46PM +1000, Nicholas Piggin wrote: > This patch provides an arch option, ARCH_SUSPEND_NONZERO_CPU, to > opt-in to allowing suspend to occur on one of the housekeeping CPUs > rather than hardcoded CPU0. > > This will allow CPU0 to be a nohz_full CPU with a later change. > > It may be possible for platforms with hardware/firmware restrictions > on suspend/wake effectively support this by handing off the final > stage to CPU0 when kernel housekeeping is no longer required. Another > option is to make housekeeping / nohz_full mask dynamic at runtime, > but the complexity could not be justified at this time. Should we not tie this into whatever already allows an achitecture to hotplug CPU-0? For instance, x86 default disallows this but has cpu0_hotpluggable to allow this. Presumably POWER already allows hotplugging CPU-0 ?
Re: [PATCH v5 00/23] Include linux ACPI docs into Sphinx TOC tree
.On Wed, Apr 24, 2019 at 7:54 PM Changbin Du wrote: > > Hi 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. > > 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/ I'd like to queue up this series, but it is missing a patch to create Documentation/firmware-guide/acpi/index.rst. Care to provide one?
Re: [PATCHv2] kernel/crash: make parse_crashkernel()'s return value more indicant
On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote:
>
>
[...]
> > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char
> > *cmdline,
> > pr_warn("crashkernel: unrecognized char: %c\n", *cur);
> > return -EINVAL;
> > }
> > + if (*crash_size == 0)
> > + return -EINVAL;
>
> This covers the case where I pass an argument like "crashkernel=0M" ?
> Can't we fix that by using kstrtoull() in memparse and check if the return
> value
> is < 0? In that case we could return without updating the retptr and we will
> be
> fine.
>
It seems that kstrtoull() treats 0M as invalid parameter, while
simple_strtoull() does not.
If changed like your suggestion, then all the callers of memparse()
will treats 0M as invalid parameter. This affects many components
besides kexec. Not sure this can be done or not.
Regards,
Pingfan
> >
> > return 0;
> > }
> > @@ -181,6 +185,8 @@ static int __init parse_crashkernel_suffix(char
> > *cmdline,
> > pr_warn("crashkernel: unrecognized char: %c\n", *cur);
> > return -EINVAL;
> > }
> > + if (*crash_size == 0)
> > + return -EINVAL;
>
> Same here.
>
> >
> > return 0;
> > }
> > @@ -266,6 +272,8 @@ static int __init __parse_crashkernel(char *cmdline,
> > /*
> > * That function is the entry point for command line parsing and should be
> > * called from the arch-specific code.
> > + * On success 0. On error for either syntax error or crash_size=0, -EINVAL
> > is
> > + * returned.
> > */
> > int __init parse_crashkernel(char *cmdline,
> >unsigned long long system_ram,
> >
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On Wed 24-04-19 11:13:48, Dan Williams wrote: > On Wed, Apr 24, 2019 at 10:38 AM Matthew Wilcox wrote: > > > > On Wed, Apr 24, 2019 at 10:13:15AM -0700, Dan Williams wrote: > > > I think unaligned addresses have always been passed to > > > vmf_insert_pfn_pmd(), but nothing cared until this patch. I *think* > > > the only change needed is the following, thoughts? > > > > > > diff --git a/fs/dax.c b/fs/dax.c > > > index ca0671d55aa6..82aee9a87efa 100644 > > > --- a/fs/dax.c > > > +++ b/fs/dax.c > > > @@ -1560,7 +1560,7 @@ static vm_fault_t dax_iomap_pmd_fault(struct > > > vm_fault *vmf, pfn_t *pfnp, > > > } > > > > > > trace_dax_pmd_insert_mapping(inode, vmf, PMD_SIZE, pfn, > > > entry); > > > - result = vmf_insert_pfn_pmd(vma, vmf->address, vmf->pmd, > > > pfn, > > > + result = vmf_insert_pfn_pmd(vma, pmd_addr, vmf->pmd, pfn, > > > write); > > > > We also call vmf_insert_pfn_pmd() in dax_insert_pfn_mkwrite() -- does > > that need to change too? > > It wasn't clear to me that it was a problem. I think that one already > happens to be pmd-aligned. Why would it need to be? The address is taken from vmf->address and that's set up in __handle_mm_fault() like .address = address & PAGE_MASK. So I don't see anything forcing PMD alignment of the virtual address... Honza -- Jan Kara SUSE Labs, CR
Re: powerpc hugepage leak caused by 576ed913 "block: use bio_add_page in bio_iov_iter_get_pages"
Just curious: What exact trees do you see this with? This area changed a lot with the multipage bvec support, and subsequent fixes. So I'd be really curious if it can be reproduced with Jens' latest block for-5.2 tree (which should be in latest linux-next).
