mirror of https://github.com/torvalds/linux.git
dt-bindings: fix spelling, typos, grammar, duplicated words
Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
This commit is contained in:
Markus Heidelberg
Rob Herring (Arm)
parent
86eedc669a
commit
d6f57d8c5a
|
|
@ -140,7 +140,7 @@ patternProperties:
|
|||
the connection between the motherboard and any tiles. Sometimes the
|
||||
compatible is placed directly under this node, sometimes it is placed
|
||||
in a subnode named "motherboard-bus". Sometimes the compatible includes
|
||||
"arm,vexpress,v2?-p1" sometimes (on software models) is is just
|
||||
"arm,vexpress,v2?-p1" sometimes (on software models) it is just
|
||||
"simple-bus". If the compatible is placed in the "motherboard-bus" node,
|
||||
it is stricter and always has two compatibles.
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ required:
|
|||
#
|
||||
# For multiple 'if' schema, group them under an 'allOf'.
|
||||
#
|
||||
# If the conditionals become too unweldy, then it may be better to just split
|
||||
# If the conditionals become too unwieldy, then it may be better to just split
|
||||
# the binding into separate schema documents.
|
||||
allOf:
|
||||
- if:
|
||||
|
|
|
|||
|
|
@ -35,8 +35,8 @@ and bit-banged data signals:
|
|||
<&gpio1 15 0>;
|
||||
|
||||
In the above example, &gpio1 uses 2 cells to specify a gpio. The first cell is
|
||||
a local offset to the GPIO line and the second cell represent consumer flags,
|
||||
such as if the consumer desire the line to be active low (inverted) or open
|
||||
a local offset to the GPIO line and the second cell represents consumer flags,
|
||||
such as if the consumer desires the line to be active low (inverted) or open
|
||||
drain. This is the recommended practice.
|
||||
|
||||
The exact meaning of each specifier cell is controller specific, and must be
|
||||
|
|
@ -59,7 +59,7 @@ GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
|||
Optional standard bitfield specifiers for the last cell:
|
||||
|
||||
- Bit 0: 0 means active high, 1 means active low
|
||||
- Bit 1: 0 mean push-pull wiring, see:
|
||||
- Bit 1: 0 means push-pull wiring, see:
|
||||
https://en.wikipedia.org/wiki/Push-pull_output
|
||||
1 means single-ended wiring, see:
|
||||
https://en.wikipedia.org/wiki/Single-ended_triode
|
||||
|
|
@ -176,7 +176,7 @@ example of a name from an SoC's reference manual) would not be desirable.
|
|||
|
||||
In either case placeholders are discouraged: rather use the "" (blank
|
||||
string) if the use of the GPIO line is undefined in your design. Ideally,
|
||||
try to add comments to the dts file describing the naming the convention
|
||||
try to add comments to the dts file describing the naming convention
|
||||
you have chosen, and specifying from where the names are derived.
|
||||
|
||||
The names are assigned starting from line offset 0, from left to right,
|
||||
|
|
@ -304,7 +304,7 @@ pins 50..69.
|
|||
It is also possible to use pin groups for gpio ranges when pin groups are the
|
||||
easiest and most convenient mapping.
|
||||
|
||||
Both both <pinctrl-base> and <count> must set to 0 when using named pin groups
|
||||
Both <pinctrl-base> and <count> must be set to 0 when using named pin groups
|
||||
names.
|
||||
|
||||
The property gpio-ranges-group-names must contain exactly one string for each
|
||||
|
|
@ -313,7 +313,7 @@ range.
|
|||
Elements of gpio-ranges-group-names must contain the name of a pin group
|
||||
defined in the respective pin controller. The number of pins/GPIO lines in the
|
||||
range is the number of pins in that pin group. The number of pins of that
|
||||
group is defined int the implementation and not in the device tree.
|
||||
group is defined in the implementation and not in the device tree.
|
||||
|
||||
If numerical and named pin groups are mixed, the string corresponding to a
|
||||
numerical pin range in gpio-ranges-group-names must be empty.
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ description: |+
|
|||
As above, The Multimedia HW will go through SMI and M4U while it
|
||||
access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
|
||||
smi local arbiter and smi common. It will control whether the Multimedia
|
||||
HW should go though the m4u for translation or bypass it and talk
|
||||
HW should go through the m4u for translation or bypass it and talk
|
||||
directly with EMI. And also SMI help control the power domain and clocks for
|
||||
each local arbiter.
|
||||
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ properties:
|
|||
default-state:
|
||||
description:
|
||||
The initial state of the LED. If the LED is already on or off and the
|
||||
default-state property is set the to same value, then no glitch should be
|
||||
default-state property is set to the same value, then no glitch should be
|
||||
produced where the LED momentarily turns off (or on). The "keep" setting
|
||||
will keep the LED at whatever its current state is, without producing a
|
||||
glitch.
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ properties:
|
|||
'#gpio-cells':
|
||||
description:
|
||||
The first cell is the pin number.
|
||||
The second cell is is used to specify flags.
|
||||
The second cell is used to specify flags.
|
||||
See ../gpio/gpio.txt for more information.
|
||||
const: 2
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ properties:
|
|||
'#gpio-cells':
|
||||
description:
|
||||
The first cell is the pin number.
|
||||
The second cell is is used to specify flags.
|
||||
The second cell is used to specify flags.
|
||||
See ../gpio/gpio.txt for more information.
|
||||
const: 2
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ properties:
|
|||
'#gpio-cells':
|
||||
description:
|
||||
The first cell is the pin number.
|
||||
The second cell is is used to specify flags.
|
||||
The second cell is used to specify flags.
|
||||
See ../gpio/gpio.txt for more information.
|
||||
const: 2
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ properties:
|
|||
# latter case. We choose to use the XOR logic for GPIO CD and WP
|
||||
# lines. This means, the two properties are "superimposed," for
|
||||
# example leaving the GPIO_ACTIVE_LOW flag clear and specifying the
|
||||
# respective *-inverted property property results in a
|
||||
# respective *-inverted property results in a
|
||||
# double-inversion and actually means the "normal" line polarity is
|
||||
# in effect.
|
||||
wp-inverted:
|
||||
|
|
@ -264,7 +264,7 @@ properties:
|
|||
mmc-pwrseq-simple.yaml. But now it\'s reused as a tunable delay
|
||||
waiting for I/O signalling and card power supply to be stable,
|
||||
regardless of whether pwrseq-simple is used. Default to 10ms if
|
||||
no available.
|
||||
not available.
|
||||
default: 10
|
||||
|
||||
supports-cqe:
|
||||
|
|
|
|||
|
|
@ -149,7 +149,7 @@ properties:
|
|||
- description:
|
||||
The first register range should be the one of the DWMAC controller
|
||||
- description:
|
||||
The second range is is for the Amlogic specific configuration
|
||||
The second range is for the Amlogic specific configuration
|
||||
(for example the PRG_ETHERNET register range on Meson8b and newer)
|
||||
|
||||
interrupts:
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ properties:
|
|||
reg:
|
||||
maxItems: 1
|
||||
description:
|
||||
This define the LED index in the PHY or the MAC. It's really
|
||||
This defines the LED index in the PHY or the MAC. It's really
|
||||
driver dependent and required for ports that define multiple
|
||||
LED for the same port.
|
||||
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ properties:
|
|||
reg:
|
||||
maxItems: 1
|
||||
description:
|
||||
This define the LED index in the PHY or the MAC. It's really
|
||||
This defines the LED index in the PHY or the MAC. It's really
|
||||
driver dependent and required for ports that define multiple
|
||||
LED for the same port.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ KSZ9021:
|
|||
|
||||
All skew control options are specified in picoseconds. The minimum
|
||||
value is 0, the maximum value is 3000, and it can be specified in 200ps
|
||||
steps, *but* these values are in not fact what you get because this chip's
|
||||
steps, *but* these values are in no way what you get because this chip's
|
||||
skew values actually increase in 120ps steps, starting from -840ps. The
|
||||
incorrect values came from an error in the original KSZ9021 datasheet
|
||||
before it was corrected in revision 1.2 (Feb 2014), but it is too late to
|
||||
|
|
@ -153,7 +153,7 @@ KSZ9031:
|
|||
- micrel,force-master:
|
||||
Boolean, force phy to master mode. Only set this option if the phy
|
||||
reference clock provided at CLK125_NDO pin is used as MAC reference
|
||||
clock because the clock jitter in slave mode is to high (errata#2).
|
||||
clock because the clock jitter in slave mode is too high (errata#2).
|
||||
Attention: The link partner must be configurable as slave otherwise
|
||||
no link will be established.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Optional properties:
|
|||
Setting the RMII Reference Clock Select bit enables 25 MHz rather
|
||||
than 50 MHz clock mode.
|
||||
|
||||
Note that this option in only needed for certain PHY revisions with a
|
||||
Note that this option is only needed for certain PHY revisions with a
|
||||
non-standard, inverted function of this configuration bit.
|
||||
Specifically, a clock reference ("rmii-ref" below) is always needed to
|
||||
actually select a mode.
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ II. For kernel maintainers
|
|||
For subsystem bindings (anything affecting more than a single device),
|
||||
getting a devicetree maintainer to review it is required.
|
||||
|
||||
3) For a series going though multiple trees, the binding patch should be
|
||||
3) For a series going through multiple trees, the binding patch should be
|
||||
kept with the driver using the binding.
|
||||
|
||||
4) The DTS files should however never be applied via driver subsystem tree,
|
||||
|
|
|
|||
Loading…
Reference in New Issue