Lines Matching +full:phy +full:- +full:is +full:- +full:integrated
1 # SPDX-License-Identifier: GPL-2.0
3 ---
4 $id: http://devicetree.org/schemas/net/ethernet-controller.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - David S. Miller <davem@davemloft.net>
19 max-speed:
24 nvmem-cells:
29 nvmem-cell-names:
30 const: mac-address
32 phy-connection-type:
35 layer (PHY) device.
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
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
55 - rgmii
57 # RX and TX delays are not provided by the PCB. This is the most
59 - rgmii-id
61 # TX delay is provided by the PCB. See below
62 - rgmii-rxid
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
76 # 10GBASE-KR, XFI, SFI
77 - 10gbase-kr
78 - usxgmii
79 - 10gbase-r
80 - 25gbase-r
81 - 10g-qxgmii
83 phy-mode:
84 $ref: "#/properties/phy-connection-type"
86 pcs-handle:
87 $ref: /schemas/types.yaml#/definitions/phandle-array
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.
94 pcs-handle-names:
96 The name of each PCS in pcs-handle.
98 phy-handle:
101 Specifies a reference to a node representing a PHY device.
103 phy:
104 $ref: "#/properties/phy-handle"
107 phy-device:
108 $ref: "#/properties/phy-handle"
111 rx-fifo-depth:
114 The size of the controller\'s receive fifo in bytes. This is used
116 and is useful for determining certain configuration settings
124 tx-fifo-depth:
128 is used for components that can have configurable fifo sizes.
132 Specifies the PHY management type. If auto is set and fixed-link
133 is not specified, it uses MDIO for management.
137 - auto
138 - in-band-status
140 fixed-link:
142 - $ref: /schemas/types.yaml#/definitions/uint32-array
145 - minimum: 0
148 Emulated PHY ID, choose any but unique to the all
149 specified fixed-links
151 - enum: [0, 1]
156 - enum: [10, 100, 1000, 2500, 10000]
160 - enum: [0, 1]
164 - enum: [0, 1]
168 - type: object
177 full-duplex:
180 Indicates that full-duplex is used. When absent, half
181 duplex is assumed.
188 asym-pause:
193 link-gpios:
196 GPIO to determine if the link is up
199 - speed
204 These LEDs are not integrated in the PHY and PHY doesn't have any
211 '#address-cells':
214 '#size-cells':
218 '^led@[a-f0-9]+$':
225 This define the LED index in the PHY or the MAC. It's really
230 - reg
237 pcs-handle-names: [pcs-handle]
240 - $ref: /schemas/net/network-class.yaml#
241 - if:
243 phy-mode:
246 - rgmii
247 - rgmii-rxid
248 - rgmii-txid
249 - rgmii-id
252 rx-internal-delay-ps:
254 RGMII Receive Clock Delay defined in pico seconds. This is used for
256 property is present then the MAC applies the RX delay.
257 tx-internal-delay-ps:
259 RGMII Transmit Clock Delay defined in pico seconds. This is used for
261 property is present then the MAC applies the TX delay.
268 # 'phy-modes' & 'phy-connection-type' properties 'rgmii', 'rgmii-id',
269 # 'rgmii-rxid', and 'rgmii-txid' are frequently used wrongly by
273 # clock signals on the RGMII bus. How this delay is implemented is not
276 # One option is to make the clock traces on the PCB longer than the
282 # 'rgmii-id' should be used. Here, 'id' refers to 'internal delay',
283 # where either the MAC or PHY adds the delay.
286 # lines, either 'rgmii-rxid' or 'rgmii-txid' should be used,
287 # indicating the MAC or PHY should implement one of the delays
291 # PCB between the MAC and the PHY, if the PCB implements delays or
295 # any RGMII phy mode other than 'rgmii-id' is probably wrong, and is
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
304 # the MAC and PHY to add these delays when the PCB does not. As stated
306 # is reduce the frequency of these errors by Linux developers. Other
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
318 # Experience to date is that all PHYs which implement RGMII also
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
325 # delays which cannot be disabled. The 'phy-mode' only describes the
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
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
335 # non-functioning link.
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
341 # expected here are small. A value of 2000ps, i.e 2ns, and a phy-mode
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