+1 -1

Documentation/driver-api/acpi/acpi-drivers.rst

reviewed

··· 47 47 Moreover, a device ID is necessary to bind a driver directly to an ACPI device 48 48 node, but device IDs are not generally associated with all of them. Some of 49 49 them contain alternative information allowing the corresponding pieces of 50 50 - hardware to be identified, for example represeted by an _ADR object return 50 50 + hardware to be identified, for example represented by an _ADR object return 51 51 value, and device IDs are not used in those cases. In consequence, confusingly 52 52 enough, binding an ACPI driver to an ACPI device node may even be impossible. 53 53

+1 -1

Documentation/driver-api/cxl/platform/acpi/cedt.rst

reviewed

··· 55 55 Bit[1]: CXL Type 3 Memory 56 56 Bit[2]: Volatile Memory 57 57 Bit[3]: Persistent Memory 58 58 - Bit[4]: Fixed Config (HPA cannot be re-used) 58 58 + Bit[4]: Fixed Config (HPA cannot be reused) 59 59 60 60 INTRA-host-bridge interleave (multiple devices on one host bridge) is NOT 61 61 reported in this structure, and is solely defined via CXL device decoder

+1 -1

Documentation/driver-api/cxl/platform/bios-and-efi.rst

reviewed

··· 277 277 the described memory region allows volatile or persistent memory (or both). If 278 278 the platform intends to support either: 279 279 280 280 - 1) A device with multiple medias, or 280 280 + 1) A device with multiple media, or 281 281 2) Using a persistent memory device as normal memory 282 282 283 283 A platform may wish to create multiple CEDT CFMWS entries to describe the same

+1 -1

Documentation/driver-api/dmaengine/pxa_dma.rst

reviewed

··· 40 40 ====== 41 41 a) Virtual channels 42 42 Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual 43 43 - channel" linked to the requestor line, and the physical DMA channel is 43 43 + channel" linked to the requester line, and the physical DMA channel is 44 44 assigned on the fly when the transfer is issued. 45 45 46 46 b) Transfer anatomy for a scatter-gather transfer

+1 -1

Documentation/driver-api/libata.rst

reviewed

··· 286 286 implementation is to call :c:func:`ata_std_error_handler`. 287 287 288 288 :c:func:`ata_std_error_handler` will perform a standard error handling sequence 289 289 - to resurect failed devices, detach lost devices and add new devices (if any). 289 289 + to resurrect failed devices, detach lost devices and add new devices (if any). 290 290 This function will call the various reset operations for a port, as needed. 291 291 These operations are as follows. 292 292

+1 -1

Documentation/driver-api/pci/p2pdma.rst

reviewed

··· 38 38 At the lowest level the P2P subsystem offers a naked struct p2p_provider that 39 39 delegates lifecycle management to the providing driver. It is expected that 40 40 drivers using this option will wrap their MMIO memory in DMABUF and use DMABUF 41 41 - to provide an invalidation shutdown. These MMIO addresess have no struct page, and 41 41 + to provide an invalidation shutdown. These MMIO addresses have no struct page, and 42 42 if used with mmap() must create special PTEs. As such there are very few 43 43 kernel uAPIs that can accept pointers to them; in particular they cannot be used 44 44 with read()/write(), including O_DIRECT.