Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3 |
|
#
7cef293b |
| 08-Sep-2023 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix multicast forwarding working only for last added mdb entry
The commit cited in Fixes: did 2 things: it refactored the read-back polling from sja1105_dynamic_config_read() into
net: dsa: sja1105: fix multicast forwarding working only for last added mdb entry
The commit cited in Fixes: did 2 things: it refactored the read-back polling from sja1105_dynamic_config_read() into a new function, sja1105_dynamic_config_wait_complete(), and it called that from sja1105_dynamic_config_write() too.
What is problematic is the refactoring.
The refactored code from sja1105_dynamic_config_poll_valid() works like the previous one, but the problem is that it uses another packed_buf[] SPI buffer, and there was code at the end of sja1105_dynamic_config_read() which was relying on the read-back packed_buf[]:
/* Don't dereference possibly NULL pointer - maybe caller * only wanted to see whether the entry existed or not. */ if (entry) ops->entry_packing(packed_buf, entry, UNPACK);
After the change, the packed_buf[] that this code sees is no longer the entry read back from hardware, but the original entry that the caller passed to the sja1105_dynamic_config_read(), packed into this buffer.
This difference is the most notable with the SJA1105_SEARCH uses from sja1105pqrs_fdb_add() - used for both fdb and mdb. There, we have logic added by commit 728db843df88 ("net: dsa: sja1105: ignore the FDB entry for unknown multicast when adding a new address") to figure out whether the address we're trying to add matches on any existing hardware entry, with the exception of the catch-all multicast address.
That logic was broken, because with sja1105_dynamic_config_read() not working properly, it doesn't return us the entry read back from hardware, but the entry that we passed to it. And, since for multicast, a match will always exist, it will tell us that any mdb entry already exists at index=0 L2 Address Lookup table. It is index=0 because the caller doesn't know the index - it wants to find it out, and sja1105_dynamic_config_read() does:
if (index < 0) { // SJA1105_SEARCH /* Avoid copying a signed negative number to an u64 */ cmd.index = 0; // <- this cmd.search = true; } else { cmd.index = index; cmd.search = false; }
So, to the caller of sja1105_dynamic_config_read(), the returned info looks entirely legit, and it will add all mdb entries to FDB index 0. There, they will always overwrite each other (not to mention, potentially they can also overwrite a pre-existing bridge fdb entry), and the user-visible impact will be that only the last mdb entry will be forwarded as it should. The others won't (will be flooded or dropped, depending on the egress flood settings).
Fixing is a bit more complicated, and involves either passing the same packed_buf[] to sja1105_dynamic_config_wait_complete(), or moving all the extra processing on the packed_buf[] to sja1105_dynamic_config_wait_complete(). I've opted for the latter, because it makes sja1105_dynamic_config_wait_complete() a bit more self-contained.
Fixes: df405910ab9f ("net: dsa: sja1105: wait for dynamic config command completion on writes too") Reported-by: Yanan Yang <yanan.yang@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
c9567980 |
| 08-Sep-2023 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: propagate exact error code from sja1105_dynamic_config_poll_valid()
Currently, sja1105_dynamic_config_wait_complete() returns either 0 or -ETIMEDOUT, because it just looks at the
net: dsa: sja1105: propagate exact error code from sja1105_dynamic_config_poll_valid()
Currently, sja1105_dynamic_config_wait_complete() returns either 0 or -ETIMEDOUT, because it just looks at the read_poll_timeout() return code.
There will be future changes which move some more checks to sja1105_dynamic_config_poll_valid(). It is important that we propagate their exact return code (-ENOENT, -EINVAL), because callers of sja1105_dynamic_config_read() depend on them.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15 |
|
#
eb016afd |
| 24-Oct-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: serialize access to the dynamic config interface
The sja1105 hardware seems as concurrent as can be, but when we create a background script that adds/removes a rain of FDB entries
net: dsa: sja1105: serialize access to the dynamic config interface
The sja1105 hardware seems as concurrent as can be, but when we create a background script that adds/removes a rain of FDB entries without the rtnl_mutex taken, then in parallel we do another operation like run 'bridge fdb show', we can notice these errors popping up:
sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:40 vid 0: -ENOENT sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:40 vid 0 to fdb: -2 sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:46 vid 0: -ENOENT sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:46 vid 0 to fdb: -2
Luckily what is going on does not require a major rework in the driver. The sja1105_dynamic_config_read() function sends multiple SPI buffers to the peripheral until the operation completes. We should not do anything until the hardware clears the VALID bit.
But since there is no locking (i.e. right now we are implicitly serialized by the rtnl_mutex, but if we remove that), it might be possible that the process which performs the dynamic config read is preempted and another one performs a dynamic config write.
What will happen in that case is that sja1105_dynamic_config_read(), when it resumes, expects to see VALIDENT set for the entry it reads back. But it won't.
This can be corrected by introducing a mutex for serializing SPI accesses to the dynamic config interface which should be atomic with respect to each other.
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>
show more ...
|
#
df405910 |
| 24-Oct-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: wait for dynamic config command completion on writes too
The hardware manual says that software should attempt a new dynamic config access (be it a a write or a read-back) only wh
net: dsa: sja1105: wait for dynamic config command completion on writes too
The hardware manual says that software should attempt a new dynamic config access (be it a a write or a read-back) only while the VALID bit is cleared. The VALID bit is set by software to 1, and it remains set as long as the hardware is still processing the request.
Currently the driver only polls for the command completion only for reads, because that's when we need the actual data read back. Writes have been more or less "asynchronous", although this has never been an observable issue.
This change makes sja1105_dynamic_config_write poll the VALID bit as well, to absolutely ensure that a follow-up access to the static config finds the VALID bit cleared.
So VALID means "work in progress", while VALIDENT means "entry being read is valid". On reads we check the VALIDENT bit too, while on writes that bit is not always defined. So we need to factor it out of the loop, and make the loop provide back the unpacked command structure, so that sja1105_dynamic_config_read can check the VALIDENT bit.
The change also attempts to convert the open-coded loop to use the read_poll_timeout macro, since I know this will come up during review. It's more code, but hey, it uses read_poll_timeout!
Tested on SJA1105T, SJA1105S, SJA1110A.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2d7e73f0 |
| 25-Oct-2021 |
David S. Miller <davem@davemloft.net> |
Revert "Merge branch 'dsa-rtnl'"
This reverts commit 965e6b262f48257dbdb51b565ecfd84877a0ab5f, reversing changes made to 4d98bb0d7ec2d0b417df6207b0bafe1868bad9f8.
|
#
1681ae16 |
| 22-Oct-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: serialize access to the dynamic config interface
The sja1105 hardware seems as concurrent as can be, but when we create a background script that adds/removes a rain of FDB entries
net: dsa: sja1105: serialize access to the dynamic config interface
The sja1105 hardware seems as concurrent as can be, but when we create a background script that adds/removes a rain of FDB entries without the rtnl_mutex taken, then in parallel we do another operation like run 'bridge fdb show', we can notice these errors popping up:
sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:40 vid 0: -ENOENT sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:40 vid 0 to fdb: -2 sja1105 spi2.0: port 2 failed to read back entry for 00:01:02:03:00:46 vid 0: -ENOENT sja1105 spi2.0: port 2 failed to add 00:01:02:03:00:46 vid 0 to fdb: -2
Luckily what is going on does not require a major rework in the driver. The sja1105_dynamic_config_read() function sends multiple SPI buffers to the peripheral until the operation completes. We should not do anything until the hardware clears the VALID bit.
But since there is no locking (i.e. right now we are implicitly serialized by the rtnl_mutex, but if we remove that), it might be possible that the process which performs the dynamic config read is preempted and another one performs a dynamic config write.
What will happen in that case is that sja1105_dynamic_config_read(), when it resumes, expects to see VALIDENT set for the entry it reads back. But it won't.
This can be corrected by introducing a mutex for serializing SPI accesses to the dynamic config interface which should be atomic with respect to each other.
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>
show more ...
|
#
643979cf |
| 22-Oct-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: wait for dynamic config command completion on writes too
The hardware manual says that software should attempt a new dynamic config access (be it a a write or a read-back) only wh
net: dsa: sja1105: wait for dynamic config command completion on writes too
The hardware manual says that software should attempt a new dynamic config access (be it a a write or a read-back) only while the VALID bit is cleared. The VALID bit is set by software to 1, and it remains set as long as the hardware is still processing the request.
Currently the driver only polls for the command completion only for reads, because that's when we need the actual data read back. Writes have been more or less "asynchronous", although this has never been an observable issue.
This change makes sja1105_dynamic_config_write poll the VALID bit as well, to absolutely ensure that a follow-up access to the static config finds the VALID bit cleared.
So VALID means "work in progress", while VALIDENT means "entry being read is valid". On reads we check the VALIDENT bit too, while on writes that bit is not always defined. So we need to factor it out of the loop, and make the loop provide back the unpacked command structure, so that sja1105_dynamic_config_read can check the VALIDENT bit.
The change also attempts to convert the open-coded loop to use the read_poll_timeout macro, since I know this will come up during review. It's more code, but hey, it uses read_poll_timeout!
Tested on SJA1105T, SJA1105S, SJA1110A.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
cb81698f |
| 30-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix static FDB writes for SJA1110
The blamed commit made FDB access on SJA1110 functional only as far as dumping the existing entries goes, but anything having to do with an entry
net: dsa: sja1105: fix static FDB writes for SJA1110
The blamed commit made FDB access on SJA1110 functional only as far as dumping the existing entries goes, but anything having to do with an entry's index (adding, deleting) is still broken.
There are in fact 2 problems, all caused by improperly inheriting the code from SJA1105P/Q/R/S: - An entry size is SJA1110_SIZE_L2_LOOKUP_ENTRY (24) bytes and not SJA1105PQRS_SIZE_L2_LOOKUP_ENTRY (20) bytes - The "index" field within an FDB entry is at bits 10:1 for SJA1110 and not 15:6 as in SJA1105P/Q/R/S
This patch moves the packing function for the cmd->index outside of sja1105pqrs_common_l2_lookup_cmd_packing() and into the device specific functions sja1105pqrs_l2_lookup_cmd_packing and sja1110_l2_lookup_cmd_packing.
Fixes: 74e7feff0e22 ("net: dsa: sja1105: fix dynamic access to L2 Address Lookup table for SJA1110") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
b11f0a4c |
| 28-Jul-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: be stateless when installing FDB entries
Currently there are issues when adding a bridge FDB entry as VLAN-aware and deleting it as VLAN-unaware, or vice versa.
However this is a
net: dsa: sja1105: be stateless when installing FDB entries
Currently there are issues when adding a bridge FDB entry as VLAN-aware and deleting it as VLAN-unaware, or vice versa.
However this is an unneeded complication, since the bridge always installs its default FDB entries in VLAN 0 to match on VLAN-unaware ports, and in the default_pvid (VLAN 1) to match on VLAN-aware ports. So instead of trying to outsmart the bridge, just install all entries it gives us, and they will start matching packets when the vlan_filtering mode changes.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13 |
|
#
74e7feff |
| 27-Jun-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix dynamic access to L2 Address Lookup table for SJA1110
The SJA1105P/Q/R/S and SJA1110 may have the same layout for the command to read/write/search for L2 Address Lookup entrie
net: dsa: sja1105: fix dynamic access to L2 Address Lookup table for SJA1110
The SJA1105P/Q/R/S and SJA1110 may have the same layout for the command to read/write/search for L2 Address Lookup entries, but as explained in the comments at the beginning of the sja1105_dynamic_config.c file, the command portion of the buffer is at the end, and we need to obtain a pointer to it by adding the length of the entry to the buffer.
Alas, the length of an L2 Address Lookup entry is larger in SJA1110 than it is for SJA1105P/Q/R/S, so we need to create a common helper to access the command buffer, and this receives as argument the length of the entry buffer.
Fixes: 3e77e59bf8cf ("net: dsa: sja1105: add support for the SJA1110 switch family") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.10.46, v5.10.43 |
|
#
3e77e59b |
| 08-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 whi
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>
show more ...
|
Revision tags: v5.10.42 |
|
#
96c85f51 |
| 30-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: some table entries are always present when read dynamically
The SJA1105 has a static configuration comprised of a number of tables with entries. Some of these can be read and modi
net: dsa: sja1105: some table entries are always present when read dynamically
The SJA1105 has a static configuration comprised of a number of tables with entries. Some of these can be read and modified at runtime as well, through the dynamic configuration interface.
As a careful reader can notice from the comments in this file, the software interface for accessing a table entry through the dynamic reconfiguration is a bit of a no man's land, and varies wildly across switch generations and even from one kind of table to another.
I have tried my best to come up with a software representation of a 'common denominator' SPI command to access a table entry through the dynamic configuration interface:
struct sja1105_dyn_cmd { bool search; u64 valid; /* must be set to 1 */ u64 rdwrset; /* 0 to read, 1 to write */ u64 errors; u64 valident; /* 0 if entry is invalid, 1 if valid */ u64 index; };
Relevant to this patch is the VALIDENT bit, which for READ commands is populated by the switch and lets us know if we're looking at junk or at a real table entry.
In SJA1105, the dynamic reconfiguration interface for management routes has notably not implemented the VALIDENT bit, leading to a workaround to ignore this field in sja1105_dynamic_config_read(), as it will be set to zero, but the data is valid nonetheless.
In SJA1110, this pattern has sadly been abused to death, and while there are many more tables which can be read back over the dynamic config interface compared to SJA1105, their handling isn't in any way more uniform. Generally speaking, if there is a single possible entry in a given table, and loading that table in the static config is mandatory as per the documentation, then the VALIDENT bit is deemed as redundant and more than likely not implemented.
So it is time to make the workaround more official, and add a bit to the flags implemented by dynamic config tables. It will be used by more tables when SJA1110 support arrives.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v5.10.41, v5.10.40 |
|
#
ba61cf16 |
| 24-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S
At the beginning of the sja1105_dynamic_config.c file there is a diagram of the dynamic config interface layout:
packed_buf
| V +--
net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S
At the beginning of the sja1105_dynamic_config.c file there is a diagram of the dynamic config interface layout:
packed_buf
| V +-----------------------------------------+------------------+ | ENTRY BUFFER | COMMAND BUFFER | +-----------------------------------------+------------------+
<----------------------- packed_size ------------------------>
So in order to pack/unpack the command bits into the buffer, sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by the length of the entry. This is similar to what the other *cmd_packing functions do.
This bug exists because the command packing function for P/Q/R/S was copied from the E/T generation, and on E/T, the command was actually embedded within the entry buffer itself.
Fixes: 94f94d4acfb2 ("net: dsa: sja1105: add static tables for virtual links") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
935c9443 |
| 24-May-2021 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S
commit ba61cf167cb77e54c1ec5adb7aa49a22ab3c9b28 upstream.
At the beginning of the sja1105_dynamic_config.c file there is a diagram of th
net: dsa: sja1105: fix VL lookup command packing for P/Q/R/S
commit ba61cf167cb77e54c1ec5adb7aa49a22ab3c9b28 upstream.
At the beginning of the sja1105_dynamic_config.c file there is a diagram of the dynamic config interface layout:
packed_buf
| V +-----------------------------------------+------------------+ | ENTRY BUFFER | COMMAND BUFFER | +-----------------------------------------+------------------+
<----------------------- packed_size ------------------------>
So in order to pack/unpack the command bits into the buffer, sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by the length of the entry. This is similar to what the other *cmd_packing functions do.
This bug exists because the command packing function for P/Q/R/S was copied from the E/T generation, and on E/T, the command was actually embedded within the entry buffer itself.
Fixes: 94f94d4acfb2 ("net: dsa: sja1105: add static tables for virtual links") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14 |
|
#
2b7fea0d |
| 03-Oct-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: remove duplicate prefix for VL Lookup dynamic config
This is a strictly cosmetic change that renames some macros in sja1105_dynamic_config.c. They were copy-pasted in haste and th
net: dsa: sja1105: remove duplicate prefix for VL Lookup dynamic config
This is a strictly cosmetic change that renames some macros in sja1105_dynamic_config.c. They were copy-pasted in haste and this has resulted in them having the driver prefix twice.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48 |
|
#
718e44b6 |
| 20-Jun-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: make config table operation structures constant
The per-chip instantiations of struct sja1105_table_ops and struct sja1105_dynamic_table_ops can be made constant, so do that.
Sig
net: dsa: sja1105: make config table operation structures constant
The per-chip instantiations of struct sja1105_table_ops and struct sja1105_dynamic_table_ops can be made constant, so do that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
be3fb56d |
| 20-Jun-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: remove empty structures from config table ops
Sparse is complaining and giving the following warning message: 'Using plain integer as NULL pointer'.
This is not what's going on,
net: dsa: sja1105: remove empty structures from config table ops
Sparse is complaining and giving the following warning message: 'Using plain integer as NULL pointer'.
This is not what's going on, instead {0} is used as a zero initializer for the structure members, to indicate that the particular chip revision does not support those particular config tables.
But since the config tables are declared globally, the unpopulated elements are zero-initialized anyway. So, to make sparse shut up, let's remove the zero initializers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7 |
|
#
99b981f4 |
| 30-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: fix port mirroring for P/Q/R/S
The dynamic configuration interface for the General Params and the L2 Lookup Params tables was copy-pasted between E/T devices and P/Q/R/S devices.
net: dsa: sja1105: fix port mirroring for P/Q/R/S
The dynamic configuration interface for the General Params and the L2 Lookup Params tables was copy-pasted between E/T devices and P/Q/R/S devices. Nonetheless, these interfaces are bitwise different.
The driver is using dynamic reconfiguration of the General Parameters table for the port mirroring feature, which was therefore broken on P/Q/R/S.
Note that this patch can't be backported easily very far to stable trees (since it conflicts with some other development done since the introduction of the driver). So the Fixes: tag is purely informational.
Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4d752508 |
| 27-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: offload the Credit-Based Shaper qdisc
SJA1105, being AVB/TSN switches, provide hardware assist for the Credit-Based Shaper as described in the IEEE 8021Q-2018 document.
First gen
net: dsa: sja1105: offload the Credit-Based Shaper qdisc
SJA1105, being AVB/TSN switches, provide hardware assist for the Credit-Based Shaper as described in the IEEE 8021Q-2018 document.
First generation has 10 shapers, freely assignable to any of the 4 external ports and 8 traffic classes, and second generation has 16 shapers.
The Credit-Based Shaper tables are accessed through the dynamic reconfiguration interface, so we have to restore them manually after a switch reset. The tables are backed up by the static config only on P/Q/R/S, and we don't want to add custom code only for that family, since the procedure that is in place now works for both.
Tested with the following commands:
data_rate_kbps=67000 port_transmit_rate_kbps=1000000 idleslope=$data_rate_kbps sendslope=$(($idleslope - $port_transmit_rate_kbps)) locredit=$((-0x80000000)) hicredit=$((0x7fffffff)) tc qdisc add dev swp2 root handle 1: mqprio hw 0 num_tc 8 \ map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 tc qdisc replace dev swp2 parent 1:1 cbs \ idleslope $idleslope \ sendslope $sendslope \ hicredit $hicredit \ locredit $locredit \ offload 1
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.43, v5.4.42, v5.4.41 |
|
#
88cac0fa |
| 12-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add packing ops for the Retagging Table
The Retagging Table is an optional feature that allows the switch to match frames against a {ingress port, egress port, vid} rule and chang
net: dsa: sja1105: add packing ops for the Retagging Table
The Retagging Table is an optional feature that allows the switch to match frames against a {ingress port, egress port, vid} rule and change their VLAN ID. The retagged frames are by default clones of the original ones (since the hardware-foreseen use case was to mirror traffic for debugging purposes and to tag it with a special VLAN for this purpose), but we can force the original frames to be dropped by removing the pre-retagging VLAN from the port membership list of the egress port.
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>
show more ...
|
Revision tags: v5.4.40, v5.4.39 |
|
#
94f94d4a |
| 05-May-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: add static tables for virtual links
This patch adds the register definitions for the: - VL Lookup Table - VL Policing Table - VL Forwarding Table - VL Forwarding Parameters Table
net: dsa: sja1105: add static tables for virtual links
This patch adds the register definitions for the: - VL Lookup Table - VL Policing Table - VL Forwarding Table - VL Forwarding Parameters Table
These are needed in order to perform TTEthernet operations: QoS classification, flow-based policing and/or frame redirecting with the switch.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28 |
|
#
0a7e984c |
| 23-Mar-2020 |
Vladimir Oltean <vladimir.oltean@nxp.com> |
net: dsa: sja1105: make the AVB table dynamically reconfigurable
The AVB table contains the CAS_MASTER field (to be added in the next patch) which decides the direction of the PTP_CLK pin.
Reconfig
net: dsa: sja1105: make the AVB table dynamically reconfigurable
The AVB table contains the CAS_MASTER field (to be added in the next patch) which decides the direction of the PTP_CLK pin.
Reconfiguring this field dynamically is highly preferable to having to reset the switch and upload a new static configuration, so we add support for exactly that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3 |
|
#
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 se
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>
show more ...
|
Revision tags: v5.3.2, v5.3.1, v5.3 |
|
#
7f1e4ba8 |
| 14-Sep-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Add static config tables for scheduling
In order to support tc-taprio offload, the TTEthernet egress scheduling core registers must be made visible through the static interface.
net: dsa: sja1105: Add static config tables for scheduling
In order to support tc-taprio offload, the TTEthernet egress scheduling core registers must be made visible through the static interface.
Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7 |
|
#
4b7da3d8 |
| 04-Aug-2019 |
Vladimir Oltean <olteanv@gmail.com> |
net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as well
It looks like the FDB dump taken from first-generation switches also contains information on whether entries are static or not. So use
net: dsa: sja1105: Use the LOCKEDS bit for SJA1105 E/T as well
It looks like the FDB dump taken from first-generation switches also contains information on whether entries are static or not. So use that instead of searching through the driver's tables.
Fixes: d763778224ea ("net: dsa: sja1105: Implement is_static for FDB entries on E/T") Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|