#
f30e5323 |
|
19-Sep-2023 |
Colin Ian King <colin.i.king@gmail.com> |
net: dsa: sja1105: make read-only const arrays static Don't populate read-only const arrays on the stack, instead make them static. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230919093606.24446-1-colin.i.king@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
#
9ca482a2 |
|
18-Oct-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: parse {rx, tx}-internal-delay-ps properties for RGMII delays This change does not fix any functional issue or address any real life use case that wasn't possible before. It is just a small step in the process of standardizing the way in which Ethernet MAC drivers may apply RGMII delays (traditionally these have been applied by PHYs, with no clear definition of what to do in the case of a fixed-link). The sja1105 driver used to apply MAC-level RGMII delays on the RX data lines when in fixed-link mode and using a phy-mode of "rgmii-rxid" or "rgmii-id" and on the TX data lines when using "rgmii-txid" or "rgmii-id". But the standard definitions don't say anything about behaving differently when the port is in fixed-link vs when it isn't, and the new device tree bindings are about having a way of applying the delays in a way that is independent of the phy-mode and of the fixed-link property. When the {rx,tx}-internal-delay-ps properties are present, use them, otherwise fall back to the old behavior and warn. One other thing to note is that the SJA1105 hardware applies a delay value in degrees rather than in picoseconds (the delay in ps changes depending on the frequency of the RGMII clock - 125 MHz at 1G, 25 MHz at 100M, 2.5MHz at 10M). I assume that is fine, we calculate the phase shift of the internal delay lines assuming that the device tree meant gigabit, and we let the hardware scale those according to the link speed. Link: https://patchwork.kernel.org/project/netdevbpf/patch/20210723173108.459770-6-prasanna.vengateshan@microchip.com/ Link: https://patchwork.ozlabs.org/project/netdev/patch/20200616074955.GA9092@laureti-dev/#2461123 Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3c9cfb52 |
|
17-Sep-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: update NXP copyright text NXP Legal insists that the following are not fine: - Saying "NXP Semiconductors" instead of "NXP", since the company's registered name is "NXP" - Putting a "(c)" sign in the copyright string - Putting a comma in the copyright string The only accepted copyright string format is "Copyright <year-range> NXP". This patch changes the copyright headers in the networking files that were sent by me, or derived from code sent by me. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
cb5a82d2 |
|
18-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: properly power down the microcontroller clock for SJA1110 It turns out that powering down the BASE_TIMER_CLK does not turn off the microcontroller, just its timers, including the one for the watchdog. So the embedded microcontroller is still running, and potentially still doing things. To prevent unwanted interference, we should power down the BASE_MCSS_CLK as well (MCSS = microcontroller subsystem). The trouble is that currently we turn off the BASE_TIMER_CLK for SJA1110 from the .clocking_setup() method, mostly because this is a Clock Generation Unit (CGU) setting which was traditionally configured in that method for SJA1105. But in SJA1105, the CGU was used for bringing up the port clocks at the proper speeds, and in SJA1110 it's not (but rather for initial configuration), so it's best that we rebrand the sja1110_clocking_setup() method into what it really is - an implementation of the .disable_microcontroller() method. Since disabling the microcontroller only needs to be done once, at probe time, we can choose the best place to do that as being in sja1105_setup(), before we upload the static config to the device. This guarantees that the static config being used by the switch afterwards is really ours. Note that the procedure to upload a static config necessarily resets the switch. This already did not reset the microcontroller, only the switch core, so since the .disable_microcontroller() method is guaranteed to be called by that point, if it's disabled, it remains disabled. Add a comment to make that clear. With the code movement for SJA1110 from .clocking_setup() to .disable_microcontroller(), both methods are optional and are guarded by "if" conditions. Tested by enabling in the device tree the rev-mii switch port 0 that goes towards the microcontroller, and flashing a firmware that would have networking. Without this patch, the microcontroller can be pinged, with this patch it cannot. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
3e77e59b |
|
07-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add support for the SJA1110 switch family The SJA1110 is basically an SJA1105 with more ports, some integrated PHYs (100base-T1 and 100base-TX) and an embedded microcontroller which can be disabled, and the switch core can be controlled by a host running Linux, over SPI. This patch contains: - the static and dynamic config packing functions, for the tables that are common with SJA1105 - one more static config tables which is "unique" to the SJA1110 (actually it is a rehash of stuff that was placed somewhere else in SJA1105): the PCP Remapping Table - a reset and clock configuration procedure for the SJA1110 switch. This resets just the switch subsystem, and gates off the clock which powers on the embedded microcontroller. - an RGMII delay configuration procedure for SJA1110, which is very similar to SJA1105, but different enough for us to be unable to reuse it (this is a pattern that repeats itself) - some adaptations to dynamic config table entries which are no longer programmed in the same way. For example, to delete a VLAN, you used to write an entry through the dynamic reconfiguration interface with the desired VLAN ID, and with the VALIDENT bit set to false. Now, the VLAN table entries contain a TYPE_ENTRY field, which must be set to zero (in a backwards-incompatible way) in order for the entry to be deleted, or to some other entry for the VLAN to match "inner tagged" or "outer tagged" packets. - a similar thing for the static config: the xMII Mode Parameters Table encoding for SGMII and MII (the latter just when attached to a 100base-TX PHY) just isn't what it used to be in SJA1105. They are identical, except there is an extra "special" bit which needs to be set. Set it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f41fad3c |
|
30-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: always keep RGMII ports in the MAC role In SJA1105, the xMII Mode Parameters Table field called PHY_MAC denotes the 'role' of the port, be it a PHY or a MAC. This makes a difference in the MII and RMII protocols, but RGMII is symmetric, so either PHY or MAC settings result in the same hardware behavior. The SJA1110 is different, and the RGMII ports only work when configured in MAC mode, so keep the port roles in MAC mode unconditionally. Why we had an RGMII port in the PHY role in the first place was because we wanted to have a way in the driver to denote whether RGMII delays should be applied based on the phy-mode property or not. This is already done in sja1105_parse_rgmii_delays() based on an intermediary struct sja1105_dt_port (which contains the port role). So it is a logical fallacy to use the hardware configuration as a scratchpad for driver data, it isn't necessary. We can also remove the gating condition for applying RGMII delays only for ports in the PHY role. The .setup_rgmii_delay() method looks at the priv->rgmii_rx_delay[port] and priv->rgmii_tx_delay[port] properties which are already populated properly (in the case of a port in the MAC role they are false). Removing this condition generates a few more SPI writes for these ports (clearing the RGMII delays) which are perhaps useless for SJA1105P/Q/R/S, where we know that the delays are disabled by default. But for SJA1110, the firmware on the embedded microcontroller might have done something funny, so it's always a good idea to clear the RGMII delays if that's what Linux expects. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
41fed17f |
|
30-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add a translation table for port speeds In order to support the new speed of 2500Mbps, the SJA1110 has achieved the great performance of changing the encoding in the MAC Configuration Table for the port speeds of 10, 100, 1000 compared to SJA1105. Because this is a common driver, we need a layer of indirection in order to program the hardware with the right values irrespective of switch generation. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
c5037678 |
|
24-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: skip CGU configuration if it's unnecessary There are two distinct code paths which enter sja1105_clocking.c, one through sja1105_clocking_setup() and the other through sja1105_clocking_setup_port(): sja1105_static_config_reload sja1105_setup | | | +------------------+ | | v v sja1105_clocking_setup sja1105_adjust_port_config | | v | sja1105_clocking_setup_port <------------------+ As opposed to SJA1105, the SJA1110 does not need any configuration of the Clock Generation Unit in order for xMII ports to work. Just RGMII internal delays need to be configured, and that is done inside sja1105_clocking_setup_port for the RGMII ports. So this patch introduces the concept of a "reserved address", which the CGU configuration functions from sja1105_clocking.c must check before proceeding to do anything. The SJA1110 will have reserved addresses for the CGU PLLs for MII/RMII/RGMII. Additionally, make sja1105_clocking_setup() a function pointer so it can be overridden by the SJA1110. Even though nothing port-related needs to be done in the CGU, there are some operations such as disabling the watchdog clock which are unique to the SJA1110. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
542043e9 |
|
24-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: parameterize the number of ports The sja1105 driver will gain support for the next-gen SJA1110 switch, which is very similar except for the fact it has more than 5 ports. So we need to replace the hardcoded SJA1105_NUM_PORTS in this driver with ds->num_ports. This patch is as mechanical as possible (save for the fact that ds->num_ports is not an integer constant expression). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
135e3018 |
|
17-Apr-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: enable internal pull-down for RX_DV/CRS_DV/RX_CTL and RX_ER Some boards do not have the RX_ER MII signal connected. Normally in such situation, those pins would be grounded, but then again, some boards left it electrically floating. When sending traffic to those switch ports, one can see that the N_SOFERR statistics counter is incrementing once per each packet. The user manual states for this counter that it may count the number of frames "that have the MII error input being asserted prior to or up to the SOF delimiter byte". So the switch MAC is sampling an electrically floating signal, and preventing proper traffic reception because of that. As a workaround, enable the internal weak pull-downs on the input pads for the MII control signals. This way, a floating signal would be internally tied to ground. The logic levels of signals which _are_ externally driven should not be bothered by this 40-50 KOhm internal resistor. So it is not an issue to enable the internal pull-down unconditionally, irrespective of PHY interface type (MII, RMII, RGMII, SGMII) and of board layout. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ffe10e67 |
|
20-Mar-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: Add support for the SGMII port SJA1105 switches R and S have one SerDes port with an 802.3z quasi-compatible PCS, hardwired on port 4. The other ports are still MII/RMII/RGMII. The PCS performs rate adaptation to lower link speeds; the MAC on this port is hardwired at gigabit. Only full duplex is supported. The SGMII port can be configured as part of the static config tables, as well as through a dedicated SPI address region for its pseudo-clause-22 registers. However it looks like the static configuration is not able to change some out-of-reset values (like the value of MII_BMCR), so at the end of the day, having code for it is utterly pointless. We are just going to use the pseudo-C22 interface. Because the PCS gets reset when the switch resets, we have to add even more restoration logic to sja1105_static_config_reload, otherwise the SGMII port breaks after operations such as enabling PTP timestamping which require a switch reset. >From PHYLINK perspective, the switch supports *only* SGMII (it doesn't support 1000Base-X). It also doesn't expose access to the raw config word for in-band AN in registers MII_ADV/MII_LPA. It is able to work in the following modes: - Forced speed - SGMII in-band AN slave (speed received from PHY) - SGMII in-band AN master (acting as a PHY) The latter mode is not supported by this patch. It is even unclear to me how that would be described. There is some code for it left in the patch, but 'an_master' is always passed as false. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
1bd44870 |
|
01-Oct-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Rename sja1105_spi_send_packed_buf to sja1105_xfer_buf The most commonly called function in the driver is long due for a rename. The "packed" word is redundant (it doesn't make sense to transfer an unpacked structure, since that is in CPU endianness yadda yadda), and the "spi" word is also redundant since argument 2 of the function is SPI_READ or SPI_WRITE. As for the sja1105_spi_send_long_packed_buf function, it is only being used from sja1105_spi.c, so remove its global prototype. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
09c1b412 |
|
01-Oct-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Don't use "inline" function declarations in C files Let the compiler decide. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
c05ec3d4 |
|
08-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add RGMII delay support for P/Q/R/S chips As per the DT phy-mode specification, RGMII delays are applied by the MAC when there is no PHY present on the link. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
b5b0c7f4 |
|
08-Jun-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Remove duplicate rgmii_pad_mii_tx from regs The pad_mii_tx registers point to the same memory region but were unused. So convert to using these for RGMII I/O cell configuration, as they bear a shorter name. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
f5b8631c |
|
02-May-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Error out if RGMII delays are requested in DT Documentation/devicetree/bindings/net/ethernet.txt is confusing because it says what the MAC should not do, but not what it *should* do: * "rgmii-rxid" (RGMII with internal RX delay provided by the PHY, the MAC should not add an RX delay in this case) The gap in semantics is threefold: 1. Is it illegal for the MAC to apply the Rx internal delay by itself, and simplify the phy_mode (mask off "rgmii-rxid" into "rgmii") before passing it to of_phy_connect? The documentation would suggest yes. 1. For "rgmii-rxid", while the situation with the Rx clock skew is more or less clear (needs to be added by the PHY), what should the MAC driver do about the Tx delays? Is it an implicit wild card for the MAC to apply delays in the Tx direction if it can? What if those were already added as serpentine PCB traces, how could that be made more obvious through DT bindings so that the MAC doesn't attempt to add them twice and again potentially break the link? 3. If the interface is a fixed-link and therefore the PHY object is fixed (a purely software entity that obviously cannot add clock skew), what is the meaning of the above property? So an interpretation of the RGMII bindings was chosen that hopefully does not contradict their intention but also makes them more applied. The SJA1105 driver understands to act upon "rgmii-*id" phy-mode bindings if the port is in the PHY role (either explicitly, or if it is a fixed-link). Otherwise it always passes the duty of setting up delays to the PHY driver. The error behavior that this patch adds is required on SJA1105E/T where the MAC really cannot apply internal delays. If the other end of the fixed-link cannot apply RGMII delays either (this would be specified through its own DT bindings), then the situation requires PCB delays. For SJA1105P/Q/R/S, this is however hardware supported and the error is thus only temporary. I created a stub function pointer for configuring delays per-port on RXC and TXC, and will implement it when I have access to a board with this hardware setup. Meanwhile do not allow the user to select an invalid configuration. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8aa9ebcc |
|
02-May-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch At this moment the following is supported: * Link state management through phylib * Autonomous L2 forwarding managed through iproute2 bridge commands. IP termination must be done currently through the master netdevice, since the switch is unmanaged at this point and using DSA_TAG_PROTO_NONE. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Georg Waibel <georg.waibel@sensor-technik.de> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|