1. 26 10月, 2017 1 次提交
  2. 01 8月, 2017 4 次提交
  3. 24 6月, 2017 1 次提交
  4. 23 3月, 2017 1 次提交
    • D
      net: bcmgenet: remove bcmgenet_internal_phy_setup() · 31739eae
      Doug Berger 提交于
      Commit 6ac3ce82 ("net: bcmgenet: Remove excessive PHY reset")
      removed the bcmgenet_mii_reset() function from bcmgenet_power_up() and
      bcmgenet_internal_phy_setup() functions.  In so doing it broke the reset
      of the internal PHY devices used by the GENETv1-GENETv3 which required
      this reset before the UniMAC was enabled.  It also broke the internal
      GPHY devices used by the GENETv4 because the config_init that installed
      the AFE workaround was no longer occurring after the reset of the GPHY
      performed by bcmgenet_phy_power_set() in bcmgenet_internal_phy_setup().
      In addition the code in bcmgenet_internal_phy_setup() related to the
      "enable APD" comment goes with the bcmgenet_mii_reset() so it should
      have also been removed.
      
      Commit bd4060a6 ("net: bcmgenet: Power on integrated GPHY in
      bcmgenet_power_up()") moved the bcmgenet_phy_power_set() call to the
      bcmgenet_power_up() function, but failed to remove it from the
      bcmgenet_internal_phy_setup() function.  Had it done so, the
      bcmgenet_internal_phy_setup() function would have been empty and could
      have been removed at that time.
      
      Commit 5dbebbb4 ("net: bcmgenet: Software reset EPHY after power on")
      was submitted to correct the functional problems introduced by
      commit 6ac3ce82 ("net: bcmgenet: Remove excessive PHY reset"). It
      was included in v4.4 and made available on 4.3-stable. Unfortunately,
      it didn't fully revert the commit because this bcmgenet_mii_reset()
      doesn't apply the soft reset to the internal GPHY used by GENETv4 like
      the previous one did. This prevents the restoration of the AFE work-
      arounds for internal GPHY devices after the bcmgenet_phy_power_set() in
      bcmgenet_internal_phy_setup().
      
      This commit takes the alternate approach of removing the unnecessary
      bcmgenet_internal_phy_setup() function which shouldn't have been in v4.3
      so that when bcmgenet_mii_reset() was restored it should have only gone
      into bcmgenet_power_up().  This will avoid the problems while also
      removing the redundancy (and hopefully some of the confusion).
      
      Fixes: 6ac3ce82 ("net: bcmgenet: Remove excessive PHY reset")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31739eae
  5. 14 3月, 2017 1 次提交
  6. 30 11月, 2016 1 次提交
  7. 28 11月, 2016 1 次提交
  8. 27 9月, 2016 2 次提交
    • F
      Revert "net: ethernet: bcmgenet: use phydev from struct net_device" · 0299b6ac
      Florian Fainelli 提交于
      This reverts commit 62469c76 ("net: ethernet: bcmgenet: use phydev
      from struct net_device") because it causes GENETv1/2/3 adapters to
      expose the following behavior after an ifconfig down/up sequence:
      
      PING fainelli-linux (10.112.156.244): 56 data bytes
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.352 ms
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.472 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.496 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.517 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.536 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.557 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=752.448 ms (DUP!)
      
      This was previously fixed by commit 5dbebbb4 ("net: bcmgenet:
      Software reset EPHY after power on") but the commit we are reverting was
      essentially making this previous commit void, here is why.
      
      Without commit 62469c76 we would have the following scenario after
      an ifconfig down then up sequence:
      
      - bcmgenet_open() calls bcmgenet_power_up() to make sure the PHY is
        initialized *before* we get to initialize the UniMAC, this is
        critical to ensure the PHY is in a correct state, priv->phydev is
        valid, this code executes fine
      
      - second time from bcmgenet_mii_probe(), through the normal
        phy_init_hw() call (which arguably could be optimized out)
      
      Everything is fine in that case. With commit 62469c76, we would have
      the following scenario to happen after an ifconfig down then up
      sequence:
      
      - bcmgenet_close() calls phy_disonnect() which makes dev->phydev become
        NULL
      
      - when bcmgenet_open() executes again and calls bcmgenet_mii_reset() from
        bcmgenet_power_up() to initialize the internal PHY, the NULL check
        becomes true, so we do not reset the PHY, yet we keep going on and
        initialize the UniMAC, causing MAC activity to occur
      
      - we call bcmgenet_mii_reset() from bcmgenet_mii_probe(), but this is
        too late, the PHY is botched, and causes the above bogus pings/packets
        transmission/reception to occur
      Reported-by: NJaedon Shin <jaedon.shin@gmail.com>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NPhilippe Reynes <tremyfr@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0299b6ac
    • F
      Revert "net: ethernet: bcmgenet: use phydev from struct net_device" · bf1a85a8
      Florian Fainelli 提交于
      This reverts commit 62469c76 ("net: ethernet: bcmgenet: use phydev
      from struct net_device") because it causes GENETv1/2/3 adapters to
      expose the following behavior after an ifconfig down/up sequence:
      
      PING fainelli-linux (10.112.156.244): 56 data bytes
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.352 ms
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.472 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.496 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.517 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.536 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=1.557 ms (DUP!)
      64 bytes from 10.112.156.244: seq=1 ttl=61 time=752.448 ms (DUP!)
      
      This was previously fixed by commit 5dbebbb4 ("net: bcmgenet:
      Software reset EPHY after power on") but the commit we are reverting was
      essentially making this previous commit void, here is why.
      
      Without commit 62469c76 we would have the following scenario after
      an ifconfig down then up sequence:
      
      - bcmgenet_open() calls bcmgenet_power_up() to make sure the PHY is
        initialized *before* we get to initialize the UniMAC, this is
        critical to ensure the PHY is in a correct state, priv->phydev is
        valid, this code executes fine
      
      - second time from bcmgenet_mii_probe(), through the normal
        phy_init_hw() call (which arguably could be optimized out)
      
      Everything is fine in that case. With commit 62469c76, we would have
      the following scenario to happen after an ifconfig down then up
      sequence:
      
      - bcmgenet_close() calls phy_disonnect() which makes dev->phydev become
        NULL
      
      - when bcmgenet_open() executes again and calls bcmgenet_mii_reset() from
        bcmgenet_power_up() to initialize the internal PHY, the NULL check
        becomes true, so we do not reset the PHY, yet we keep going on and
        initialize the UniMAC, causing MAC activity to occur
      
      - we call bcmgenet_mii_reset() from bcmgenet_mii_probe(), but this is
        too late, the PHY is botched, and causes the above bogus pings/packets
        transmission/reception to occur
      Reported-by: NJaedon Shin <jaedon.shin@gmail.com>
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf1a85a8
  9. 05 7月, 2016 1 次提交
  10. 22 1月, 2016 1 次提交
  11. 08 1月, 2016 3 次提交
  12. 02 11月, 2015 1 次提交
  13. 01 9月, 2015 1 次提交
  14. 27 7月, 2015 1 次提交
    • F
      net: bcmgenet: Register link_update callback for all MoCA PHYs · 6ac9de5f
      Florian Fainelli 提交于
      Commit 8d88c6eb ("net: bcmgenet: enable MoCA link state change
      detection") added a fixed PHY link_update callback for MoCA PHYs when
      registered using platform_data exclusively, this change is also
      applicable to systems using Device Tree as their primary configuration
      interface.
      
      In order for this to work, move the link_update assignment into
      bcmgenet_moca_phy_setup() where we know for sure that we are running on
      a MoCA GENET instance, and do not override phydev->link since this is:
      
      - properly taken care of by the PHY library by getting the link UP/DOWN
        interrupts
      - this now runs everytime we call bcmgenet_open(), so we need to
        preserve whatever we detected before we went administratively DOWN and
        then UP
      - we need to make sure that MoCA PHYs start with a link DOWN during
        probe in order to force a link transition to occur
      
      To avoid a forward declaration, move bcmgenet_fixed_phy_link_update()
      above its caller.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ac9de5f
  15. 21 7月, 2015 4 次提交
    • F
      net: bcmgenet: Remove init parameter from bcmgenet_mii_config · 28b45910
      Florian Fainelli 提交于
      Now that we have reworked the way we perform the PHY initialization, we
      no longer need to differentiate between init time vs. non-init time
      calls, just use a dev_info_once() print to print the PHY type.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      28b45910
    • F
      net: bcmgenet: Delay PHY initialization to bcmgenet_open() · 6cc8e6d4
      Florian Fainelli 提交于
      We are currently doing a full PHY initialization and even starting the
      pHY state machine during bcmgenet_mii_init() which is executed in the
      driver's probe function. This is convenient to determine whether we can
      attach to a proper PHY device but comes at the expense of spending up to
      10ms per MDIO transactions (to reach the waitqueue timeout), which slows
      things down.
      
      This also creates a sitaution where we end-up attaching twice to the
      PHY, which is not quite correct either.
      
      Fix this by moving bcmgenet_mii_probe() into bcmgenet_open() and update
      its error path accordingly.
      
      Avoid printing the message "attached PHY at address 1 [...]" every time
      we bring up/down the interface and remove this print since it duplicates
      what the PHY driver already does for us.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cc8e6d4
    • F
      net: bcmgenet: Determine PHY type before scanning MDIO bus · c624f891
      Florian Fainelli 提交于
      Our internal GPHY might be powered off before we attempt scanning the
      MDIO bus and bind a driver to it. The way we are currently determining
      whether a PHY is internal or not is done *after* we have successfully
      matched its driver. If the PHY is powered down, it will not respond to
      the MDIO bus, so we will not be able to bind a driver to it.
      
      Our Device Tree for GENET interfaces specifies a "phy-mode" value:
      "internal" which tells if this internal uses an internal PHY or not.
      
      If of_get_phy_mode() fails to parse the 'phy-mode' property, do an
      additional manual lookup, and if we find "internal" set the
      corresponding internal variable accordingly.
      
      Replace all uses of phy_is_internal() with a check against
      priv->internal_phy to avoid having to rely on whether or not
      priv->phydev is set correctly.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c624f891
    • F
      net: bcmgenet: Remove excessive PHY reset · 6ac3ce82
      Florian Fainelli 提交于
      We are currently issuing multiple PHY resets during a suspend/resume,
      first during bcmgenet_power_up() which does a hardware reset, then a
      software reset by calling bcmgenet_mii_reset(). This is both unnecessary
      and can take as long as 10ms per MDIO transactions while we re-apply
      workarounds because we do not yet have MDIO interrupts enabled.
      
      phy_resume() takes care of re-apply our workarounds in case we need any,
      and bcmgenet_power_up() does a PHY hardware reset, all of this is more
      than enough to guarantee that the PHY operates correctly.
      
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ac3ce82
  16. 29 6月, 2015 1 次提交
    • F
      net: bcmgenet: workaround initial read failures for integrated PHYs · 7b635da8
      Florian Fainelli 提交于
      All BCM7xxx integrated Gigabit PHYs have an issue in their MDIO
      management controller which will make the initial read or write to them
      to fail and return 0xffff. This is a real issue as the typical first
      thing we do is read from MII_PHYSID1 and MII_PHYSID2 from get_phy_id()
      to register a driver for these PHYs.
      
      Coupled with the workaround in drivers/net/phy/bcm7xxx.c, this
      workaround for the MDIO bus controller consists in scanning the list of
      PHYs to do this initial read workaround for as part of the MDIO bus
      reset routine which is invoked prior to mdiobus_scan().
      
      Once we have a proper PHY driver/device registered, all workarounds are
      located there (e.g: power management suspend/resume calls).
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b635da8
  17. 11 6月, 2015 1 次提交
  18. 09 6月, 2015 1 次提交
  19. 02 4月, 2015 1 次提交
    • P
      net: bcmgenet: enable MoCA link state change detection · 8d88c6eb
      Petri Gynther 提交于
      Currently, MoCA fixed PHYs are always in link-up state, regardless of
      whether the link is actually up or not.
      
      Add code to properly detect MoCA link state changes and to reflect the
      new state in MoCA fixed PHY. Only GENET V3 and V4 MACs are capable of
      detecting MoCA link state changes.
      
      The code works as follows:
      1. GENET MAC detects MoCA link state change and issues UMAC_IRQ_LINK_UP
         or UMAC_IRQ_LINK_DOWN interrupt.
      2. Link up/down interrupt is processed in bcmgenet_irq_task(), which
         calls phy_mac_interrupt().
      3. phy_mac_interrupt() updates the fixed PHY phydev->link and kicks
         the PHY state machine.
      4. PHY state machine proceeds to read the fixed PHY link status
         register.
      5. When the fixed PHY link status register is being read, the new
         function bcmgenet_fixed_phy_link_update() gets called. It copies
         the fixed PHY phydev->link value to the fixed PHY status->link.
      6. PHY state machine receives the new link state of the fixed PHY.
      7. MoCA fixed PHY link state now correctly reflects the real MoCA
         hardware link state.
      Signed-off-by: NPetri Gynther <pgynther@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d88c6eb
  20. 24 3月, 2015 5 次提交
  21. 09 12月, 2014 1 次提交
  22. 12 11月, 2014 2 次提交
    • F
      net: bcmgenet: apply MII configuration in bcmgenet_open() · dbd479db
      Florian Fainelli 提交于
      In case an interface has been brought down before entering S3, and then
      brought up out of S3, all the initialization done during
      bcmgenet_probe() by bcmgenet_mii_init() calling bcmgenet_mii_config() is
      just lost since register contents are restored to their reset values.
      
      Re-apply this configuration anytime we call bcmgenet_open() to make sure
      our port multiplexer is properly configured to match the PHY interface.
      
      Since we are now calling bcmgenet_mii_config() everytime bcmgenet_open()
      is called, make sure we only print the message during initialization
      time not to pollute the console.
      
      Fixes: b6e978e5 ("net: bcmgenet: add suspend/resume callbacks")
      Fixes: 1c1008c7 ("net: bcmgenet: add main driver file")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dbd479db
    • F
      net: bcmgenet: connect and disconnect from the PHY state machine · c96e731c
      Florian Fainelli 提交于
      phy_disconnect() is the only way to guarantee that we are not going to
      schedule more work on the PHY state machine workqueue for that
      particular PHY device.
      
      This fixes an issue where a network interface was suspended prior to a
      system suspend/resume cycle and would then be resumed as part of
      mdio_bus_resume(), since the GENET interface clocks would have been
      disabled, this basically resulted in bus errors to appear since we are
      invoking the GENET driver adjust_link() callback.
      
      Fixes: b6e978e5 ("net: bcmgenet: add suspend/resume callbacks")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c96e731c
  23. 06 10月, 2014 1 次提交
  24. 20 9月, 2014 2 次提交
  25. 12 8月, 2014 1 次提交
    • F
      net: bcmgenet: update UMAC_CMD only when link is detected · c677ba8b
      Florian Fainelli 提交于
      When we bring the interface down, phy_stop() will schedule the PHY state
      machine to call our link adjustment callback. By the time we do so, we
      may have clock gated off the GENET hardware block, and this will cause
      bus errors to happen in bcmgenet_mii_setup():
      
      Make sure that we only touch the UMAC_CMD register when there is an
      actual link. This is safe to do for two reasons:
      
      - updating the Ethernet MAC registers only make sense when a physical
        link is present
      - the PHY library state machine first set phydev->link = 0 before
        invoking phydev->adjust_link in the PHY_HALTED case
      
      Fixes: 24052408 ("net: bcmgenet: only update UMAC_CMD if something changed")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c677ba8b