1. 16 1月, 2021 3 次提交
    • V
      net: mscc: ocelot: register devlink ports · 6c30384e
      Vladimir Oltean 提交于
      Add devlink integration into the mscc_ocelot switchdev driver. All
      physical ports (i.e. the unused ones as well) except the CPU port module
      at ocelot->num_phys_ports are registered with devlink, and that requires
      keeping the devlink_port structure outside struct ocelot_port_private,
      since the latter has a 1:1 mapping with a struct net_device (which does
      not exist for unused ports).
      
      Since we use devlink_port_type_eth_set to link the devlink port to the
      net_device, we can as well remove the .ndo_get_phys_port_name and
      .ndo_get_port_parent_id implementations, since devlink takes care of
      retrieving the port name and number automatically, once
      .ndo_get_devlink_port is implemented.
      
      Note that the felix DSA driver is already integrated with devlink by
      default, since that is a thing that the DSA core takes care of. This is
      the reason why these devlink stubs were put in ocelot_net.c and not in
      the common library. It is also the reason why ocelot::devlink is a
      pointer and not a full structure embedded inside struct ocelot: because
      the mscc_ocelot driver allocates that by itself (as the container of
      struct ocelot, in fact), but in the case of felix, it is DSA who
      allocates the devlink, and felix just propagates the pointer towards
      struct ocelot.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      6c30384e
    • V
      net: mscc: ocelot: add ops for decoding watermark threshold and occupancy · 703b7621
      Vladimir Oltean 提交于
      We'll need to read back the watermark thresholds and occupancy from
      hardware (for devlink-sb integration), not only to write them as we did
      so far in ocelot_port_set_maxlen. So introduce 2 new functions in struct
      ocelot_ops, similar to wm_enc, and implement them for the 3 supported
      mscc_ocelot switches.
      
      Remove the INUSE and MAXUSE unpacking helpers for the QSYS_RES_STAT
      register, because that doesn't scale with the number of switches that
      mscc_ocelot supports now. They have different bit widths for the
      watermarks, and we need function pointers to abstract that difference
      away.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      703b7621
    • V
      net: mscc: ocelot: auto-detect packet buffer size and number of frame references · f6fe01d6
      Vladimir Oltean 提交于
      Instead of reading these values from the reference manual and writing
      them down into the driver, it appears that the hardware gives us the
      option of detecting them dynamically.
      
      The number of frame references corresponds to what the reference manual
      notes, however it seems that the frame buffers are reported as slightly
      less than the books would indicate. On VSC9959 (Felix), the books say it
      should have 128KB of packet buffer, but the registers indicate only
      129840 bytes (126.79 KB). Also, the unit of measurement for FREECNT from
      the documentation of all these devices is incorrect (taken from an older
      generation). This was confirmed by Younes Leroul from Microchip support.
      
      Not having anything better to do with these values at the moment* (this
      will change soon), let's just print them.
      
      *The frame buffer size is, in fact, used to calculate the tail dropping
      watermarks.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f6fe01d6
  2. 17 12月, 2020 1 次提交
  3. 06 12月, 2020 1 次提交
    • V
      net: mscc: ocelot: fix dropping of unknown IPv4 multicast on Seville · edd2410b
      Vladimir Oltean 提交于
      The current assumption is that the felix DSA driver has flooding knobs
      per traffic class, while ocelot switchdev has a single flooding knob.
      This was correct for felix VSC9959 and ocelot VSC7514, but with the
      introduction of seville VSC9953, we see a switch driven by felix.c which
      has a single flooding knob.
      
      So it is clear that we must do what should have been done from the
      beginning, which is not to overwrite the configuration done by ocelot.c
      in felix, but instead to teach the common ocelot library about the
      differences in our switches, and set up the flooding PGIDs centrally.
      
      The effect that the bogus iteration through FELIX_NUM_TC has upon
      seville is quite dramatic. ANA_FLOODING is located at 0x00b548, and
      ANA_FLOODING_IPMC is located at 0x00b54c. So the bogus iteration will
      actually overwrite ANA_FLOODING_IPMC when attempting to write
      ANA_FLOODING[1]. There is no ANA_FLOODING[1] in sevile, just ANA_FLOODING.
      
      And when ANA_FLOODING_IPMC is overwritten with a bogus value, the effect
      is that ANA_FLOODING_IPMC gets the value of 0x0003CF7D:
      	MC6_DATA = 61,
      	MC6_CTRL = 61,
      	MC4_DATA = 60,
      	MC4_CTRL = 0.
      Because MC4_CTRL is zero, this means that IPv4 multicast control packets
      are not flooded, but dropped. An invalid configuration, and this is how
      the issue was actually spotted.
      Reported-by: NEldar Gasanov <eldargasanov2@gmail.com>
      Reported-by: NMaxim Kochetkov <fido_max@inbox.ru>
      Tested-by: NEldar Gasanov <eldargasanov2@gmail.com>
      Fixes: 84705fc1 ("net: dsa: felix: introduce support for Seville VSC9953 switch")
      Fixes: 3c7b51bd ("net: dsa: felix: allow flooding for all traffic classes")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Link: https://lore.kernel.org/r/20201204175416.1445937-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      edd2410b
  4. 09 10月, 2020 1 次提交
  5. 06 10月, 2020 1 次提交
  6. 03 10月, 2020 1 次提交
  7. 30 9月, 2020 5 次提交
  8. 27 9月, 2020 1 次提交
    • V
      net: mscc: ocelot: move NPI port configuration to DSA · 2d44b097
      Vladimir Oltean 提交于
      Remove the ocelot_configure_cpu() function, which was in fact bringing
      up 2 ports: the CPU port module, which both switchdev and DSA have, and
      the NPI port, which only DSA has.
      
      The (non-Ethernet) CPU port module is at a fixed index in the analyzer,
      whereas the NPI port is selected through the "ethernet" property in the
      device tree.
      
      Therefore, the function to set up an NPI port is DSA-specific, so we
      move it there, simplifying the ocelot switch library a little bit.
      
      Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: UNGLinuxDriver <UNGLinuxDriver@microchip.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d44b097
  9. 22 9月, 2020 1 次提交
  10. 19 9月, 2020 5 次提交
  11. 23 7月, 2020 1 次提交
    • V
      net: mscc: ocelot: fix non-initialized CPU port on VSC7514 · 8bb849d6
      Vladimir Oltean 提交于
      The VSC7514 is marketed as a 10-port switch, however it has 11 physical
      ports (0->10) in the block diagram:
      https://www.microsemi.com/product-directory/ethernet-switches/3992-vsc7514
      (also in the device tree at arch/mips/boot/dts/mscc/ocelot.dtsi)
      
      Additionally, by architecture it has one more entry in the analyzer
      block, situated right after the physical ports, for the CPU port module.
      This is not a physical port, it only represents a channel for frame
      injection and extraction. That entry for the CPU port is at index 11 in
      the analyzer.
      
      When the register groups for QSYS_SWITCH_PORT_MODE, SYS_PORT_MODE and
      SYS_PAUSE_CFG are declared to be replicated 11 times, the 11th entry in
      the array of regfields is not initialized, so the CPU port module is not
      initialized either.
      
      The documentation of QSYS_SWITCH_PORT_MODE for VSC7514 also says that
      this register group is replicated 12 times, so this patch is simply
      reflecting that and not introducing any further inconsistency.
      
      Fixes: 886e1387 ("net: mscc: ocelot: convert QSYS_SWITCH_PORT_MODE and SYS_PORT_MODE to regfields")
      Fixes: 541132f0 ("net: mscc: ocelot: convert SYS_PAUSE_CFG register access to regfield")
      Reported-by: NBryan Whitehead <bryan.whitehead@microchip.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8bb849d6
  12. 14 7月, 2020 5 次提交
  13. 21 6月, 2020 2 次提交
  14. 28 5月, 2020 1 次提交
  15. 22 4月, 2020 2 次提交
  16. 05 3月, 2020 1 次提交
    • V
      net: mscc: ocelot: eliminate confusion between CPU and NPI port · 69df578c
      Vladimir Oltean 提交于
      Ocelot has the concept of a CPU port. The CPU port is represented in the
      forwarding and the queueing system, but it is not a physical device. The
      CPU port can either be accessed via register-based injection/extraction
      (which is the case of Ocelot), via Frame-DMA (similar to the first one),
      or "connected" to a physical Ethernet port (called NPI in the datasheet)
      which is the case of the Felix DSA switch.
      
      In Ocelot the CPU port is at index 11.
      In Felix the CPU port is at index 6.
      
      The CPU bit is treated special in the forwarding, as it is never cleared
      from the forwarding port mask (once added to it). Other than that, it is
      treated the same as a normal front port.
      
      Both Felix and Ocelot should use the CPU port in the same way. This
      means that Felix should not use the NPI port directly when forwarding to
      the CPU, but instead use the CPU port.
      
      This patch is fixing this such that Felix will use port 6 as its CPU
      port, and just use the NPI port to carry the traffic.
      
      Therefore, eliminate the "ocelot->cpu" variable which was holding the
      index of the NPI port for Felix, and the index of the CPU port module
      for Ocelot, so the variable was actually configuring different things
      for different drivers and causing at least part of the confusion.
      
      Also remove the "ocelot->num_cpu_ports" variable, which is the result of
      another confusion. The 2 CPU ports mentioned in the datasheet are
      because there are two frame extraction channels (register based or DMA
      based). This is of no relevance to the driver at the moment, and
      invisible to the analyzer module.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Suggested-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69df578c
  17. 04 3月, 2020 3 次提交
  18. 18 2月, 2020 1 次提交
    • H
      net: mscc: fix in frame extraction · a8154104
      Horatiu Vultur 提交于
      Each extracted frame on Ocelot has an IFH. The frame and IFH are extracted
      by reading chuncks of 4 bytes from a register.
      
      In case the IFH and frames were read corretly it would try to read the next
      frame. In case there are no more frames in the queue, it checks if there
      were any previous errors and in that case clear the queue. But this check
      will always succeed also when there are no errors. Because when extracting
      the IFH the error is checked against 4(number of bytes read) and then the
      error is set only if the extraction of the frame failed. So in a happy case
      where there are no errors the err variable is still 4. So it could be
      a case where after the check that there are no more frames in the queue, a
      frame will arrive in the queue but because the error is not reseted, it
      would try to flush the queue. So the frame will be lost.
      
      The fix consist in resetting the error after reading the IFH.
      Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Acked-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8154104
  19. 06 1月, 2020 1 次提交
  20. 22 11月, 2019 1 次提交
  21. 17 11月, 2019 1 次提交
    • H
      net: mscc: ocelot: omit error check from of_get_phy_mode · 4214fa1e
      Horatiu Vultur 提交于
      The commit 0c65b2b9 ("net: of_get_phy_mode: Change API to solve
      int/unit warnings") updated the function of_get_phy_mode declaration.
      Now it returns an error code and in case the node doesn't contain the
      property 'phy-mode' or 'phy-connection-type' it returns -EINVAL and would
      set the phy_interface_t to PHY_INTERFACE_MODE_NA.
      
      Ocelot VSC7514 has 4 internal phys which have the phy interface
      PHY_INTERFACE_MODE_NA. So because of_get_phy_mode would assign
      PHY_INTERFACE_MODE_NA to phy_mode when there is an error, there is no need
      to add the error check.
      
      Updates for v2:
       - drop error check because of_get_phy_mode already assigns phy_interface
         to PHY_INTERFACE_MODE in case of error.
      Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4214fa1e
  22. 16 11月, 2019 1 次提交