1. 26 11月, 2020 4 次提交
  2. 24 11月, 2020 1 次提交
  3. 19 11月, 2020 1 次提交
  4. 17 11月, 2020 1 次提交
    • M
      net: lantiq: Wait for the GPHY firmware to be ready · 2a1828e3
      Martin Blumenstingl 提交于
      A user reports (slightly shortened from the original message):
        libphy: lantiq,xrx200-mdio: probed
        mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing.
        gswip 1e108000.switch lan: no phy at 2
        gswip 1e108000.switch lan: failed to connect to port 2: -19
        lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy
      
      This is a single-port board using the internal Fast Ethernet PHY. The
      user reports that switching to PHY scanning instead of configuring the
      PHY within device-tree works around this issue.
      
      The documentation for the standalone variant of the PHY11G (which is
      probably very similar to what is used inside the xRX200 SoCs but having
      the firmware burnt onto that standalone chip in the factory) states that
      the PHY needs 300ms to be ready for MDIO communication after releasing
      the reset.
      
      Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
      firmware had enough time to initialize and to appear on the MDIO bus.
      Unfortunately there is no (known) documentation on what the minimum time
      to wait after releasing the reset on an internal PHY so play safe and
      take the one for the external variant. Only wait after the last GPHY
      firmware is loaded to not slow down the initialization too much (
      xRX200 has two GPHYs but newer SoCs have at least three GPHYs).
      
      Fixes: 14fceff4 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20201115165757.552641-1-martin.blumenstingl@googlemail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      2a1828e3
  5. 15 11月, 2020 1 次提交
    • T
      net: dsa: mv88e6xxx: Avoid VTU corruption on 6097 · 92307069
      Tobias Waldekranz 提交于
      As soon as you add the second port to a VLAN, all other port
      membership configuration is overwritten with zeroes. The HW interprets
      this as all ports being "unmodified members" of the VLAN.
      
      In the simple case when all ports belong to the same VLAN, switching
      will still work. But using multiple VLANs or trying to set multiple
      ports as tagged members will not work.
      
      On the 6352, doing a VTU GetNext op, followed by an STU GetNext op
      will leave you with both the member- and state- data in the VTU/STU
      data registers. But on the 6097 (which uses the same implementation),
      the STU GetNext will override the information gathered from the VTU
      GetNext.
      
      Separate the two stages, parsing the result of the VTU GetNext before
      doing the STU GetNext.
      
      We opt to update the existing implementation for all applicable chips,
      as opposed to creating a separate callback for 6097, because although
      the previous implementation did work for (at least) 6352, the
      datasheet does not mention the masking behavior.
      
      Fixes: ef6fcea3 ("net: dsa: mv88e6xxx: get STU entry on VTU GetNext")
      Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com>
      Link: https://lore.kernel.org/r/20201112114335.27371-1-tobias@waldekranz.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      92307069
  6. 12 11月, 2020 1 次提交
  7. 11 11月, 2020 2 次提交
  8. 10 11月, 2020 1 次提交
  9. 06 11月, 2020 4 次提交
    • K
      net: dsa: hellcreek: Add PTP status LEDs · 7d9ee2e8
      Kurt Kanzenbach 提交于
      The switch has two controllable I/Os which are usually connected to LEDs. This
      is useful to immediately visually see the PTP status.
      
      These provide two signals:
      
       * is_gm
      
         This LED can be activated if the current device is the grand master in that
         PTP domain.
      
       * sync_good
      
         This LED can be activated if the current device is in sync with the network
         time.
      
      Expose these via the LED framework to be controlled via user space
      e.g. linuxptp.
      Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      7d9ee2e8
    • K
      net: dsa: hellcreek: Add support for hardware timestamping · f0d4ba9e
      Kamil Alkhouri 提交于
      The switch has the ability to take hardware generated time stamps per port for
      PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
      time synchronization precision for TSN devices/switches. So add support for it.
      
      There are two directions:
      
       * RX
      
         The switch has a single register per port to capture a timestamp. That
         mechanism is not used due to correlation problems. If the software processing
         is too slow and a PTPv2 event message is received before the previous one has
         been processed, false timestamps will be captured. Therefore, the switch can
         do "inline" timestamping which means it can insert the nanoseconds part of
         the timestamp directly into the PTPv2 event message. The reserved field (4
         bytes) is leveraged for that. This might not be in accordance with (older)
         PTP standards, but is the only way to get reliable results.
      
       * TX
      
         In Tx direction there is no correlation problem, because the software and the
         driver has to ensure that only one event message is "on the fly". However,
         the switch provides also a mechanism to check whether a timestamp is
         lost. That can only happen when a timestamp is read and at this point another
         message is timestamped. So, that lost bit is checked just in case to indicate
         to the user that the driver or the software is somewhat buggy.
      Signed-off-by: NKamil Alkhouri <kamil.alkhouri@hs-offenburg.de>
      Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f0d4ba9e
    • K
      net: dsa: hellcreek: Add PTP clock support · ddd56dfe
      Kamil Alkhouri 提交于
      The switch has internal PTP hardware clocks. Add support for it. There are three
      clocks:
      
       * Synchronized
       * Syntonized
       * Free running
      
      Currently the synchronized clock is exported to user space which is a good
      default for the beginning. The free running clock might be exported later
      e.g. for implementing 802.1AS-2011/2020 Time Aware Bridges (TAB). The switch
      also supports cross time stamping for that purpose.
      
      The implementation adds support setting/getting the time as well as offset and
      frequency adjustments. However, the clock only holds a partial timeofday
      timestamp. This is why we track the seconds completely in software (see overflow
      work and last_ts).
      
      Furthermore, add the PTP multicast addresses into the FDB to forward that
      packages only to the CPU port where they are processed by a PTP program.
      Signed-off-by: NKamil Alkhouri <kamil.alkhouri@hs-offenburg.de>
      Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de>
      Acked-by: NRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ddd56dfe
    • K
      net: dsa: Add DSA driver for Hirschmann Hellcreek switches · e4b27ebc
      Kurt Kanzenbach 提交于
      Add a basic DSA driver for Hirschmann Hellcreek switches. Those switches are
      implementing features needed for Time Sensitive Networking (TSN) such as support
      for the Time Precision Protocol and various shapers like the Time Aware Shaper.
      
      This driver includes basic support for networking:
      
       * VLAN handling
       * FDB handling
       * Port statistics
       * STP
       * Phylink
      Signed-off-by: NKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      e4b27ebc
  10. 05 11月, 2020 1 次提交
  11. 03 11月, 2020 4 次提交
  12. 31 10月, 2020 1 次提交
  13. 21 10月, 2020 1 次提交
  14. 20 10月, 2020 1 次提交
  15. 13 10月, 2020 1 次提交
    • C
      net: dsa: microchip: fix race condition · 8098bd69
      Christian Eggers 提交于
      Between queuing the delayed work and finishing the setup of the dsa
      ports, the process may sleep in request_module() (via
      phy_device_create()) and the queued work may be executed prior to the
      switch net devices being registered. In ksz_mib_read_work(), a NULL
      dereference will happen within netof_carrier_ok(dp->slave).
      
      Not queuing the delayed work in ksz_init_mib_timer() makes things even
      worse because the work will now be queued for immediate execution
      (instead of 2000 ms) in ksz_mac_link_down() via
      dsa_port_link_register_of().
      
      Call tree:
      ksz9477_i2c_probe()
      \--ksz9477_switch_register()
         \--ksz_switch_register()
            +--dsa_register_switch()
            |  \--dsa_switch_probe()
            |     \--dsa_tree_setup()
            |        \--dsa_tree_setup_switches()
            |           +--dsa_switch_setup()
            |           |  +--ksz9477_setup()
            |           |  |  \--ksz_init_mib_timer()
            |           |  |     |--/* Start the timer 2 seconds later. */
            |           |  |     \--schedule_delayed_work(&dev->mib_read, msecs_to_jiffies(2000));
            |           |  \--__mdiobus_register()
            |           |     \--mdiobus_scan()
            |           |        \--get_phy_device()
            |           |           +--get_phy_id()
            |           |           \--phy_device_create()
            |           |              |--/* sleeping, ksz_mib_read_work() can be called meanwhile */
            |           |              \--request_module()
            |           |
            |           \--dsa_port_setup()
            |              +--/* Called for non-CPU ports */
            |              +--dsa_slave_create()
            |              |  +--/* Too late, ksz_mib_read_work() may be called beforehand */
            |              |  \--port->slave = ...
            |             ...
            |              +--Called for CPU port */
            |              \--dsa_port_link_register_of()
            |                 \--ksz_mac_link_down()
            |                    +--/* mib_read must be initialized here */
            |                    +--/* work is already scheduled, so it will be executed after 2000 ms */
            |                    \--schedule_delayed_work(&dev->mib_read, 0);
            \-- /* here port->slave is setup properly, scheduling the delayed work should be safe */
      
      Solution:
      1. Do not queue (only initialize) delayed work in ksz_init_mib_timer().
      2. Only queue delayed work in ksz_mac_link_down() if init is completed.
      3. Queue work once in ksz_switch_register(), after dsa_register_switch()
      has completed.
      
      Fixes: 7c6ff470 ("net: dsa: microchip: add MIB counter reading support")
      Signed-off-by: NChristian Eggers <ceggers@arri.de>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      8098bd69
  16. 11 10月, 2020 1 次提交
  17. 10 10月, 2020 1 次提交
  18. 06 10月, 2020 1 次提交
  19. 05 10月, 2020 2 次提交
    • V
      net: dsa: propagate switchdev vlan_filtering prepare phase to drivers · 2e554a7a
      Vladimir Oltean 提交于
      A driver may refuse to enable VLAN filtering for any reason beyond what
      the DSA framework cares about, such as:
      - having tc-flower rules that rely on the switch being VLAN-aware
      - the particular switch does not support VLAN, even if the driver does
        (the DSA framework just checks for the presence of the .port_vlan_add
        and .port_vlan_del pointers)
      - simply not supporting this configuration to be toggled at runtime
      
      Currently, when a driver rejects a configuration it cannot support, it
      does this from the commit phase, which triggers various warnings in
      switchdev.
      
      So propagate the prepare phase to drivers, to give them the ability to
      refuse invalid configurations cleanly and avoid the warnings.
      
      Since we need to modify all function prototypes and check for the
      prepare phase from within the drivers, take that opportunity and move
      the existing driver restrictions within the prepare phase where that is
      possible and easy.
      
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: Hauke Mehrtens <hauke@hauke-m.de>
      Cc: Woojung Huh <woojung.huh@microchip.com>
      Cc: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
      Cc: Sean Wang <sean.wang@mediatek.com>
      Cc: Landen Chao <Landen.Chao@mediatek.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Jonathan McDowell <noodles@earth.li>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e554a7a
    • A
      net: dsa: mv88e6xxx: Add per port devlink regions · b71a8d60
      Andrew Lunn 提交于
      Add a devlink region to return the per port registers.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b71a8d60
  20. 04 10月, 2020 1 次提交
  21. 03 10月, 2020 3 次提交
  22. 30 9月, 2020 6 次提交