Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 03 Sep, 2024 1 commit
  3. 27 Aug, 2024 1 commit
  5. 16 Aug, 2024 4 commits
  7. 08 Aug, 2024 1 commit
  9. 07 Aug, 2024 1 commit
  11. 03 Jul, 2024 1 commit
  13. 25 Jun, 2024 1 commit
    • Tristram Ha's avatar
      net: dsa: microchip: fix wrong register write when masking interrupt · b1c4b4d4
      Tristram Ha authored 
      The switch global port interrupt mask, REG_SW_PORT_INT_MASK__4, is
defined as 0x001C in ksz9477_reg.h.  The designers used 32-bit value in
anticipation for increase of port count in future product but currently
the maximum port count is 7 and the effective value is 0x7F in register
0x001F.  Each port has its own interrupt mask and is defined as 0x#01F.
It uses only 4 bits for different interrupts.

The developer who implemented the current interrupt mechanism in the
switch driver noticed there are similarities between the mechanism to
mask port interrupts in global interrupt and individual interrupts in
each port and so used the same code to handle these interrupts.  He
updated the code to use the new macro REG_SW_PORT_INT_MASK__1 which is
defined as 0x1F in ksz_common.h but he forgot to update the 32-bit write
to 8-bit as now the mask registers are 0x1F and 0x#01F.

In addition all KSZ switches other than the KSZ9897/KSZ9893 and LAN937X
families use only 8-bit access and so this common code will eventually
be changed to accommodate them.

Fixes: e1add7dd ("net: dsa: microchip: use common irq routines for girq and pirq")
Signed-off-by: default avatarTristram Ha <tristram.ha@microchip.com>
Link: https://lore.kernel.org/r/1719009262-2948-1-git-send-email-Tristram.Ha@microchip.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      b1c4b4d4
  15. 23 Jun, 2024 1 commit
  17. 21 Jun, 2024 1 commit
    • Lukasz Majewski's avatar
      net: dsa: ksz_common: Allow only up to two HSR HW offloaded ports for KSZ9477 · dcec8d29
      Lukasz Majewski authored 
      The KSZ9477 allows HSR in-HW offloading for any of two selected ports.
This patch adds check if one tries to use more than two ports with
HSR offloading enabled.

The problem is with RedBox configuration (HSR-SAN) - when configuring:
ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 interlink lan3 \
	supervision 45 version 1

The lan1 (port0) and lan2 (port1) are correctly configured as ports, which
can use HSR offloading on ksz9477.

However, when we do already have two bits set in hsr_ports, we need to
return (-ENOTSUPP), so the interlink port (lan3) would be used with
SW based HSR RedBox support.

Otherwise, I do see some strange network behavior, as some HSR frames are
visible on non-HSR network and vice versa.

This causes the switch connected to interlink port (lan3) to drop frames
and no communication is possible.

Moreover, conceptually - the interlink (i.e. HSR-SAN port - lan3/port2)
shall be only supported in software as it is also possible to use ksz9477
with only SW based HSR (i.e. port0/1 -> hsr0 with offloading, port2 ->
HSR-SAN/interlink, port4/5 -> hsr1 with SW based HSR).

Fixes: 5055cccf ("net: hsr: Provide RedBox support (HSR-SAN)")
Signed-off-by: default avatarLukasz Majewski <lukma@denx.de>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Reviewed-by: default avatarDan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: default avatarFlorian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dcec8d29
  19. 30 May, 2024 1 commit
  21. 13 May, 2024 1 commit
  23. 08 May, 2024 5 commits
  25. 30 Apr, 2024 4 commits
  27. 08 Mar, 2024 1 commit
  29. 26 Feb, 2024 1 commit
  31. 01 Feb, 2024 1 commit
  33. 31 Jan, 2024 1 commit
  35. 08 Dec, 2023 1 commit
  37. 07 Dec, 2023 2 commits
    • Sean Nyekjaer's avatar
      net: dsa: microchip: provide a list of valid protocols for xmit handler · 1499b892
      Sean Nyekjaer authored 
      Provide a list of valid protocols for which the driver will provide
it's deferred xmit handler.

When using DSA_TAG_PROTO_KSZ8795 protocol, it does not provide a
"connect" method, therefor ksz_connect() is not allocating ksz_tagger_data.

This avoids the following null pointer dereference:
 ksz_connect_tag_protocol from dsa_register_switch+0x9ac/0xee0
 dsa_register_switch from ksz_switch_register+0x65c/0x828
 ksz_switch_register from ksz_spi_probe+0x11c/0x168
 ksz_spi_probe from spi_probe+0x84/0xa8
 spi_probe from really_probe+0xc8/0x2d8

Fixes: ab32f56a ("net: dsa: microchip: ptp: add packet transmission timestamping")
Signed-off-by: default avatarSean Nyekjaer <sean@geanix.com>
Reviewed-by: default avatarFlorian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20231206071655.1626479-1-sean@geanix.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      1499b892
    • Vladimir Oltean's avatar
      net: dsa: microchip: properly support platform_data probing · 3bc05faf
      Vladimir Oltean authored 
      The ksz driver has bits and pieces of platform_data probing support, but
it doesn't work.

The conventional thing to do is to have an encapsulating structure for
struct dsa_chip_data that gets put into dev->platform_data. This driver
expects a struct ksz_platform_data, but that doesn't contain a struct
dsa_chip_data as first element, which will obviously not work with
dsa_switch_probe() -> dsa_switch_parse().

Pointing dev->platform_data to a struct dsa_chip_data directly is in
principle possible, but that doesn't work either. The driver has
ksz_switch_detect() to read the device ID from hardware, followed by
ksz_check_device_id() to compare it against a predetermined expected
value. This protects against early errors in the SPI/I2C communication.
With platform_data, the mechanism in ksz_check_device_id() doesn't work
and even leads to NULL pointer dereferences, since of_device_get_match_data()
doesn't work in that probe path.

So obviously, the platform_data support is actually missing, and the
existing handling of struct ksz_platform_data is bogus. Complete the
support by adding a struct dsa_chip_data as first element, and fixing up
ksz_check_device_id() to pick up the platform_data instead of the
unavailable of_device_get_match_data().

The early dev->chip_id assignment from ksz_switch_register() is also
bogus, because ksz_switch_detect() sets it to an initial value. So
remove it.

Also, ksz_platform_data :: enabled_ports isn't used anywhere, delete it.

Link: https://lore.kernel.org/netdev/20231204154315.3906267-1-dd@embedd.com/Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: default avatarDaniel Danzberger <dd@embedd.com>
Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3bc05faf
  39. 29 Nov, 2023 3 commits
  41. 27 Oct, 2023 5 commits
  43. 25 Oct, 2023 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7