bybrooklyn/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux.git synced 2026-04-18 06:44:00 -04:00
Code Issues Packages Projects Releases Wiki Activity

docs: fix 're-use' -> 'reuse' in documentation

Browse Source 
Signed-off-by: Rhys Tumelty <rhys@tumelty.co.uk>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260128220233.179439-1-rhys@tumelty.co.uk>
This commit is contained in:
Rhys Tumelty
2026-01-28 22:02:31 +00:00
committed by Jonathan Corbet
parent 1482f61ccd
commit 78a00cac1e
17 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/driver-api/phy/phy.rst
View File

@@ -19,7 +19,7 @@ PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
SATA etc.
The intention of creating this framework is to bring the PHY drivers spread
all over the Linux kernel to drivers/phy to increase code re-use and for
all over the Linux kernel to drivers/phy to increase code reuse and for
better code maintainability.
This framework will be of use only to devices that use external PHY (PHY

2
Documentation/driver-api/tty/tty_ldisc.rst
View File

@@ -18,7 +18,7 @@ Registration
Line disciplines are registered with tty_register_ldisc() passing the ldisc
structure. At the point of registration the discipline must be ready to use and
it is possible it will get used before the call returns success. If the call
returns an error then it won’t get called. Do not re-use ldisc numbers as they
returns an error then it won’t get called. Do not reuse ldisc numbers as they
are part of the userspace ABI and writing over an existing ldisc will cause
demons to eat your computer. You must not re-register over the top of the line
discipline even with the same data or your computer again will be eaten by

2
Documentation/driver-api/usb/gadget.rst
View File

@@ -459,7 +459,7 @@ Linux-USB host side driver stack, or as a peripheral, using this
``gadget`` framework. To do that, the system software relies on small
additions to those programming interfaces, and on a new internal
component (here called an "OTG Controller") affecting which driver stack
connects to the OTG port. In each role, the system can re-use the
connects to the OTG port. In each role, the system can reuse the
existing pool of hardware-neutral drivers, layered on top of the
controller driver interfaces (:c:type:`usb_bus` or :c:type:`usb_gadget`).
Such drivers need at most minor changes, and most of the calls added to