Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 1月, 2016 2 次提交
    • F
      net: phy: Fix phy_mac_interrupt() · deccd16f
      由 Florian Fainelli 提交于 
      Commit 5ea94e76 ("phy: add phy_mac_interrupt()") to use with
PHY_IGNORE_INTERRUPT added a cancel_work_sync() into phy_mac_interrupt()
which is allowed to sleep, whereas phy_mac_interrupt() is expected to be
callable from interrupt context.

Now that we have fixed how the PHY state machine treats
PHY_IGNORE_INTERRUPT with respect to state changes, we can just set the
new link state, and queue the PHY state machine for execution so it is
going to read the new link state.

For that to work properly, we need to update phy_change() not to try to
invoke any interrupt callbacks if we have configured the PHY device for
PHY_IGNORE_INTERRUPT, because that PHY device and its driver are not
required to implement those.

Fixes: 5ea94e76 ("phy: add phy_mac_interrupt() to use with PHY_IGNORE_INTERRUPT")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      deccd16f
    • F
      net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS · d5c3d846
      由 Florian Fainelli 提交于 
      Commit 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed
a hunk in phy_state_machine() in the PHY_RUNNING case which was not
needed. The change essentially makes the PHY library treat PHY devices
with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even
though the intent is not to do it.

Fix this by reverting that specific hunk, which makes the PHY state
machine wait for state changes, and stay in the PHY_RUNNING state for as
long as needed.

Fixes: 2c7b4921 ("phy: fix the use of PHY_IGNORE_INTERRUPT")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5c3d846
  3. 08 1月, 2016 3 次提交
  5. 04 12月, 2015 1 次提交
  7. 18 11月, 2015 1 次提交
  9. 29 8月, 2015 1 次提交
  11. 26 8月, 2015 1 次提交
  13. 18 8月, 2015 1 次提交
  15. 11 7月, 2015 2 次提交
  17. 27 5月, 2015 1 次提交
  19. 21 5月, 2015 1 次提交
    • T
      net: phy: Make sure phy_start() always re-enables the phy interrupts · c15e10e7
      由 Tim Beale 提交于 
      This is an alternative way of fixing:
 commit db9683fb ("net: phy: Make sure PHY_RESUMING state change
                      is always processed")

When the PHY state transitions from PHY_HALTED to PHY_RESUMING, there are
two things we need to do:
1). Re-enable interrupts (and power up the physical link, if powered down)
2). Update the PHY state and net-device based on the link status.

There's no strict reason why #1 has to be done from within the main
phy_state_machine() function. There is a risk that other changes to the
PHY (e.g. setting speed/duplex, which calls phy_start_aneg()) could cause
a subsequent state transition before phy_state_machine() has processed
the PHY_RESUMING state change. This would leave the PHY with interrupts
disabled and/or still in the BMCR_PDOWN/low-power mode.

Moving enabling the interrupts and phy_resume() into phy_start() will
guarantee this work always gets done. As the PHY is already in the HALTED
state and interrupts are disabled, it shouldn't conflict with any work
being done in phy_state_machine(). The downside of this change is that if
the PHY_RESUMING state is ever entered from anywhere else, it'll also have
to repeat this work.
Signed-off-by: NTim Beale <tim.beale@alliedtelesis.co.nz>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15e10e7
  21. 17 5月, 2015 2 次提交
    • T
      net: phy: Make sure PHY_RESUMING state change is always processed · db9683fb
      由 Tim Beale 提交于 
      If phy_start_aneg() was called while the phydev is in the PHY_RESUMING
state, then its state would immediately transition to PHY_AN (or
PHY_FORCING). This meant the phy_state_machine() never processed the
PHY_RESUMING state change, which meant interrupts weren't enabled for the
PHY. If the PHY used low-power mode (i.e. using BMCR_PDOWN), then the
physical link wouldn't get powered up again.

There seems no point for phy_start_aneg() to make the PHY_RESUMING -->
PHY_AN transition, as the state machine will do this anyway. I'm not sure
about the case where autoneg is disabled, as my patch will change
behaviour so that the PHY goes to PHY_NOLINK instead of PHY_FORCING. An
alternative solution would be to move the phy_config_interrupt() and
phy_resume() work out of the state machine and into phy_start().

The background behind this: we're running linux v3.16.7 and from user-space
we want to enable the eth port (i.e. do a SIOCSIFFLAGS ioctl with the
IFF_UP flag) and immediately afterward set the interface's speed/duplex.
Enabling the interface calls .ndo_open() then phy_start() and the PHY
transitions PHY_HALTED --> PHY_RESUMING. Setting the speed/duplex ends up
calling phy_ethtool_sset(), which calls phy_start_aneg() (meanwhile the
phy_state_machine() hasn't processed the PHY_RESUMING state change yet).
Signed-off-by: NTim Beale <tim.beale@alliedtelesis.co.nz>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db9683fb
    • F
      net: phy: Add state machine state transitions debug prints · 3e2186e0
      由 Florian Fainelli 提交于 
      It can be useful to debug the PHY state machine, add dynamic debug
prints of the old and new PHY devices state under a friendly format.
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e2186e0
  23. 16 5月, 2015 1 次提交
    • F
      net: phy: Allow EEE for all RGMII variants · 7e140696
      由 Florian Fainelli 提交于 
      RGMII interfaces come in multiple flavors: RGMII with transmit or
receive internal delay, no delays at all, or delays in both direction.

This change extends the initial check for PHY_INTERFACE_MODE_RGMII to
cover all of these variants since EEE should be allowed for any of these
modes, since it is a property of the RGMII, hence Gigabit PHY capability
more than the RGMII electrical interface and its delays.

Fixes: a59a4d19 ("phy: add the EEE support and the way to access to the MMD registers")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e140696
  25. 21 2月, 2015 1 次提交
  27. 27 1月, 2015 1 次提交
  29. 12 11月, 2014 1 次提交
  31. 28 8月, 2014 1 次提交
  33. 24 8月, 2014 2 次提交
  35. 31 7月, 2014 1 次提交
    • V
      net: libphy: Add phy specific function to access mmd phy registers · 0c1d77df
      由 Vince Bridgers 提交于 
      libphy was originally written assuming all phy devices support clause 45
access extensions to the mmd registers through the indirection registers
located within the first 16 phy registers. This assumption is not true
in all cases, and one specific example is the Micrel ksz9021 10/100/1000
Mbps phy. Using the stmmac driver, accessing the mmd registers to query
and configure energy efficient Ethernet (EEE) features yielded unexpected
behavior.

This patch adds mmd access functions to the phy driver that can be
overriden by the phy specific driver if the phy does not support this
mechanism or uses it's own non-standard access mechanism. By default,
the IEEE Compatible clause 45 access mechanism described in clause 22
is used. With this patch, EEE query/configure functions as expected
using the stmmac and the Micrel ksz9021 phy.
Signed-off-by: NVince Bridgers <vbridgers2013@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c1d77df
  37. 16 7月, 2014 1 次提交
  39. 22 6月, 2014 1 次提交
  41. 17 5月, 2014 1 次提交
  43. 03 5月, 2014 1 次提交
  45. 10 4月, 2014 1 次提交
  47. 07 3月, 2014 1 次提交
  49. 14 2月, 2014 1 次提交
  51. 13 2月, 2014 6 次提交
  53. 17 1月, 2014 1 次提交
  55. 05 1月, 2014 2 次提交