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>
Showing
Please register or sign in to comment