1. 25 3月, 2023 6 次提交
  2. 17 3月, 2023 1 次提交
    • M
      net: dsa: microchip: fix RGMII delay configuration on KSZ8765/KSZ8794/KSZ8795 · 5ae06327
      Marek Vasut 提交于
      The blamed commit has replaced a ksz_write8() call to address
      REG_PORT_5_CTRL_6 (0x56) with a ksz_set_xmii() -> ksz_pwrite8() call to
      regs[P_XMII_CTRL_1], which is also defined as 0x56 for ksz8795_regs[].
      
      The trouble is that, when compared to ksz_write8(), ksz_pwrite8() also
      adjusts the register offset with the port base address. So in reality,
      ksz_pwrite8(offset=0x56) accesses register 0x56 + 0x50 = 0xa6, which in
      this switch appears to be unmapped, and the RGMII delay configuration on
      the CPU port does nothing.
      
      So if the switch wasn't fine with the RGMII delay configuration done
      through pin strapping and relied on Linux to apply a different one in
      order to pass traffic, this is now broken.
      
      Using the offset translation logic imposed by ksz_pwrite8(), the correct
      value for regs[P_XMII_CTRL_1] should have been 0x6 on ksz8795_regs[], in
      order to really end up accessing register 0x56.
      
      Static code analysis shows that, despite there being multiple other
      accesses to regs[P_XMII_CTRL_1] in this driver, the only code path that
      is applicable to ksz8795_regs[] and ksz8_dev_ops is ksz_set_xmii().
      Therefore, the problem is isolated to RGMII delays.
      
      In its current form, ksz8795_regs[] contains the same value for
      P_XMII_CTRL_0 and for P_XMII_CTRL_1, and this raises valid suspicions
      that writes made by the driver to regs[P_XMII_CTRL_0] might overwrite
      writes made to regs[P_XMII_CTRL_1] or vice versa.
      
      Again, static analysis shows that the only accesses to P_XMII_CTRL_0
      from the driver are made from code paths which are not reachable with
      ksz8_dev_ops. So the accesses made by ksz_set_xmii() are safe for this
      switch family.
      
      [ vladimiroltean: rewrote commit message ]
      
      Fixes: c476bede ("net: dsa: microchip: ksz8795: use common xmii function")
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: NArun Ramadoss <arun.ramadoss@microchip.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20230315231916.2998480-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      5ae06327
  3. 13 2月, 2023 1 次提交
  4. 31 1月, 2023 1 次提交
    • A
      net: dsa: microchip: ptp: fix up PTP dependency · 562c6548
      Arnd Bergmann 提交于
      When NET_DSA_MICROCHIP_KSZ_COMMON is built-in but PTP is a loadable
      module, the ksz_ptp support still causes a link failure:
      
      ld.lld-16: error: undefined symbol: ptp_clock_index
      >>> referenced by ksz_ptp.c
      >>>               drivers/net/dsa/microchip/ksz_ptp.o:(ksz_get_ts_info) in archive vmlinux.a
      
      This can happen if NET_DSA_MICROCHIP_KSZ8863_SMI is enabled, or
      even if none of the KSZ9477_I2C/KSZ_SPI/KSZ8863_SMI ones are active
      but only the common module is.
      
      The most straightforward way to address this is to move the
      dependency to NET_DSA_MICROCHIP_KSZ_PTP itself, which can now
      only be enabled if both PTP_1588_CLOCK support is reachable
      from NET_DSA_MICROCHIP_KSZ_COMMON. Alternatively, one could make
      NET_DSA_MICROCHIP_KSZ_COMMON a hidden Kconfig symbol and extend the
      PTP_1588_CLOCK_OPTIONAL dependency to NET_DSA_MICROCHIP_KSZ8863_SMI as
      well, but that is a little more fragile.
      
      Fixes: eac1ea20 ("net: dsa: microchip: ptp: add the posix clock support")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20230130131808.1084796-1-arnd@kernel.orgSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      562c6548
  5. 24 1月, 2023 3 次提交
    • A
      net: dsa: microchip: add support for credit based shaper · 71d7920f
      Arun Ramadoss 提交于
      KSZ9477, KSZ9567, KSZ9563, KSZ8563 and LAN937x supports Credit based
      shaper. To differentiate the chip supporting cbs, tc_cbs_supported
      flag is introduced in ksz_chip_data.
      And KSZ series has 16bit Credit increment registers whereas LAN937x has
      24bit register. The value to be programmed in the credit increment is
      determined using the successive multiplication method to convert decimal
      fraction to hexadecimal fraction.
      For example: if idleslope is 10000 and sendslope is -90000, then
      bandwidth is 10000 - (-90000) = 100000.
      The 10% bandwidth of 100Mbps means 10/100 = 0.1(decimal). This value has
      to be converted to hexa.
      1) 0.1 * 16 = 1.6  --> fraction 0.6 Carry = 1 (MSB)
      2) 0.6 * 16 = 9.6  --> fraction 0.6 Carry = 9
      3) 0.6 * 16 = 9.6  --> fraction 0.6 Carry = 9
      4) 0.6 * 16 = 9.6  --> fraction 0.6 Carry = 9
      5) 0.6 * 16 = 9.6  --> fraction 0.6 Carry = 9
      6) 0.6 * 16 = 9.6  --> fraction 0.6 Carry = 9 (LSB)
      Now 0.1(decimal) becomes 0.199999(Hex).
      If it is LAN937x, 24 bit value will be programmed to Credit Inc
      register, 0x199999. For others 16 bit value will be prgrammed, 0x1999.
      Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      71d7920f
    • A
      net: dsa: microchip: enable port queues for tc mqprio · e30f33a5
      Arun Ramadoss 提交于
      LAN937x family of switches has 8 queues per port where the KSZ switches
      has 4 queues per port. By default, only one queue per port is enabled.
      The queues are configurable in 2, 4 or 8. This patch add 8 number of
      queues for LAN937x and 4 for other switches.
      In the tag_ksz.c file, prioirty of the packet is queried using the skb
      buffer and the corresponding value is updated in the tag.
      Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      e30f33a5
    • A
      net: dsa: microchip: fix probe of I2C-connected KSZ8563 · 360fdc99
      Ahmad Fatoum 提交于
      Starting with commit eee16b14 ("net: dsa: microchip: perform the
      compatibility check for dev probed"), the KSZ switch driver now bails
      out if it thinks the DT compatible doesn't match the actual chip ID
      read back from the hardware:
      
        ksz9477-switch 1-005f: Device tree specifies chip KSZ9893 but found
        KSZ8563, please fix it!
      
      For the KSZ8563, which used ksz_switch_chips[KSZ9893], this was fine
      at first, because it indeed shares the same chip id as the KSZ9893.
      
      Commit b4490809 ("net: dsa: microchip: add separate struct
      ksz_chip_data for KSZ8563 chip") started differentiating KSZ9893
      compatible chips by consulting the 0x1F register. The resulting breakage
      was fixed for the SPI driver in the same commit by introducing the
      appropriate ksz_switch_chips[KSZ8563], but not for the I2C driver.
      
      Fix this for I2C-connected KSZ8563 now to get it probing again.
      
      Fixes: b4490809 ("net: dsa: microchip: add separate struct ksz_chip_data for KSZ8563 chip").
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NAhmad Fatoum <a.fatoum@pengutronix.de>
      Acked-by: NArun Ramadoss <arun.ramadoss@microchip.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20230120110933.1151054-1-a.fatoum@pengutronix.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      360fdc99
  6. 21 1月, 2023 1 次提交
  7. 20 1月, 2023 2 次提交
  8. 13 1月, 2023 12 次提交
  9. 20 12月, 2022 1 次提交
  10. 09 12月, 2022 1 次提交
  11. 07 12月, 2022 6 次提交
  12. 24 11月, 2022 1 次提交
  13. 23 11月, 2022 1 次提交
  14. 09 11月, 2022 3 次提交