Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
---
 Documentation/bpf/prog_flow_dissector.rst  | 4 ++--
 Documentation/fb/fbcon.rst                 | 2 +-
 Documentation/filesystems/path-lookup.rst  | 2 +-
 Documentation/hwmon/lm75.rst               | 2 +-
 Documentation/kernel-hacking/hacking.rst   | 2 +-
 Documentation/networking/phy.rst           | 8 ++++----
 Documentation/process/management-style.rst | 2 +-
 7 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/bpf/prog_flow_dissector.rst b/Documentation/bpf/prog_flow_dissector.rst
index f24270b8b034..8de1446b278b 100644
--- a/Documentation/bpf/prog_flow_dissector.rst
+++ b/Documentation/bpf/prog_flow_dissector.rst
@@ -68,7 +68,7 @@ Pre-VLAN parsing::
 
 .. code:: c
 
-  skb->data + flow_keys->nhoff point the to first byte of TCI
+  skb->data + flow_keys->nhoff point to the first byte of TCI
   flow_keys->thoff = nhoff
   flow_keys->n_proto = TPID
 
@@ -87,7 +87,7 @@ Post-VLAN parsing::
 
 .. code:: c
 
-  skb->data + flow_keys->nhoff point the to first byte of L3_HEADER
+  skb->data + flow_keys->nhoff point to the first byte of L3_HEADER
   flow_keys->thoff = nhoff
   flow_keys->n_proto = ETHER_TYPE
 
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index a98a5cb0b0d8..b278a8fe7e2b 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -109,7 +109,7 @@ C. Boot options
 	available, fb0, adding fbcon=map:1 tells fbcon not to take over the
 	console.
 
-	Later on, when you want to map the console the to the framebuffer
+	Later on, when you want to map the console to the framebuffer
 	device, you can use the con2fbmap utility.
 
 3. fbcon=vc:<n1>-<n2>
diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
index 9ced1135608e..4e374f9073f6 100644
--- a/Documentation/filesystems/path-lookup.rst
+++ b/Documentation/filesystems/path-lookup.rst
@@ -1077,7 +1077,7 @@ whether in RCU-walk or REF-walk, the symlink stack needs to contain,
 along with the path remnants:
 
 - the ``struct path`` to provide a reference to the previous path
-- the ``const char *`` to provide a reference to the to previous name
+- the ``const char *`` to provide a reference to the previous name
 - the ``seq`` to allow the path to be safely switched from RCU-walk to REF-walk
 - the ``struct delayed_call`` for later invocation.
 
diff --git a/Documentation/hwmon/lm75.rst b/Documentation/hwmon/lm75.rst
index c6a54bbca3c5..f05799c53474 100644
--- a/Documentation/hwmon/lm75.rst
+++ b/Documentation/hwmon/lm75.rst
@@ -154,7 +154,7 @@ The LM75 implements one temperature sensor. Limits can be set through the
 Overtemperature Shutdown register and Hysteresis register. Each value can be
 set and read to half-degree accuracy.
 An alarm is issued (usually to a connected LM78) when the temperature
-gets higher then the Overtemperature Shutdown value; it stays on until
+gets higher than the Overtemperature Shutdown value; it stays on until
 the temperature falls below the Hysteresis value.
 All temperatures are in degrees Celsius, and are guaranteed within a
 range of -55 to +125 degrees.
diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index 0042776a9e17..b3d352d2ffcc 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -259,7 +259,7 @@ overruns. Make sure that will be enough.
 .. note::
 
     You will know when you are a real kernel hacker when you start
-    typoing printf as printk in your user programs :)
+    typing printf as printk in your user programs :)
 
 .. note::
 
diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst
index 7f159043ad5a..8d457979a1f1 100644
--- a/Documentation/networking/phy.rst
+++ b/Documentation/networking/phy.rst
@@ -5,7 +5,7 @@ PHY Abstraction Layer
 Purpose
 =======
 
-Most network devices consist of set of registers which provide an interface
+Most network devices consist of a set of registers which provide an interface
 to a MAC layer, which communicates with the physical connection through a
 PHY.  The PHY concerns itself with negotiating link parameters with the link
 partner on the other side of the network connection (typically, an ethernet
@@ -262,7 +262,7 @@ Some of the interface modes are described below:
     encoding.  The underlying data rate is 1Gbps, with the slower speeds of
     100Mbps and 10Mbps being achieved through replication of each data symbol.
     The 802.3 control word is re-purposed to send the negotiated speed and
-    duplex information from to the MAC, and for the MAC to acknowledge
+    duplex information to the MAC, and for the MAC to acknowledge
     receipt.  This does not include "up-clocked" variants such as 2.5Gbps
     speeds.
 
@@ -285,7 +285,7 @@ Some of the interface modes are described below:
 
     Note: 10GBASE-R is just one protocol that can be used with XFI and SFI.
     XFI and SFI permit multiple protocols over a single SERDES lane, and
-    also defines the electrical characteristics of the signals with a host
+    also define the electrical characteristics of the signals with a host
     compliance board plugged into the host XFP/SFP connector. Therefore,
     XFI and SFI are not PHY interface types in their own right.
 
@@ -545,7 +545,7 @@ When phy_register_fixup() or \*_for_uid()/\*_for_id() is called at module load
 time, the module needs to unregister the fixup and free allocated memory when
 it's unloaded.
 
-Call one of following function before unloading module::
+Call one of the following functions before unloading the module::
 
  int phy_unregister_fixup(const char *phy_id, u32 phy_uid, u32 phy_uid_mask);
  int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask);
