Commit 395107a7 authored by Marneni PoornaChandu's avatar Marneni PoornaChandu Committed by Jonathan Corbet
Browse files

docs: driver-api: fix spelling of "buses". 



Replace incorrect plural form "busses" with "buses" in
multiple documentation files under "Documentation/driver-api".

Signed-off-by: default avatarMarneni PoornaChandu <Poornachandumarneni@gmail.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
Message-ID: <20250917220430.5815-1-Poornachandumarneni@gmail.com>
parent 4eb018bd

Documentation/driver-api/device-io.rst

+2 −2
Original line number Diff line number Diff line
@@ -16,7 +16,7 @@ Bus-Independent Device Accesses 
Introduction

============



Linux provides an API which abstracts performing IO across all busses

Linux provides an API which abstracts performing IO across all buses

and devices, allowing device drivers to be written independently of bus

type.
@@ -71,7 +71,7 @@ can be compiler optimised, you can use __readb() and friends to 
indicate the relaxed ordering. Use this with care.



While the basic functions are defined to be synchronous with respect to

each other and ordered with respect to each other the busses the devices

each other and ordered with respect to each other the buses the devices

sit on may themselves have asynchronicity. In particular many authors

are burned by the fact that PCI bus writes are posted asynchronously. A

driver author must issue a read from the same device to ensure that

Documentation/driver-api/driver-model/overview.rst

+1 −1
Original line number Diff line number Diff line
@@ -22,7 +22,7 @@ uniformity across the different bus types. 


The current driver model provides a common, uniform data model for describing

a bus and the devices that can appear under the bus. The unified bus

model includes a set of common attributes which all busses carry, and a set

model includes a set of common attributes which all buses carry, and a set

of common callbacks, such as device discovery during bus probing, bus

shutdown, bus power management, etc.

Documentation/driver-api/driver-model/platform.rst

+1 −1
Original line number Diff line number Diff line
@@ -4,7 +4,7 @@ Platform Devices and Drivers 


See <linux/platform_device.h> for the driver model interface to the

platform bus:  platform_device, and platform_driver.  This pseudo-bus

is used to connect devices on busses with minimal infrastructure,

is used to connect devices on buses with minimal infrastructure,

like those used to integrate peripherals on many system-on-chip

processors, or some "legacy" PC interconnects; as opposed to large

formally specified ones like PCI or USB.

Documentation/driver-api/eisa.rst

+3 −3
Original line number Diff line number Diff line
@@ -8,9 +8,9 @@ This document groups random notes about porting EISA drivers to the 
new EISA/sysfs API.



Starting from version 2.5.59, the EISA bus is almost given the same

status as other much more mainstream busses such as PCI or USB. This

status as other much more mainstream buses such as PCI or USB. This

has been possible through sysfs, which defines a nice enough set of

abstractions to manage busses, devices and drivers.

abstractions to manage buses, devices and drivers.



Although the new API is quite simple to use, converting existing

drivers to the new infrastructure is not an easy task (mostly because
@@ -205,7 +205,7 @@ Random notes 
Converting an EISA driver to the new API mostly involves *deleting*

code (since probing is now in the core EISA code). Unfortunately, most

drivers share their probing routine between ISA, and EISA. Special

care must be taken when ripping out the EISA code, so other busses

care must be taken when ripping out the EISA code, so other buses

won't suffer from these surgical strikes...



You *must not* expect any EISA device to be detected when returning

Documentation/driver-api/i3c/protocol.rst

+2 −2
Original line number Diff line number Diff line
@@ -165,8 +165,8 @@ The first thing attached to an HDR command is the HDR mode. There are currently 
for more details):



* HDR-DDR: Double Data Rate mode

* HDR-TSP: Ternary Symbol Pure. Only usable on busses with no I2C devices

* HDR-TSL: Ternary Symbol Legacy. Usable on busses with I2C devices

* HDR-TSP: Ternary Symbol Pure. Only usable on buses with no I2C devices

* HDR-TSL: Ternary Symbol Legacy. Usable on buses with I2C devices



When sending an HDR command, the whole bus has to enter HDR mode, which is done

using a broadcast CCC command.