1. 23 1月, 2017 1 次提交
  2. 21 1月, 2017 1 次提交
  3. 17 1月, 2017 1 次提交
  4. 13 1月, 2017 3 次提交
  5. 11 1月, 2017 1 次提交
    • R
      net: phy: marvell: fix Marvell 88E1512 used in SGMII mode · a13c0652
      Russell King 提交于
      When an Marvell 88E1512 PHY is connected to a nic in SGMII mode, the
      fiber page is used for the SGMII host-side connection.  The PHY driver
      notices that SUPPORTED_FIBRE is set, so it tries reading the fiber page
      for the link status, and ends up reading the MAC-side status instead of
      the outgoing (copper) link.  This leads to incorrect results reported
      via ethtool.
      
      If the PHY is connected via SGMII to the host, ignore the fiber page.
      However, continue to allow the existing power management code to
      suspend and resume the fiber page.
      
      Fixes: 6cfb3bcc ("Marvell phy: check link status in case of fiber link.")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a13c0652
  6. 10 1月, 2017 2 次提交
    • J
      net: phy: Add Meson GXL PHY hardware dependency · 2ebae8bd
      Jean Delvare 提交于
      As I understand it the Meson GXL PHY driver is only useful on one
      architecture so only make it visible on that architecture.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Fixes: 7334b3e4 ("net: phy: Add Meson GXL Internal PHY driver")
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ebae8bd
    • Z
      phy state machine: failsafe leave invalid RUNNING state · 811a9191
      Zefir Kurtisi 提交于
      While in RUNNING state, phy_state_machine() checks for link changes by
      comparing phydev->link before and after calling phy_read_status().
      This works as long as it is guaranteed that phydev->link is never
      changed outside the phy_state_machine().
      
      If in some setups this happens, it causes the state machine to miss
      a link loss and remain RUNNING despite phydev->link being 0.
      
      This has been observed running a dsa setup with a process continuously
      polling the link states over ethtool each second (SNMPD RFC-1213
      agent). Disconnecting the link on a phy followed by a ETHTOOL_GSET
      causes dsa_slave_get_settings() / dsa_slave_get_link_ksettings() to
      call phy_read_status() and with that modify the link status - and
      with that bricking the phy state machine.
      
      This patch adds a fail-safe check while in RUNNING, which causes to
      move to CHANGELINK when the link is gone and we are still RUNNING.
      Signed-off-by: NZefir Kurtisi <zefir.kurtisi@neratec.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      811a9191
  7. 09 1月, 2017 1 次提交
  8. 07 1月, 2017 1 次提交
    • G
      net: phy: dp83867: fix irq generation · 5ca7d1ca
      Grygorii Strashko 提交于
      For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
      programmed as an interrupt output instead of a Powerdown input in
      Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
      current driver doesn't do this and as result IRQs will not be generated by
      DP83867 phy even if they are properly configured in DT.
      
      Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
      ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
      Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
      driver will work properly in interrupt enabled mode.
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ca7d1ca
  9. 25 12月, 2016 1 次提交
  10. 21 12月, 2016 2 次提交
  11. 11 12月, 2016 1 次提交
    • T
      net: phy: phy drivers should not set SUPPORTED_[Asym_]Pause · 529ed127
      Timur Tabi 提交于
      Instead of having individual PHY drivers set the SUPPORTED_Pause and
      SUPPORTED_Asym_Pause flags, phylib itself should set those flags,
      unless there is a hardware erratum or other special case.  During
      autonegotiation, the PHYs will determine whether to enable pause
      frame support.
      
      Pause frames are a feature that is supported by the MAC.  It is the MAC
      that generates the frames and that processes them.  The PHY can only be
      configured to allow them to pass through.
      
      This commit also effectively reverts the recently applied c7a61319
      ("net: phy: dp83848: Support ethernet pause frames").
      
      So the new process is:
      
      1) Unless the PHY driver overrides it, phylib sets the SUPPORTED_Pause
      and SUPPORTED_AsymPause bits in phydev->supported.  This indicates that
      the PHY supports pause frames.
      
      2) The MAC driver checks phydev->supported before it calls phy_start().
      If (SUPPORTED_Pause | SUPPORTED_AsymPause) is set, then the MAC driver
      sets those bits in phydev->advertising, if it wants to enable pause
      frame support.
      
      3) When the link state changes, the MAC driver checks phydev->pause and
      phydev->asym_pause,  If the bits are set, then it enables the corresponding
      features in the MAC.  The algorithm is:
      
      	if (phydev->pause)
      		The MAC should be programmed to receive and honor
                      pause frames it receives, i.e. enable receive flow control.
      
      	if (phydev->pause != phydev->asym_pause)
      		The MAC should be programmed to transmit pause
      		frames when needed, i.e. enable transmit flow control.
      Signed-off-by: NTimur Tabi <timur@codeaurora.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      529ed127
  12. 09 12月, 2016 1 次提交
    • W
      phy: add phy fixup unregister functions · f38e7a32
      Woojung.Huh@microchip.com 提交于
      >From : Woojung Huh <woojung.huh@microchip.com>
      
      Add functions to unregister phy fixup for modules.
      
      int phy_unregister_fixup(const char *bus_id, u32 phy_uid, u32 phy_uid_mask)
      	Unregister phy fixup from phy_fixup_list per bus_id, phy_uid &
      	phy_uid_mask
      
      int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask)
      	Unregister phy fixup from phy_fixup_list.
      	Use it for fixup registered by phy_register_fixup_for_uid()
      
      int phy_unregister_fixup_for_id(const char *bus_id)
      	Unregister phy fixup from phy_fixup_list.
      	Use it for fixup registered by phy_register_fixup_for_id()
      Signed-off-by: NWoojung Huh <woojung.huh@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f38e7a32
  13. 08 12月, 2016 1 次提交
  14. 06 12月, 2016 1 次提交
  15. 02 12月, 2016 4 次提交
  16. 30 11月, 2016 4 次提交
  17. 29 11月, 2016 1 次提交
    • M
      net: phy: realtek: fix enabling of the TX-delay for RTL8211F · e3230494
      Martin Blumenstingl 提交于
      The old logic always enabled the TX-delay when the phy-mode was set to
      PHY_INTERFACE_MODE_RGMII. There are dedicated phy-modes which tell the
      PHY driver to enable the RX and/or TX delays:
      - PHY_INTERFACE_MODE_RGMII should disable the RX and TX delay in the
        PHY (if required, the MAC should add the delays in this case)
      - PHY_INTERFACE_MODE_RGMII_ID should enable RX and TX delay in the PHY
      - PHY_INTERFACE_MODE_RGMII_TXID should enable the TX delay in the PHY
      - PHY_INTERFACE_MODE_RGMII_RXID should enable the RX delay in the PHY
        (currently not supported by RTL8211F)
      
      With this patch we enable the TX delay for PHY_INTERFACE_MODE_RGMII_ID
      and PHY_INTERFACE_MODE_RGMII_TXID.
      Additionally we now explicity disable the TX-delay, which seems to be
      enabled automatically after a hard-reset of the PHY (by triggering it's
      reset pin) to get a consistent state (as defined by the phy-mode).
      
      This fixes a compatibility problem with some SoCs where the TX-delay was
      also added by the MAC. With the TX-delay being applied twice the TX
      clock was off and TX traffic was broken or very slow (<10Mbit/s) on
      1000Mbit/s links.
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3230494
  18. 26 11月, 2016 1 次提交
  19. 25 11月, 2016 6 次提交
  20. 24 11月, 2016 1 次提交
  21. 19 11月, 2016 2 次提交
  22. 18 11月, 2016 1 次提交
  23. 17 11月, 2016 1 次提交
  24. 16 11月, 2016 1 次提交