[PATCH v4] media: Documentation: Improve grammar in DVB API

[PATCH v4] media: Documentation: Improve grammar in DVB API

[Hanne-Lotta Mäenpää]

Fix typos and punctuation and improve grammar in documentation.

Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>
---

Notes:
    v1 -> v2:
    
    Left out changes based on feedback from Jonathan Corbet
    <corbet@lwn.net> and Bagas Sanjaya <bagasdotme@gmail.com>
    
    v2 -> v3:
    
    Switched word order in DTV_BANDWIDTH_HZ description based
    on feedback from Bagas Sanjaya <bagasdotme@gmail.com>.
    
    Shortened the patch series to two patches, as parts
    3/4 and 4/4 have been applied.
    
    v3 -> v4:
    
    Shortened commit title and message.
    
    Converted from a patch series to one patch, as other
    parts have been applied.

 .../media/dvb/fe-diseqc-send-burst.rst        |  2 +-
 .../userspace-api/media/dvb/fe-set-tone.rst   |  2 +-
 .../media/dvb/fe-set-voltage.rst              |  2 +-
 .../media/dvb/fe_property_parameters.rst      | 23 +++++++++----------
 .../frontend-property-terrestrial-systems.rst |  2 +-
 .../userspace-api/media/dvb/intro.rst         |  4 ++--
 .../media/dvb/legacy_dvb_audio.rst            |  4 ++--
 7 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/Documentation/userspace-api/media/dvb/fe-diseqc-send-burst.rst b/Documentation/userspace-api/media/dvb/fe-diseqc-send-burst.rst
index 8fb73ee29951..6ac1e5cd50ce 100644
--- a/Documentation/userspace-api/media/dvb/fe-diseqc-send-burst.rst
+++ b/Documentation/userspace-api/media/dvb/fe-diseqc-send-burst.rst
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :c:func:`open()`.
 
 ``tone``
-    An integer enumered value described at :c:type:`fe_sec_mini_cmd`.
+    An integer enumerated value described at :c:type:`fe_sec_mini_cmd`.
 
 Description
 ===========
diff --git a/Documentation/userspace-api/media/dvb/fe-set-tone.rst b/Documentation/userspace-api/media/dvb/fe-set-tone.rst
index 9f44bf946183..41cd7111a243 100644
--- a/Documentation/userspace-api/media/dvb/fe-set-tone.rst
+++ b/Documentation/userspace-api/media/dvb/fe-set-tone.rst
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :c:func:`open()`.
 
 ``tone``
-    an integer enumered value described at :c:type:`fe_sec_tone_mode`
+    An integer enumerated value described at :c:type:`fe_sec_tone_mode`
 
 Description
 ===========
diff --git a/Documentation/userspace-api/media/dvb/fe-set-voltage.rst b/Documentation/userspace-api/media/dvb/fe-set-voltage.rst
index c66771830be1..4d09ca5876f0 100644
--- a/Documentation/userspace-api/media/dvb/fe-set-voltage.rst
+++ b/Documentation/userspace-api/media/dvb/fe-set-voltage.rst
@@ -26,7 +26,7 @@ Arguments
     File descriptor returned by :c:func:`open()`.
 
 ``voltage``
-    an integer enumered value described at :c:type:`fe_sec_voltage`
+    An integer enumerated value described at :c:type:`fe_sec_voltage`
 
 Description
 ===========
diff --git a/Documentation/userspace-api/media/dvb/fe_property_parameters.rst b/Documentation/userspace-api/media/dvb/fe_property_parameters.rst
index 1717a0565fe8..ce962d4a02c0 100644
--- a/Documentation/userspace-api/media/dvb/fe_property_parameters.rst
+++ b/Documentation/userspace-api/media/dvb/fe_property_parameters.rst
@@ -72,11 +72,11 @@ DTV_MODULATION
 ==============
 
 Specifies the frontend modulation type for delivery systems that
-supports more multiple modulations.
+support multiple modulations.
 
 The modulation can be one of the types defined by enum :c:type:`fe_modulation`.
 
-Most of the digital TV standards offers more than one possible
+Most of the digital TV standards offer more than one possible
 modulation type.
 
 The table below presents a summary of the types of modulation types
@@ -143,9 +143,8 @@ ISDB-T			5MHz, 6MHz, 7MHz and 8MHz, although most places
      (DTV_ISDBT_SB_SEGMENT_IDX, DTV_ISDBT_SB_SEGMENT_COUNT).
 
   #. On Satellite and Cable delivery systems, the bandwidth depends on
-     the symbol rate. So, the Kernel will silently ignore any setting
-     :ref:`DTV-BANDWIDTH-HZ`. I will however fill it back with a
-     bandwidth estimation.
+     the symbol rate. The kernel will silently ignore any :ref:`DTV-BANDWIDTH-HZ`
+     setting and overwrites it with bandwidth estimation.
 
      Such bandwidth estimation takes into account the symbol rate set with
      :ref:`DTV-SYMBOL-RATE`, and the rolloff factor, with is fixed for
