Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tjh.dev
kernel
os
linux
1# SPDX-License-Identifier: GPL-2.0
2%YAML 1.2
3---
4$id: http://devicetree.org/schemas/net/ethernet-controller.yaml#
5$schema: http://devicetree.org/meta-schemas/core.yaml#
6
7title: Ethernet Controller Common Properties
8
9maintainers:
10 - David S. Miller <davem@davemloft.net>
11
12properties:
13 $nodename:
14 pattern: "^ethernet(@.*)?$"
15
16 label:
17 description: Human readable label on a port of a box.
18
19 max-speed:
20 $ref: /schemas/types.yaml#/definitions/uint32
21 description:
22 Specifies maximum speed in Mbit/s supported by the device.
23
24 nvmem-cells:
25 maxItems: 1
26 description:
27 Reference to an nvmem node for the MAC address
28
29 nvmem-cell-names:
30 const: mac-address
31
32 phy-connection-type:
33 description:
34 Specifies interface type between the Ethernet device and a physical
35 layer (PHY) device.
36 enum:
37 # There is not a standard bus between the MAC and the PHY,
38 # something proprietary is being used to embed the PHY in the
39 # MAC.
40 - internal
41 - mii
42 - mii-lite
43 - gmii
44 - sgmii
45 - psgmii
46 - qsgmii
47 - qusgmii
48 - tbi
49 - rev-mii
50 - rmii
51 - rev-rmii
52 - moca
53
54 # RX and TX delays are provided by the PCB. See below
55 - rgmii
56
57 # RX and TX delays are not provided by the PCB. This is the most
58 # frequent case. See below
59 - rgmii-id
60
61 # TX delay is provided by the PCB. See below
62 - rgmii-rxid
63
64 # RX delay is provided by the PCB. See below
65 - rgmii-txid
66 - rtbi
67 - smii
68 - xgmii
69 - trgmii
70 - 1000base-x
71 - 2500base-x
72 - 5gbase-r
73 - rxaui
74 - xaui
75
76 # 10GBASE-KR, XFI, SFI
77 - 10gbase-kr
78 - usxgmii
79 - 10gbase-r
80 - 25gbase-r
81 - 10g-qxgmii
82
83 phy-mode:
84 $ref: "#/properties/phy-connection-type"
85
86 pcs-handle:
87 $ref: /schemas/types.yaml#/definitions/phandle-array
88 items:
89 maxItems: 1
90 description:
91 Specifies a reference to a node representing a PCS PHY device on a MDIO
92 bus to link with an external PHY (phy-handle) if exists.
93
94 pcs-handle-names:
95 description:
96 The name of each PCS in pcs-handle.
97
98 phy-handle:
99 $ref: /schemas/types.yaml#/definitions/phandle
100 description:
101 Specifies a reference to a node representing a PHY device.
102
103 phy:
104 $ref: "#/properties/phy-handle"
105 deprecated: true
106
107 phy-device:
108 $ref: "#/properties/phy-handle"
109 deprecated: true
110
111 rx-fifo-depth:
112 $ref: /schemas/types.yaml#/definitions/uint32
113 description:
114 The size of the controller\'s receive fifo in bytes. This is used
115 for components that can have configurable receive fifo sizes,
116 and is useful for determining certain configuration settings
117 such as flow control thresholds.
118
119 sfp:
120 $ref: /schemas/types.yaml#/definitions/phandle
121 description:
122 Specifies a reference to a node representing a SFP cage.
123
124 tx-fifo-depth:
125 $ref: /schemas/types.yaml#/definitions/uint32
126 description:
127 The size of the controller\'s transmit fifo in bytes. This
128 is used for components that can have configurable fifo sizes.
129
130 managed:
131 description:
132 Specifies the PHY management type. If auto is set and fixed-link
133 is not specified, it uses MDIO for management.
134 $ref: /schemas/types.yaml#/definitions/string
135 default: auto
136 enum:
137 - auto
138 - in-band-status
139
140 fixed-link:
141 oneOf:
142 - $ref: /schemas/types.yaml#/definitions/uint32-array
143 deprecated: true
144 items:
145 - minimum: 0
146 maximum: 31
147 description:
148 Emulated PHY ID, choose any but unique to the all
149 specified fixed-links
150
151 - enum: [0, 1]
152 description:
153 Duplex configuration. 0 for half duplex or 1 for
154 full duplex
155
156 - enum: [10, 100, 1000, 2500, 10000]
157 description:
158 Link speed in Mbits/sec.
159
160 - enum: [0, 1]
161 description:
162 Pause configuration. 0 for no pause, 1 for pause
163
164 - enum: [0, 1]
165 description:
166 Asymmetric pause configuration. 0 for no asymmetric
167 pause, 1 for asymmetric pause
168 - type: object
169 additionalProperties: false
170 properties:
171 speed:
172 description:
173 Link speed.
174 $ref: /schemas/types.yaml#/definitions/uint32
175 enum: [10, 100, 1000, 2500, 5000, 10000]
176
177 full-duplex:
178 $ref: /schemas/types.yaml#/definitions/flag
179 description:
180 Indicates that full-duplex is used. When absent, half
181 duplex is assumed.
182
183 pause:
184 $ref: /schemas/types.yaml#/definitions/flag
185 description:
186 Indicates that pause should be enabled.
187
188 asym-pause:
189 $ref: /schemas/types.yaml#/definitions/flag
190 description:
191 Indicates that asym_pause should be enabled.
192
193 link-gpios:
194 maxItems: 1
195 description:
196 GPIO to determine if the link is up
197
198 required:
199 - speed
200
201 leds:
202 description:
203 Describes the LEDs associated by Ethernet Controller.
204 These LEDs are not integrated in the PHY and PHY doesn't have any
205 control on them. Ethernet Controller regs are used to control
206 these defined LEDs.
207
208 type: object
209
210 properties:
211 '#address-cells':
212 const: 1
213
214 '#size-cells':
215 const: 0
216
217 patternProperties:
218 '^led@[a-f0-9]+$':
219 $ref: /schemas/leds/common.yaml#
220
221 properties:
222 reg:
223 maxItems: 1
224 description:
225 This define the LED index in the PHY or the MAC. It's really
226 driver dependent and required for ports that define multiple
227 LED for the same port.
228
229 required:
230 - reg
231
232 unevaluatedProperties: false
233
234 additionalProperties: false
235
236dependencies:
237 pcs-handle-names: [pcs-handle]
238
239allOf:
240 - $ref: /schemas/net/network-class.yaml#
241 - if:
242 properties:
243 phy-mode:
244 contains:
245 enum:
246 - rgmii
247 - rgmii-rxid
248 - rgmii-txid
249 - rgmii-id
250 then:
251 properties:
252 rx-internal-delay-ps:
253 description:
254 RGMII Receive Clock Delay defined in pico seconds. This is used for
255 controllers that have configurable RX internal delays. If this
256 property is present then the MAC applies the RX delay.
257 tx-internal-delay-ps:
258 description:
259 RGMII Transmit Clock Delay defined in pico seconds. This is used for
260 controllers that have configurable TX internal delays. If this
261 property is present then the MAC applies the TX delay.
262
263additionalProperties: true
264
265# Informative
266# ===========
267#
268# 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',
269# 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by
270# developers. This informative section clarifies their usage.
271#
272# The RGMII specification requires a 2ns delay between the data and
273# clock signals on the RGMII bus. How this delay is implemented is not
274# specified.
275#
276# One option is to make the clock traces on the PCB longer than the
277# data traces. A sufficiently difference in length can provide the 2ns
278# delay. If both the RX and TX delays are implemented in this manner,
279# 'rgmii' should be used, so indicating the PCB adds the delays.
280#
281# If the PCB does not add these delays via extra long traces,
282# 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
283# where either the MAC or PHY adds the delay.
284#
285# If only one of the two delays are implemented via extra long clock
286# lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,
287# indicating the MAC or PHY should implement one of the delays
288# internally, while the PCB implements the other delay.
289#
290# Device Tree describes hardware, and in this case, it describes the
291# PCB between the MAC and the PHY, if the PCB implements delays or
292# not.
293#
294# In practice, very few PCBs make use of extra long clock lines. Hence
295# any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
296# unlikely to be accepted during review without details provided in
297# the commit description and comments in the .dts file.
298#
299# When the PCB does not implement the delays, the MAC or PHY must. As
300# such, this is software configuration, and so not described in Device
301# Tree.
302#
303# The following describes how Linux implements the configuration of
304# the MAC and PHY to add these delays when the PCB does not. As stated
305# above, developers often get this wrong, and the aim of this section
306# is reduce the frequency of these errors by Linux developers. Other
307# users of the Device Tree may implement it differently, and still be
308# consistent with both the normative and informative description
309# above.
310#
311# By default in Linux, when using phylib/phylink, the MAC is expected
312# to read the 'phy-mode' from Device Tree, not implement any delays,
313# and pass the value to the PHY. The PHY will then implement delays as
314# specified by the 'phy-mode'. The PHY should always be reconfigured
315# to implement the needed delays, replacing any setting performed by
316# strapping or the bootloader, etc.
317#
318# Experience to date is that all PHYs which implement RGMII also
319# implement the ability to add or not add the needed delays. Hence
320# this default is expected to work in all cases. Ignoring this default
321# is likely to be questioned by Reviews, and require a strong argument
322# to be accepted.
323#
324# There are a small number of cases where the MAC has hard coded
325# delays which cannot be disabled. The 'phy-mode' only describes the
326# PCB. The inability to disable the delays in the MAC does not change
327# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
328# 'rgmii' is now invalid, it cannot be supported, since both the PCB
329# and the MAC and PHY adding delays cannot result in a functional
330# link. Thus the MAC should report a fatal error for any modes which
331# cannot be supported. When the MAC implements the delay, it must
332# ensure that the PHY does not also implement the same delay. So it
333# must modify the phy-mode it passes to the PHY, removing the delay it
334# has added. Failure to remove the delay will result in a
335# non-functioning link.
336#
337# Sometimes there is a need to fine tune the delays. Often the MAC or
338# PHY can perform this fine tuning. In the MAC node, the Device Tree
339# properties 'rx-internal-delay-ps' and 'tx-internal-delay-ps' should
340# be used to indicate fine tuning performed by the MAC. The values
341# expected here are small. A value of 2000ps, i.e 2ns, and a phy-mode
342# of 'rgmii' will not be accepted by Reviewers.
343#
344# If the PHY is to perform fine tuning, the properties
345# 'rx-internal-delay-ps' and 'tx-internal-delay-ps' in the PHY node
346# should be used. When the PHY is implementing delays, e.g. 'rgmii-id'
347# these properties should have a value near to 2000ps. If the PCB is
348# implementing delays, e.g. 'rgmii', a small value can be used to fine
349# tune the delay added by the PCB.
350...