On Fri, Aug 26, 2022 at 4:14 PM Jean Delvare <jdelvare@xxxxxxx> wrote: > > "sturct" -> "struct" > "similar than with" -> "similar to" > Missing comma, "it" and "to" Makes sense to me, thanks! Reviewed-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > Signed-off-by: Jean Delvare <jdelvare@xxxxxxx> > Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx> > Cc: Len Brown <lenb@xxxxxxxxxx> > --- > 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/ > > > -- > Jean Delvare > SUSE L3 Support -- With Best Regards, Andy Shevchenko