diff --git a/Documentation/process/management-style.rst b/Documentation/process/management-style.rst
index dfbc69bf49d4..0b9e074277d0 100644
--- a/Documentation/process/management-style.rst
+++ b/Documentation/process/management-style.rst
@@ -42,7 +42,7 @@ actually true.
 The name of the game is to **avoid** having to make a decision.  In
 particular, if somebody tells you "choose (a) or (b), we really need you
 to decide on this", you're in trouble as a manager.  The people you
-manage had better know the details better than you, so if they come to
+manage know the details better than you, so if they come to
 you for a technical decision, you're screwed.  You're clearly not
 competent to make that decision for them.
 

base-commit: e30917da6074205bb1071a52e325c9d6ffe68ad5
prerequisite-patch-id: 81e067eae729d71e41b653c4f550dd3449003592
prerequisite-patch-id: 21078cbf43929b4a0d56ab4bb4acea907af70d7a
-- 
2.43.0

Hi Markus,

On 9/26/25 2:53 AM, Markus Heidelberg wrote:
> Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
> ---
>  Documentation/bpf/prog_flow_dissector.rst  | 4 ++--
>  Documentation/fb/fbcon.rst                 | 2 +-
>  Documentation/filesystems/path-lookup.rst  | 2 +-
>  Documentation/hwmon/lm75.rst               | 2 +-
>  Documentation/kernel-hacking/hacking.rst   | 2 +-
>  Documentation/networking/phy.rst           | 8 ++++----
>  Documentation/process/management-style.rst | 2 +-
>  7 files changed, 11 insertions(+), 11 deletions(-)

These changes mostly look good. I'm curious about how you
found these. ??

thanks.
-- 
~Randy

On Fri, Sep 26, 2025 at 10:36:28AM -0700, Randy Dunlap wrote:
> On 9/26/25 2:53 AM, Markus Heidelberg wrote:
> > Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
> > ---
> >  Documentation/bpf/prog_flow_dissector.rst  | 4 ++--
> >  Documentation/fb/fbcon.rst                 | 2 +-
> >  Documentation/filesystems/path-lookup.rst  | 2 +-
> >  Documentation/hwmon/lm75.rst               | 2 +-
> >  Documentation/kernel-hacking/hacking.rst   | 2 +-
> >  Documentation/networking/phy.rst           | 8 ++++----
> >  Documentation/process/management-style.rst | 2 +-
> >  7 files changed, 11 insertions(+), 11 deletions(-)
> 
> These changes mostly look good. I'm curious about how you
> found these. ??

Hi Randy,

I just stumbled upon them while reading the documentation.
The "the to -> to the" swap I originally found in another file and then
searched for more occurrences with something like this:

  $ git grep -w -C1 "the to"

Markus

Markus Heidelberg <m.heidelberg@cab.de> writes:

> diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
> index 0042776a9e17..b3d352d2ffcc 100644
> --- a/Documentation/kernel-hacking/hacking.rst
> +++ b/Documentation/kernel-hacking/hacking.rst
> @@ -259,7 +259,7 @@ overruns. Make sure that will be enough.
>  .. note::
>  
>      You will know when you are a real kernel hacker when you start
> -    typoing printf as printk in your user programs :)
> +    typing printf as printk in your user programs :)

This one, at least, is as intended and does not need to be "fixed".

For a future version, it would be better to split the patches apart and
send them to the relevant maintainers.

jon

On Fri, Sep 26, 2025 at 06:32:52AM -0600, Jonathan Corbet wrote:
> Markus Heidelberg <m.heidelberg@cab.de> writes:
>
> > diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
> > index 0042776a9e17..b3d352d2ffcc 100644
> > --- a/Documentation/kernel-hacking/hacking.rst
> > +++ b/Documentation/kernel-hacking/hacking.rst
> > @@ -259,7 +259,7 @@ overruns. Make sure that will be enough.
> >  .. note::
> >  
> >      You will know when you are a real kernel hacker when you start
> > -    typoing printf as printk in your user programs :)
> > +    typing printf as printk in your user programs :)
>
> This one, at least, is as intended and does not need to be "fixed".

Oh, I got that joke now :)

> For a future version, it would be better to split the patches apart and
> send them to the relevant maintainers.

I've scratched my head about the best approach a long time, looked at
typo git commits, followed mailing list discussion from Link: tags.
Found documentation patches like this across different subsystems and
also a reply about undesired one-liner typo patches.
So I thought, if not touching the technical content, using one combined
documentation patch might be a proper way.

Will have a look at splitting the patch up if not resulting in
one-liners only.

Markus