On Fri, Aug 26, 2022 at 5:31 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > 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/ > > > > > > -- Applied as 6.1 material, thanks!
