1. 26 Sep, 2019 1 commit
  2. 16 Aug, 2019 1 commit
  3. 06 Aug, 2019 1 commit
    • Nathan Chancellor's avatar
      net: mdio-octeon: Fix Kconfig warnings and build errors · b8fb6406
      Nathan Chancellor authored
      After commit 171a9bae ("staging/octeon: Allow test build on
      !MIPS"), the following combination of configs cause a few Kconfig
      warnings and build errors (distilled from arm allyesconfig and Randy's
      randconfig builds):
      and CONFIG_OCTEON_ETHERNET as either a module or built-in.
      WARNING: unmet direct dependencies detected for MDIO_OCTEON
        Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
      && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
        Selected by [y]:
      COMPILE_TEST [=y]) && NETDEVICES [=y]
      In file included from ../drivers/net/phy/mdio-octeon.c:14:
      ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
      function ‘writeq’; did you mean ‘writel’?
        111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
            |                                    ^~~~~~
      CONFIG_64BIT is not strictly necessary if the proper readq/writeq
      definitions are included from io-64-nonatomic-lo-hi.h.
      CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
      of commit f9dc9ac5 ("of/mdio: Add dummy functions in of_mdio.h.").
      Fixes: 171a9bae
       ("staging/octeon: Allow test build on !MIPS")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Reported-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      Reported-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  4. 03 Aug, 2019 1 commit
    • Andrew Jeffery's avatar
      net: phy: Add mdio-aspeed · f160e994
      Andrew Jeffery authored
      The AST2600 design separates the MDIO controllers from the MAC, which is
      where they were placed in the AST2400 and AST2500. Further, the register
      interface is reworked again, so now we have three possible different
      interface implementations, however this driver only supports the
      interface provided by the AST2600. The AST2400 and AST2500 will continue
      to be supported by the MDIO support embedded in the FTGMAC100 driver.
      The hardware supports both C22 and C45 mode, but for the moment only C22
      support is implemented.
      Signed-off-by: default avatarAndrew Jeffery <andrew@aj.id.au>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 09 Jun, 2019 1 commit
  6. 26 May, 2019 1 commit
  7. 21 May, 2019 1 commit
  8. 23 Apr, 2019 1 commit
    • Kavya Sree Kotagiri's avatar
      net: phy: mscc: add support for VSC8514 PHY. · e4f9ba64
      Kavya Sree Kotagiri authored
      The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX,
      1000BASE-X, can communicate with the MAC via QSGMII.
      The MAC interface protocol for each port within QSGMII can
      be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is
      connecting to supports this functionality.
      VSC8514 also supports SGMII MAC-side autonegotiation on each individual
      port, downshifting, can set the blinking pattern of each of its 4 LEDs,
      SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection.
      This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T,
      QSGMII link with the MAC, downshifting, HP Auto-MDIX detection
      and blinking pattern for its 4 LEDs.
      The GPIO register bank is a set of registers that are common to all PHYs
      in the package. So any modification in any register of this bank affects
      all PHYs of the package.
      If the PHYs haven't been reset before booting the Linux kernel and were
      configured to use interrupts for e.g. link status updates, it is
      required to clear the interrupts mask register of all PHYs before being
      able to use interrupts with any PHY. The first PHY of the package that
      will be init will take care of clearing all PHYs interrupts mask
      registers. Thus, we need to keep track of the init sequence in the
      package, if it's already been done or if it's to be done.
      Most of the init sequence of a PHY of the package is common to all PHYs
      in the package, thus we use the SMI broadcast feature which enables us
      to propagate a write in one register of one PHY to all PHYs in the same
      Signed-off-by: default avatarKavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
      Signed-off-by: default avatarQuentin Schulz <quentin.schulz@bootlin.com>
      Co-developed-by: default avatarQuentin Schulz <quentin.schulz@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  9. 07 Apr, 2019 1 commit
  10. 24 Mar, 2019 2 commits
  11. 21 Mar, 2019 1 commit
  12. 04 Mar, 2019 1 commit
  13. 27 Feb, 2019 1 commit
  14. 13 Sep, 2018 1 commit
  15. 22 Jul, 2018 1 commit
    • Guenter Roeck's avatar
      net: phy: sfp: Do not use "imply HWMON" · b5293443
      Guenter Roeck authored
      "imply HWMON" was supposed to ensure that the SFP phy code can be built
      with HWMON enabled or disabled while at the same time ensuring that
      HWMON is not built as module if SFP is built into the kernel.
      Unfortunately, that does not work as intended. With "allmodconfig", it
      results in several unrelated HWMON drivers to be disabled instead of
      being built as module as expected.
      Let's use the old "depends on HWMON || HWMON=n" instead. This is slightly
      different (it enforces SFP to be built as module if HWMON is built as
      module), but it is better than the alternative of using "IS_REACHABLE()"
      in the driver since that would disable sensor support if HWMON is built
      as module and SFP is built into the kernel.
      Fixes: 1323061a
       ("net: phy: sfp: Add HWMON support for module sensors")
      Cc: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  16. 18 Jul, 2018 2 commits
    • Florian Fainelli's avatar
      net: phy: Drop OF dependency for MDIO_BCM_UNIMAC · 8be7d96e
      Florian Fainelli authored
      The driver builds fine even with CONFIG_OF=n since we now have stubs that are
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Andrew Lunn's avatar
      net: phy: sfp: Add HWMON support for module sensors · 1323061a
      Andrew Lunn authored
      SFP modules can contain a number of sensors. The EEPROM also contains
      recommended alarm and critical values for each sensor, and indications
      of if these have been exceeded. Export this information via
      HWMON. Currently temperature, VCC, bias current, transmit power, and
      possibly receiver power is supported.
      The sensors in the modules can either return calibrate or uncalibrated
      values. Uncalibrated values need to be manipulated, using coefficients
      provided in the SFP EEPROM. Uncalibrated receive power values require
      floating point maths in order to calibrate them. Performing this in
      the kernel is hard. So if the SFP module indicates it uses
      uncalibrated values, RX power is not made available.
      With this hwmon device, it is possible to view the sensor values using
      lm-sensors programs:
      in0:          +3.29 V  (crit min =  +2.90 V, min =  +3.00 V)
                             (max =  +3.60 V, crit max =  +3.70 V)
      temp1:        +33.0°C  (low  =  -5.0°C, high = +80.0°C)
                             (crit low = -10.0°C, crit = +85.0°C)
      power1:      1000.00 nW (max = 794.00 uW, min =  50.00 uW)  ALARM (LCRIT)
                             (lcrit =  40.00 uW, crit = 1000.00 uW)
      curr1:        +0.00 A  (crit min =  +0.00 A, min =  +0.00 A)  ALARM (LCRIT, MIN)
                             (max =  +0.01 A, crit max =  +0.01 A)
      The scaling sensors performs on the bias current is not particularly
      good. The raw values are more useful:
        curr1_input: 0.000
        curr1_min: 0.002
        curr1_max: 0.010
        curr1_lcrit: 0.000
        curr1_crit: 0.011
        curr1_min_alarm: 1.000
        curr1_max_alarm: 0.000
        curr1_lcrit_alarm: 1.000
        curr1_crit_alarm: 0.000
      In order to keep the I2C overhead to a minimum, the constant values,
      such as limits and calibration coefficients are read once at module
      insertion time. Thus only reading *_input and *_alarm properties
      requires i2c read operations.
      Signed-off-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  17. 23 Jun, 2018 1 commit
  18. 17 May, 2018 1 commit
  19. 15 May, 2018 1 commit
  20. 11 May, 2018 1 commit
  21. 10 May, 2018 1 commit
  22. 28 Apr, 2018 1 commit
    • Florian Fainelli's avatar
      net: phy: Fix modular PHYLIB build · 9e8d438e
      Florian Fainelli authored
      After commit c59530d0 ("net: Move PHY statistics code into PHY
      library helpers") we made net/core/ethtool.c reference symbols which are
      part of the library which can be modular. David introduced a temporary
      fix with 1ecd6e8a ("phy: Temporary build fix after phylib changes.")
      which would prevent such modularity.
      This is not desireable of course, so instead, just inline the functions
      into include/linux/phy.h to keep both options available.
      Fixes: c59530d0 ("net: Move PHY statistics code into PHY library helpers")
      Fixes: 1ecd6e8a
       ("phy: Temporary build fix after phylib changes.")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  23. 27 Apr, 2018 1 commit
  24. 19 Apr, 2018 1 commit
  25. 08 Nov, 2017 1 commit
  26. 11 Oct, 2017 1 commit
  27. 10 Oct, 2017 1 commit
  28. 19 Sep, 2017 1 commit
  29. 01 Sep, 2017 1 commit
  30. 14 Aug, 2017 1 commit
  31. 11 Aug, 2017 1 commit
  32. 07 Aug, 2017 3 commits
    • Russell King's avatar
      sfp: add SFP module support · 73970055
      Russell King authored
      Add support for SFP hotpluggable modules via sfp-bus and phylink.
      This supports both copper and optical SFP modules, which require
      different Serdes modes in order to properly negotiate the link.
      Optical SFP modules typically require the Serdes link to be talking
      1000BaseX mode - this is the gigabit ethernet mode defined by the
      802.3 standard.
      Copper SFP modules typically integrate a PHY in the module to convert
      from Serdes to copper, and the PHY will be configured by the vendor
      to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a
      SGMII Serdes link.  However, this is vendor defined, so we instead
      detect the PHY, switch the link to SGMII mode, and use traditional
      PHY based negotiation.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Russell King's avatar
      phylink: add phylink infrastructure · 9525ae83
      Russell King authored
      The link between the ethernet MAC and its PHY has become more complex
      as the interface evolves.  This is especially true with serdes links,
      where the part of the PHY is effectively integrated into the MAC.
      Serdes links can be connected to a variety of devices, including SFF
      modules soldered down onto the board with the MAC, a SFP cage with
      a hotpluggable SFP module which may contain a PHY or directly modulate
      the serdes signals onto optical media with or without a PHY, or even
      a classical PHY connection.
      Moreover, the negotiation information on serdes links comes in two
      varieties - SGMII mode, where the PHY provides its speed/duplex/flow
      control information to the MAC, and 1000base-X mode where both ends
      exchange their abilities and each resolve the link capabilities.
      This means we need a more flexible means to support these arrangements,
      particularly with the hotpluggable nature of SFP, where the PHY can
      be attached or detached after the network device has been brought up.
      Ethtool information can come from multiple sources:
      - we may have a PHY operating in either SGMII or 1000base-X mode, in
        which case we take ethtool/mii data directly from the PHY.
      - we may have a optical SFP module without a PHY, with the MAC
        operating in 1000base-X mode - the ethtool/mii data needs to come
        from the MAC.
      - we may have a copper SFP module with a PHY whic can't be accessed,
        which means we need to take ethtool/mii data from the MAC.
      Phylink aims to solve this by providing an intermediary between the
      MAC and PHY, providing a safe way for PHYs to be hotplugged, and
      allowing a SFP driver to reconfigure the serdes connection.
      Phylink also takes over support of fixed link connections, where the
      speed/duplex/flow control are fixed, but link status may be controlled
      by a GPIO signal.  By avoiding the fixed-phy implementation, phylink
      can provide a faster response to link events: fixed-phy has to wait for
      phylib to operate its state machine, which can take several seconds.
      In comparison, phylink takes milliseconds.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      - remove sync status
      - rework supported and advertisment handling
      - add 1000base-x speed for fixed links
      - use functionality exported from phy-core, reworking
        __phylink_ethtool_ksettings_set for it
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Russell King's avatar
      net: phy: add I2C mdio bus · 453d00de
      Russell King authored
      Add an I2C MDIO bus bridge library, to allow phylib to access PHYs which
      are connected to an I2C bus instead of the more conventional MDIO bus.
      Such PHYs can be found in SFP adapters and SFF modules.
      Since PHYs appear at I2C bus address 0x40..0x5f, and 0x50/0x51 are
      reserved for SFP EEPROMs/diagnostics, we must not allow the MDIO bus
      to access these I2C addresses.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  33. 28 Jul, 2017 1 commit
    • Arnd Bergmann's avatar
      net: phy: rework Kconfig settings for MDIO_BUS · 4c3464a8
      Arnd Bergmann authored
      I still see build errors in randconfig builds and have had this
      patch for a while to locally work around it:
      drivers/built-in.o: In function `xgene_mdio_probe':
      mux-core.c:(.text+0x352154): undefined reference to `of_mdiobus_register'
      mux-core.c:(.text+0x352168): undefined reference to `mdiobus_free'
      mux-core.c:(.text+0x3521c0): undefined reference to `mdiobus_alloc_size'
      The idea is that CONFIG_MDIO_BUS now reflects whether the mdio_bus
      code is built-in or a module, and other drivers that use the core
      code can simply depend on that, instead of having a complex
      dependency line.
      Fixes: 90eff909
       ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  34. 13 Jun, 2017 1 commit
  35. 07 Jun, 2017 1 commit
  36. 30 May, 2017 1 commit