Lines Matching +full:phy +full:- +full:device
2 -------
3 PHY Abstraction Layer
4 (Updated 2008-04-08)
10 PHY. The PHY concerns itself with negotiating link parameters with the link
17 the PHY management code with the network driver. This has resulted in large
23 accessed are, in fact, busses, the PHY Abstraction Layer treats them as such.
26 1) Increase code-reuse
27 2) Increase overall code-maintainability
30 Basically, this layer is meant to provide an interface to PHY devices which
36 Most network devices are connected to a PHY by means of a management bus.
39 registered as a distinct device.
46 mii_id is the address on the bus for the PHY, and regnum is the register
62 5) The bus must also be declared somewhere as a device, and registered.
66 for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/")
70 The Reduced Gigabit Medium Independent Interface (RGMII) is a 12-pin
73 between the clock line (RXC or TXC) and the data lines to let the PHY (clock
75 PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let
76 the PHY driver and optionally the MAC driver, implement the required delay. The
77 values of phy_interface_t must be understood from the perspective of the PHY
78 device itself, leading to the following:
80 * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
82 or the PCB traces) insert the correct 1.5-2ns delay
84 * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
85 for the transmit data lines (TXD[3:0]) processed by the PHY device
87 * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
88 for the receive data lines (RXD[3:0]) processed by the PHY device
90 * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
91 both transmit AND receive data lines from/to the PHY device
93 Whenever possible, use the PHY side RGMII delay for these reasons:
95 * PHY devices may offer sub-nanosecond granularity in how they allow a
99 * PHY devices are typically qualified for a large range of applications
103 * PHY device drivers in PHYLIB being reusable by nature, being able to
107 For cases where the PHY is not capable of providing this delay, but the
111 side delay from the perspective of the PHY device. Conversely, if the Ethernet
113 PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are
116 In case neither the Ethernet MAC, nor the PHY are capable of providing the
129 When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this
131 the PHY or MAC take a snapshot of these signals to translate them into logical
145 Connecting to a PHY
148 between the PHY device, and the network device. At this time, the PHY's bus
150 At this point, there are several ways to connect to the PHY:
162 4) The PAL serves only as a library of functions, with the network device
163 manually calling functions to update status, and configure the PHY
166 Letting the PHY Abstraction Layer do Everything
169 useful to drivers that can't), connecting to the PHY is simple:
176 Next, you need to know the device name of the PHY connected to this device.
178 bus id, and the second is the PHY's address on that bus. Typically,
185 phydev is a pointer to the phy_device structure which represents the PHY. If
188 PHY's software state machine, and registered for the PHY's interrupt, if it
190 current state, though the PHY will not yet be truly operational at this
193 PHY-specific flags should be set in phydev->dev_flags prior to the call
194 to phy_connect() such that the underlying PHY driver can check for flags
197 the PHY/controller, of which the PHY needs to be aware.
200 between the controller and the PHY. Examples are GMII, MII,
201 RGMII, and SGMII. For a full list, see include/linux/phy.h
203 Now just make sure that phydev->supported and phydev->advertising have any
205 controller may be connected to a gigabit capable PHY, so you would need to
208 SUPPORTED_Pause and SUPPORTED_AsymPause bits (see below), or the PHY may get
213 PHY to connect to the network. If you want to handle your own interrupts,
214 just set phydev->irq to PHY_IGNORE_INTERRUPT before you call phy_start.
215 Similarly, if you don't want to use interrupts, set phydev->irq to PHY_POLL.
222 The PHY does not participate directly in flow control/pause frames except by
235 It is possible that the PAL's built-in state machine needs a little help to
236 keep your network device and the PHY properly in sync. If so, you can
237 register a helper function when connecting to the PHY, which will be called
249 There's a remote chance that the PAL's built-in state machine cannot track
250 the complex interactions between the PHY and your network device. If this is
252 phy_prepare_link(). This will mean that phydev->state is entirely yours to
257 accessed without the state-machine running, and most of these functions are
258 descended from functions which did not interact with a complex state-machine.
272 A convenience function to print out the PHY status neatly.
277 Requests the IRQ for the PHY interrupts, then enables them for
283 Attaches a network device to a particular PHY, binding the PHY to a generic
294 Fills the phydev structure with up-to-date information about the current
295 settings in the PHY.
310 PHY Device Drivers
312 With the PHY Abstraction Layer, adding support for new PHYs is
314 many PHYs require a little hand-holding to get up-and-running.
316 Generic PHY driver
318 If the desired PHY doesn't have any errata, quirks, or special
320 support, and let the PHY Abstraction Layer's Generic PHY Driver
323 Writing a PHY driver
325 If you do need to write a PHY driver, the first thing to do is
326 make sure it can be matched with an appropriate PHY device.
327 This is done during bus initialization by reading the device's
340 etc) your PHY device and driver support. Most PHYs support
345 in include/linux/phy.h under the phy_driver structure.
349 preferred to use the generic phy driver's versions of these two
357 drivers/net/phy/ for examples (the lxt and qsemi drivers have
360 The PHY's MMD register accesses are handled by the PAL framework
361 by default, but can be overridden by a specific PHY driver if
362 required. This could be the case if a PHY was released for
363 manufacturing before the MMD PHY register definitions were
365 the generic PAL framework for accessing the PHY's MMD registers.
368 registers for EEE query and configuration if the PHY supports
369 the IEEE standard access mechanisms, or can use the PHY's specific
370 access interfaces if overridden by the specific PHY driver. See
371 the Micrel driver in drivers/net/phy/ for an example of how this
376 Sometimes the specific interaction between the platform and the PHY requires
377 special handling. For instance, to change where the PHY's clock input is,
379 to support such contingencies, the PHY Layer allows platform code to register
380 fixups to be run when the PHY is brought up (or subsequently reset).
382 When the PHY Layer brings up a PHY it checks to see if there are any fixups
383 registered for it, matching based on UID (contained in the PHY device's phy_id
384 field) and the bus identifier (contained in phydev->dev.bus_id). Both must
388 When a match is found, the PHY layer will invoke the run function associated
390 interest. It should therefore only operate on that PHY.
421 http://standards.ieee.org/getieee802/download/802.3-2008_section2.pdf