1. 13 6月, 2019 1 次提交
  2. 05 6月, 2019 1 次提交
    • R
      net: dsa: mv88e6xxx: add support for mv88e6250 · 1f71836f
      Rasmus Villemoes 提交于
      This adds support for the Marvell 88E6250. I've checked that each
      member in the ops-structure makes sense, and basic switchdev
      functionality works fine.
      
      It uses the new dual_chip option, and since its port registers start
      at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
      introduce a new compatible string in order for the auto-identification
      in mv88e6xxx_detect() to work.
      
      The chip has four per port 16-bits statistics registers, two of which
      correspond to the existing "sw_in_filtered" and "sw_out_filtered" (but
      at offsets 0x13 and 0x10 rather than 0x12 and 0x13, because why should
      this be easy...). Wiring up those four statistics seems to require
      introducing a STATS_TYPE_PORT_6250 bit or similar, which seems a tad
      ugly, so for now this just allows access to the STATS_TYPE_BANK0 ones.
      
      The chip does have ptp support, and the existing
      mv88e6352_{gpio,avb,ptp}_ops at first glance seem like they would work
      out-of-the-box, but for simplicity (and lack of testing) I'm eliding
      this.
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f71836f
  3. 03 6月, 2019 1 次提交
  4. 31 5月, 2019 2 次提交
  5. 06 5月, 2019 1 次提交
  6. 04 5月, 2019 3 次提交
  7. 28 4月, 2019 1 次提交
  8. 20 4月, 2019 1 次提交
  9. 28 3月, 2019 1 次提交
  10. 09 3月, 2019 1 次提交
  11. 05 3月, 2019 2 次提交
  12. 04 3月, 2019 1 次提交
  13. 02 3月, 2019 2 次提交
    • A
      net: dsa: mv88e6xxx: Fix statistics on mv88e6161 · a6da21bb
      Andrew Lunn 提交于
      Despite what the datesheet says, the silicon implements the older way
      of snapshoting the statistics. Change the op.
      
      Reported-by: Chris.Healy@zii.aero
      Tested-by: Chris.Healy@zii.aero
      Fixes: 0ac64c39 ("net: dsa: mv88e6xxx: mv88e6161 uses mv88e6320 stats snapshot")
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6da21bb
    • H
      net: dsa: mv88e6xxx: prevent interrupt storm caused by mv88e6390x_port_set_cmode · ed8fe202
      Heiner Kallweit 提交于
      When debugging another issue I faced an interrupt storm in this
      driver (88E6390, port 9 in SGMII mode), consisting of alternating
      link-up / link-down interrupts. Analysis showed that the driver
      wanted to set a cmode that was set already. But so far
      mv88e6390x_port_set_cmode() doesn't check this and powers down
      SERDES, what causes the link to break, and eventually results in
      the described interrupt storm.
      
      Fix this by checking whether the cmode actually changes. We want
      that the very first call to mv88e6390x_port_set_cmode() always
      configures the registers, therefore initialize port.cmode with
      a value that is different from any supported cmode value.
      We have to take care that we only init the ports cmode once
      chip->info->num_ports is set.
      
      v2:
      - add small helper and init the number of actual ports only
      
      Fixes: 364e9d77 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change")
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed8fe202
  14. 01 3月, 2019 1 次提交
  15. 26 2月, 2019 1 次提交
  16. 25 2月, 2019 3 次提交
    • A
      dsa: Remove phydev parameter from disable_port call · 75104db0
      Andrew Lunn 提交于
      No current DSA driver makes use of the phydev parameter passed to the
      disable_port call. Remove it.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75104db0
    • A
      net: dsa: mv88e6xxx: Release lock while requesting IRQ · 342a0ee7
      Andrew Lunn 提交于
      There is no need to hold the register lock while requesting the GPIO
      interrupt. By not holding it we can also avoid a false positive
      lockdep splat.
      Reported-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      342a0ee7
    • A
      net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat · f6d9758b
      Andrew Lunn 提交于
      The following false positive lockdep splat has been observed.
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.20.0+ #302 Not tainted
      ------------------------------------------------------
      systemd-udevd/160 is trying to acquire lock:
      edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704
      
      but task is already holding lock:
      edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&desc->request_mutex){+.+.}:
             mutex_lock_nested+0x1c/0x24
             __setup_irq+0xa0/0x704
             request_threaded_irq+0xd0/0x150
             mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx]
             mdio_probe+0x2c/0x54
             really_probe+0x200/0x2c4
             driver_probe_device+0x5c/0x174
             __driver_attach+0xd8/0xdc
             bus_for_each_dev+0x58/0x7c
             bus_add_driver+0xe4/0x1f0
             driver_register+0x7c/0x110
             mdio_driver_register+0x24/0x58
             do_one_initcall+0x74/0x2e8
             do_init_module+0x60/0x1d0
             load_module+0x1968/0x1ff4
             sys_finit_module+0x8c/0x98
             ret_fast_syscall+0x0/0x28
             0xbedf2ae8
      
      -> #0 (&chip->reg_lock){+.+.}:
             __mutex_lock+0x50/0x8b8
             mutex_lock_nested+0x1c/0x24
             __setup_irq+0x640/0x704
             request_threaded_irq+0xd0/0x150
             mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx]
             mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx]
             mdio_probe+0x2c/0x54
             really_probe+0x200/0x2c4
             driver_probe_device+0x5c/0x174
             __driver_attach+0xd8/0xdc
             bus_for_each_dev+0x58/0x7c
             bus_add_driver+0xe4/0x1f0
             driver_register+0x7c/0x110
             mdio_driver_register+0x24/0x58
             do_one_initcall+0x74/0x2e8
             do_init_module+0x60/0x1d0
             load_module+0x1968/0x1ff4
             sys_finit_module+0x8c/0x98
             ret_fast_syscall+0x0/0x28
             0xbedf2ae8
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&desc->request_mutex);
                                     lock(&chip->reg_lock);
                                     lock(&desc->request_mutex);
        lock(&chip->reg_lock);
      
      &desc->request_mutex refer to two different mutex. #1 is the GPIO for
      the chip interrupt. #2 is the chained interrupt between global 1 and
      global 2.
      
      Add lockdep classes to the GPIO interrupt to avoid this.
      Reported-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6d9758b
  17. 24 2月, 2019 1 次提交
    • F
      net: dsa: mv88e6xxx: Fix -Wformat-security warnings · 3f8b8696
      Florian Fainelli 提交于
      We are not specifying an explicit format argument but instead passing a
      string litteral which causes these two warnings to show up:
      
      drivers/net/dsa/mv88e6xxx/chip.c: In function
      'mv88e6xxx_irq_poll_setup':
      drivers/net/dsa/mv88e6xxx/chip.c:483:2: warning: format not a string
      literal and no format arguments [-Wformat-security]
        chip->kworker = kthread_create_worker(0, dev_name(chip->dev));
        ^~~~
      drivers/net/dsa/mv88e6xxx/ptp.c: In function 'mv88e6xxx_ptp_setup':
      drivers/net/dsa/mv88e6xxx/ptp.c:403:4: warning: format not a string
      literal and no format arguments [-Wformat-security]
          dev_name(chip->dev));
          ^~~~~~~~
        LD [M]  drivers/net/dsa/mv88e6xxx/mv88e6xxx.o
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f8b8696
  18. 22 2月, 2019 1 次提交
  19. 14 2月, 2019 1 次提交
    • J
      dsa: mv88e6xxx: Ensure all pending interrupts are handled prior to exit · 7c0db24c
      John David Anglin 提交于
      The GPIO interrupt controller on the espressobin board only supports edge interrupts.
      If one enables the use of hardware interrupts in the device tree for the 88E6341, it is
      possible to miss an edge.  When this happens, the INTn pin on the Marvell switch is
      stuck low and no further interrupts occur.
      
      I found after adding debug statements to mv88e6xxx_g1_irq_thread_work() that there is
      a race in handling device interrupts (e.g. PHY link interrupts).  Some interrupts are
      directly cleared by reading the Global 1 status register.  However, the device interrupt
      flag, for example, is not cleared until all the unmasked SERDES and PHY ports are serviced.
      This is done by reading the relevant SERDES and PHY status register.
      
      The code only services interrupts whose status bit is set at the time of reading its status
      register.  If an interrupt event occurs after its status is read and before all interrupts
      are serviced, then this event will not be serviced and the INTn output pin will remain low.
      
      This is not a problem with polling or level interrupts since the handler will be called
      again to process the event.  However, it's a big problem when using level interrupts.
      
      The fix presented here is to add a loop around the code servicing switch interrupts.  If
      any pending interrupts remain after the current set has been handled, we loop and process
      the new set.  If there are no pending interrupts after servicing, we are sure that INTn has
      gone high and we will get an edge when a new event occurs.
      
      Tested on espressobin board.
      
      Fixes: dc30c35b ("net: dsa: mv88e6xxx: Implement interrupt support.")
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c0db24c
  20. 10 2月, 2019 1 次提交
  21. 07 2月, 2019 1 次提交
  22. 11 1月, 2019 1 次提交
  23. 20 12月, 2018 1 次提交
  24. 18 12月, 2018 1 次提交
  25. 16 11月, 2018 1 次提交
  26. 12 11月, 2018 3 次提交
  27. 18 10月, 2018 1 次提交
  28. 13 9月, 2018 1 次提交
  29. 03 9月, 2018 1 次提交
  30. 01 9月, 2018 1 次提交
  31. 15 8月, 2018 1 次提交