Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On Wed, Apr 24, 2019 at 6:37 PM Aneesh Kumar K.V wrote: > > On 4/24/19 11:43 PM, 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. > > > > How about vmf_insert_pfn_pud()? That is currently not used by fsdax, only devdax, but it does seem that it passes the unaligned fault address rather than the pud aligned address. I'll add that to the proposed fix.
Re: [PATCH 5/6] powerpc/mmu: drop mmap_sem now that locked_vm is atomic
On Wed, Apr 24, 2019 at 11:10:24AM +, Jason Gunthorpe wrote: > On Tue, Apr 23, 2019 at 07:15:44PM -0700, Davidlohr Bueso wrote: > > Wouldn't the cmpxchg alternative also be exposed the locked_vm changing > > between > > validating the new value and the cmpxchg() and we'd bogusly fail even when > > there > > is still just because the value changed (I'm assuming we don't hold any > > locks, > > otherwise all this is pointless). That's true, I hadn't considered that we could retry even when there's enough locked_vm. Seems like another one is that RLIMIT_MEMLOCK could change after it's read. I guess nothing's going to be perfect. :/ > Well it needs a loop.. > > again: >current_locked = atomic_read(>locked_vm); >new_locked = current_locked + npages; >if (new_locked < lock_limit) > if (cmpxchg(>locked_vm, current_locked, new_locked) != > current_locked) > goto again; > > So it won't have bogus failures as there is no unwind after > error. Basically this is a load locked/store conditional style of > locking pattern. This is basically what I have so far. > > > That's a good idea, and especially worth doing considering that an > > > arbitrary > > > number of threads that charge a low amount of locked_vm can fail just > > > because > > > one thread charges lots of it. > > > > Yeah but the window for this is quite small, I doubt it would be a real > > issue. > > > What if before doing the atomic_add_return(), we first did the racy > > new_locked > > check for ENOMEM, then do the speculative add and cleanup, if necessary. > > This > > would further reduce the scope of the window where false ENOMEM can occur. So the upside of this is that there's no retry loop so tasks don't spin under heavy contention? Seems better to always guard against false ENOMEM, at least from the locked_vm side if not from the rlimit changing. > > > pinned_vm appears to be broken the same way, so I can fix it too unless > > > someone > > > beats me to it. > > > > This should not be a surprise for the rdma folks. Cc'ing Jason nonetheless. > > I think we accepted this tiny race as a side effect of removing the > lock, which was very beneficial. Really the time window between the > atomic failing and unwind is very small, and there are enough other > ways a hostile user could DOS locked_vm that I don't think it really > matters in practice.. > > However, the cmpxchg seems better, so a helper to implement that would > probably be the best thing to do. I've collapsed all the locked_vm users into such a helper and am now working on converting the pinned_vm users to the same helper. Taking longer than I thought.
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On 4/24/19 11:43 PM, 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. How about vmf_insert_pfn_pud()? -aneesh
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Wed, Apr 24, 2019 at 10:01:56PM -0300, Thiago Jung Bauermann wrote: > > Michael S. Tsirkin writes: > > > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: > >> > >> Michael S. Tsirkin writes: > >> > >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: > >> >> > >> >> Michael S. Tsirkin writes: > >> >> > >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: > >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host > >> >> >> >will > >> >> >> only ever try to access memory addresses that are supplied to it by > >> >> >> the > >> >> >> guest, so all of the secure guest memory that the host cares about is > >> >> >> accessible: > >> >> >> > >> >> >> If this feature bit is set to 0, then the device has same access > >> >> >> to > >> >> >> memory addresses supplied to it as the driver has. In particular, > >> >> >> the device will always use physical addresses matching addresses > >> >> >> used by the driver (typically meaning physical addresses used by > >> >> >> the > >> >> >> CPU) and not translated further, and can access any address > >> >> >> supplied > >> >> >> to it by the driver. When clear, this overrides any > >> >> >> platform-specific description of whether device access is > >> >> >> limited or > >> >> >> translated in any way, e.g. whether an IOMMU may be present. > >> >> >> > >> >> >> All of the above is true for POWER guests, whether they are secure > >> >> >> guests or not. > >> >> >> > >> >> >> Or are you saying that a virtio device may want to access memory > >> >> >> addresses that weren't supplied to it by the driver? > >> >> > > >> >> > Your logic would apply to IOMMUs as well. For your mode, there are > >> >> > specific encrypted memory regions that driver has access to but device > >> >> > does not. that seems to violate the constraint. > >> >> > >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that > >> >> the device can ignore the IOMMU for all practical purposes I would > >> >> indeed say that the logic would apply to IOMMUs as well. :-) > >> >> > >> >> I guess I'm still struggling with the purpose of signalling to the > >> >> driver that the host may not have access to memory addresses that it > >> >> will never try to access. > >> > > >> > For example, one of the benefits is to signal to host that driver does > >> > not expect ability to access all memory. If it does, host can > >> > fail initialization gracefully. > >> > >> But why would the ability to access all memory be necessary or even > >> useful? When would the host access memory that the driver didn't tell it > >> to access? > > > > When I say all memory I mean even memory not allowed by the IOMMU. > > Yes, but why? How is that memory relevant? It's relevant when driver is not trusted to only supply correct addresses. The feature was originally designed to support userspace drivers within guests. > >> >> >> >> > But the name "sev_active" makes me scared because at least AMD > >> >> >> >> > guys who > >> >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM > >> >> >> >> > >> >> >> >> My understanding is, AMD guest-platform knows in advance that > >> >> >> >> their > >> >> >> >> guest will run in secure mode and hence sets the flag at the time > >> >> >> >> of VM > >> >> >> >> instantiation. Unfortunately we dont have that luxury on our > >> >> >> >> platforms. > >> >> >> > > >> >> >> > Well you do have that luxury. It looks like that there are existing > >> >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not > >> >> >> > happy > >> >> >> > with how that path is slow. So you are trying to optimize for > >> >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability > >> >> >> > to invoke DMA API. > >> >> >> > > >> >> >> > For example if there was another flag just like ACCESS_PLATFORM > >> >> >> > just not yet used by anyone, you would be all fine using that > >> >> >> > right? > >> >> >> > >> >> >> Yes, a new flag sounds like a great idea. What about the definition > >> >> >> below? > >> >> >> > >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning > >> >> >> as > >> >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the > >> >> >> exception that the IOMMU is explicitly defined to be off or > >> >> >> bypassed > >> >> >> when accessing memory addresses supplied to the device by the > >> >> >> driver. This flag should be set by the guest if offered, but to > >> >> >> allow for backward-compatibility device implementations allow > >> >> >> for it > >> >> >> to be left unset by the guest. It is an error to set both this > >> >> >> flag > >> >> >> and VIRTIO_F_ACCESS_PLATFORM. > >> >> > > >> >> > It looks kind of narrow but it's an option. > >> >> > >> >> Great! > >> >> > >> >> > I wonder how we'll define what's an iommu though. > >> >> > >> >>
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
Michael S. Tsirkin writes: > On Wed, Apr 17, 2019 at 06:42:00PM -0300, Thiago Jung Bauermann wrote: >> >> Michael S. Tsirkin writes: >> >> > On Thu, Mar 21, 2019 at 09:05:04PM -0300, Thiago Jung Bauermann wrote: >> >> >> >> Michael S. Tsirkin writes: >> >> >> >> > On Wed, Mar 20, 2019 at 01:13:41PM -0300, Thiago Jung Bauermann wrote: >> >> >> >From what I understand of the ACCESS_PLATFORM definition, the host >> >> >> >will >> >> >> only ever try to access memory addresses that are supplied to it by the >> >> >> guest, so all of the secure guest memory that the host cares about is >> >> >> accessible: >> >> >> >> >> >> If this feature bit is set to 0, then the device has same access to >> >> >> memory addresses supplied to it as the driver has. In particular, >> >> >> the device will always use physical addresses matching addresses >> >> >> used by the driver (typically meaning physical addresses used by >> >> >> the >> >> >> CPU) and not translated further, and can access any address >> >> >> supplied >> >> >> to it by the driver. When clear, this overrides any >> >> >> platform-specific description of whether device access is limited >> >> >> or >> >> >> translated in any way, e.g. whether an IOMMU may be present. >> >> >> >> >> >> All of the above is true for POWER guests, whether they are secure >> >> >> guests or not. >> >> >> >> >> >> Or are you saying that a virtio device may want to access memory >> >> >> addresses that weren't supplied to it by the driver? >> >> > >> >> > Your logic would apply to IOMMUs as well. For your mode, there are >> >> > specific encrypted memory regions that driver has access to but device >> >> > does not. that seems to violate the constraint. >> >> >> >> Right, if there's a pre-configured 1:1 mapping in the IOMMU such that >> >> the device can ignore the IOMMU for all practical purposes I would >> >> indeed say that the logic would apply to IOMMUs as well. :-) >> >> >> >> I guess I'm still struggling with the purpose of signalling to the >> >> driver that the host may not have access to memory addresses that it >> >> will never try to access. >> > >> > For example, one of the benefits is to signal to host that driver does >> > not expect ability to access all memory. If it does, host can >> > fail initialization gracefully. >> >> But why would the ability to access all memory be necessary or even >> useful? When would the host access memory that the driver didn't tell it >> to access? > > When I say all memory I mean even memory not allowed by the IOMMU. Yes, but why? How is that memory relevant? >> >> >> >> > But the name "sev_active" makes me scared because at least AMD >> >> >> >> > guys who >> >> >> >> > were doing the sensible thing and setting ACCESS_PLATFORM >> >> >> >> >> >> >> >> My understanding is, AMD guest-platform knows in advance that their >> >> >> >> guest will run in secure mode and hence sets the flag at the time >> >> >> >> of VM >> >> >> >> instantiation. Unfortunately we dont have that luxury on our >> >> >> >> platforms. >> >> >> > >> >> >> > Well you do have that luxury. It looks like that there are existing >> >> >> > guests that already acknowledge ACCESS_PLATFORM and you are not happy >> >> >> > with how that path is slow. So you are trying to optimize for >> >> >> > them by clearing ACCESS_PLATFORM and then you have lost ability >> >> >> > to invoke DMA API. >> >> >> > >> >> >> > For example if there was another flag just like ACCESS_PLATFORM >> >> >> > just not yet used by anyone, you would be all fine using that right? >> >> >> >> >> >> Yes, a new flag sounds like a great idea. What about the definition >> >> >> below? >> >> >> >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_IOMMU This feature has the same meaning as >> >> >> VIRTIO_F_ACCESS_PLATFORM both when set and when not set, with the >> >> >> exception that the IOMMU is explicitly defined to be off or >> >> >> bypassed >> >> >> when accessing memory addresses supplied to the device by the >> >> >> driver. This flag should be set by the guest if offered, but to >> >> >> allow for backward-compatibility device implementations allow for >> >> >> it >> >> >> to be left unset by the guest. It is an error to set both this flag >> >> >> and VIRTIO_F_ACCESS_PLATFORM. >> >> > >> >> > It looks kind of narrow but it's an option. >> >> >> >> Great! >> >> >> >> > I wonder how we'll define what's an iommu though. >> >> >> >> Hm, it didn't occur to me it could be an issue. I'll try. >> >> I rephrased it in terms of address translation. What do you think of >> this version? The flag name is slightly different too: >> >> >> VIRTIO_F_ACCESS_PLATFORM_NO_TRANSLATION This feature has the same >> meaning as VIRTIO_F_ACCESS_PLATFORM both when set and when not set, >> with the exception that address translation is guaranteed to be >> unnecessary when accessing memory addresses supplied to the device >> by the driver. Which
Re: [PATCH v5 20/23] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
On Wed, Apr 24, 2019 at 03:12:36PM -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 25 Apr 2019 01:53:03 +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
> > ---
> > .../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
>
> Yeah, there it is: you're removing those two lines.
>
They are indented, see below diffs. I did remove "-" two lines.
> > +Some of the CPPC registers are exposed via sysfs under::
> >
> > -
> > + /sys/devices/system/cpu/cpuX/acpi_cppc/
>
> As per my reply to v4.
>
> Thanks,
> Mauro
--
Cheers,
Changbin Du
Re: [PATCH v5 23/23] Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 01:53:06 +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/firmware-guide/acpi/index.rst | 1 +
> .../acpi/video_extension.rst} | 83 +++
> 2 files changed, 50 insertions(+), 34 deletions(-)
> rename Documentation/{acpi/video_extension.txt =>
> firmware-guide/acpi/video_extension.rst} (70%)
>
> 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 70%
> rename from Documentation/acpi/video_extension.txt
> rename to Documentation/firmware-guide/acpi/video_extension.rst
> index 79bf6a4921be..099b8607e07b 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,10 @@ 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 does 3 things regarding backlight control.
Hmm... didn't notice this change before... The way it is, this
sentence sounds incomplete, specially since you removed the
numbering from the paragraphs. Perhaps you could, instead, be
explicit about what the video driver does, e. g.:
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:
@ACPI maintainers:
Please check if the above properly summarizes the activity done
with regards to backlight control.
If you agree with that, feel free to add:
Reviewed-by: Mauro Carvalho Chehab
>
> -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 +26,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
> + })
>
Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option
On Wed, 24 Apr 2019, Will Deacon wrote: > Hi Thomas, > > On Tue, Apr 16, 2019 at 09:26:13PM +0200, Thomas Gleixner wrote: > > On Fri, 12 Apr 2019, Josh Poimboeuf wrote: > > > > > Configure arm64 runtime CPU speculation bug mitigations in accordance > > > with the 'mitigations=' cmdline option. This affects Meltdown, Spectre > > > v2, and Speculative Store Bypass. > > > > > > The default behavior is unchanged. > > > > > > Signed-off-by: Josh Poimboeuf > > > --- > > > NOTE: This is based on top of Jeremy Linton's patches: > > > > > > https://lkml.kernel.org/r/20190410231237.52506-1-jeremy.lin...@arm.com > > > > So I keep that out and we have to revisit that once the ARM64 stuff hits a > > tree, right? I can have a branch with just the 4 first patches applied > > which ARM64 folks can pull in when they apply Jeremy's patches before te > > merge window. > > I'm assuming that this refers to the core/speculation branch in tip: > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=core/speculation > > but please can you confirm that I'm good to pull that into arm64? Yes. It's all yours :) Thanks, tglx
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
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.
Re: [PATCH v5 20/23] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 01:53:03 +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
> ---
> .../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
Yeah, there it is: you're removing those two lines.
> +Some of the CPPC registers are exposed via sysfs under::
>
> -
> + /sys/devices/system/cpu/cpuX/acpi_cppc/
As per my reply to v4.
Thanks,
Mauro
Re: [PATCH v5 14/23] Documentation: ACPI: move dsd/data-node-references.txt to firmware-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 01:52:57 +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
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
Thanks,
Mauro
Re: [PATCH v5 08/23] Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 01:52:51 +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
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
Re: [PATCH v4 21/63] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 01:22:34 +0800
Changbin Du escreveu:
> On Wed, Apr 24, 2019 at 11:48:44AM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 24 Apr 2019 00:28:50 +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
> > > ---
> > > .../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
> >
> > Hmm... removed by mistake?
> >
> I comfirmed that no content removed.
At this patch, it looks that you removed the line: "for each cpu X"
(or am I reading it wrong?)
>
> > > +Some of the CPPC registers are exposed via sysfs under::
> > >
> > > -
> > > + /sys/devices/system/cpu/cpuX/acpi_cppc/
> >
> > Did you parse this with Sphinx? It doesn't sound a valid ReST construction
> > to my eyes, as:
> >
> > 1) I've seen some versions of Sphinx to abort with severe errors when
> >there's no blank line after the horizontal bar markup;
> >
> > 2) It will very likely ignore the "::" (I didn't test it myself), as you're
> >not indenting the horizontal bar. End of indentation will mean the end
> >of an (empty) literal block.
> >
> > So, I would stick with:
> >
> >
> > Some of the CPPC registers are exposed via sysfs under:
> >
> > /sys/devices/system/cpu/cpuX/acpi_cppc/
> >
> >
> > -
> >
> > for each cpu X::
> >
> >
> > or:
> >
> > Some of the CPPC registers are exposed via sysfs under:
> >
> > /sys/devices/system/cpu/cpuX/acpi_cppc/
> >
> > for each cpu X
> >
> >
> >
> >
> > ::
> >
> > (with is closer to the original author's intent)
> >
> > Same applies to the other similar changes on this document.
> >
> I didn't seen any warning here and the generated html is good. So I think it
> is
> ok.
Basically, what you're doing is:
::
foo
literal-block bar
(where "foo" is the horizontal bar markup)
I would avoid such pattern for two reasons:
1) it sounds a violation of ReST syntax to format an in
indented paragraph some non-blank lines after a non-indented
line. As such, I won't doubt that different versions of Sphinx
would handle it differently. I'm even tempted to open a BZ
to Sphinx in order for them to provide a fix for that, if the
latest version of Sphinx accepts such crazy markup.
2) It is very confusing for any human reading it.
Thanks,
Mauro
Re: [PATCH v12 00/31] Speculative page faults
Le 22/04/2019 à 23:29, Michel Lespinasse a écrit : Hi Laurent, Thanks a lot for copying me on this patchset. It took me a few days to go through it - I had not been following the previous iterations of this series so I had to catch up. I will be sending comments for individual commits, but before tat I would like to discuss the series as a whole. Hi Michel, Thanks for reviewing this series. I think these changes are a big step in the right direction. My main reservation about them is that they are additive - adding some complexity for speculative page faults - and I wonder if it'd be possible, over the long term, to replace the existing complexity we have in mmap_sem retry mechanisms instead of adding to it. This is not something that should block your progress, but I think it would be good, as we introduce spf, to evaluate whether we could eventually get all the way to removing the mmap_sem retry mechanism, or if we will actually have to keep both. Until we get rid of the mmap_sem which seems to be a very long story, I can't see how we could get rid of the retry mechanism. The proposed spf mechanism only handles anon vmas. Is there a fundamental reason why it couldn't handle mapped files too ? My understanding is that the mechanism of verifying the vma after taking back the ptl at the end of the fault would work there too ? The file has to stay referenced during the fault, but holding the vma's refcount could be made to cover that ? the vm_file refcount would have to be released in __free_vma() instead of remove_vma; I'm not quite sure if that has more implications than I realize ? The only concern is the flow of operation done in the vm_ops->fault() processing. Most of the file system relie on the generic filemap_fault() which should be safe to use. But we need a clever way to identify fault processing which are compatible with the SPF handler. This could be done using a tag/flag in the vm_ops structure or in the vma's flags. This would be the next step. The proposed spf mechanism only works at the pte level after the page tables have already been created. The non-spf page fault path takes the mm->page_table_lock to protect against concurrent page table allocation by multiple page faults; I think unmapping/freeing page tables could be done under mm->page_table_lock too so that spf could implement allocating new page tables by verifying the vma after taking the mm->page_table_lock ? I've to admit that I didn't dig further here. Do you have a patch? ;) The proposed spf mechanism depends on ARCH_HAS_PTE_SPECIAL. I am not sure what is the issue there - is this due to the vma->vm_start and vma->vm_pgoff reads in *__vm_normal_page() ? Yes that's the reason, no way to guarantee the value of these fields in the SPF path. My last potential concern is about performance. The numbers you have look great, but I worry about potential regressions in PF performance for threaded processes that don't currently encounter contention (i.e. there may be just one thread actually doing all the work while the others are blocked). I think one good proxy for measuring that would be to measure a single threaded workload - kernbench would be fine - without the special-case optimization in patch 22 where handle_speculative_fault() immediately aborts in the single-threaded case. I'll have to give it a try. Reviewed-by: Michel Lespinasse This is for the series as a whole; I expect to do another review pass on individual commits in the series when we have agreement on the toplevel stuff (I noticed a few things like out-of-date commit messages but that's really minor stuff). Thanks a lot for reviewing this long series. I want to add a note about mmap_sem. In the past there has been discussions about replacing it with an interval lock, but these never went anywhere because, mostly, of the fact that such mechanisms were too expensive to use in the page fault path. I think adding the spf mechanism would invite us to revisit this issue - interval locks may be a great way to avoid blocking between unrelated mmap_sem writers (for example, do not delay stack creation for new threads while a large mmap or munmap may be going on), and probably also to handle mmap_sem readers that can't easily use the spf mechanism (for example, gup callers which make use of the returned vmas). But again that is a separate topic to explore which doesn't have to get resolved before spf goes in.
[PATCH v5 23/23] 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
---
Documentation/firmware-guide/acpi/index.rst | 1 +
.../acpi/video_extension.rst} | 83 +++
2 files changed, 50 insertions(+), 34 deletions(-)
rename Documentation/{acpi/video_extension.txt =>
firmware-guide/acpi/video_extension.rst} (70%)
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 70%
rename from Documentation/acpi/video_extension.txt
rename to Documentation/firmware-guide/acpi/video_extension.rst
index 79bf6a4921be..099b8607e07b 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,10 @@ 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 does 3 things regarding backlight control.
-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 +26,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 +71,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, the
- following key code will appear to user space:
+ following key code will appear to user space::
EV_KEY, KEY_BRIGHTNESSUP
EV_KEY,
[PATCH v5 22/23] 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 v5 21/23] 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 v5 20/23] 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 v5 19/23] 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 v5 18/23] 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 v5 17/23] 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 v5 16/23] 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 v5 15/23] 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 v5 14/23] 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
---
.../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 v5 13/23] 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 v5 12/23] 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 v5 11/23] 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 v5 10/23] 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 v5 09/23] 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 v5 08/23] 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
---
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 v5 07/23] 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 v5 06/23] 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 v5 05/23] 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 v5 04/23] 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 v5 03/23] 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 v5 02/23] 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 v5 01/23] 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
Re: [PATCH v4 09/63] Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST
Em Thu, 25 Apr 2019 00:28:52 +0800 Changbin Du escreveu: > On Tue, Apr 23, 2019 at 06:03:16PM -0300, Mauro Carvalho Chehab wrote: > > Em Wed, 24 Apr 2019 00:28:38 +0800 > > Changbin Du escreveu: > > > > > +.. 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". > > > > Hmm... this may work (not sure if Sphinx would warn or not), but it > > is visually bad on text mode. I would code it, instead, with something > > like: > > > > .. 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. > > > > - The same ACPI control method can be overridden for many times, > > and it's always the latest one that used by Linux/kernel. > > > > - To get the ACPI debug object output (Store (, Debug)), > > please run:: > > > > echo 1 > /sys/module/acpi/parameters/aml_debug_output > > > > As this would make it visually better on both text and html formats. > > > No warnings given. Interesting. I'm now wondering if it did the right thing or if it produced some weird output... Maybe the answer depends on the Sphinx version one would be using. > Your suggested style is better so applied it. Thanks! Thank you! Thanks, Mauro
[PATCH v5 00/23] 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! v5: Fix all comments from Mauro. Thanks for your careful review! Changbin Du (23): 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 | 4 + .../acpi/initrd_table_override.rst| 115 +++ .../admin-guide/acpi/ssdt-overlays.rst| 180 +++ Documentation/driver-api/acpi/index.rst | 2 + .../acpi/linuxized-acpica.rst}| 109 --- .../acpi/scan_handlers.rst} | 24 +- .../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 +++-- .../firmware-guide/acpi/i2c-muxes.rst | 61 Documentation/firmware-guide/acpi/index.rst | 17 + .../lpit.txt => firmware-guide/acpi/lpit.rst} | 18 +- .../acpi/method-customizing.rst
Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
Em Wed, 24 Apr 2019 23:46:18 +0800 Changbin Du escreveu: > On Tue, Apr 23, 2019 at 12:36:44PM -0500, Bjorn Helgaas wrote: > > On Tue, Apr 23, 2019 at 06:39:47PM +0200, Rafael J. Wysocki wrote: > > > On Tue, Apr 23, 2019 at 6:30 PM Changbin Du wrote: > > > > Hi Corbet and All, > > > > The kernel now uses Sphinx to generate intelligent and beautiful > > > > documentation from reStructuredText files. I converted all of the Linux > > > > ACPI/PCI/X86 docs to reST format in this serias. > > > > > > > > In this version I combined ACPI and PCI docs, and added new x86 docs > > > > conversion. > > > > > > I'm not sure if combining all three into one big patch series has been > > > a good idea, honestly. > > > > Yeah, if you post this again, I would find it easier to deal with if > > linux-pci only got the PCI-related things. 63 patches is a little too > > much for one series. > > > sure, so I will resend them respectively. I reviewed up to patch 39. There are too many files on x86 that seems to be mangled by some tab->whitespace conversion, with caused very big diffs and lots of broken ascii artwork. Please ensure that the diffs will contain the minimal amount of stuff that would be required for them to be properly formatted as ReST files there. Ah, perhaps next time you could format the patches with a lower merge similarity logic (using, for example, the parameter -M10). Regards, Mauro > > > Bjorn > Thanks, Mauro
Re: [PATCH v4 39/63] Documentation: x86: convert topology.txt to reST
Em Wed, 24 Apr 2019 00:29:08 +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/index.rst| 1 + > Documentation/x86/topology.rst | 228 + > Documentation/x86/topology.txt | 217 --- > 3 files changed, 229 insertions(+), 217 deletions(-) > create mode 100644 Documentation/x86/topology.rst > delete mode 100644 Documentation/x86/topology.txt Why? Please preserve as much as possible from the original file... it is really hard to see what you're doing. Most of those x86 files are already almost at ReST format (like this one). There's absolutely **no reason** why you would do so much radical changes that would below the 50% similarity threshold that would make git to recognize as a change on the same file! I'll give a quick review on this one, but it is really hard to be sure that something is missing, when the similarity is too low. > > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst > index 8f08caf4fbbb..2033791e53bc 100644 > --- a/Documentation/x86/index.rst > +++ b/Documentation/x86/index.rst > @@ -9,3 +9,4 @@ Linux x86 Support > :numbered: > > boot > + topology > diff --git a/Documentation/x86/topology.rst b/Documentation/x86/topology.rst > new file mode 100644 > index ..1df5f56f4882 > --- /dev/null > +++ b/Documentation/x86/topology.rst > @@ -0,0 +1,228 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > + > +x86 Topology > + > + > +This documents and clarifies the main aspects of x86 topology modelling and > +representation in the kernel. Update/change when doing changes to the > +respective code. > + > +The architecture-agnostic topology definitions are in > +Documentation/cputopology.txt. This file holds x86-specific > +differences/specialities which must not necessarily apply to the generic > +definitions. Thus, the way to read up on Linux topology on x86 is to start > +with the generic one and look at this one in parallel for the x86 specifics. > + > +Needless to say, code should use the generic functions - this file is *only* > +here to *document* the inner workings of x86 topology. > + > +Started by Thomas Gleixner and Borislav Petkov > . > + > +The main aim of the topology facilities is to present adequate interfaces to > +code which needs to know/query/use the structure of the running system wrt > +threads, cores, packages, etc. > + > +The kernel does not care about the concept of physical sockets because a > +socket has no relevance to software. It's an electromechanical component. In > +the past a socket always contained a single package (see below), but with the > +advent of Multi Chip Modules (MCM) a socket can hold more than one package. > So > +there might be still references to sockets in the code, but they are of > +historical nature and should be cleaned up. > + > +The topology of a system is described in the units of: > + > +- packages > +- cores > +- threads > + > +Package > +=== > + > +Packages contain a number of cores plus shared resources, e.g. DRAM > +controller, shared caches etc. > + > +AMD nomenclature for package is 'Node'. > + > +Package-related topology information in the kernel: > + > + - cpuinfo_x86.x86_max_cores: > + > +The number of cores in a package. This information is retrieved via > CPUID. > + > + - cpuinfo_x86.phys_proc_id: > + > +The physical ID of the package. This information is retrieved via CPUID > +and deduced from the APIC IDs of the cores in the package. > + > + - cpuinfo_x86.logical_id: > + > +The logical ID of the package. As we do not trust BIOSes to enumerate the > +packages in a consistent way, we introduced the concept of logical > package > +ID so we can sanely calculate the number of maximum possible packages in > +the system and have the packages enumerated linearly. > + > + - topology_max_packages(): > + > +The maximum possible number of packages in the system. Helpful for per > +package facilities to preallocate per package information. > + > + - cpu_llc_id: > + > +A per-CPU variable containing: > + > +- On Intel, the first APIC ID of the list of CPUs sharing the Last Level > + Cache. > + > +- On AMD, the Node ID or Core Complex ID containing the Last Level > + Cache. In general, it is a number identifying an LLC uniquely on the > + system. > + > +Cores > += > + > +A core consists of 1 or more threads. It does not matter whether the threads > +are SMT- or CMT-type threads. > + > +AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses > +"core". > + > +Core-related topology information in the kernel: > + > + - smp_num_siblings: > + > +The number of threads in a core. The number of threads in a package can > be > +
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
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?
Re: [PATCH v4 38/63] Documentation: x86: convert boot.txt to reST
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 structsetup_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. > + > +MEMORY LAYOUT > += > + > +The traditional memory map for the kernel loader, used for Image or > +zImage kernels, typically looks like:: > + > +| | > + 0A ++ > +| Reserved for BIOS | Do not use. Reserved for BIOS EBDA. > + 09A000
Re: [PATCH v4 24/63] Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
On Wed, Apr 24, 2019 at 11:56:47AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:53 +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/firmware-guide/acpi/index.rst | 1 +
> > .../acpi/video_extension.rst} | 63 ++-
> > 2 files changed, 36 insertions(+), 28 deletions(-)
> > rename Documentation/{acpi/video_extension.txt =>
> > firmware-guide/acpi/video_extension.rst} (79%)
> >
> > 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 79%
> > rename from Documentation/acpi/video_extension.txt
> > rename to Documentation/firmware-guide/acpi/video_extension.rst
> > index 79bf6a4921be..06f7e3230b6e 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,10 @@ 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 does 3 things regarding backlight control.
> >
> > -1 Export a sysfs interface for user space to control backlight level
> > +1. 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
>
> Hmm... you didn't touch on this part of the document:
>
> 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
>
> You should touch it. My suggestion here is:
>
> 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
>
Thanks, done.
> > @@ -32,26 +36,26 @@ 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 +66,15 @@ as a "brightness level" indicator. Thus from the
Re: [PATCH v4 21/63] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
On Wed, Apr 24, 2019 at 11:48:44AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:50 +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
> > ---
> > .../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
>
> Hmm... removed by mistake?
>
I comfirmed that no content removed.
> > +Some of the CPPC registers are exposed via sysfs under::
> >
> > -
> > + /sys/devices/system/cpu/cpuX/acpi_cppc/
>
> Did you parse this with Sphinx? It doesn't sound a valid ReST construction
> to my eyes, as:
>
> 1) I've seen some versions of Sphinx to abort with severe errors when
>there's no blank line after the horizontal bar markup;
>
> 2) It will very likely ignore the "::" (I didn't test it myself), as you're
>not indenting the horizontal bar. End of indentation will mean the end
>of an (empty) literal block.
>
> So, I would stick with:
>
>
> Some of the CPPC registers are exposed via sysfs under:
>
> /sys/devices/system/cpu/cpuX/acpi_cppc/
>
>
> -
>
> for each cpu X::
>
>
> or:
>
> Some of the CPPC registers are exposed via sysfs under:
>
> /sys/devices/system/cpu/cpuX/acpi_cppc/
>
> for each cpu X
>
>
>
>
> ::
>
> (with is closer to the original author's intent)
>
> Same applies to the other similar changes on this document.
>
I didn't seen any warning here and the generated html is good. So I think it is
ok.
> >
> > -$ 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).
> > *
[PATCH 4.4 052/168] ASoC: fsl-asoc-card: fix object reference leaks in fsl_asoc_card_probe
[ Upstream commit 11907e9d3533648615db08140e3045b829d2c141 ] The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Signed-off-by: Wen Yang Cc: Timur Tabi Cc: Nicolin Chen Cc: Xiubo Li Cc: Fabio Estevam Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: alsa-de...@alsa-project.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/fsl/fsl-asoc-card.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c index 1b05d1c5d9fd..a32fe14b4687 100644 --- a/sound/soc/fsl/fsl-asoc-card.c +++ b/sound/soc/fsl/fsl-asoc-card.c @@ -659,6 +659,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev) asrc_fail: of_node_put(asrc_np); of_node_put(codec_np); + put_device(_pdev->dev); fail: of_node_put(cpu_np); -- 2.19.1
[PATCH 4.4 037/168] SoC: imx-sgtl5000: add missing put_device()
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: NXP Linux Team
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/imx-sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index b99e0b5e00e9..8e525f7ac08d 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+ put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
--
2.19.1
Re: [PATCH v2] mm: Fix modifying of page protection by insert_pfn_pmd()
On Tue, Apr 2, 2019 at 4:51 AM Aneesh Kumar K.V
wrote:
>
> With some architectures like ppc64, set_pmd_at() cannot cope with
> a situation where there is already some (different) valid entry present.
>
> Use pmdp_set_access_flags() instead to modify the pfn which is built to
> deal with modifying existing PMD entries.
>
> This is similar to
> commit cae85cb8add3 ("mm/memory.c: fix modifying of page protection by
> insert_pfn()")
>
> We also do similar update w.r.t insert_pfn_pud eventhough ppc64 don't support
> pud pfn entries now.
>
> Without this patch we also see the below message in kernel log
> "BUG: non-zero pgtables_bytes on freeing mm:"
>
> CC: sta...@vger.kernel.org
> Reported-by: Chandan Rajendra
> Signed-off-by: Aneesh Kumar K.V
> ---
> Changes from v1:
> * Fix the pgtable leak
>
> mm/huge_memory.c | 36
> 1 file changed, 36 insertions(+)
This patch is triggering the following bug in v4.19.35.
kernel BUG at arch/x86/mm/pgtable.c:515!
invalid opcode: [#1] SMP NOPTI
CPU: 51 PID: 43713 Comm: java Tainted: G OE 4.19.35 #1
RIP: 0010:pmdp_set_access_flags+0x48/0x50
[..]
Call Trace:
vmf_insert_pfn_pmd+0x198/0x350
dax_iomap_fault+0xe82/0x1190
ext4_dax_huge_fault+0x103/0x1f0
? __switch_to_asm+0x40/0x70
__handle_mm_fault+0x3f6/0x1370
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
handle_mm_fault+0xda/0x200
__do_page_fault+0x249/0x4f0
do_page_fault+0x32/0x110
? page_fault+0x8/0x30
page_fault+0x1e/0x30
I asked the reporter to try a kernel with commit c6f3c5ee40c1
"mm/huge_memory.c: fix modifying of page protection by
insert_pfn_pmd()" reverted and the failing test passed.
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);
break;
case IOMAP_UNWRITTEN:
I'll ask the reporter to try this fix as well.
Re: [PATCH v4 20/63] Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and convert to reST
On Wed, Apr 24, 2019 at 11:33:49AM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:49 +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
> > ---
> > .../acpi/apei/einj.rst} | 98 ++-
> > Documentation/firmware-guide/acpi/index.rst | 1 +
> > 2 files changed, 53 insertions(+), 46 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..d85e2667155c 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.
> >
> > @@ -35,22 +38,22 @@ The following files belong to it:
> >
> > - available_error_type
> >
> > - 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
> > + 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
>
> This is a table and not a literal block.
>
> The best here to preserve the author's intent is to just adjust the table
> markups in order to make it parseable, e. g.:
>
> This file shows which error types are supported:
>
> ===
> Error Type ValueError 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
>
[PATCH 3.18 020/104] SoC: imx-sgtl5000: add missing put_device()
[ Upstream commit 8fa857da9744f513036df1c43ab57f338941ae7d ]
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
Detected by coccinelle with the following warnings:
./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device;
call of_find_device_by_node on line 105, but without a corresponding
object release within this function.
Signed-off-by: Wen Yang
Cc: Timur Tabi
Cc: Nicolin Chen
Cc: Xiubo Li
Cc: Fabio Estevam
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: NXP Linux Team
Cc: alsa-de...@alsa-project.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/fsl/imx-sgtl5000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c
index 1cb22dd034eb..110f3cf361af 100644
--- a/sound/soc/fsl/imx-sgtl5000.c
+++ b/sound/soc/fsl/imx-sgtl5000.c
@@ -115,6 +115,7 @@ static int imx_sgtl5000_probe(struct platform_device *pdev)
ret = -EPROBE_DEFER;
goto fail;
}
+ put_device(_pdev->dev);
codec_dev = of_find_i2c_device_by_node(codec_np);
if (!codec_dev) {
dev_err(>dev, "failed to find codec platform device\n");
--
2.19.1
Re: [PATCH v4 37/63] Documentation: add Linux x86 docs to Sphinx TOC tree
Em Wed, 24 Apr 2019 00:29:06 +0800 Changbin Du escreveu: > Add a index.rst for x86 support. More docs will be added later. > > Signed-off-by: Changbin Du > --- > Documentation/index.rst | 1 + > Documentation/x86/index.rst | 9 + > 2 files changed, 10 insertions(+) > create mode 100644 Documentation/x86/index.rst > > diff --git a/Documentation/index.rst b/Documentation/index.rst > index d80138284e0f..f185c8040fa9 100644 > --- a/Documentation/index.rst > +++ b/Documentation/index.rst > @@ -112,6 +112,7 @@ implementation. > .. toctree:: > :maxdepth: 2 > > + x86/index > sh/index > > Filesystem Documentation > diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst > new file mode 100644 > index ..7612d3142b2a > --- /dev/null > +++ b/Documentation/x86/index.rst > @@ -0,0 +1,9 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > += > +Linux x86 Support > += > + > +.. toctree:: > + :maxdepth: 2 > + :numbered: Looks ok to me: Reviewed-by: Mauro Carvalho Chehab Just one reminder: after merging both this and my conversions, we may need to do some review at the architecture titles, in order to make them consistent. On mu conversion patches, I'm using == $arch Architecture == Probably also not the best title. Anyway, this can easily be fixed with a follow up patch once we get everything merged. Thanks, Mauro
Re: [PATCH v4 36/63] Documentation: PCI: convert endpoint/pci-test-howto.txt to reST
Em Wed, 24 Apr 2019 00:29:05 +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
> Acked-by: Bjorn Helgaas
Reviewed-by: Mauro Carvalho Chehab
> ---
> Documentation/PCI/endpoint/index.rst | 1 +
> ...{pci-test-howto.txt => pci-test-howto.rst} | 81 +--
> 2 files changed, 56 insertions(+), 26 deletions(-)
> rename Documentation/PCI/endpoint/{pci-test-howto.txt => pci-test-howto.rst}
> (78%)
>
> diff --git a/Documentation/PCI/endpoint/index.rst
> b/Documentation/PCI/endpoint/index.rst
> index b680a3fc4fec..d114ea74b444 100644
> --- a/Documentation/PCI/endpoint/index.rst
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -10,3 +10,4 @@ PCI Endpoint Framework
> pci-endpoint
> pci-endpoint-cfs
> pci-test-function
> + pci-test-howto
> diff --git a/Documentation/PCI/endpoint/pci-test-howto.txt
> b/Documentation/PCI/endpoint/pci-test-howto.rst
> similarity index 78%
> rename from Documentation/PCI/endpoint/pci-test-howto.txt
> rename to Documentation/PCI/endpoint/pci-test-howto.rst
> index 040479f437a5..909f770a07d6 100644
> --- a/Documentation/PCI/endpoint/pci-test-howto.txt
> +++ b/Documentation/PCI/endpoint/pci-test-howto.rst
> @@ -1,38 +1,51 @@
> - PCI TEST USERGUIDE
> - Kishon Vijay Abraham I
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +PCI Test User Guide
> +===
> +
> +:Author: Kishon Vijay Abraham I
>
> This document is a guide to help users use pci-epf-test function driver
> and pci_endpoint_test host driver for testing PCI. The list of steps to
> be followed in the host side and EP side is given below.
>
> -1. Endpoint Device
> +Endpoint Device
> +===
>
> -1.1 Endpoint Controller Devices
> +Endpoint Controller Devices
> +---
>
> -To find the list of endpoint controller devices in the system:
> +To find the list of endpoint controller devices in the system::
>
> # ls /sys/class/pci_epc/
> 5100.pcie_ep
>
> -If PCI_ENDPOINT_CONFIGFS is enabled
> +If PCI_ENDPOINT_CONFIGFS is enabled::
> +
> # ls /sys/kernel/config/pci_ep/controllers
> 5100.pcie_ep
>
> -1.2 Endpoint Function Drivers
>
> -To find the list of endpoint function drivers in the system:
> +Endpoint Function Drivers
> +-
> +
> +To find the list of endpoint function drivers in the system::
>
> # ls /sys/bus/pci-epf/drivers
> pci_epf_test
>
> -If PCI_ENDPOINT_CONFIGFS is enabled
> +If PCI_ENDPOINT_CONFIGFS is enabled::
> +
> # ls /sys/kernel/config/pci_ep/functions
> pci_epf_test
>
> -1.3 Creating pci-epf-test Device
> +
> +Creating pci-epf-test Device
> +
>
> PCI endpoint function device can be created using the configfs. To create
> -pci-epf-test device, the following commands can be used
> +pci-epf-test device, the following commands can be used::
>
> # mount -t configfs none /sys/kernel/config
> # cd /sys/kernel/config/pci_ep/
> @@ -42,7 +55,7 @@ The "mkdir func1" above creates the pci-epf-test function
> device that will
> be probed by pci_epf_test driver.
>
> The PCI endpoint framework populates the directory with the following
> -configurable fields.
> +configurable fields::
>
> # ls functions/pci_epf_test/func1
> baseclass_codeinterrupt_pin progif_code subsys_id
> @@ -51,67 +64,83 @@ configurable fields.
>
> The PCI endpoint function driver populates these entries with default values
> when the device is bound to the driver. The pci-epf-test driver populates
> -vendorid with 0x and interrupt_pin with 0x0001
> +vendorid with 0x and interrupt_pin with 0x0001::
>
> # cat functions/pci_epf_test/func1/vendorid
> 0x
> # cat functions/pci_epf_test/func1/interrupt_pin
> 0x0001
>
> -1.4 Configuring pci-epf-test Device
> +
> +Configuring pci-epf-test Device
> +---
>
> The user can configure the pci-epf-test device using configfs entry. In order
> to change the vendorid and the number of MSI interrupts used by the function
> -device, the following commands can be used.
> +device, the following commands can be used::
>
> # echo 0x104c > functions/pci_epf_test/func1/vendorid
> # echo 0xb500 > functions/pci_epf_test/func1/deviceid
> # echo 16 > functions/pci_epf_test/func1/msi_interrupts
> # echo 8 > functions/pci_epf_test/func1/msix_interrupts
>
> -1.5 Binding pci-epf-test Device to EP Controller
> +
> +Binding pci-epf-test Device to EP Controller
> +
>
> In order for the endpoint function device to be useful, it has to be bound to
> a PCI endpoint controller driver. Use the configfs to bind the function
>
Re: [PATCH v4 35/63] Documentation: PCI: convert endpoint/pci-test-function.txt to reST
Em Wed, 24 Apr 2019 00:29:04 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/endpoint/index.rst | 1 +
> ...est-function.txt => pci-test-function.rst} | 32 +++
> 2 files changed, 20 insertions(+), 13 deletions(-)
> rename Documentation/PCI/endpoint/{pci-test-function.txt =>
> pci-test-function.rst} (84%)
>
> diff --git a/Documentation/PCI/endpoint/index.rst
> b/Documentation/PCI/endpoint/index.rst
> index 3951de9f923c..b680a3fc4fec 100644
> --- a/Documentation/PCI/endpoint/index.rst
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -9,3 +9,4 @@ PCI Endpoint Framework
>
> pci-endpoint
> pci-endpoint-cfs
> + pci-test-function
> diff --git a/Documentation/PCI/endpoint/pci-test-function.txt
> b/Documentation/PCI/endpoint/pci-test-function.rst
> similarity index 84%
> rename from Documentation/PCI/endpoint/pci-test-function.txt
> rename to Documentation/PCI/endpoint/pci-test-function.rst
> index 5916f1f592bb..ba02cddcec37 100644
> --- a/Documentation/PCI/endpoint/pci-test-function.txt
> +++ b/Documentation/PCI/endpoint/pci-test-function.rst
> @@ -1,5 +1,10 @@
> - PCI TEST
> - Kishon Vijay Abraham I
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=
> +PCI Test Function
> +=
> +
> +:Author: Kishon Vijay Abraham I
>
> Traditionally PCI RC has always been validated by using standard
> PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
> @@ -23,30 +28,31 @@ The PCI endpoint test device has the following registers:
> 8) PCI_ENDPOINT_TEST_IRQ_TYPE
> 9) PCI_ENDPOINT_TEST_IRQ_NUMBER
>
> -*) PCI_ENDPOINT_TEST_MAGIC
> +* PCI_ENDPOINT_TEST_MAGIC
Same comment as on a previous patch. I suspect that the author's intention
for all stuff under Documentation/PCI/endpoint/ (or perhaps this is due
tothe markup language he uses) is to have:
*) foo
as a chapter, e. g. the right conversion would be, instead:
PCI_ENDPOINT_TEST_MAGIC
===
(same applies to the other similar markups here and on other files under
the endpoint/ directory)
>
> This register will be used to test BAR0. A known pattern will be written
> and read back from MAGIC register to verify BAR0.
>
> -*) PCI_ENDPOINT_TEST_COMMAND:
> +* PCI_ENDPOINT_TEST_COMMAND:
>
> This register will be used by the host driver to indicate the function
> that the endpoint device must perform.
>
> -Bitfield Description:
> +Bitfield Description::
> +
>Bit 0 : raise legacy IRQ
>Bit 1 : raise MSI IRQ
>Bit 2 : raise MSI-X IRQ
>Bit 3 : read command (read data from RC buffer)
>Bit 4 : write command (write data to RC buffer)
> - Bit 5 : copy command (copy data from one RC buffer to another
> - RC buffer)
> + Bit 5 : copy command (copy data from one RC buffer to another
> RC buffer)
Please use a table instead:
Bitfield Description:
= ===
Bit 0 raise legacy IRQ
Bit 1 raise MSI IRQ
Bit 2 raise MSI-X IRQ
Bit 3 read command (read data from RC buffer)
Bit 4 write command (write data to RC buffer)
Bit 5 copy command (copy data from one RC buffer to another
RC buffer)
= ===
>
> -*) PCI_ENDPOINT_TEST_STATUS
> +* PCI_ENDPOINT_TEST_STATUS
>
> This register reflects the status of the PCI endpoint device.
>
> -Bitfield Description:
> +Bitfield Description::
> +
>Bit 0 : read success
>Bit 1 : read fail
>Bit 2 : write success
> @@ -57,17 +63,17 @@ Bitfield Description:
>Bit 7 : source address is invalid
>Bit 8 : destination address is invalid
Same here:
Bitfield Description:
= ==
Bit 0 read success
Bit 1 read fail
Bit 2 write success
Bit 3 write fail
Bit 4 copy success
Bit 5 copy fail
Bit 6 IRQ raised
Bit 7 source address is invalid
Bit 8 destination address is invalid
= ==
>
> -*) PCI_ENDPOINT_TEST_SRC_ADDR
> +* PCI_ENDPOINT_TEST_SRC_ADDR
>
> This register contains the source address (RC buffer address) for the
> COPY/READ command.
>
> -*) PCI_ENDPOINT_TEST_DST_ADDR
> +* PCI_ENDPOINT_TEST_DST_ADDR
>
> This register contains the destination address (RC buffer address) for
> the COPY/WRITE command.
>
> -*) PCI_ENDPOINT_TEST_IRQ_TYPE
> +* PCI_ENDPOINT_TEST_IRQ_TYPE
>
> This
Re: [PATCH v4 17/63] Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi and convert to rsST
On Wed, Apr 24, 2019 at 11:26:38AM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 24 Apr 2019 00:28:46 +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/acpi/method-tracing.txt | 192 --- > > Documentation/firmware-guide/acpi/index.rst | 1 + > > .../firmware-guide/acpi/method-tracing.rst| 225 ++ > > 3 files changed, 226 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 > >
Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
Em Wed, 24 Apr 2019 10:18:46 -0600 Jonathan Corbet escreveu: > On Wed, 24 Apr 2019 00:28:29 +0800 > Changbin Du wrote: > > > The kernel now uses Sphinx to generate intelligent and beautiful > > documentation > > from reStructuredText files. I converted all of the Linux ACPI/PCI/X86 docs > > to > > reST format in this serias. > > > > In this version I combined ACPI and PCI docs, and added new x86 docs > > conversion. > > As mentioned by others, this is a lot of stuff; I would really rather see > each of those groups as separate patch sets. Yeah, makes sense to me, either to split into separate patchsets or to group the changes per sub-dir (or both). > If you can do a reasonably quick turnaround with Mauro's suggestions > addressed and tags applied, we should be able to get at least some of this > into 5.2. Thanks, Mauro, for looking at all of this stuff! Anytime! Just to make clear, I'm still reviewing it... I'm at patch 35/63 now. So, expect more comments from my side. Thanks, Mauro
Re: [PATCH v4 15/63] Documentation: ACPI: move dsd/data-node-references.txt to firmware-guide/acpi and convert to reST
On Tue, Apr 23, 2019 at 06:17:48PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:44 +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
> > ---
> > .../acpi/dsd/data-node-references.rst}| 28 +++
> > Documentation/firmware-guide/acpi/index.rst | 1 +
> > 2 files changed, 17 insertions(+), 12 deletions(-)
> > rename Documentation/{acpi/dsd/data-node-references.txt =>
> > firmware-guide/acpi/dsd/data-node-references.rst} (79%)
> >
> > diff --git a/Documentation/acpi/dsd/data-node-references.txt
> > b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > similarity index 79%
> > rename from Documentation/acpi/dsd/data-node-references.txt
> > rename to Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> > index c3871565c8cf..79c5368eaecf 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,10 +79,10 @@ 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>,
>
> Hmm... on the previous patch, you replaced by some_url,
> with makes sense. Please do the same here and on other patches on
> this series with a similar way to describe URLs.
>
Done, thanks.
> > 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
>
>
>
> Thanks,
> Mauro
--
Cheers,
Changbin Du
Re: [PATCH v4 10/63] Documentation: ACPI: move initrd_table_override.txt to admin-guide/acpi and convert to reST
On Tue, Apr 23, 2019 at 06:07:34PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:39 +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/acpi/initrd_table_override.txt | 111
> > Documentation/admin-guide/acpi/index.rst | 1 +
> > .../acpi/initrd_table_override.rst| 120 ++
> > 3 files changed, 121 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
> >
Re: [PATCH v4 09/63] Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST
On Tue, Apr 23, 2019 at 06:03:16PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:38 +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/acpi/method-customizing.txt | 73 -
> > Documentation/firmware-guide/acpi/index.rst | 3 +-
> > .../acpi/method-customizing.rst | 82 +++
> > 3 files changed, 84 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
> >
Re: [PATCH v4 34/63] Documentation: PCI: convert endpoint/pci-endpoint-cfs.txt to reST
Em Wed, 24 Apr 2019 00:29:03 +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
> Acked-by: Bjorn Helgaas
Reviewed-by: Mauro Carvalho Chehab
> ---
> Documentation/PCI/endpoint/index.rst | 1 +
> ...-endpoint-cfs.txt => pci-endpoint-cfs.rst} | 99 +++
> 2 files changed, 57 insertions(+), 43 deletions(-)
> rename Documentation/PCI/endpoint/{pci-endpoint-cfs.txt =>
> pci-endpoint-cfs.rst} (64%)
>
> diff --git a/Documentation/PCI/endpoint/index.rst
> b/Documentation/PCI/endpoint/index.rst
> index 0db4f2fcd7f0..3951de9f923c 100644
> --- a/Documentation/PCI/endpoint/index.rst
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -8,3 +8,4 @@ PCI Endpoint Framework
> :maxdepth: 2
>
> pci-endpoint
> + pci-endpoint-cfs
> diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
> b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
> similarity index 64%
> rename from Documentation/PCI/endpoint/pci-endpoint-cfs.txt
> rename to Documentation/PCI/endpoint/pci-endpoint-cfs.rst
> index d740f29960a4..b6d39cdec56e 100644
> --- a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
> +++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
> @@ -1,41 +1,51 @@
> - CONFIGURING PCI ENDPOINT USING CONFIGFS
> -Kishon Vijay Abraham I
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +Configuring PCI Endpoint Using CONFIGFS
> +===
> +
> +:Author: Kishon Vijay Abraham I
>
> The PCI Endpoint Core exposes configfs entry (pci_ep) to configure the
> PCI endpoint function and to bind the endpoint function
> with the endpoint controller. (For introducing other mechanisms to
> configure the PCI Endpoint Function refer to [1]).
>
> -*) Mounting configfs
> +Mounting configfs
> +=
>
> The PCI Endpoint Core layer creates pci_ep directory in the mounted configfs
> -directory. configfs can be mounted using the following command.
> +directory. configfs can be mounted using the following command::
>
> mount -t configfs none /sys/kernel/config
>
> -*) Directory Structure
> +Directory Structure
> +===
>
> The pci_ep configfs has two directories at its root: controllers and
> functions. Every EPC device present in the system will have an entry in
> the *controllers* directory and and every EPF driver present in the system
> will have an entry in the *functions* directory.
> +::
>
> -/sys/kernel/config/pci_ep/
> - .. controllers/
> - .. functions/
> + /sys/kernel/config/pci_ep/
> + .. controllers/
> + .. functions/
>
> -*) Creating EPF Device
> +Creating EPF Device
> +===
>
> Every registered EPF driver will be listed in controllers directory. The
> entries corresponding to EPF driver will be created by the EPF core.
> +::
>
> -/sys/kernel/config/pci_ep/functions/
> - .. /
> - ... /
> - ... /
> - .. /
> - ... /
> - ... /
> + /sys/kernel/config/pci_ep/functions/
> + .. /
> + ... /
> + ... /
> + .. /
> + ... /
> + ... /
>
> In order to create a of the type probed by , the
> user has to create a directory inside .
> @@ -44,34 +54,37 @@ Every directory consists of the following
> entries that can be
> used to configure the standard configuration header of the endpoint function.
> (These entries are created by the framework when any new is
> created)
> -
> - .. /
> - ... /
> - ... vendorid
> - ... deviceid
> - ... revid
> - ... progif_code
> - ... subclass_code
> - ... baseclass_code
> - ... cache_line_size
> - ... subsys_vendor_id
> - ... subsys_id
> - ... interrupt_pin
> -
> -*) EPC Device
> +::
> +
> + .. /
> + ... /
> + ... vendorid
> + ... deviceid
> + ... revid
> + ... progif_code
> + ... subclass_code
> + ... baseclass_code
> + ... cache_line_size
> + ... subsys_vendor_id
> + ... subsys_id
> + ... interrupt_pin
> +
> +EPC Device
> +==
>
> Every registered EPC device will be listed in controllers directory. The
> entries corresponding to EPC device will be created by the EPC core.
> -
> -/sys/kernel/config/pci_ep/controllers/
> - ..
Re: [PATCH v4 08/63] Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi and convert to reST
On Tue, Apr 23, 2019 at 05:55:15PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:37 +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
> > ---
> > .../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..89c636963544 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
Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
On Wed, 24 Apr 2019 00:28:29 +0800 Changbin Du wrote: > The kernel now uses Sphinx to generate intelligent and beautiful documentation > from reStructuredText files. I converted all of the Linux ACPI/PCI/X86 docs to > reST format in this serias. > > In this version I combined ACPI and PCI docs, and added new x86 docs > conversion. As mentioned by others, this is a lot of stuff; I would really rather see each of those groups as separate patch sets. If you can do a reasonably quick turnaround with Mauro's suggestions addressed and tags applied, we should be able to get at least some of this into 5.2. Thanks, Mauro, for looking at all of this stuff! Thanks, jon
Re: [PATCH v4 05/63] Documentation: ACPI: move linuxized-acpica.txt to driver-api/acpi and convert to reST
On Tue, Apr 23, 2019 at 05:50:30PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:34 +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/driver-api/acpi/index.rst | 1 +
> > .../acpi/linuxized-acpica.rst}| 115 ++
> > 2 files changed, 66 insertions(+), 50 deletions(-)
> > rename Documentation/{acpi/linuxized-acpica.txt =>
> > driver-api/acpi/linuxized-acpica.rst} (78%)
> >
> > 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 78%
> > rename from Documentation/acpi/linuxized-acpica.txt
> > rename to Documentation/driver-api/acpi/linuxized-acpica.rst
> > index 3ad7b0dfb083..f8aaea668e41 100644
> > --- a/Documentation/acpi/linuxized-acpica.txt
> > +++ b/Documentation/driver-api/acpi/linuxized-acpica.rst
> > @@ -1,31 +1,35 @@
> > -Linuxized ACPICA - Introduction to ACPICA Release Automation
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. include::
> >
> > -Copyright (C) 2013-2016, Intel Corporation
> > -Author: Lv Zheng
> > +
> > +Linuxized ACPICA - Introduction to ACPICA Release Automation
> > +
> >
> > +:Copyright: |copy| 2013-2016, Intel Corporation
> >
> > -Abstract:
> > +:Author: Lv Zheng
> >
> > -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.
> > +: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.
> >
>
> Same comment as on patch 02: I would keep the abstracts as a chapter,
> in order to make them visible at the index, as this may help readers
> to quickly look at the document's contents.
>
ok, done.
> I'm sure other APCI documents also have abstracts. So, please consider
> this comment also for the other docs.
>
For short description, I'd keep it. For long case, will make it as a chapter.
Thanks.
> Anyway, this is just a suggestion. I'm also fine with the above.
> Either way, for the conversion itself:
>
> Reviewed-by: Mauro Carvalho Chehab
>
> >
> > -1. ACPICA Project
> > +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 +75,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 -
Re: [PATCH v4 02/63] Documentation: ACPI: move namespace.txt to firmware-guide/acpi and convert to reST
On Tue, Apr 23, 2019 at 05:38:40PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 24 Apr 2019 00:28:31 +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/firmware-guide/acpi/index.rst | 1 +
> > .../acpi/namespace.rst} | 310 +-
> > 2 files changed, 161 insertions(+), 150 deletions(-)
> > rename Documentation/{acpi/namespace.txt =>
> > firmware-guide/acpi/namespace.rst} (54%)
> >
> > diff --git a/Documentation/firmware-guide/acpi/index.rst
> > b/Documentation/firmware-guide/acpi/index.rst
> > index 0ec7d072ba22..210ad8acd6df 100644
> > --- a/Documentation/firmware-guide/acpi/index.rst
> > +++ b/Documentation/firmware-guide/acpi/index.rst
> > @@ -7,3 +7,4 @@ ACPI Support
> > .. toctree::
> > :maxdepth: 1
> >
> > + namespace
> > diff --git a/Documentation/acpi/namespace.txt
> > b/Documentation/firmware-guide/acpi/namespace.rst
> > similarity index 54%
> > rename from Documentation/acpi/namespace.txt
> > rename to Documentation/firmware-guide/acpi/namespace.rst
> > index 1860cb3865c6..443f0e5d0617 100644
> > --- a/Documentation/acpi/namespace.txt
> > +++ b/Documentation/firmware-guide/acpi/namespace.rst
> > @@ -1,85 +1,88 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. include::
> > +
> > +===
> > ACPI Device Tree - Representation of ACPI Namespace
> > +===
> > +
> > +:Copyright: |copy| 2013, Intel Corporation
> > +
> > +:Author: Lv Zheng
> > +
> > +:Abstract: The Linux ACPI subsystem converts ACPI namespace objects into a
> > Linux
> > + device tree under the /sys/devices/LNXSYSTEM:00 and updates it
> > upon
> > + receiving ACPI hotplug notification events. For each device
> > object
> > + in this hierarchy there is a corresponding symbolic link in the
> > + /sys/bus/acpi/devices.
> > + This document illustrates the structure of the ACPI device tree.
>
> Well, this is a matter of preference. I would add Abstract as a chapter,
> as this would make it part of the top index, with can be useful.
>
Now it becomes a chapter. Thanks.
> In any case:
>
> Reviewed-by: Mauro Carvalho Chehab
>
> > +
> > +:Credit: Thanks for the help from Zhang Rui and
> > + Rafael J.Wysocki .
> > +
> > +
> > +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 | |
> > + | +- - - - - - - - - -+ |
> > +
Re: [PATCH v4 33/63] Documentation: PCI: convert endpoint/pci-endpoint.txt to reST
Em Wed, 24 Apr 2019 00:29:02 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/endpoint/index.rst | 10 ++
> .../{pci-endpoint.txt => pci-endpoint.rst}| 95 +++
> Documentation/PCI/index.rst | 1 +
> 3 files changed, 68 insertions(+), 38 deletions(-)
> create mode 100644 Documentation/PCI/endpoint/index.rst
> rename Documentation/PCI/endpoint/{pci-endpoint.txt => pci-endpoint.rst}
> (82%)
>
> diff --git a/Documentation/PCI/endpoint/index.rst
> b/Documentation/PCI/endpoint/index.rst
> new file mode 100644
> index ..0db4f2fcd7f0
> --- /dev/null
> +++ b/Documentation/PCI/endpoint/index.rst
> @@ -0,0 +1,10 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==
> +PCI Endpoint Framework
> +==
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + pci-endpoint
> diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt
> b/Documentation/PCI/endpoint/pci-endpoint.rst
> similarity index 82%
> rename from Documentation/PCI/endpoint/pci-endpoint.txt
> rename to Documentation/PCI/endpoint/pci-endpoint.rst
> index e86a96b66a6a..6674ce5425bf 100644
> --- a/Documentation/PCI/endpoint/pci-endpoint.txt
> +++ b/Documentation/PCI/endpoint/pci-endpoint.rst
> @@ -1,11 +1,17 @@
> - PCI ENDPOINT FRAMEWORK
> - Kishon Vijay Abraham I
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +==
> +PCI Endpoint Framework
> +==
Hmm... considering that you decided to create an index file for the
endpoint, with the same title, I would just remove this from here.
> +
> +:Author: Kishon Vijay Abraham I
>
> This document is a guide to use the PCI Endpoint Framework in order to create
> endpoint controller driver, endpoint function driver, and using configfs
> interface to bind the function driver to the controller driver.
>
> -1. Introduction
> +Introduction
> +
>
> Linux has a comprehensive PCI subsystem to support PCI controllers that
> operates in Root Complex mode. The subsystem has capability to scan PCI bus,
> @@ -19,24 +25,27 @@ add endpoint mode support in Linux. This will help to run
> Linux in an
> EP system which can have a wide variety of use cases from testing or
> validation, co-processor accelerator, etc.
>
> -2. PCI Endpoint Core
> +PCI Endpoint Core
> +=
>
> The PCI Endpoint Core layer comprises 3 components: the Endpoint Controller
> library, the Endpoint Function library, and the configfs layer to bind the
> endpoint function with the endpoint controller.
>
> -2.1 PCI Endpoint Controller(EPC) Library
> +PCI Endpoint Controller(EPC) Library
> +
>
> The EPC library provides APIs to be used by the controller that can operate
> in endpoint mode. It also provides APIs to be used by function driver/library
> in order to implement a particular endpoint function.
>
> -2.1.1 APIs for the PCI controller Driver
> +APIs for the PCI controller Driver
> +~~
>
> This section lists the APIs that the PCI Endpoint core provides to be used
> by the PCI controller driver.
>
> -*) devm_pci_epc_create()/pci_epc_create()
> +* devm_pci_epc_create()/pci_epc_create()
I would, instead, promote this as a sub-level. E. g. something like:
devm_pci_epc_create()/pci_epc_create()
..
(if you do that, you'll need to also promote some similar function
documentation within this doc)
>
> The PCI controller driver should implement the following ops:
>* write_header: ops to populate configuration space header
Better to add a blank line between those two lines. There's no sense
(IMHO) on using bold font to the first line here.
> @@ -51,110 +60,116 @@ by the PCI controller driver.
> The PCI controller driver can then create a new EPC device by invoking
> devm_pci_epc_create()/pci_epc_create().
>
> -*) devm_pci_epc_destroy()/pci_epc_destroy()
> +* devm_pci_epc_destroy()/pci_epc_destroy()
>
> The PCI controller driver can destroy the EPC device created by either
> devm_pci_epc_create() or pci_epc_create() using devm_pci_epc_destroy() or
> pci_epc_destroy().
>
> -*) pci_epc_linkup()
> +* pci_epc_linkup()
>
> In order to notify all the function devices that the EPC device to which
> they are linked has established a link with the host, the PCI controller
> driver should invoke pci_epc_linkup().
>
> -*) pci_epc_mem_init()
> +* pci_epc_mem_init()
>
> Initialize the pci_epc_mem structure used for allocating EPC addr space.
>
> -*) pci_epc_mem_exit()
> +* pci_epc_mem_exit()
>
> Cleanup the pci_epc_mem structure allocated during pci_epc_mem_init().
>
> -2.1.2 APIs
Re: [PATCH v4 32/63] Documentation: PCI: convert pcieaer-howto.txt to reST
Em Wed, 24 Apr 2019 00:29:01 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/index.rst | 1 +
> .../{pcieaer-howto.txt => pcieaer-howto.rst} | 110 --
> 2 files changed, 74 insertions(+), 37 deletions(-)
> rename Documentation/PCI/{pcieaer-howto.txt => pcieaer-howto.rst} (81%)
>
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index 5ee4dba07116..86c76c22810b 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -14,3 +14,4 @@ Linux PCI Bus Subsystem
> MSI-HOWTO
> acpi-info
> pci-error-recovery
> + pcieaer-howto
> diff --git a/Documentation/PCI/pcieaer-howto.txt
> b/Documentation/PCI/pcieaer-howto.rst
> similarity index 81%
> rename from Documentation/PCI/pcieaer-howto.txt
> rename to Documentation/PCI/pcieaer-howto.rst
> index 48ce7903e3c6..67f77ff76865 100644
> --- a/Documentation/PCI/pcieaer-howto.txt
> +++ b/Documentation/PCI/pcieaer-howto.rst
> @@ -1,21 +1,29 @@
> - The PCI Express Advanced Error Reporting Driver Guide HOWTO
> - T. Long Nguyen
> - Yanmin Zhang
> - 07/29/2006
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include::
>
> +===
> +The PCI Express Advanced Error Reporting Driver Guide HOWTO
> +===
>
> -1. Overview
> +:Authors: - T. Long Nguyen
> + - Yanmin Zhang
>
> -1.1 About this guide
> +:Copyright: |copy| 2006 Intel Corporation
> +
> +Overview
> +===
> +
> +About this guide
> +
>
> This guide describes the basics of the PCI Express Advanced Error
> Reporting (AER) driver and provides information on how to use it, as
> well as how to enable the drivers of endpoint devices to conform with
> PCI Express AER driver.
>
> -1.2 Copyright (C) Intel Corporation 2006.
>
> -1.3 What is the PCI Express AER Driver?
> +What is the PCI Express AER Driver?
> +---
>
> PCI Express error signaling can occur on the PCI Express link itself
> or on behalf of transactions initiated on the link. PCI Express
> @@ -30,17 +38,19 @@ The PCI Express AER driver provides the infrastructure to
> support PCI
> Express Advanced Error Reporting capability. The PCI Express AER
> driver provides three basic functions:
>
> --Gathers the comprehensive error information if errors occurred.
> --Reports error to the users.
> --Performs error recovery actions.
> + - Gathers the comprehensive error information if errors occurred.
> + - Reports error to the users.
> + - Performs error recovery actions.
>
> AER driver only attaches root ports which support PCI-Express AER
> capability.
>
>
> -2. User Guide
> +User Guide
> +==
>
> -2.1 Include the PCI Express AER Root Driver into the Linux Kernel
> +Include the PCI Express AER Root Driver into the Linux Kernel
> +-
>
> The PCI Express AER Root driver is a Root Port service driver attached
> to the PCI Express Port Bus driver. If a user wants to use it, the driver
> @@ -48,7 +58,8 @@ has to be compiled. Option CONFIG_PCIEAER supports this
> capability. It
> depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
> CONFIG_PCIEAER = y.
>
> -2.2 Load PCI Express AER Root Driver
> +Load PCI Express AER Root Driver
> +
>
> Some systems have AER support in firmware. Enabling Linux AER support at
> the same time the firmware handles AER may result in unpredictable
> @@ -56,30 +67,34 @@ behavior. Therefore, Linux does not handle AER events
> unless the firmware
> grants AER control to the OS via the ACPI _OSC method. See the PCI FW 3.0
> Specification for details regarding _OSC usage.
>
> -2.3 AER error output
> +AER error output
> +
>
> When a PCIe AER error is captured, an error message will be output to
> console. If it's a correctable error, it is output as a warning.
> Otherwise, it is printed as an error. So users could choose different
> log level to filter out correctable error messages.
>
> -Below shows an example:
> -:50:00.0: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction
> Layer, id=0500(Requester ID)
> -:50:00.0: device [8086:0329] error status/mask=0010/
> -:50:00.0:[20] Unsupported Request(First)
> -:50:00.0: TLP Header: 0401 00200a03 0501 00050100
> +Below shows an example::
> +
> + :50:00.0: PCIe Bus Error: severity=Uncorrected (Fatal),
> type=Transaction Layer, id=0500(Requester ID)
> + :50:00.0: device [8086:0329] error status/mask=0010/
> +
Re: [PATCH v4 00/63] Include linux ACPI/PCI/X86 docs into Sphinx TOC tree
On Tue, Apr 23, 2019 at 12:36:44PM -0500, Bjorn Helgaas wrote: > On Tue, Apr 23, 2019 at 06:39:47PM +0200, Rafael J. Wysocki wrote: > > On Tue, Apr 23, 2019 at 6:30 PM Changbin Du wrote: > > > Hi Corbet and All, > > > The kernel now uses Sphinx to generate intelligent and beautiful > > > documentation from reStructuredText files. I converted all of the Linux > > > ACPI/PCI/X86 docs to reST format in this serias. > > > > > > In this version I combined ACPI and PCI docs, and added new x86 docs > > > conversion. > > > > I'm not sure if combining all three into one big patch series has been > > a good idea, honestly. > > Yeah, if you post this again, I would find it easier to deal with if > linux-pci only got the PCI-related things. 63 patches is a little too > much for one series. > sure, so I will resend them respectively. > Bjorn -- Cheers, Changbin Du
Re: [PATCH v4 31/63] Documentation: PCI: convert pci-error-recovery.txt to reST
Em Wed, 24 Apr 2019 00:29:00 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/index.rst | 1 +
> ...or-recovery.txt => pci-error-recovery.rst} | 178 +-
> MAINTAINERS | 2 +-
> 3 files changed, 94 insertions(+), 87 deletions(-)
> rename Documentation/PCI/{pci-error-recovery.txt => pci-error-recovery.rst}
> (80%)
>
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index c877a369481d..5ee4dba07116 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -13,3 +13,4 @@ Linux PCI Bus Subsystem
> pci-iov-howto
> MSI-HOWTO
> acpi-info
> + pci-error-recovery
> diff --git a/Documentation/PCI/pci-error-recovery.txt
> b/Documentation/PCI/pci-error-recovery.rst
> similarity index 80%
> rename from Documentation/PCI/pci-error-recovery.txt
> rename to Documentation/PCI/pci-error-recovery.rst
> index 0b6bb3ef449e..533ec4035bf5 100644
> --- a/Documentation/PCI/pci-error-recovery.txt
> +++ b/Documentation/PCI/pci-error-recovery.rst
> @@ -1,12 +1,13 @@
> +.. SPDX-License-Identifier: GPL-2.0
>
> - PCI Error Recovery
> - --
> -February 2, 2006
> +==
> +PCI Error Recovery
> +==
>
> - Current document maintainer:
> - Linas Vepstas
> - updated by Richard Lary
> - and Mike Mason on 27-Jul-2009
Just wondering: wouldn't be good to preserve the date here?
> +
> +:Authors: - Linas Vepstas
> + - Richard Lary
> + - Mike Mason
>
>
> Many PCI bus controllers are able to detect a variety of hardware
> @@ -63,7 +64,8 @@ mechanisms for dealing with SCSI bus errors and SCSI bus
> resets.
>
>
> Detailed Design
>
> +===
> +
> Design and implementation details below, based on a chain of
> public email discussions with Ben Herrenschmidt, circa 5 April 2005.
>
> @@ -73,30 +75,33 @@ pci_driver. A driver that fails to provide the structure
> is "non-aware",
> and the actual recovery steps taken are platform dependent. The
> arch/powerpc implementation will simulate a PCI hotplug remove/add.
>
> -This structure has the form:
> -struct pci_error_handlers
> -{
> - int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
> - int (*mmio_enabled)(struct pci_dev *dev);
> - int (*slot_reset)(struct pci_dev *dev);
> - void (*resume)(struct pci_dev *dev);
> -};
> -
> -The possible channel states are:
> -enum pci_channel_state {
> - pci_channel_io_normal, /* I/O channel is in normal state */
> - pci_channel_io_frozen, /* I/O to channel is blocked */
> - pci_channel_io_perm_failure, /* PCI card is dead */
> -};
> -
> -Possible return values are:
> -enum pci_ers_result {
> - PCI_ERS_RESULT_NONE,/* no result/none/not supported in device
> driver */
> - PCI_ERS_RESULT_CAN_RECOVER, /* Device driver can recover without slot
> reset */
> - PCI_ERS_RESULT_NEED_RESET, /* Device driver wants slot to be reset. */
> - PCI_ERS_RESULT_DISCONNECT, /* Device has completely failed, is
> unrecoverable */
> - PCI_ERS_RESULT_RECOVERED, /* Device driver is fully recovered and
> operational */
> -};
> +This structure has the form::
> +
> + struct pci_error_handlers
> + {
> + int (*error_detected)(struct pci_dev *dev, enum
> pci_channel_state);
> + int (*mmio_enabled)(struct pci_dev *dev);
> + int (*slot_reset)(struct pci_dev *dev);
> + void (*resume)(struct pci_dev *dev);
> + };
> +
> +The possible channel states are::
> +
> + enum pci_channel_state {
> + pci_channel_io_normal, /* I/O channel is in normal state */
> + pci_channel_io_frozen, /* I/O to channel is blocked */
> + pci_channel_io_perm_failure, /* PCI card is dead */
> + };
> +
> +Possible return values are::
> +
> + enum pci_ers_result {
> + PCI_ERS_RESULT_NONE,/* no result/none/not supported in
> device driver */
> + PCI_ERS_RESULT_CAN_RECOVER, /* Device driver can recover
> without slot reset */
> + PCI_ERS_RESULT_NEED_RESET, /* Device driver wants slot to be
> reset. */
> + PCI_ERS_RESULT_DISCONNECT, /* Device has completely failed, is
> unrecoverable */
> + PCI_ERS_RESULT_RECOVERED, /* Device driver is fully recovered
> and operational */
> + };
>
> A driver does not have to implement all of these callbacks; however,
> if it implements any, it must implement error_detected(). If a callback
> @@ -134,16 +139,17 @@ shouldn't do any new IOs. Called in task context. This
> is
[RFC PATCH for 5.2 09/10] rseq/selftests: powerpc code signature: generate valid instructions
Use "twui" as the guard instruction for the restartable sequence abort
handler.
Signed-off-by: Mathieu Desnoyers
CC: Benjamin Herrenschmidt
CC: Paul Mackerras
CC: Michael Ellerman
CC: Boqun Feng
CC: Peter Zijlstra
CC: "Paul E. McKenney"
CC: Alan Modra
CC: linuxppc-dev@lists.ozlabs.org
---
tools/testing/selftests/rseq/rseq-ppc.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rseq/rseq-ppc.h
b/tools/testing/selftests/rseq/rseq-ppc.h
index 9df18487fa9f..76be90196fe4 100644
--- a/tools/testing/selftests/rseq/rseq-ppc.h
+++ b/tools/testing/selftests/rseq/rseq-ppc.h
@@ -6,7 +6,15 @@
* (C) Copyright 2016-2018 - Boqun Feng
*/
-#define RSEQ_SIG 0x53053053
+/*
+ * RSEQ_SIG is used with the following trap instruction:
+ *
+ * powerpc-be:0f e5 00 0b twui r5,11
+ * powerpc64-le: 0b 00 e5 0f twui r5,11
+ * powerpc64-be: 0f e5 00 0b twui r5,11
+ */
+
+#define RSEQ_SIG 0x0fe5000b
#define rseq_smp_mb() __asm__ __volatile__ ("sync"::: "memory",
"cc")
#define rseq_smp_lwsync() __asm__ __volatile__ ("lwsync" ::: "memory",
"cc")
--
2.11.0
Re: [PATCH v4 30/63] Documentation: PCI: convert acpi-info.txt to reST
Em Wed, 24 Apr 2019 00:28:59 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/{acpi-info.txt => acpi-info.rst} | 11 ---
> Documentation/PCI/index.rst| 1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
> rename Documentation/PCI/{acpi-info.txt => acpi-info.rst} (97%)
>
> diff --git a/Documentation/PCI/acpi-info.txt b/Documentation/PCI/acpi-info.rst
> similarity index 97%
> rename from Documentation/PCI/acpi-info.txt
> rename to Documentation/PCI/acpi-info.rst
> index 3ffa3b03970e..f7dabb7ca255 100644
> --- a/Documentation/PCI/acpi-info.txt
> +++ b/Documentation/PCI/acpi-info.rst
> @@ -1,4 +1,8 @@
> - ACPI considerations for PCI host bridges
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +
> +ACPI considerations for PCI host bridges
> +
>
> The general rule is that the ACPI namespace should describe everything the
> OS might use unless there's another way for the OS to find it [1, 2].
> @@ -135,8 +139,9 @@ address always corresponds to bus 0, even if the bus
> range below the bridge
>
> Extended Address Space Descriptor (.4)
> General Flags: Bit [0] Consumer/Producer:
> - 1–This device consumes this resource
> - 0–This device produces and consumes this resource
> +
> +* 1 – This device consumes this resource
> +* 0 – This device produces and consumes this resource
Hmm.. I think that you would need to add some extra blank lines before
the above, e. g., something like:
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
General Flags: Bit [0] Ignored
Extended Address Space Descriptor (.4)
General Flags: Bit [0] Consumer/Producer:
* 1 – This device consumes this resource
* 0 – This device produces and consumes this resource
>
> [5] ACPI 6.2, sec 19.6.43:
> ResourceUsage specifies whether the Memory range is consumed by
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index 1b25bcc1edca..c877a369481d 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -12,3 +12,4 @@ Linux PCI Bus Subsystem
> PCIEBUS-HOWTO
> pci-iov-howto
> MSI-HOWTO
> + acpi-info
Thanks,
Mauro
Re: [PATCH v4 29/63] Documentation: PCI: convert MSI-HOWTO.txt to reST
Em Wed, 24 Apr 2019 00:28:58 +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
> Acked-by: Bjorn Helgaas
>
> ---
> v2:
> o drop numbering.
> o simplify author list
> ---
> .../PCI/{MSI-HOWTO.txt => MSI-HOWTO.rst} | 83 +++
> Documentation/PCI/index.rst | 1 +
> 2 files changed, 50 insertions(+), 34 deletions(-)
> rename Documentation/PCI/{MSI-HOWTO.txt => MSI-HOWTO.rst} (88%)
Renamed names in lowercase, please.
>
> diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.rst
> similarity index 88%
> rename from Documentation/PCI/MSI-HOWTO.txt
> rename to Documentation/PCI/MSI-HOWTO.rst
> index 618e13d5e276..18cc3700489b 100644
> --- a/Documentation/PCI/MSI-HOWTO.txt
> +++ b/Documentation/PCI/MSI-HOWTO.rst
> @@ -1,13 +1,14 @@
> - The MSI Driver Guide HOWTO
> - Tom L Nguyen tom.l.ngu...@intel.com
> - 10/03/2003
> - Revised Feb 12, 2004 by Martine Silbermann
> - email: martine.silberm...@hp.com
> - Revised Jun 25, 2004 by Tom L Nguyen
> - Revised Jul 9, 2008 by Matthew Wilcox
> - Copyright 2003, 2008 Intel Corporation
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include::
>
> -1. About this guide
> +==
> +The MSI Driver Guide HOWTO
> +==
> +
> +:Authors: Tom L Nguyen; Martine Silbermann; Matthew Wilcox
Not so sure about this, as you removed the author emails.
It seems you missed to keep:
Copyright 2003, 2008 Intel Corporation
After re-adding the missing copyright:
Reviewed-by: Mauro Carvalho Chehab
> +
> +About this guide
> +
>
> This guide describes the basics of Message Signaled Interrupts (MSIs),
> the advantages of using MSI over traditional interrupt mechanisms, how
> @@ -15,7 +16,8 @@ to change your driver to use MSI or MSI-X and some basic
> diagnostics to
> try if a device doesn't support MSIs.
>
>
> -2. What are MSIs?
> +What are MSIs?
> +==
>
> A Message Signaled Interrupt is a write from the device to a special
> address which causes an interrupt to be received by the CPU.
> @@ -29,7 +31,8 @@ Devices may support both MSI and MSI-X, but only one can be
> enabled at
> a time.
>
>
> -3. Why use MSIs?
> +Why use MSIs?
> +=
>
> There are three reasons why using MSIs can give an advantage over
> traditional pin-based interrupts.
> @@ -61,14 +64,16 @@ Other possible designs include giving one interrupt to
> each packet queue
> in a network card or each port in a storage controller.
>
>
> -4. How to use MSIs
> +How to use MSIs
> +===
>
> PCI devices are initialised to use pin-based interrupts. The device
> driver has to set up the device to use MSI or MSI-X. Not all machines
> support MSIs correctly, and for those machines, the APIs described below
> will simply fail and the device will continue to use pin-based interrupts.
>
> -4.1 Include kernel support for MSIs
> +Include kernel support for MSIs
> +---
>
> To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI
> option enabled. This option is only available on some architectures,
> @@ -76,14 +81,15 @@ and it may depend on some other options also being set.
> For example,
> on x86, you must also enable X86_UP_APIC or SMP in order to see the
> CONFIG_PCI_MSI option.
>
> -4.2 Using MSI
> +Using MSI
> +-
>
> Most of the hard work is done for the driver in the PCI layer. The driver
> simply has to request that the PCI layer set up the MSI capability for this
> device.
>
> To automatically use MSI or MSI-X interrupt vectors, use the following
> -function:
> +function::
>
>int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
> unsigned int max_vecs, unsigned int flags);
> @@ -101,12 +107,12 @@ any possible kind of interrupt. If the
> PCI_IRQ_AFFINITY flag is set,
> pci_alloc_irq_vectors() will spread the interrupts around the available CPUs.
>
> To get the Linux IRQ numbers passed to request_irq() and free_irq() and the
> -vectors, use the following function:
> +vectors, use the following function::
>
>int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
>
> Any allocated resources should be freed before removing the device using
> -the following function:
> +the following function::
>
>void pci_free_irq_vectors(struct pci_dev *dev);
>
> @@ -126,7 +132,7 @@ The typical usage of MSI or MSI-X interrupts is to
> allocate as many vectors
> as possible, likely up to the limit supported by the device. If nvec is
> larger than the number supported by the device it will automatically be
> capped to the supported limit, so there is no need to query the number of
> -vectors supported
Re: [PATCH v4 28/63] Documentation: PCI: convert pci-iov-howto.txt to reST
Em Wed, 24 Apr 2019 00:28:57 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/index.rst | 1 +
> .../{pci-iov-howto.txt => pci-iov-howto.rst} | 161 ++
> 2 files changed, 94 insertions(+), 68 deletions(-)
> rename Documentation/PCI/{pci-iov-howto.txt => pci-iov-howto.rst} (63%)
Reviewed-by: Mauro Carvalho Chehab
>
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index 452723318405..e1c19962a7f8 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -10,3 +10,4 @@ Linux PCI Bus Subsystem
>
> pci
> PCIEBUS-HOWTO
> + pci-iov-howto
> diff --git a/Documentation/PCI/pci-iov-howto.txt
> b/Documentation/PCI/pci-iov-howto.rst
> similarity index 63%
> rename from Documentation/PCI/pci-iov-howto.txt
> rename to Documentation/PCI/pci-iov-howto.rst
> index d2a84151e99c..b9fd003206f1 100644
> --- a/Documentation/PCI/pci-iov-howto.txt
> +++ b/Documentation/PCI/pci-iov-howto.rst
> @@ -1,14 +1,19 @@
> - PCI Express I/O Virtualization Howto
> - Copyright (C) 2009 Intel Corporation
> - Yu Zhao
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include::
>
> - Update: November 2012
> - -- sysfs-based SRIOV enable-/disable-ment
> - Donald Dutile
> +
> +PCI Express I/O Virtualization Howto
> +
>
> -1. Overview
> +:Copyright: |copy| 2009 Intel Corporation
> +:Authors: - Yu Zhao
> + - Donald Dutile
>
> -1.1 What is SR-IOV
> +Overview
> +
> +
> +What is SR-IOV
> +--
>
> Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended
> capability which makes one physical device appear as multiple virtual
> @@ -23,9 +28,11 @@ Memory Space, which is used to map its register set. VF
> device driver
> operates on the register set so it can be functional and appear as a
> real existing PCI device.
>
> -2. User Guide
> +User Guide
> +==
>
> -2.1 How can I enable SR-IOV capability
> +How can I enable SR-IOV capability
> +--
>
> Multiple methods are available for SR-IOV enablement.
> In the first method, the device driver (PF driver) will control the
> @@ -43,105 +50,123 @@ checks, e.g., check numvfs == 0 if enabling VFs, ensure
> numvfs <= totalvfs.
> The second method is the recommended method for new/future VF devices.
>
> -2.2 How can I use the Virtual Functions
> +How can I use the Virtual Functions
> +---
>
> The VF is treated as hot-plugged PCI devices in the kernel, so they
> should be able to work in the same way as real PCI devices. The VF
> requires device driver that is same as a normal PCI device's.
>
> -3. Developer Guide
> +Developer Guide
> +===
>
> -3.1 SR-IOV API
> +SR-IOV API
> +--
>
> To enable SR-IOV capability:
> -(a) For the first method, in the driver:
> +
> +(a) For the first method, in the driver::
> +
> int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
> - 'nr_virtfn' is number of VFs to be enabled.
> -(b) For the second method, from sysfs:
> +
> +'nr_virtfn' is number of VFs to be enabled.
> +
> +(b) For the second method, from sysfs::
> +
> echo 'nr_virtfn' > \
> /sys/bus/pci/devices//sriov_numvfs
>
> To disable SR-IOV capability:
> -(a) For the first method, in the driver:
> +
> +(a) For the first method, in the driver::
> +
> void pci_disable_sriov(struct pci_dev *dev);
> -(b) For the second method, from sysfs:
> +
> +(b) For the second method, from sysfs::
> +
> echo 0 > \
> /sys/bus/pci/devices//sriov_numvfs
>
> To enable auto probing VFs by a compatible driver on the host, run
> command below before enabling SR-IOV capabilities. This is the
> default behavior.
> +::
> +
> echo 1 > \
>
> /sys/bus/pci/devices//sriov_drivers_autoprobe
>
> To disable auto probing VFs by a compatible driver on the host, run
> command below before enabling SR-IOV capabilities. Updating this
> entry will not affect VFs which are already probed.
> +::
> +
> echo 0 > \
>
> /sys/bus/pci/devices//sriov_drivers_autoprobe
>
> -3.2 Usage example
> +Usage example
> +-
>
> Following piece of code illustrates the usage of the SR-IOV API.
> +::
>
> -static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
> -{
> - pci_enable_sriov(dev, NR_VIRTFN);
> + static int dev_probe(struct pci_dev *dev, const struct pci_device_id
> *id)
> + {
> + pci_enable_sriov(dev, NR_VIRTFN);
>
> - ...
> -
> - return 0;
> -}
> + ...
>
> -static void
Re: [PATCH v4 27/63] Documentation: PCI: convert PCIEBUS-HOWTO.txt to reST
Em Wed, 24 Apr 2019 00:28:56 +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
> Acked-by: Bjorn Helgaas
> ---
> .../{PCIEBUS-HOWTO.txt => PCIEBUS-HOWTO.rst} | 140 ++
> Documentation/PCI/index.rst | 1 +
> 2 files changed, 82 insertions(+), 59 deletions(-)
> rename Documentation/PCI/{PCIEBUS-HOWTO.txt => PCIEBUS-HOWTO.rst} (70%)
Names in lowercase after rename, please.
For the changes itself at the txt file:
Reviewed-by: Mauro Carvalho Chehab
>
> diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt
> b/Documentation/PCI/PCIEBUS-HOWTO.rst
> similarity index 70%
> rename from Documentation/PCI/PCIEBUS-HOWTO.txt
> rename to Documentation/PCI/PCIEBUS-HOWTO.rst
> index 15f0bb3b5045..f882ff62c51f 100644
> --- a/Documentation/PCI/PCIEBUS-HOWTO.txt
> +++ b/Documentation/PCI/PCIEBUS-HOWTO.rst
> @@ -1,16 +1,23 @@
> - The PCI Express Port Bus Driver Guide HOWTO
> - Tom L Nguyen tom.l.ngu...@intel.com
> - 11/03/2004
> +.. SPDX-License-Identifier: GPL-2.0
> +.. include::
>
> -1. About this guide
> +===
> +The PCI Express Port Bus Driver Guide HOWTO
> +===
> +
> +:Author: Tom L Nguyen tom.l.ngu...@intel.com 11/03/2004
> +:Copyright: |copy| 2004 Intel Corporation
> +
> +About this guide
> +
>
> This guide describes the basics of the PCI Express Port Bus driver
> and provides information on how to enable the service drivers to
> register/unregister with the PCI Express Port Bus Driver.
>
> -2. Copyright 2004 Intel Corporation
>
> -3. What is the PCI Express Port Bus Driver
> +What is the PCI Express Port Bus Driver
> +===
>
> A PCI Express Port is a logical PCI-PCI Bridge structure. There
> are two types of PCI Express Port: the Root Port and the Switch
> @@ -30,7 +37,8 @@ support (AER), and virtual channel support (VC). These
> services may
> be handled by a single complex driver or be individually distributed
> and handled by corresponding service drivers.
>
> -4. Why use the PCI Express Port Bus Driver?
> +Why use the PCI Express Port Bus Driver?
> +
>
> In existing Linux kernels, the Linux Device Driver Model allows a
> physical device to be handled by only a single driver. The PCI
> @@ -51,28 +59,31 @@ PCI Express Ports and distributes all provided service
> requests
> to the corresponding service drivers as required. Some key
> advantages of using the PCI Express Port Bus driver are listed below:
>
> - - Allow multiple service drivers to run simultaneously on
> - a PCI-PCI Bridge Port device.
> + - Allow multiple service drivers to run simultaneously on
> +a PCI-PCI Bridge Port device.
>
> - - Allow service drivers implemented in an independent
> - staged approach.
> + - Allow service drivers implemented in an independent
> +staged approach.
>
> - - Allow one service driver to run on multiple PCI-PCI Bridge
> - Port devices.
> + - Allow one service driver to run on multiple PCI-PCI Bridge
> +Port devices.
>
> - - Manage and distribute resources of a PCI-PCI Bridge Port
> - device to requested service drivers.
> + - Manage and distribute resources of a PCI-PCI Bridge Port
> +device to requested service drivers.
>
> -5. Configuring the PCI Express Port Bus Driver vs. Service Drivers
> +Configuring the PCI Express Port Bus Driver vs. Service Drivers
> +===
>
> -5.1 Including the PCI Express Port Bus Driver Support into the Kernel
> +Including the PCI Express Port Bus Driver Support into the Kernel
> +-
>
> Including the PCI Express Port Bus driver depends on whether the PCI
> Express support is included in the kernel config. The kernel will
> automatically include the PCI Express Port Bus driver as a kernel
> driver when the PCI Express support is enabled in the kernel.
>
> -5.2 Enabling Service Driver Support
> +Enabling Service Driver Support
> +---
>
> PCI device drivers are implemented based on Linux Device Driver Model.
> All service drivers are PCI device drivers. As discussed above, it is
> @@ -89,9 +100,11 @@ header file /include/linux/pcieport_if.h, before calling
> these APIs.
> Failure to do so will result an identity mismatch, which prevents
> the PCI Express Port Bus driver from loading a service driver.
>
> -5.2.1 pcie_port_service_register
> +pcie_port_service_register
> +~~
> +::
>
> -int pcie_port_service_register(struct pcie_port_service_driver *new)
> + int pcie_port_service_register(struct pcie_port_service_driver
Re: [PATCH v4 26/63] Documentation: PCI: convert pci.txt to reST
Em Wed, 24 Apr 2019 00:28:55 +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
> Acked-by: Bjorn Helgaas
> ---
> Documentation/PCI/index.rst| 2 +
> Documentation/PCI/{pci.txt => pci.rst} | 267 +
> 2 files changed, 140 insertions(+), 129 deletions(-)
> rename Documentation/PCI/{pci.txt => pci.rst} (78%)
>
> diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst
> index c2f8728d11cf..7babf43709b0 100644
> --- a/Documentation/PCI/index.rst
> +++ b/Documentation/PCI/index.rst
> @@ -7,3 +7,5 @@ Linux PCI Bus Subsystem
> .. toctree::
> :maxdepth: 2
> :numbered:
> +
> + pci
See my comments to patch 25/63. It applies to all PCI stuff,
so I won't keep repeating it. Anyway, the final decision with
regards to file naming belongs to the docs maintainer and to
the PCI maintainer.
> diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.rst
> similarity index 78%
> rename from Documentation/PCI/pci.txt
> rename to Documentation/PCI/pci.rst
> index badb26ac33dc..29ddd2e9177a 100644
> --- a/Documentation/PCI/pci.txt
> +++ b/Documentation/PCI/pci.rst
I would either rename this file or Documentation/driver-api/pci/pci.rst.
Even if the decision is to keep those on different directories, it
sounds a very bad idea on my eyes to keep two files with different
content and identical names on different directories that belong to
the same subsystem.
@PCI maintainers:
The MAINTAINERS file, at the PCI SUBSYSTEM part is missing
an entry for Documentation/driver-api/pci/.
> @@ -1,10 +1,12 @@
> +.. SPDX-License-Identifier: GPL-2.0
>
> - How To Write Linux PCI Drivers
> +==
> +How To Write Linux PCI Drivers
> +==
>
> - by Martin Mares on 07-Feb-2000
> - updated by Grant Grundler on 23-Dec-2006
> +:Authors: - Martin Mares
> + - Grant Grundler
>
> -
> The world of PCI is vast and full of (mostly unpleasant) surprises.
> Since each CPU architecture implements different chip-sets and PCI devices
> have different requirements (erm, "features"), the result is the PCI support
> @@ -26,8 +28,8 @@ Please send questions/comments/patches about Linux PCI API
> to the
>
>
>
> -0. Structure of PCI drivers
> -~~~
> +Structure of PCI drivers
> +
> PCI drivers "discover" PCI devices in a system via pci_register_driver().
> Actually, it's the other way around. When the PCI generic code discovers
> a new device, the driver with a matching "description" will be notified.
> @@ -42,24 +44,25 @@ pointers and thus dictates the high level structure of a
> driver.
> Once the driver knows about a PCI device and takes ownership, the
> driver generally needs to perform the following initialization:
>
> - Enable the device
> - Request MMIO/IOP resources
> - Set the DMA mask size (for both coherent and streaming DMA)
> - Allocate and initialize shared control data (pci_allocate_coherent())
> - Access device configuration space (if needed)
> - Register IRQ handler (request_irq())
> - Initialize non-PCI (i.e. LAN/SCSI/etc parts of the chip)
> - Enable DMA/processing engines
> + - Enable the device
> + - Request MMIO/IOP resources
> + - Set the DMA mask size (for both coherent and streaming DMA)
> + - Allocate and initialize shared control data (pci_allocate_coherent())
> + - Access device configuration space (if needed)
> + - Register IRQ handler (request_irq())
> + - Initialize non-PCI (i.e. LAN/SCSI/etc parts of the chip)
> + - Enable DMA/processing engines
>
> When done using the device, and perhaps the module needs to be unloaded,
> the driver needs to take the follow steps:
> - Disable the device from generating IRQs
> - Release the IRQ (free_irq())
> - Stop all DMA activity
> - Release DMA buffers (both streaming and coherent)
> - Unregister from other subsystems (e.g. scsi or netdev)
> - Release MMIO/IOP resources
> - Disable the device
> +
> + - Disable the device from generating IRQs
> + - Release the IRQ (free_irq())
> + - Stop all DMA activity
> + - Release DMA buffers (both streaming and coherent)
> + - Unregister from other subsystems (e.g. scsi or netdev)
> + - Release MMIO/IOP resources
> + - Disable the device
>
> Most of these topics are covered in the following sections.
> For the rest look at LDD3 or .
> @@ -70,13 +73,12 @@ completely empty or just returning an appropriate error
> codes to avoid
> lots of ifdefs in the drivers.
>
>
> -
> -1. pci_register_driver() call
> -~
> +pci_register_driver() call
> +==
>
> PCI device
Re: [PATCH v12 22/31] mm: provide speculative fault infrastructure
On Wed, Apr 24, 2019 at 04:56:14PM +0200, Laurent Dufour wrote:
> Le 22/04/2019 à 23:26, Jerome Glisse a écrit :
> > On Tue, Apr 16, 2019 at 03:45:13PM +0200, Laurent Dufour wrote:
> > > From: Peter Zijlstra
> > >
> > > Provide infrastructure to do a speculative fault (not holding
> > > mmap_sem).
> > >
> > > The not holding of mmap_sem means we can race against VMA
> > > change/removal and page-table destruction. We use the SRCU VMA freeing
> > > to keep the VMA around. We use the VMA seqcount to detect change
> > > (including umapping / page-table deletion) and we use gup_fast() style
> > > page-table walking to deal with page-table races.
> > >
> > > Once we've obtained the page and are ready to update the PTE, we
> > > validate if the state we started the fault with is still valid, if
> > > not, we'll fail the fault with VM_FAULT_RETRY, otherwise we update the
> > > PTE and we're done.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel)
> > >
> > > [Manage the newly introduced pte_spinlock() for speculative page
> > > fault to fail if the VMA is touched in our back]
> > > [Rename vma_is_dead() to vma_has_changed() and declare it here]
> > > [Fetch p4d and pud]
> > > [Set vmd.sequence in __handle_mm_fault()]
> > > [Abort speculative path when handle_userfault() has to be called]
> > > [Add additional VMA's flags checks in handle_speculative_fault()]
> > > [Clear FAULT_FLAG_ALLOW_RETRY in handle_speculative_fault()]
> > > [Don't set vmf->pte and vmf->ptl if pte_map_lock() failed]
> > > [Remove warning comment about waiting for !seq&1 since we don't want
> > > to wait]
> > > [Remove warning about no huge page support, mention it explictly]
> > > [Don't call do_fault() in the speculative path as __do_fault() calls
> > > vma->vm_ops->fault() which may want to release mmap_sem]
> > > [Only vm_fault pointer argument for vma_has_changed()]
> > > [Fix check against huge page, calling pmd_trans_huge()]
> > > [Use READ_ONCE() when reading VMA's fields in the speculative path]
> > > [Explicitly check for __HAVE_ARCH_PTE_SPECIAL as we can't support for
> > > processing done in vm_normal_page()]
> > > [Check that vma->anon_vma is already set when starting the speculative
> > > path]
> > > [Check for memory policy as we can't support MPOL_INTERLEAVE case due to
> > > the processing done in mpol_misplaced()]
> > > [Don't support VMA growing up or down]
> > > [Move check on vm_sequence just before calling handle_pte_fault()]
> > > [Don't build SPF services if !CONFIG_SPECULATIVE_PAGE_FAULT]
> > > [Add mem cgroup oom check]
> > > [Use READ_ONCE to access p*d entries]
> > > [Replace deprecated ACCESS_ONCE() by READ_ONCE() in vma_has_changed()]
> > > [Don't fetch pte again in handle_pte_fault() when running the speculative
> > > path]
> > > [Check PMD against concurrent collapsing operation]
> > > [Try spin lock the pte during the speculative path to avoid deadlock with
> > > other CPU's invalidating the TLB and requiring this CPU to catch the
> > > inter processor's interrupt]
> > > [Move define of FAULT_FLAG_SPECULATIVE here]
> > > [Introduce __handle_speculative_fault() and add a check against
> > > mm->mm_users in handle_speculative_fault() defined in mm.h]
> > > [Abort if vm_ops->fault is set instead of checking only vm_ops]
> > > [Use find_vma_rcu() and call put_vma() when we are done with the VMA]
> > > Signed-off-by: Laurent Dufour
> >
> >
> > Few comments and questions for this one see below.
> >
> >
> > > ---
> > > include/linux/hugetlb_inline.h | 2 +-
> > > include/linux/mm.h | 30 +++
> > > include/linux/pagemap.h| 4 +-
> > > mm/internal.h | 15 ++
> > > mm/memory.c| 344 -
> > > 5 files changed, 389 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/include/linux/hugetlb_inline.h
> > > b/include/linux/hugetlb_inline.h
> > > index 0660a03d37d9..9e25283d6fc9 100644
> > > --- a/include/linux/hugetlb_inline.h
> > > +++ b/include/linux/hugetlb_inline.h
> > > @@ -8,7 +8,7 @@
> > > static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
> > > {
> > > - return !!(vma->vm_flags & VM_HUGETLB);
> > > + return !!(READ_ONCE(vma->vm_flags) & VM_HUGETLB);
> > > }
> > > #else
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index f761a9c65c74..ec609cbad25a 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -381,6 +381,7 @@ extern pgprot_t protection_map[16];
> > > #define FAULT_FLAG_USER 0x40/* The fault originated in
> > > userspace */
> > > #define FAULT_FLAG_REMOTE 0x80/* faulting for non current
> > > tsk/mm */
> > > #define FAULT_FLAG_INSTRUCTION 0x100 /* The fault was during an
> > > instruction fetch */
> > > +#define FAULT_FLAG_SPECULATIVE 0x200 /* Speculative fault, not
> > > holding mmap_sem */
> > > #define FAULT_FLAG_TRACE \
> > > { FAULT_FLAG_WRITE,
Re: [PATCH v4 25/63] Documentation: add Linux PCI to Sphinx TOC tree
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. > Documentation/index.rst | 1 + > 2 files changed, 10 insertions(+) > create mode 100644 Documentation/PCI/index.rst > > diff --git a/Documentation/PCI/index.rst b/Documentation/PCI/index.rst > new file mode 100644 > index ..c2f8728d11cf > --- /dev/null > +++ b/Documentation/PCI/index.rst > @@ -0,0 +1,9 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +=== > +Linux PCI Bus Subsystem > +=== > + > +.. toctree:: > + :maxdepth: 2 > + :numbered: > diff --git a/Documentation/index.rst b/Documentation/index.rst > index fdfa85c56a50..d80138284e0f 100644 > --- a/Documentation/index.rst > +++ b/Documentation/index.rst > @@ -100,6 +100,7 @@ needed). > filesystems/index > vm/index > bpf/index > + PCI/index > misc-devices/index > > Architecture-specific documentation Thanks, Mauro
Re: [PATCH v12 23/31] mm: don't do swap readahead during speculative page fault
Le 22/04/2019 à 23:36, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:14PM +0200, Laurent Dufour wrote:
Vinayak Menon faced a panic because one thread was page faulting a page in
swap, while another one was mprotecting a part of the VMA leading to a VMA
split.
This raise a panic in swap_vma_readahead() because the VMA's boundaries
were not more matching the faulting address.
To avoid this, if the page is not found in the swap, the speculative page
fault is aborted to retry a regular page fault.
Reported-by: Vinayak Menon
Signed-off-by: Laurent Dufour
Reviewed-by: Jérôme Glisse
Note that you should also skip non swap entry in do_swap_page() when doing
speculative page fault at very least you need to is_device_private_entry()
case.
But this should either be part of patch 22 or another patch to fix swap
case.
Thanks Jérôme,
Yes I missed that, I guess the best option would be to abort on non swap
entry. I'll add that in the patch 22.
---
mm/memory.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 6e6bf61c0e5c..1991da97e2db 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2900,6 +2900,17 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
lru_cache_add_anon(page);
swap_readpage(page, true);
}
+ } else if (vmf->flags & FAULT_FLAG_SPECULATIVE) {
+ /*
+* Don't try readahead during a speculative page fault
+* as the VMA's boundaries may change in our back.
+* If the page is not in the swap cache and synchronous
+* read is disabled, fall back to the regular page
+* fault mechanism.
+*/
+ delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
+ ret = VM_FAULT_RETRY;
+ goto out;
} else {
page = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE,
vmf);
--
2.21.0
Re: [PATCH v4 24/63] Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:53 +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/firmware-guide/acpi/index.rst | 1 +
> .../acpi/video_extension.rst} | 63 ++-
> 2 files changed, 36 insertions(+), 28 deletions(-)
> rename Documentation/{acpi/video_extension.txt =>
> firmware-guide/acpi/video_extension.rst} (79%)
>
> 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 79%
> rename from Documentation/acpi/video_extension.txt
> rename to Documentation/firmware-guide/acpi/video_extension.rst
> index 79bf6a4921be..06f7e3230b6e 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,10 @@ 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 does 3 things regarding backlight control.
>
> -1 Export a sysfs interface for user space to control backlight level
> +1. 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
Hmm... you didn't touch on this part of the document:
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
You should touch it. My suggestion here is:
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
> @@ -32,26 +36,26 @@ 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 +66,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
> +2. Notify user space about hotkey event
>
Re: [PATCH v12 22/31] mm: provide speculative fault infrastructure
Le 22/04/2019 à 23:26, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:13PM +0200, Laurent Dufour wrote:
From: Peter Zijlstra
Provide infrastructure to do a speculative fault (not holding
mmap_sem).
The not holding of mmap_sem means we can race against VMA
change/removal and page-table destruction. We use the SRCU VMA freeing
to keep the VMA around. We use the VMA seqcount to detect change
(including umapping / page-table deletion) and we use gup_fast() style
page-table walking to deal with page-table races.
Once we've obtained the page and are ready to update the PTE, we
validate if the state we started the fault with is still valid, if
not, we'll fail the fault with VM_FAULT_RETRY, otherwise we update the
PTE and we're done.
Signed-off-by: Peter Zijlstra (Intel)
[Manage the newly introduced pte_spinlock() for speculative page
fault to fail if the VMA is touched in our back]
[Rename vma_is_dead() to vma_has_changed() and declare it here]
[Fetch p4d and pud]
[Set vmd.sequence in __handle_mm_fault()]
[Abort speculative path when handle_userfault() has to be called]
[Add additional VMA's flags checks in handle_speculative_fault()]
[Clear FAULT_FLAG_ALLOW_RETRY in handle_speculative_fault()]
[Don't set vmf->pte and vmf->ptl if pte_map_lock() failed]
[Remove warning comment about waiting for !seq&1 since we don't want
to wait]
[Remove warning about no huge page support, mention it explictly]
[Don't call do_fault() in the speculative path as __do_fault() calls
vma->vm_ops->fault() which may want to release mmap_sem]
[Only vm_fault pointer argument for vma_has_changed()]
[Fix check against huge page, calling pmd_trans_huge()]
[Use READ_ONCE() when reading VMA's fields in the speculative path]
[Explicitly check for __HAVE_ARCH_PTE_SPECIAL as we can't support for
processing done in vm_normal_page()]
[Check that vma->anon_vma is already set when starting the speculative
path]
[Check for memory policy as we can't support MPOL_INTERLEAVE case due to
the processing done in mpol_misplaced()]
[Don't support VMA growing up or down]
[Move check on vm_sequence just before calling handle_pte_fault()]
[Don't build SPF services if !CONFIG_SPECULATIVE_PAGE_FAULT]
[Add mem cgroup oom check]
[Use READ_ONCE to access p*d entries]
[Replace deprecated ACCESS_ONCE() by READ_ONCE() in vma_has_changed()]
[Don't fetch pte again in handle_pte_fault() when running the speculative
path]
[Check PMD against concurrent collapsing operation]
[Try spin lock the pte during the speculative path to avoid deadlock with
other CPU's invalidating the TLB and requiring this CPU to catch the
inter processor's interrupt]
[Move define of FAULT_FLAG_SPECULATIVE here]
[Introduce __handle_speculative_fault() and add a check against
mm->mm_users in handle_speculative_fault() defined in mm.h]
[Abort if vm_ops->fault is set instead of checking only vm_ops]
[Use find_vma_rcu() and call put_vma() when we are done with the VMA]
Signed-off-by: Laurent Dufour
Few comments and questions for this one see below.
---
include/linux/hugetlb_inline.h | 2 +-
include/linux/mm.h | 30 +++
include/linux/pagemap.h| 4 +-
mm/internal.h | 15 ++
mm/memory.c| 344 -
5 files changed, 389 insertions(+), 6 deletions(-)
diff --git a/include/linux/hugetlb_inline.h b/include/linux/hugetlb_inline.h
index 0660a03d37d9..9e25283d6fc9 100644
--- a/include/linux/hugetlb_inline.h
+++ b/include/linux/hugetlb_inline.h
@@ -8,7 +8,7 @@
static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
{
- return !!(vma->vm_flags & VM_HUGETLB);
+ return !!(READ_ONCE(vma->vm_flags) & VM_HUGETLB);
}
#else
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f761a9c65c74..ec609cbad25a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -381,6 +381,7 @@ extern pgprot_t protection_map[16];
#define FAULT_FLAG_USER 0x40/* The fault originated in
userspace */
#define FAULT_FLAG_REMOTE 0x80/* faulting for non current tsk/mm */
#define FAULT_FLAG_INSTRUCTION 0x100 /* The fault was during an instruction
fetch */
+#define FAULT_FLAG_SPECULATIVE 0x200 /* Speculative fault, not holding
mmap_sem */
#define FAULT_FLAG_TRACE \
{ FAULT_FLAG_WRITE, "WRITE" }, \
@@ -409,6 +410,10 @@ struct vm_fault {
gfp_t gfp_mask; /* gfp mask to be used for allocations
*/
pgoff_t pgoff; /* Logical page offset based on vma */
unsigned long address; /* Faulting virtual address */
+#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
+ unsigned int sequence;
+ pmd_t orig_pmd; /* value of PMD at the time of fault */
+#endif
pmd_t *pmd; /* Pointer to pmd entry matching
* the 'address' */
pud_t *pud; /* Pointer to
Re: [PATCH v4 23/63] Documentation: ACPI: move ssdt-overlays.txt to admin-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:52 +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
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
Re: [PATCH v4 22/63] Documentation: ACPI: move lpit.txt to firmware-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:51 +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
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
Thanks,
Mauro
Re: [PATCH v4 21/63] Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:50 +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
> ---
> .../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
Hmm... removed by mistake?
> +Some of the CPPC registers are exposed via sysfs under::
>
> -
> + /sys/devices/system/cpu/cpuX/acpi_cppc/
Did you parse this with Sphinx? It doesn't sound a valid ReST construction
to my eyes, as:
1) I've seen some versions of Sphinx to abort with severe errors when
there's no blank line after the horizontal bar markup;
2) It will very likely ignore the "::" (I didn't test it myself), as you're
not indenting the horizontal bar. End of indentation will mean the end
of an (empty) literal block.
So, I would stick with:
Some of the CPPC registers are exposed via sysfs under:
/sys/devices/system/cpu/cpuX/acpi_cppc/
-
for each cpu X::
or:
Some of the CPPC registers are exposed via sysfs under:
/sys/devices/system/cpu/cpuX/acpi_cppc/
for each cpu X
::
(with is closer to the original author's intent)
Same applies to the other similar changes on this document.
>
> -$ 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
[PATCH AUTOSEL 4.14 29/35] kmemleak: powerpc: skip scanning holes in the .bss section
From: Catalin Marinas
[ Upstream commit 298a32b132087550d3fa80641ca58323c5dfd4d9 ]
Commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocator.
kernel_init
kvm_guest_init
kvm_free_tmp
free_reserved_area
free_unref_page
free_unref_page_prepare
With DEBUG_PAGEALLOC=y, it will unmap those pages from kernel. As the
result, kmemleak scan will trigger a panic when it scans the .bss
section with unmapped pages.
This patch creates dedicated kmemleak objects for the .data, .bss and
potentially .data..ro_after_init sections to allow partial freeing via
the kmemleak_free_part() in the powerpc kvm_free_tmp() function.
Link: http://lkml.kernel.org/r/20190321171917.62049-1-catalin.mari...@arm.com
Signed-off-by: Catalin Marinas
Reported-by: Qian Cai
Acked-by: Michael Ellerman (powerpc)
Tested-by: Qian Cai
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Avi Kivity
Cc: Paolo Bonzini
Cc: Radim Krcmar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/powerpc/kernel/kvm.c | 7 +++
mm/kmemleak.c | 16 +++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index 9ad37f827a97..7b59cc853abf 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -712,6 +713,12 @@ static void kvm_use_magic_page(void)
static __init void kvm_free_tmp(void)
{
+ /*
+* Inform kmemleak about the hole in the .bss section since the
+* corresponding pages will be unmapped with DEBUG_PAGEALLOC=y.
+*/
+ kmemleak_free_part(_tmp[kvm_tmp_index],
+ ARRAY_SIZE(kvm_tmp) - kvm_tmp_index);
free_reserved_area(_tmp[kvm_tmp_index],
_tmp[ARRAY_SIZE(kvm_tmp)], -1, NULL);
}
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index d9e0be2a8189..337be9aacb7a 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1492,11 +1492,6 @@ static void kmemleak_scan(void)
}
rcu_read_unlock();
- /* data/bss scanning */
- scan_large_block(_sdata, _edata);
- scan_large_block(__bss_start, __bss_stop);
- scan_large_block(__start_ro_after_init, __end_ro_after_init);
-
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
for_each_possible_cpu(i)
@@ -2027,6 +2022,17 @@ void __init kmemleak_init(void)
}
local_irq_restore(flags);
+ /* register the data/bss sections */
+ create_object((unsigned long)_sdata, _edata - _sdata,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ create_object((unsigned long)__bss_start, __bss_stop - __bss_start,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ /* only register .data..ro_after_init if not within .data */
+ if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata)
+ create_object((unsigned long)__start_ro_after_init,
+ __end_ro_after_init - __start_ro_after_init,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+
/*
* This is the point where tracking allocations is safe. Automatic
* scanning is started during the late initcall. Add the early logged
--
2.19.1
Re: [PATCH v12 21/31] mm: Introduce find_vma_rcu()
Le 22/04/2019 à 22:57, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:12PM +0200, Laurent Dufour wrote:
This allows to search for a VMA structure without holding the mmap_sem.
The search is repeated while the mm seqlock is changing and until we found
a valid VMA.
While under the RCU protection, a reference is taken on the VMA, so the
caller must call put_vma() once it not more need the VMA structure.
At the time a VMA is inserted in the MM RB tree, in vma_rb_insert(), a
reference is taken to the VMA by calling get_vma().
When removing a VMA from the MM RB tree, the VMA is not release immediately
but at the end of the RCU grace period through vm_rcu_put(). This ensures
that the VMA remains allocated until the end the RCU grace period.
Since the vm_file pointer, if valid, is released in put_vma(), there is no
guarantee that the file pointer will be valid on the returned VMA.
Signed-off-by: Laurent Dufour
Minor comments about comment (i love recursion :)) see below.
Reviewed-by: Jérôme Glisse
Thanks Jérôme, see my comments to your comments on my comments below ;)
---
include/linux/mm_types.h | 1 +
mm/internal.h| 5 ++-
mm/mmap.c| 76 ++--
3 files changed, 78 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 6a6159e11a3f..9af6694cb95d 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -287,6 +287,7 @@ struct vm_area_struct {
#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
atomic_t vm_ref_count;
+ struct rcu_head vm_rcu;
#endif
struct rb_node vm_rb;
diff --git a/mm/internal.h b/mm/internal.h
index 302382bed406..1e368e4afe3c 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -55,7 +55,10 @@ static inline void put_vma(struct vm_area_struct *vma)
__free_vma(vma);
}
-#else
+extern struct vm_area_struct *find_vma_rcu(struct mm_struct *mm,
+ unsigned long addr);
+
+#else /* CONFIG_SPECULATIVE_PAGE_FAULT */
static inline void get_vma(struct vm_area_struct *vma)
{
diff --git a/mm/mmap.c b/mm/mmap.c
index c106440dcae7..34bf261dc2c8 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -179,6 +179,18 @@ static inline void mm_write_sequnlock(struct mm_struct *mm)
{
write_sequnlock(>mm_seq);
}
+
+static void __vm_rcu_put(struct rcu_head *head)
+{
+ struct vm_area_struct *vma = container_of(head, struct vm_area_struct,
+ vm_rcu);
+ put_vma(vma);
+}
+static void vm_rcu_put(struct vm_area_struct *vma)
+{
+ VM_BUG_ON_VMA(!RB_EMPTY_NODE(>vm_rb), vma);
+ call_rcu(>vm_rcu, __vm_rcu_put);
+}
#else
static inline void mm_write_seqlock(struct mm_struct *mm)
{
@@ -190,6 +202,8 @@ static inline void mm_write_sequnlock(struct mm_struct *mm)
void __free_vma(struct vm_area_struct *vma)
{
+ if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT))
+ VM_BUG_ON_VMA(!RB_EMPTY_NODE(>vm_rb), vma);
mpol_put(vma_policy(vma));
vm_area_free(vma);
}
@@ -197,11 +211,24 @@ void __free_vma(struct vm_area_struct *vma)
/*
* Close a vm structure and free it, returning the next.
*/
-static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
+static struct vm_area_struct *__remove_vma(struct vm_area_struct *vma)
{
struct vm_area_struct *next = vma->vm_next;
might_sleep();
+ if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT) &&
+ !RB_EMPTY_NODE(>vm_rb)) {
+ /*
+* If the VMA is still linked in the RB tree, we must release
+* that reference by calling put_vma().
+* This should only happen when called from exit_mmap().
+* We forcely clear the node to satisfy the chec in
^
Typo: chec -> check
Yep
+* __free_vma(). This is safe since the RB tree is not walked
+* anymore.
+*/
+ RB_CLEAR_NODE(>vm_rb);
+ put_vma(vma);
+ }
if (vma->vm_ops && vma->vm_ops->close)
vma->vm_ops->close(vma);
if (vma->vm_file)
@@ -211,6 +238,13 @@ static struct vm_area_struct *remove_vma(struct
vm_area_struct *vma)
return next;
}
+static struct vm_area_struct *remove_vma(struct vm_area_struct *vma)
+{
+ if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT))
+ VM_BUG_ON_VMA(!RB_EMPTY_NODE(>vm_rb), vma);
Adding a comment here explaining the BUG_ON so people can understand
what is wrong if that happens. For instance:
/*
* remove_vma() should be call only once a vma have been remove from the rbtree
* at which point the vma->vm_rb is an empty node. The exception is when vmas
* are destroy through exit_mmap() in which case we do not bother updating the
* rbtree (see comment in __remove_vma()).
[PATCH AUTOSEL 4.19 44/52] kmemleak: powerpc: skip scanning holes in the .bss section
From: Catalin Marinas
[ Upstream commit 298a32b132087550d3fa80641ca58323c5dfd4d9 ]
Commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocator.
kernel_init
kvm_guest_init
kvm_free_tmp
free_reserved_area
free_unref_page
free_unref_page_prepare
With DEBUG_PAGEALLOC=y, it will unmap those pages from kernel. As the
result, kmemleak scan will trigger a panic when it scans the .bss
section with unmapped pages.
This patch creates dedicated kmemleak objects for the .data, .bss and
potentially .data..ro_after_init sections to allow partial freeing via
the kmemleak_free_part() in the powerpc kvm_free_tmp() function.
Link: http://lkml.kernel.org/r/20190321171917.62049-1-catalin.mari...@arm.com
Signed-off-by: Catalin Marinas
Reported-by: Qian Cai
Acked-by: Michael Ellerman (powerpc)
Tested-by: Qian Cai
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Avi Kivity
Cc: Paolo Bonzini
Cc: Radim Krcmar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/powerpc/kernel/kvm.c | 7 +++
mm/kmemleak.c | 16 +++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index 683b5b3805bd..cd381e2291df 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -712,6 +713,12 @@ static void kvm_use_magic_page(void)
static __init void kvm_free_tmp(void)
{
+ /*
+* Inform kmemleak about the hole in the .bss section since the
+* corresponding pages will be unmapped with DEBUG_PAGEALLOC=y.
+*/
+ kmemleak_free_part(_tmp[kvm_tmp_index],
+ ARRAY_SIZE(kvm_tmp) - kvm_tmp_index);
free_reserved_area(_tmp[kvm_tmp_index],
_tmp[ARRAY_SIZE(kvm_tmp)], -1, NULL);
}
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 17dd883198ae..5912a26e041c 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1501,11 +1501,6 @@ static void kmemleak_scan(void)
}
rcu_read_unlock();
- /* data/bss scanning */
- scan_large_block(_sdata, _edata);
- scan_large_block(__bss_start, __bss_stop);
- scan_large_block(__start_ro_after_init, __end_ro_after_init);
-
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
for_each_possible_cpu(i)
@@ -2036,6 +2031,17 @@ void __init kmemleak_init(void)
}
local_irq_restore(flags);
+ /* register the data/bss sections */
+ create_object((unsigned long)_sdata, _edata - _sdata,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ create_object((unsigned long)__bss_start, __bss_stop - __bss_start,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ /* only register .data..ro_after_init if not within .data */
+ if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata)
+ create_object((unsigned long)__start_ro_after_init,
+ __end_ro_after_init - __start_ro_after_init,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+
/*
* This is the point where tracking allocations is safe. Automatic
* scanning is started during the late initcall. Add the early logged
--
2.19.1
[PATCH AUTOSEL 5.0 53/66] kmemleak: powerpc: skip scanning holes in the .bss section
From: Catalin Marinas
[ Upstream commit 298a32b132087550d3fa80641ca58323c5dfd4d9 ]
Commit 2d4f567103ff ("KVM: PPC: Introduce kvm_tmp framework") adds
kvm_tmp[] into the .bss section and then free the rest of unused spaces
back to the page allocator.
kernel_init
kvm_guest_init
kvm_free_tmp
free_reserved_area
free_unref_page
free_unref_page_prepare
With DEBUG_PAGEALLOC=y, it will unmap those pages from kernel. As the
result, kmemleak scan will trigger a panic when it scans the .bss
section with unmapped pages.
This patch creates dedicated kmemleak objects for the .data, .bss and
potentially .data..ro_after_init sections to allow partial freeing via
the kmemleak_free_part() in the powerpc kvm_free_tmp() function.
Link: http://lkml.kernel.org/r/20190321171917.62049-1-catalin.mari...@arm.com
Signed-off-by: Catalin Marinas
Reported-by: Qian Cai
Acked-by: Michael Ellerman (powerpc)
Tested-by: Qian Cai
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: Avi Kivity
Cc: Paolo Bonzini
Cc: Radim Krcmar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin (Microsoft)
---
arch/powerpc/kernel/kvm.c | 7 +++
mm/kmemleak.c | 16 +++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/kvm.c b/arch/powerpc/kernel/kvm.c
index 683b5b3805bd..cd381e2291df 100644
--- a/arch/powerpc/kernel/kvm.c
+++ b/arch/powerpc/kernel/kvm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -712,6 +713,12 @@ static void kvm_use_magic_page(void)
static __init void kvm_free_tmp(void)
{
+ /*
+* Inform kmemleak about the hole in the .bss section since the
+* corresponding pages will be unmapped with DEBUG_PAGEALLOC=y.
+*/
+ kmemleak_free_part(_tmp[kvm_tmp_index],
+ ARRAY_SIZE(kvm_tmp) - kvm_tmp_index);
free_reserved_area(_tmp[kvm_tmp_index],
_tmp[ARRAY_SIZE(kvm_tmp)], -1, NULL);
}
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 707fa5579f66..6c318f5ac234 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1529,11 +1529,6 @@ static void kmemleak_scan(void)
}
rcu_read_unlock();
- /* data/bss scanning */
- scan_large_block(_sdata, _edata);
- scan_large_block(__bss_start, __bss_stop);
- scan_large_block(__start_ro_after_init, __end_ro_after_init);
-
#ifdef CONFIG_SMP
/* per-cpu sections scanning */
for_each_possible_cpu(i)
@@ -2071,6 +2066,17 @@ void __init kmemleak_init(void)
}
local_irq_restore(flags);
+ /* register the data/bss sections */
+ create_object((unsigned long)_sdata, _edata - _sdata,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ create_object((unsigned long)__bss_start, __bss_stop - __bss_start,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+ /* only register .data..ro_after_init if not within .data */
+ if (__start_ro_after_init < _sdata || __end_ro_after_init > _edata)
+ create_object((unsigned long)__start_ro_after_init,
+ __end_ro_after_init - __start_ro_after_init,
+ KMEMLEAK_GREY, GFP_ATOMIC);
+
/*
* This is the point where tracking allocations is safe. Automatic
* scanning is started during the late initcall. Add the early logged
--
2.19.1
Re: [PATCH v4 20/63] Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:49 +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
> ---
> .../acpi/apei/einj.rst} | 98 ++-
> Documentation/firmware-guide/acpi/index.rst | 1 +
> 2 files changed, 53 insertions(+), 46 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..d85e2667155c 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.
>
> @@ -35,22 +38,22 @@ The following files belong to it:
>
> - available_error_type
>
> - 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
> + 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
This is a table and not a literal block.
The best here to preserve the author's intent is to just adjust the table
markups in order to make it parseable, e. g.:
This file shows which error types are supported:
===
Error Type Value Error Description
===
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
===
After such change:
Reviewed-by: Mauro Carvalho Chehab
>
>
Re: [PATCH v4 19/63] Documentation: ACPI: move apei/output_format.txt to firmware-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:48 +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 For the conversion changes: 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 -string> 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 -strings> 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 @@ > +..
Re: [PATCH v4 18/63] Documentation: ACPI: move aml-debugger.txt to firmware-guide/acpi and convert to reST
Em Wed, 24 Apr 2019 00:28:47 +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 For the conversion changes: 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
Re: [PATCH v4 17/63] Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi and convert to rsST
Em Wed, 24 Apr 2019 00:28:46 +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/acpi/method-tracing.txt | 192 --- > Documentation/firmware-guide/acpi/index.rst | 1 + > .../firmware-guide/acpi/method-tracing.rst| 225 ++ > 3 files changed, 226 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]
Re: [PATCH v12 20/31] mm: introduce vma reference counter
Le 22/04/2019 à 22:36, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:11PM +0200, Laurent Dufour wrote:
The final goal is to be able to use a VMA structure without holding the
mmap_sem and to be sure that the structure will not be freed in our back.
The lockless use of the VMA will be done through RCU protection and thus a
dedicated freeing service is required to manage it asynchronously.
As reported in a 2010's thread [1], this may impact file handling when a
file is still referenced while the mapping is no more there. As the final
goal is to handle anonymous VMA in a speculative way and not file backed
mapping, we could close and free the file pointer in a synchronous way, as
soon as we are guaranteed to not use it without holding the mmap_sem. For
sanity reason, in a minimal effort, the vm_file file pointer is unset once
the file pointer is put.
[1] https://lore.kernel.org/linux-mm/20100104182429.833180...@chello.nl/
Signed-off-by: Laurent Dufour
Using kref would have been better from my POV even with RCU freeing
but anyway:
Reviewed-by: Jérôme Glisse
Thanks Jérôme,
I think kref is a good option here, I'll give it a try.
---
include/linux/mm.h | 4
include/linux/mm_types.h | 3 +++
mm/internal.h| 27 +++
mm/mmap.c| 13 +
4 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f14b2c9ddfd4..f761a9c65c74 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -529,6 +529,9 @@ static inline void vma_init(struct vm_area_struct *vma,
struct mm_struct *mm)
vma->vm_mm = mm;
vma->vm_ops = _vm_ops;
INIT_LIST_HEAD(>anon_vma_chain);
+#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
+ atomic_set(>vm_ref_count, 1);
+#endif
}
static inline void vma_set_anonymous(struct vm_area_struct *vma)
@@ -1418,6 +1421,7 @@ static inline void INIT_VMA(struct vm_area_struct *vma)
INIT_LIST_HEAD(>anon_vma_chain);
#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
seqcount_init(>vm_sequence);
+ atomic_set(>vm_ref_count, 1);
#endif
}
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 24b3f8ce9e42..6a6159e11a3f 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -285,6 +285,9 @@ struct vm_area_struct {
/* linked list of VM areas per task, sorted by address */
struct vm_area_struct *vm_next, *vm_prev;
+#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
+ atomic_t vm_ref_count;
+#endif
struct rb_node vm_rb;
/*
diff --git a/mm/internal.h b/mm/internal.h
index 9eeaf2b95166..302382bed406 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -40,6 +40,33 @@ void page_writeback_init(void);
vm_fault_t do_swap_page(struct vm_fault *vmf);
+
+extern void __free_vma(struct vm_area_struct *vma);
+
+#ifdef CONFIG_SPECULATIVE_PAGE_FAULT
+static inline void get_vma(struct vm_area_struct *vma)
+{
+ atomic_inc(>vm_ref_count);
+}
+
+static inline void put_vma(struct vm_area_struct *vma)
+{
+ if (atomic_dec_and_test(>vm_ref_count))
+ __free_vma(vma);
+}
+
+#else
+
+static inline void get_vma(struct vm_area_struct *vma)
+{
+}
+
+static inline void put_vma(struct vm_area_struct *vma)
+{
+ __free_vma(vma);
+}
+#endif /* CONFIG_SPECULATIVE_PAGE_FAULT */
+
void free_pgtables(struct mmu_gather *tlb, struct vm_area_struct *start_vma,
unsigned long floor, unsigned long ceiling);
diff --git a/mm/mmap.c b/mm/mmap.c
index f7f6027a7dff..c106440dcae7 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -188,6 +188,12 @@ static inline void mm_write_sequnlock(struct mm_struct *mm)
}
#endif /* CONFIG_SPECULATIVE_PAGE_FAULT */
+void __free_vma(struct vm_area_struct *vma)
+{
+ mpol_put(vma_policy(vma));
+ vm_area_free(vma);
+}
+
/*
* Close a vm structure and free it, returning the next.
*/
@@ -200,8 +206,8 @@ static struct vm_area_struct *remove_vma(struct
vm_area_struct *vma)
vma->vm_ops->close(vma);
if (vma->vm_file)
fput(vma->vm_file);
- mpol_put(vma_policy(vma));
- vm_area_free(vma);
+ vma->vm_file = NULL;
+ put_vma(vma);
return next;
}
@@ -990,8 +996,7 @@ int __vma_adjust(struct vm_area_struct *vma, unsigned long start,
if (next->anon_vma)
anon_vma_merge(vma, next);
mm->map_count--;
- mpol_put(vma_policy(next));
- vm_area_free(next);
+ put_vma(next);
/*
* In mprotect's case 6 (see comments on vma_merge),
* we must remove another next too. It would clutter
--
2.21.0
Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option
Hi Thomas, On Tue, Apr 16, 2019 at 09:26:13PM +0200, Thomas Gleixner wrote: > On Fri, 12 Apr 2019, Josh Poimboeuf wrote: > > > Configure arm64 runtime CPU speculation bug mitigations in accordance > > with the 'mitigations=' cmdline option. This affects Meltdown, Spectre > > v2, and Speculative Store Bypass. > > > > The default behavior is unchanged. > > > > Signed-off-by: Josh Poimboeuf > > --- > > NOTE: This is based on top of Jeremy Linton's patches: > > https://lkml.kernel.org/r/20190410231237.52506-1-jeremy.lin...@arm.com > > So I keep that out and we have to revisit that once the ARM64 stuff hits a > tree, right? I can have a branch with just the 4 first patches applied > which ARM64 folks can pull in when they apply Jeremy's patches before te > merge window. I'm assuming that this refers to the core/speculation branch in tip: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=core/speculation but please can you confirm that I'm good to pull that into arm64? Cheers, Will
Re: [PATCH v1 03/27] powerpc/mm: don't BUG() in slice_mask_for_size()
Le 11/04/2019 à 07:41, Aneesh Kumar K.V a écrit : Christophe Leroy writes: When no mask is found for the page size, WARN() and return NULL instead of BUG()ing. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/slice.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c index aec91dbcdc0b..011d470ea340 100644 --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -165,7 +165,8 @@ static struct slice_mask *slice_mask_for_size(struct mm_struct *mm, int psize) if (psize == MMU_PAGE_16G) return >context.mask_16g; #endif - BUG(); + WARN_ON(true); + return NULL; } Same here. There are not catching runtime errors. We should never find that true. This is to catch mistakes during development changes. Switch to VM_BUG_ON? Ok, I'll switch to VM_BUG_ON() Christophe #elif defined(CONFIG_PPC_8xx) static struct slice_mask *slice_mask_for_size(struct mm_struct *mm, int psize) @@ -178,7 +179,8 @@ static struct slice_mask *slice_mask_for_size(struct mm_struct *mm, int psize) if (psize == MMU_PAGE_8M) return >context.mask_8m; #endif - BUG(); + WARN_ON(true); + return NULL; } #else #error "Must define the slice masks for page sizes supported by the platform" -- 2.13.3
Re: [PATCH v1 02/27] powerpc/mm: don't BUG in add_huge_page_size()
Le 11/04/2019 à 07:41, Aneesh Kumar K.V a écrit : Christophe Leroy writes: No reason to BUG() in add_huge_page_size(). Just WARN and reject the add. Signed-off-by: Christophe Leroy --- arch/powerpc/mm/hugetlbpage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 9e732bb2c84a..cf2978e235f3 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -634,7 +634,8 @@ static int __init add_huge_page_size(unsigned long long size) } #endif - BUG_ON(mmu_psize_defs[mmu_psize].shift != shift); + if (WARN_ON(mmu_psize_defs[mmu_psize].shift != shift)) + return -EINVAL; Same here. There are not catching runtime errors. We should never find that true. This is to catch mistakes during development changes. Switch to VM_BUG_ON? Ok, I'll switch to VM_BUG_ON() Christophe /* Return if huge page size has already been setup */ if (size_to_hstate(size)) -- 2.13.3
Re: [PATCH v1 01/27] powerpc/mm: Don't BUG() in hugepd_page()
Le 11/04/2019 à 07:39, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
Don't BUG(), just warn and return NULL.
If the NULL value is not handled, it will get catched anyway.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hugetlb.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/hugetlb.h
b/arch/powerpc/include/asm/hugetlb.h
index 8d40565ad0c3..48c29686c78e 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -14,7 +14,8 @@
*/
static inline pte_t *hugepd_page(hugepd_t hpd)
{
- BUG_ON(!hugepd_ok(hpd));
+ if (WARN_ON(!hugepd_ok(hpd)))
+ return NULL;
We should not find that true. That BUG_ON was there to catch errors
when changing pte formats. May be switch that VM_BUG_ON()?
Ok, I'll switch to VM_BUG_ON()
Christophe
/*
* We have only four bits to encode, MMU page size
*/
@@ -42,7 +43,8 @@ static inline void flush_hugetlb_page(struct vm_area_struct
*vma,
static inline pte_t *hugepd_page(hugepd_t hpd)
{
- BUG_ON(!hugepd_ok(hpd));
+ if (WARN_ON(!hugepd_ok(hpd)))
+ return NULL;
#ifdef CONFIG_PPC_8xx
return (pte_t *)__va(hpd_val(hpd) & ~HUGEPD_SHIFT_MASK);
#else
--
2.13.3
Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4
On Mon, Apr 22, 2019 at 03:27:56PM +, Diana Madalina Craciun wrote: > On 4/21/2019 7:34 PM, Greg KH wrote: > > On Mon, Apr 22, 2019 at 12:19:45AM +1000, Michael Ellerman wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Hi Greg/Sasha, > >> > >> Please queue up these powerpc patches for 4.4 if you have no objections. > > why? Do you, or someone else, really care about spectre issues in 4.4? > > Who is using ppc for 4.4 becides a specific enterprise distro (and they > > don't seem to be pulling in my stable updates anyway...)? > > We (NXP) received questions from customers regarding Spectre mitigations > on kernel 4.4. Not sure if they really need them as some systems are > enclosed embedded ones, but they asked for them. "Asking about", and "actually needing them" are two different things, as you state. It would be good to get confirmation from someone that these are "actually needed". thanks, greg k-h
Re: [PATCH v3 5/6] powerpc/mm: Reduce memory usage for mm_context_t for radix
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 ?
Christophe
#ifdef CONFIG_SPAPR_TCE_IOMMU
mm_iommu_init(_mm);
#endif
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2cb3a456f5b5..04ac7c36d380 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -968,6 +968,7 @@ void __init hash__early_init_devtree(void)
htab_scan_page_sizes();
}
+struct hash_mm_context init_hash_mm_context;
void __init hash__early_init_mmu(void)
{
#ifndef CONFIG_PPC_64K_PAGES
@@ -1041,7 +1042,8 @@ void __init hash__early_init_mmu(void)
*/
htab_initialize();
- init_mm.context.slb_addr_limit = DEFAULT_MAP_WINDOW_USER64;
+ init_mm.context.hash_context = _hash_mm_context;
+ init_mm.context.hash_context->slb_addr_limit =
DEFAULT_MAP_WINDOW_USER64;
pr_info("Initializing hash mmu with SLB\n");
/* Initialize SLB management */
diff --git a/arch/powerpc/mm/mmu_context_book3s64.c
b/arch/powerpc/mm/mmu_context_book3s64.c
index f720c5cc0b5e..6eef5a36b2e9 100644
--- a/arch/powerpc/mm/mmu_context_book3s64.c
+++ b/arch/powerpc/mm/mmu_context_book3s64.c
@@ -63,6 +63,12 @@ static int hash__init_new_context(struct mm_struct *mm)
if (index < 0)
return index;
+ mm->context.hash_context = kmalloc(sizeof(struct hash_mm_context), GFP_KERNEL);
+ if (!mm->context.hash_context) {
+ ida_free(_context_ida, index);
+ return -ENOMEM;
+ }
+
/*
* The old code would re-promote on fork, we don't do that when using
* slices as it could cause problem promoting slices that have been
@@ -77,8 +83,14 @@ static int hash__init_new_context(struct mm_struct *mm)
* We should not be calling init_new_context() on init_mm. Hence a
* check against 0 is OK.
*/
- if (mm->context.id == 0)
+ if (mm->context.id == 0) {
+ memset(mm->context.hash_context, 0, sizeof(struct
hash_mm_context));
slice_init_new_context_exec(mm);
+ } else {
+ /* This is fork. Copy hash_context details from current->mm */
+ memcpy(mm->context.hash_context,
current->mm->context.hash_context, sizeof(struct hash_mm_context));
+
+ }
subpage_prot_init_new_context(mm);
@@ -118,6 +130,7 @@ static int radix__init_new_context(struct mm_struct *mm)
asm volatile("ptesync;isync" : : : "memory");
mm->context.npu_context = NULL;
+ mm->context.hash_context = NULL;
return index;
}
@@ -162,6 +175,7 @@ static void destroy_contexts(mm_context_t *ctx)
if (context_id)
ida_free(_context_ida, context_id);
}
+ kfree(ctx->hash_context);
}
static void pmd_frag_destroy(void *pmd_frag)
Re: [PATCH 5/6] powerpc/mmu: drop mmap_sem now that locked_vm is atomic
On Tue, Apr 23, 2019 at 07:15:44PM -0700, Davidlohr Bueso wrote: > On Wed, 03 Apr 2019, Daniel Jordan wrote: > > > On Wed, Apr 03, 2019 at 06:58:45AM +0200, Christophe Leroy wrote: > > > Le 02/04/2019 à 22:41, Daniel Jordan a écrit : > > > > With locked_vm now an atomic, there is no need to take mmap_sem as > > > > writer. Delete and refactor accordingly. > > > > > > Could you please detail the change ? > > > > Ok, I'll be more specific in the next version, using some of your language > > in > > fact. :) > > > > > It looks like this is not the only > > > change. I'm wondering what the consequences are. > > > > > > Before we did: > > > - lock > > > - calculate future value > > > - check the future value is acceptable > > > - update value if future value acceptable > > > - return error if future value non acceptable > > > - unlock > > > > > > Now we do: > > > - atomic update with future (possibly too high) value > > > - check the new value is acceptable > > > - atomic update back with older value if new value not acceptable and > > > return > > > error > > > > > > So if a concurrent action wants to increase locked_vm with an acceptable > > > step while another one has temporarily set it too high, it will now fail. > > > > > > I think we should keep the previous approach and do a cmpxchg after > > > validating the new value. > > Wouldn't the cmpxchg alternative also be exposed the locked_vm changing > between > validating the new value and the cmpxchg() and we'd bogusly fail even when > there > is still just because the value changed (I'm assuming we don't hold any locks, > otherwise all this is pointless). > > current_locked = atomic_read(>locked_vm); > new_locked = current_locked + npages; > if (new_locked < lock_limit) > if (cmpxchg(>locked_vm, current_locked, new_locked) == > current_locked) >/* ENOMEM */ Well it needs a loop.. again: current_locked = atomic_read(>locked_vm); new_locked = current_locked + npages; if (new_locked < lock_limit) if (cmpxchg(>locked_vm, current_locked, new_locked) != current_locked) goto again; So it won't have bogus failures as there is no unwind after error. Basically this is a load locked/store conditional style of locking pattern. > > That's a good idea, and especially worth doing considering that an arbitrary > > number of threads that charge a low amount of locked_vm can fail just > > because > > one thread charges lots of it. > > Yeah but the window for this is quite small, I doubt it would be a real issue. > > What if before doing the atomic_add_return(), we first did the racy new_locked > check for ENOMEM, then do the speculative add and cleanup, if necessary. This > would further reduce the scope of the window where false ENOMEM can occur. > > > pinned_vm appears to be broken the same way, so I can fix it too unless > > someone > > beats me to it. > > This should not be a surprise for the rdma folks. Cc'ing Jason nonetheless. I think we accepted this tiny race as a side effect of removing the lock, which was very beneficial. Really the time window between the atomic failing and unwind is very small, and there are enough other ways a hostile user could DOS locked_vm that I don't think it really matters in practice.. However, the cmpxchg seems better, so a helper to implement that would probably be the best thing to do. Jason
[PATCH] memblock: make keeping memblock memory opt-in rather than opt-out
Most architectures do not need the memblock memory after the page allocator is initialized, but only few enable ARCH_DISCARD_MEMBLOCK in the arch Kconfig. Replacing ARCH_DISCARD_MEMBLOCK with ARCH_KEEP_MEMBLOCK and inverting the logic makes it clear which architectures actually use memblock after system initialization and skips the necessity to add ARCH_DISCARD_MEMBLOCK to the architectures that are still missing that option. Signed-off-by: Mike Rapoport --- arch/arm/Kconfig | 2 +- arch/arm64/Kconfig | 1 + arch/hexagon/Kconfig | 1 - arch/ia64/Kconfig| 1 - arch/m68k/Kconfig| 1 - arch/mips/Kconfig| 1 - arch/nios2/Kconfig | 1 - arch/powerpc/Kconfig | 1 + arch/s390/Kconfig| 1 + arch/sh/Kconfig | 1 - arch/x86/Kconfig | 1 - include/linux/memblock.h | 3 ++- kernel/kexec_file.c | 16 mm/Kconfig | 2 +- mm/memblock.c| 6 +++--- mm/page_alloc.c | 3 +-- 16 files changed, 19 insertions(+), 23 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 850b480..7073436 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -4,7 +4,6 @@ config ARM default y select ARCH_32BIT_OFF_T select ARCH_CLOCKSOURCE_DATA - select ARCH_DISCARD_MEMBLOCK if !HAVE_ARCH_PFN_VALID && !KEXEC select ARCH_HAS_DEBUG_VIRTUAL if MMU select ARCH_HAS_DEVMEM_IS_ALLOWED select ARCH_HAS_ELF_RANDOMIZE @@ -21,6 +20,7 @@ config ARM select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAVE_CUSTOM_GPIO_H select ARCH_HAS_GCOV_PROFILE_ALL + select ARCH_KEEP_MEMBLOCK if HAVE_ARCH_PFN_VALID || KEXEC select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_NO_SG_CHAIN if !ARM_HAS_SG_CHAIN select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 7e34b9e..d71f043 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -58,6 +58,7 @@ config ARM64 select ARCH_INLINE_SPIN_UNLOCK_BH if !PREEMPT select ARCH_INLINE_SPIN_UNLOCK_IRQ if !PREEMPT select ARCH_INLINE_SPIN_UNLOCK_IRQRESTORE if !PREEMPT + select ARCH_KEEP_MEMBLOCK select ARCH_USE_CMPXCHG_LOCKREF select ARCH_USE_QUEUED_RWLOCKS select ARCH_USE_QUEUED_SPINLOCKS diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index ac44168..bbe3819 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -22,7 +22,6 @@ config HEXAGON select GENERIC_IRQ_SHOW select HAVE_ARCH_KGDB select HAVE_ARCH_TRACEHOOK - select ARCH_DISCARD_MEMBLOCK select NEED_SG_DMA_LENGTH select NO_IOPORT_MAP select GENERIC_IOMAP diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 8d7396b..bd51d3b 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -33,7 +33,6 @@ config IA64 select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB select VIRT_TO_BUS - select ARCH_DISCARD_MEMBLOCK select GENERIC_IRQ_PROBE select GENERIC_PENDING_IRQ if SMP select GENERIC_IRQ_SHOW diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index b542064..7d1e5d9 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -27,7 +27,6 @@ config M68K select MODULES_USE_ELF_RELA select OLD_SIGSUSPEND3 select OLD_SIGACTION - select ARCH_DISCARD_MEMBLOCK config CPU_BIG_ENDIAN def_bool y diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 4a5f5b0..8b9298b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -5,7 +5,6 @@ config MIPS select ARCH_32BIT_OFF_T if !64BIT select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT select ARCH_CLOCKSOURCE_DATA - select ARCH_DISCARD_MEMBLOCK select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_HAS_UBSAN_SANITIZE_ALL diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig index 4ef15a6..dc4239c 100644 --- a/arch/nios2/Kconfig +++ b/arch/nios2/Kconfig @@ -23,7 +23,6 @@ config NIOS2 select SPARSE_IRQ select USB_ARCH_HAS_HCD if USB_SUPPORT select CPU_NO_EFFICIENT_FFS - select ARCH_DISCARD_MEMBLOCK config GENERIC_CSUM def_bool y diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 2d0be82..39877b9 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -143,6 +143,7 @@ config PPC select ARCH_HAS_UBSAN_SANITIZE_ALL select ARCH_HAS_ZONE_DEVICE if PPC_BOOK3S_64 select ARCH_HAVE_NMI_SAFE_CMPXCHG + select ARCH_KEEP_MEMBLOCK select ARCH_MIGHT_HAVE_PC_PARPORT select ARCH_MIGHT_HAVE_PC_SERIO select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index
Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
Le 23/04/2019 à 18:19, Mark Rutland a écrit : On Tue, Apr 23, 2019 at 05:36:31PM +0200, Laurent Dufour wrote: Le 18/04/2019 à 23:51, Jerome Glisse a écrit : On Tue, Apr 16, 2019 at 03:41:56PM +0100, Mark Rutland wrote: On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote: Le 16/04/2019 à 16:27, Mark Rutland a écrit : On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote: From: Mahendran Ganesh Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This enables Speculative Page Fault handler. Signed-off-by: Ganesh Mahendran This is missing your S-o-B. You're right, I missed that... The first patch noted that the ARCH_SUPPORTS_* option was there because the arch code had to make an explicit call to try to handle the fault speculatively, but that isn't addeed until patch 30. Why is this separate from that code? Andrew was recommended this a long time ago for bisection purpose. This allows to build the code with CONFIG_SPECULATIVE_PAGE_FAULT before the code that trigger the spf handler is added to the per architecture's code. Ok. I think it would be worth noting that in the commit message, to avoid anyone else asking the same question. :) Should have read this thread before looking at x86 and ppc :) In any case the patch is: Reviewed-by: Jérôme Glisse Thanks Mark and Jérôme for reviewing this. Regarding the change in the commit message, I'm wondering if this would be better to place it in the Series's letter head. But I'm fine to put it in each architecture's commit. I think noting it in both the cover letter and specific patches is best. Having something in the commit message means that the intent will be clear when the patch is viewed in isolation (e.g. as they will be once merged). All that's necessary is something like: Note that this patch only enables building the common speculative page fault code such that this can be bisected, and has no functional impact. The architecture-specific code to make use of this and enable the feature will be addded in a subsequent patch. Thanks Mark, will do it this way. Thanks, Mark.
Re: [PATCH v12 18/31] mm: protect against PTE changes done by dup_mmap()
Le 22/04/2019 à 22:32, Jerome Glisse a écrit :
On Tue, Apr 16, 2019 at 03:45:09PM +0200, Laurent Dufour wrote:
Vinayak Menon and Ganesh Mahendran reported that the following scenario may
lead to thread being blocked due to data corruption:
CPU 1 CPU 2CPU 3
Process 1, Process 1, Process 1,
Thread AThread B Thread C
while (1) { while (1) { while(1) {
pthread_mutex_lock(l) pthread_mutex_lock(l)fork
pthread_mutex_unlock(l) pthread_mutex_unlock(l) }
} }
In the details this happens because :
CPU 1CPU 2 CPU 3
fork()
copy_pte_range()
set PTE rdonly
got to next VMA...
. PTE is seen rdonly PTE still writable
. thread is writing to page
. -> page fault
. copy the page Thread writes to page
. .-> no page fault
. update the PTE
. flush TLB for that PTE
flush TLBPTE are now rdonly
Should the fork be on CPU3 to be consistant with the top thing (just to
make it easier to read and go from one to the other as thread can move
from one CPU to another).
Sure, this is quite confusing this way ;)
So the write done by the CPU 3 is interfering with the page copy operation
done by CPU 2, leading to the data corruption.
To avoid this we mark all the VMA involved in the COW mechanism as changing
by calling vm_write_begin(). This ensures that the speculative page fault
handler will not try to handle a fault on these pages.
The marker is set until the TLB is flushed, ensuring that all the CPUs will
now see the PTE as not writable.
Once the TLB is flush, the marker is removed by calling vm_write_end().
The variable last is used to keep tracked of the latest VMA marked to
handle the error path where part of the VMA may have been marked.
Since multiple VMA from the same mm may have the sequence count increased
during this process, the use of the vm_raw_write_begin/end() is required to
avoid lockdep false warning messages.
Reported-by: Ganesh Mahendran
Reported-by: Vinayak Menon
Signed-off-by: Laurent Dufour
A minor comment (see below)
Reviewed-by: Jérome Glisse
Thanks for the review Jérôme.
---
kernel/fork.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index f8dae021c2e5..2992d2c95256 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -462,7 +462,7 @@ EXPORT_SYMBOL(free_task);
static __latent_entropy int dup_mmap(struct mm_struct *mm,
struct mm_struct *oldmm)
{
- struct vm_area_struct *mpnt, *tmp, *prev, **pprev;
+ struct vm_area_struct *mpnt, *tmp, *prev, **pprev, *last = NULL;
struct rb_node **rb_link, *rb_parent;
int retval;
unsigned long charge;
@@ -581,8 +581,18 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
rb_parent = >vm_rb;
mm->map_count++;
- if (!(tmp->vm_flags & VM_WIPEONFORK))
+ if (!(tmp->vm_flags & VM_WIPEONFORK)) {
+ if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT)) {
+ /*
+* Mark this VMA as changing to prevent the
+* speculative page fault hanlder to process
+* it until the TLB are flushed below.
+*/
+ last = mpnt;
+ vm_raw_write_begin(mpnt);
+ }
retval = copy_page_range(mm, oldmm, mpnt);
+ }
if (tmp->vm_ops && tmp->vm_ops->open)
tmp->vm_ops->open(tmp);
@@ -595,6 +605,22 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
out:
up_write(>mmap_sem);
flush_tlb_mm(oldmm);
+
+ if (IS_ENABLED(CONFIG_SPECULATIVE_PAGE_FAULT)) {
You do not need to check for CONFIG_SPECULATIVE_PAGE_FAULT as last
will always be NULL if it is not enabled but maybe the compiler will
miss the optimization opportunity if you only have the for() loop
below.
I didn't check for the generated code, perhaps the compiler will be
optimize that correctly.
This being said, I think the if block is better for the code
readability, highlighting that this block is only needed in the case of SPF.
+ /*
+* Since the TLB has been flush, we can safely unmark the
+* copied VMAs and allows the speculative page fault handler to
+* process them again.
+* Walk back the
