Re: [PATCH] ACPI: docs: enumeration: Fix a few typos and wording mistakes

["Rafael J. Wysocki" <rafael@kernel.org>]

On Fri, Aug 26, 2022 at 5:31 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Fri, Aug 26, 2022 at 4:14 PM Jean Delvare <jdelvare@suse.de> wrote:
> >
> > "sturct" -> "struct"
> > "similar than with" -> "similar to"
> > Missing comma, "it" and "to"
>
> Makes sense to me, thanks!
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
> > Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> > Cc: Len Brown <lenb@kernel.org>
> > ---
> >  Documentation/firmware-guide/acpi/enumeration.rst |   16 ++++++++--------
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > --- linux-5.19.orig/Documentation/firmware-guide/acpi/enumeration.rst   2022-08-26 12:46:35.307949217 +0200
> > +++ linux-5.19/Documentation/firmware-guide/acpi/enumeration.rst        2022-08-26 15:02:50.245981296 +0200
> > @@ -21,7 +21,7 @@ In order to support this and re-use the
> >    - Devices behind real busses where there is a connector resource
> >      are represented as struct spi_device or struct i2c_device. Note
> >      that standard UARTs are not busses so there is no struct uart_device,
> > -    although some of them may be represented by sturct serdev_device.
> > +    although some of them may be represented by struct serdev_device.
> >
> >  As both ACPI and Device Tree represent a tree of devices (and their
> >  resources) this implementation follows the Device Tree way as much as
> > @@ -205,7 +205,7 @@ enumerated once spi_register_master() is
> >                 }
> >                 ...
> >
> > -The SPI device drivers only need to add ACPI IDs in a similar way than with
> > +The SPI device drivers only need to add ACPI IDs in a similar way to
> >  the platform device drivers. Below is an example where we add ACPI support
> >  to at25 SPI eeprom driver (this is meant for the above ACPI snippet)::
> >
> > @@ -362,7 +362,7 @@ These GPIO numbers are controller relati
> >  specifies the path to the controller. In order to use these GPIOs in Linux
> >  we need to translate them to the corresponding Linux GPIO descriptors.
> >
> > -There is a standard GPIO API for that and is documented in
> > +There is a standard GPIO API for that and it is documented in
> >  Documentation/admin-guide/gpio/.
> >
> >  In the above example we can get the corresponding two GPIO descriptors with
> > @@ -538,8 +538,8 @@ information.
> >  PCI hierarchy representation
> >  ============================
> >
> > -Sometimes could be useful to enumerate a PCI device, knowing its position on the
> > -PCI bus.
> > +Sometimes it could be useful to enumerate a PCI device, knowing its position on
> > +the PCI bus.
> >
> >  For example, some systems use PCI devices soldered directly on the mother board,
> >  in a fixed position (ethernet, Wi-Fi, serial ports, etc.). In this conditions it
> > @@ -550,7 +550,7 @@ To identify a PCI device, a complete hie
> >  the chipset root port to the final device, through all the intermediate
> >  bridges/switches of the board.
> >
> > -For example, let us assume to have a system with a PCIe serial port, an
> > +For example, let's assume we have a system with a PCIe serial port, an
> >  Exar XR17V3521, soldered on the main board. This UART chip also includes
> >  16 GPIOs and we want to add the property ``gpio-line-names`` [1] to these pins.
> >  In this case, the ``lspci`` output for this component is::
> > @@ -593,8 +593,8 @@ To describe this Exar device on the PCI
> >
> >         Bus: 0 - Device: 14 - Function: 1
> >
> > -To find this information is necessary disassemble the BIOS ACPI tables, in
> > -particular the DSDT (see also [2])::
> > +To find this information, it is necessary to disassemble the BIOS ACPI tables,
> > +in particular the DSDT (see also [2])::
> >
> >         mkdir ~/tables/
> >         cd ~/tables/
> >
> >
> > --

Applied as 6.1 material, thanks!