Lines Matching refs:and

12  cable), and provides a register interface to allow drivers to determine what
13  settings were chosen, and to configure what settings are allowed.
15  While these devices are distinct from the network devices, and conform to a
18  amounts of redundant code.  Also, on embedded systems with multiple (and
22  Since the PHYs are devices, and the management busses through which they are
28    3) Speed development time for new network drivers, and for new systems
41  1) read and write functions must be implemented.  Their prototypes are:
46    mii_id is the address on the bus for the PHY, and regnum is the register
55    driver needs, setup the mii_bus structure, and register with the PAL using
59  4) Like any driver, the device_driver structure must be configured, and init
62  5) The bus must also be declared somewhere as a device, and registered.
65  drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file
71  between the PHY device, and the network device.  At this time, the PHY's bus
72  and drivers need to all have been loaded, so it is ready for the connection.
75  1) The PAL handles everything, and only calls the network driver when
86    manually calling functions to update status, and configure the PHY
101  bus id, and the second is the PHY's address on that bus.  Typically,
111  PHY's software state machine, and registered for the PHY's interrupt, if it
118  and perform specific operations based on them.
123  between the controller and the PHY.  Examples are GMII, MII,
124  RGMII, and SGMII.  For a full list, see include/linux/phy.h
126  Now just make sure that phydev->supported and phydev->advertising have any
134  phy_start(phydev).  This tells the PAL that you are ready, and configures the
145  keep your network device and the PHY properly in sync.  If so, you can
148  need to manually call phy_attach() and phy_prepare_link(), and then call
152  Currently there are no examples of how to use this functionality, and testing
159  the complex interactions between the PHY and your network device.  If this is
160  so, you can simply call phy_attach(), and not call phy_start_machine or
162  handle (phy_start and phy_stop toggle between some of the states, so you
166  accessed without the state-machine running, and most of these functions are
198    and resets autonegotiation, or disables autonegotiation, and configures
216    use this only to write registers which are not standard, and don't set off
224  many PHYs require a little hand-holding to get up-and-running.
230  support, and let the PHY Abstraction Layer's Generic PHY Driver
238  UID (stored in registers 2 and 3), then comparing it to each
250  etc) your PHY device and driver support.  Most PHYs support
278  Of these, only config_aneg and read_status are required to be
281  functions if at all possible: genphy_read_status and
283  you only need to perform some actions before and after invoking
284  these functions, and so your functions will wrap the generic
287  Feel free to look at the Marvell, Cicada, and Davicom drivers in
288  drivers/net/phy/ for examples (the lxt and qsemi drivers have
299  registers for EEE query and configuration if the PHY supports
307  Sometimes the specific interaction between the platform and the PHY requires
315  field) and the bus identifier (contained in phydev->dev.bus_id).  Both must
316  match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
317  wildcards for the bus ID and UID, respectively.
329  Or using one of the two stubs, phy_register_fixup_for_uid() and
337  The stubs set one of the two matching criteria, and set the other one to