@@ -200,7 +199,7 @@ DTV_VOLTAGE
 Used on satellite delivery systems.
 
 The voltage is usually used with non-DiSEqC capable LNBs to switch the
-polarzation (horizontal/vertical). When using DiSEqC epuipment this
+polarization (horizontal/vertical). When using DiSEqC equipment this
 voltage has to be switched consistently to the DiSEqC commands as
 described in the DiSEqC spec.
 
@@ -280,7 +279,7 @@ DTV_ISDBT_PARTIAL_RECEPTION
 
 Used only on ISDB.
 
-If ``DTV_ISDBT_SOUND_BROADCASTING`` is '0' this bit-field represents
+If ``DTV_ISDBT_SOUND_BROADCASTING`` is '0' this bit field represents
 whether the channel is in partial reception mode or not.
 
 If '1' ``DTV_ISDBT_LAYERA_*`` values are assigned to the center segment
@@ -331,8 +330,8 @@ broadcaster has several possibilities to put those channels in the air:
 Assuming a normal 13-segment ISDB-T spectrum he can align the 8 segments
 from position 1-8 to 5-13 or anything in between.
 
-The underlying layer of segments are subchannels: each segment is
-consisting of several subchannels with a predefined IDs. A sub-channel
+The underlying layer of segments are sub-channels: each segment is
+consisting of several sub-channels with a predefined IDs. A sub-channel
 is used to help the demodulator to synchronize on the channel.
 
 An ISDB-T channel is always centered over all sub-channels. As for the
@@ -728,7 +727,7 @@ DTV_ATSCMH_RS_FRAME_ENSEMBLE
 
 Used only on ATSC-MH.
 
-Reed Solomon(RS) frame ensemble.
+Reed Solomon (RS) frame ensemble.
 
 The acceptable values are defined by :c:type:`atscmh_rs_frame_ensemble`.
 
@@ -954,14 +953,14 @@ DTV_ENUM_DELSYS
 
 A Multi standard frontend needs to advertise the delivery systems
 provided. Applications need to enumerate the provided delivery systems,
-before using any other operation with the frontend. Prior to it's
+before using any other operation with the frontend. Prior to its
 introduction, FE_GET_INFO was used to determine a frontend type. A
 frontend which provides more than a single delivery system,
 FE_GET_INFO doesn't help much. Applications which intends to use a
 multistandard frontend must enumerate the delivery systems associated
 with it, rather than trying to use FE_GET_INFO. In the case of a
 legacy frontend, the result is just the same as with FE_GET_INFO, but
-in a more structured format
+in a more structured format.
 
 The acceptable values are defined by :c:type:`fe_delivery_system`.
 
diff --git a/Documentation/userspace-api/media/dvb/frontend-property-terrestrial-systems.rst b/Documentation/userspace-api/media/dvb/frontend-property-terrestrial-systems.rst
index 8cd461ceeea7..8aad9ea817f2 100644
--- a/Documentation/userspace-api/media/dvb/frontend-property-terrestrial-systems.rst
+++ b/Documentation/userspace-api/media/dvb/frontend-property-terrestrial-systems.rst
@@ -52,7 +52,7 @@ DVB-T2 delivery system
 ======================
 
 DVB-T2 support is currently in the early stages of development, so
-expect that this section maygrow and become more detailed with time.
+expect that this section may grow and become more detailed with time.
 
 The following parameters are valid for DVB-T2:
 
diff --git a/Documentation/userspace-api/media/dvb/intro.rst b/Documentation/userspace-api/media/dvb/intro.rst
index 6784ae79657c..854c2073e69a 100644
--- a/Documentation/userspace-api/media/dvb/intro.rst
+++ b/Documentation/userspace-api/media/dvb/intro.rst
@@ -1,6 +1,6 @@
 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
 
-.. _dvb_introdution:
+.. _dvb_introduction:
 
 ************
 Introduction
@@ -125,7 +125,7 @@ demux, CA and IP-over-DVB networking. The video and audio devices
 control the MPEG2 decoder hardware, the frontend device the tuner and
 the Digital TV demodulator. The demux device gives you control over the PES
 and section filters of the hardware. If the hardware does not support
-filtering these filters can be implemented in software. Finally, the CA
+filtering, these filters can be implemented in software. Finally, the CA
 device controls all the conditional access capabilities of the hardware.
 It can depend on the individual security requirements of the platform,
 if and how many of the CA functions are made available to the
diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
index b46fe2becd02..81b762ef17c4 100644
--- a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
+++ b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
@@ -195,7 +195,7 @@ Description
 ~~~~~~~~~~~
 
 The audio channel selected via `AUDIO_CHANNEL_SELECT`_ is determined by
-this values.
+this value.
 
 
 -----
