mirror of
https://github.com/torvalds/linux.git
synced 2024-11-21 19:41:42 +00:00
ACPI: docs: enumeration: Fix a few typos and wording mistakes
"sturct" -> "struct" "similar than with" -> "similar to" Missing comma, "it" and "to" Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This commit is contained in:
parent
b90cb10531
commit
e6e8c6c238
@ -21,7 +21,7 @@ possible we decided to do following:
|
||||
- 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 @@ Here is what the ACPI namespace for a SPI slave might look like::
|
||||
}
|
||||
...
|
||||
|
||||
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 relative and path "\\_SB.PCI0.GPI0"
|
||||
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 hierarchical description is required, from
|
||||
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 @@ of the chipset bridge (also called "root port") with address::
|
||||
|
||||
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/
|
||||
|
Loading…
Reference in New Issue
Block a user