Re: [PATCH v3] docs: driver-api: fix 6 spelling typos in Documentation/driver-api

[Josh Law]

On 24 March 2026 16:36:04 GMT, "Tomás Pando" <tovictakamine@xxxxxxxxx> wrote:
>Fix minor spelling mistakes in the driver-api documentation. These
>changes improve readability in ACPI, CXL, DMA and PCI docs.
>v3: Added reviewed-by from Randy Dunlap.
>v2: Added full name as requested by Jon Corbet.
>
>Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
>Signed-off-by: Tomás Pando <tovictakamine@xxxxxxxxx>
>---
> Documentation/driver-api/acpi/acpi-drivers.rst         | 2 +-
> Documentation/driver-api/cxl/platform/acpi/cedt.rst    | 2 +-
> Documentation/driver-api/cxl/platform/bios-and-efi.rst | 2 +-
> Documentation/driver-api/dmaengine/pxa_dma.rst         | 2 +-
> Documentation/driver-api/libata.rst                    | 2 +-
> Documentation/driver-api/pci/p2pdma.rst                | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/Documentation/driver-api/acpi/acpi-drivers.rst b/Documentation/driver-api/acpi/acpi-drivers.rst
>index b1fbbddb8..376b6d8a6 100644
>--- a/Documentation/driver-api/acpi/acpi-drivers.rst
>+++ b/Documentation/driver-api/acpi/acpi-drivers.rst
>@@ -47,7 +47,7 @@ generally be avoided and so struct acpi_driver objects should not be used.
> Moreover, a device ID is necessary to bind a driver directly to an ACPI device
> node, but device IDs are not generally associated with all of them.  Some of
> them contain alternative information allowing the corresponding pieces of
>-hardware to be identified, for example represeted by an _ADR object return
>+hardware to be identified, for example represented by an _ADR object return
> value, and device IDs are not used in those cases.  In consequence, confusingly
> enough, binding an ACPI driver to an ACPI device node may even be impossible.
> 
>diff --git a/Documentation/driver-api/cxl/platform/acpi/cedt.rst b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
>index 1d9c9d359..217a75fb4 100644
>--- a/Documentation/driver-api/cxl/platform/acpi/cedt.rst
>+++ b/Documentation/driver-api/cxl/platform/acpi/cedt.rst
>@@ -55,7 +55,7 @@ voltile vs persistent, etc). One or more bits may be set. ::
>   Bit[1]: CXL Type 3 Memory
>   Bit[2]: Volatile Memory
>   Bit[3]: Persistent Memory
>-  Bit[4]: Fixed Config (HPA cannot be re-used)
>+  Bit[4]: Fixed Config (HPA cannot be reused)
> 
> INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT
> reported in this structure, and is solely defined via CXL device decoder
>diff --git a/Documentation/driver-api/cxl/platform/bios-and-efi.rst b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
>index a4b44c018..5d918b06f 100644
>--- a/Documentation/driver-api/cxl/platform/bios-and-efi.rst
>+++ b/Documentation/driver-api/cxl/platform/bios-and-efi.rst
>@@ -277,7 +277,7 @@ The CFMWS field of the CEDT has special restriction bits which describe whether
> the described memory region allows volatile or persistent memory (or both). If
> the platform intends to support either:
> 
>-1) A device with multiple medias, or
>+1) A device with multiple media, or
> 2) Using a persistent memory device as normal memory
> 
> A platform may wish to create multiple CEDT CFMWS entries to describe the same
>diff --git a/Documentation/driver-api/dmaengine/pxa_dma.rst b/Documentation/driver-api/dmaengine/pxa_dma.rst
>index 442ee691a..8f9da66b0 100644
>--- a/Documentation/driver-api/dmaengine/pxa_dma.rst
>+++ b/Documentation/driver-api/dmaengine/pxa_dma.rst
>@@ -40,7 +40,7 @@ Design
> ======
> a) Virtual channels
> Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
>-channel" linked to the requestor line, and the physical DMA channel is
>+channel" linked to the requester line, and the physical DMA channel is
> assigned on the fly when the transfer is issued.
> 
> b) Transfer anatomy for a scatter-gather transfer
>diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst
>index 93d97fe78..28b8437f6 100644
>--- a/Documentation/driver-api/libata.rst
>+++ b/Documentation/driver-api/libata.rst
>@@ -286,7 +286,7 @@ and other exceptional conditions. The primary responsibility of an
> implementation is to call :c:func:`ata_std_error_handler`.
> 
> :c:func:`ata_std_error_handler` will perform a standard error handling sequence
>-to resurect failed devices, detach lost devices and add new devices (if any).
>+to resurrect failed devices, detach lost devices and add new devices (if any).
> This function will call the various reset operations for a port, as needed.
> These operations are as follows.
> 
>diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver-api/pci/p2pdma.rst
>index 280673b50..d3f406cca 100644
>--- a/Documentation/driver-api/pci/p2pdma.rst
>+++ b/Documentation/driver-api/pci/p2pdma.rst
>@@ -38,7 +38,7 @@ for all usage refcounts to reach zero.
> At the lowest level the P2P subsystem offers a naked struct p2p_provider that
> delegates lifecycle management to the providing driver. It is expected that
> drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF
>-to provide an invalidation shutdown. These MMIO addresess have no struct page, and
>+to provide an invalidation shutdown. These MMIO addresses have no struct page, and
> if used with mmap() must create special PTEs. As such there are very few
> kernel uAPIs that can accept pointers to them; in particular they cannot be used
> with read()/write(), including O_DIRECT.



Acked-By: Josh Law <objecting@xxxxxxxxxxxxx>


Patches like these are good clarification 

Keep it up!


V/R

Josh Law