@@ -413,7 +413,7 @@ Constants
        -  ``AUDIO_CAP_MP3``
 
        -  The hardware accepts MPEG-1 Audio Layer III.
-          Commomly known as .mp3.
+          Commonly known as .mp3.
 
     -  ..
 
-- 
2.50.0

Re: [PATCH v4] media: Documentation: Improve grammar in DVB API

[David Hunter]

On 7/8/25 11:52, Hanne-Lotta Mäenpää wrote:
> Fix typos and punctuation and improve grammar in documentation.
> 
> Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>

Overall, good work. Here is a suggestion for future patch series:

Subsequent versions of patch series should be posted as replies in the same thread. Currently, each version is its own independent thread, which makes it hard to track changes. This link has the documentation for the proper way to handle subsequent patches:

https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html

The relevant part starts at "To that end, send them as replies to either..."

Another good practice is to have the previous versions' links from "lore.kernel.org" directly in the change log. 

Thanks, 
David Hunter

Re: [PATCH v4] media: Documentation: Improve grammar in DVB API

[Hanne-Lotta Mäenpää]

Hello,

On 7/10/25 7:22 AM, David Hunter wrote:
> On 7/8/25 11:52, Hanne-Lotta Mäenpää wrote:
>> Fix typos and punctuation and improve grammar in documentation.
>>
>> Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>
> 
> Overall, good work. Here is a suggestion for future patch series:

Thank you very much!

> Subsequent versions of patch series should be posted as replies in the same thread. Currently, each version is its own independent thread, which makes it hard to track changes. This link has the documentation for the proper way to handle subsequent patches:
> 
> https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html
> 
> The relevant part starts at "To that end, send them as replies to either..."

I wonder which way is preferred. I have been reading the kernel 
documentation at 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#explicit-in-reply-to-headers

Quoting the instructions:

"However, for a multi-patch series, it is generally best to avoid using 
In-Reply-To: to link to older versions of the series."

> Another good practice is to have the previous versions' links from "lore.kernel.org" directly in the change log.

Good point, thank you. I will start to include the links to previous 
versions.

> Thanks,
> David Hunter

How come there are two sets of documentation?

Best regards,

Hanne-Lotta Mäenpää

Re: [PATCH v4] media: Documentation: Improve grammar in DVB API

[Brigham Campbell]

On Wed Jul 9, 2025 at 10:22 PM MDT, David Hunter wrote:
> On 7/8/25 11:52, Hanne-Lotta Mäenpää wrote:
>> Fix typos and punctuation and improve grammar in documentation.
>> 
>> Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>
>
> Overall, good work. Here is a suggestion for future patch series:
>
> Subsequent versions of patch series should be posted as replies in the same thread. Currently, each version is its own independent thread, which makes it hard to track changes. This link has the documentation for the proper way to handle subsequent patches:
>
> https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html
>
> The relevant part starts at "To that end, send them as replies to either..."

This documentation you've linked is specific to git, not the linux
kernel.

The kernel documentation argues against doing what you suggest [1]: "for
a multi-patch series, it is generally best to avoid using In-Reply-To:
to link to older versions of the series. This way multiple versions of
the patch don’t become an unmanageable forest of references in email
clients."

[1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html

>
> Another good practice is to have the previous versions' links from "lore.kernel.org" directly in the change log. 
>
> Thanks, 
> David Hunter

Nice work, as usual, Hanne-Lotta.

Brigham

Re: [PATCH v4] media: Documentation: Improve grammar in DVB API

[Hanne-Lotta Mäenpää]

Hello,

On 7/11/25 2:55 AM, Brigham Campbell wrote:
> On Wed Jul 9, 2025 at 10:22 PM MDT, David Hunter wrote:
>> On 7/8/25 11:52, Hanne-Lotta Mäenpää wrote:
>>> Fix typos and punctuation and improve grammar in documentation.
>>>
>>> Signed-off-by: Hanne-Lotta Mäenpää <hannelotta@gmail.com>
>>
>> Overall, good work. Here is a suggestion for future patch series:
>>
>> Subsequent versions of patch series should be posted as replies in the same thread. Currently, each version is its own independent thread, which makes it hard to track changes. This link has the documentation for the proper way to handle subsequent patches:
>>
>> https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html
>>
>> The relevant part starts at "To that end, send them as replies to either..."
> 
> This documentation you've linked is specific to git, not the linux
> kernel.
> 
> The kernel documentation argues against doing what you suggest [1]: "for
> a multi-patch series, it is generally best to avoid using In-Reply-To:
> to link to older versions of the series. This way multiple versions of
> the patch don’t become an unmanageable forest of references in email
> clients."
> 
> [1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> 

Right, that clears it up. On a closer look, the URL indicates which 
documentation is for git development.

> 
> Nice work, as usual, Hanne-Lotta.
> 
> Brigham
> 

I really appreciate this comment. Thank you for your encouragement!

Best regards,

Hanne-Lotta Mäenpää