All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: [PATCH net-next 08/13] net: dsa: sja1105: some table entries are always present when read dynamically
Date: Tue, 25 May 2021 02:22:09 +0300	[thread overview]
Message-ID: <20210524232214.1378937-9-olteanv@gmail.com> (raw)
In-Reply-To: <20210524232214.1378937-1-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean@nxp.com>

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>
---
 drivers/net/dsa/sja1105/sja1105_dynamic_config.c | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
index 12cd04b56803..ff2742f53de3 100644
--- a/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
+++ b/drivers/net/dsa/sja1105/sja1105_dynamic_config.c
@@ -78,6 +78,9 @@
  *		   on its ENTRY portion, as a result of a SPI write command.
  *		   Only the TCAM-based FDB table on SJA1105 P/Q/R/S supports
  *		   this.
+ *	OP_VALID_ANYWAY: Reading some tables through the dynamic config
+ *			 interface is possible even if the VALIDENT bit is not
+ *			 set in the writeback. So don't error out in that case.
  * - .max_entry_count: The number of entries, counting from zero, that can be
  *		       reconfigured through the dynamic interface. If a static
  *		       table can be reconfigured at all dynamically, this
@@ -651,6 +654,7 @@ static size_t sja1105pqrs_cbs_entry_packing(void *buf, void *entry_ptr,
 #define OP_WRITE	BIT(1)
 #define OP_DEL		BIT(2)
 #define OP_SEARCH	BIT(3)
+#define OP_VALID_ANYWAY	BIT(4)
 
 /* SJA1105E/T: First generation */
 const struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
@@ -673,7 +677,7 @@ const struct sja1105_dynamic_table_ops sja1105et_dyn_ops[BLK_IDX_MAX_DYN] = {
 	[BLK_IDX_MGMT_ROUTE] = {
 		.entry_packing = sja1105et_mgmt_route_entry_packing,
 		.cmd_packing = sja1105et_mgmt_route_cmd_packing,
-		.access = (OP_READ | OP_WRITE),
+		.access = (OP_READ | OP_WRITE | OP_VALID_ANYWAY),
 		.max_entry_count = SJA1105_NUM_PORTS,
 		.packed_size = SJA1105ET_SIZE_L2_LOOKUP_DYN_CMD,
 		.addr = 0x20,
@@ -757,7 +761,7 @@ const struct sja1105_dynamic_table_ops sja1105pqrs_dyn_ops[BLK_IDX_MAX_DYN] = {
 	[BLK_IDX_MGMT_ROUTE] = {
 		.entry_packing = sja1105pqrs_mgmt_route_entry_packing,
 		.cmd_packing = sja1105pqrs_mgmt_route_cmd_packing,
-		.access = (OP_READ | OP_WRITE | OP_DEL | OP_SEARCH),
+		.access = (OP_READ | OP_WRITE | OP_DEL | OP_SEARCH | OP_VALID_ANYWAY),
 		.max_entry_count = SJA1105_NUM_PORTS,
 		.packed_size = SJA1105PQRS_SIZE_L2_LOOKUP_DYN_CMD,
 		.addr = 0x24,
@@ -911,11 +915,8 @@ int sja1105_dynamic_config_read(struct sja1105_private *priv,
 
 		cmd = (struct sja1105_dyn_cmd) {0};
 		ops->cmd_packing(packed_buf, &cmd, UNPACK);
-		/* UM10944: [valident] will always be found cleared
-		 * during a read access with MGMTROUTE set.
-		 * So don't error out in that case.
-		 */
-		if (!cmd.valident && blk_idx != BLK_IDX_MGMT_ROUTE)
+
+		if (!cmd.valident && !(ops->access & OP_VALID_ANYWAY))
 			return -ENOENT;
 		cpu_relax();
 	} while (cmd.valid && --retries);
-- 
2.25.1


  parent reply	other threads:[~2021-05-24 23:22 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 23:22 [PATCH net-next 00/13] Add NXP SJA1110 support to the sja1105 DSA driver Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 01/13] net: dsa: sja1105: be compatible with "ethernet-ports" OF node name Vladimir Oltean
2021-05-25  2:13   ` Florian Fainelli
2021-05-24 23:22 ` [PATCH net-next 02/13] net: dsa: sja1105: allow SGMII PCS configuration to be per port Vladimir Oltean
2021-05-25  2:16   ` Florian Fainelli
2021-05-26 12:39     ` Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 03/13] net: dsa: sja1105: the 0x1F0000 SGMII "base address" is actually MDIO_MMD_VEND2 Vladimir Oltean
2021-05-25  2:19   ` Florian Fainelli
2021-05-25  9:12     ` Vladimir Oltean
2021-05-25  2:40   ` Andrew Lunn
2021-05-24 23:22 ` [PATCH net-next 04/13] net: dsa: sja1105: cache the phy-mode port property Vladimir Oltean
2021-05-25  2:19   ` Florian Fainelli
2021-05-24 23:22 ` [PATCH net-next 05/13] net: dsa: sja1105: add a PHY interface type compatibility matrix Vladimir Oltean
2021-05-25  2:23   ` Florian Fainelli
2021-05-26 12:37     ` Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 06/13] net: dsa: sja1105: add a translation table for port speeds Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 07/13] net: dsa: sja1105: always keep RGMII ports in the MAC role Vladimir Oltean
2021-05-25  2:24   ` Florian Fainelli
2021-05-24 23:22 ` Vladimir Oltean [this message]
2021-05-24 23:22 ` [PATCH net-next 09/13] dt-bindings: net: dsa: sja1105: add compatible strings for SJA1110 Vladimir Oltean
2021-05-25  2:24   ` Florian Fainelli
2021-05-25 11:57     ` Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 10/13] net: dsa: sja1105: add support for the SJA1110 switch family Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 11/13] net: dsa: sja1105: register the MDIO buses for 100base-T1 and 100base-TX Vladimir Oltean
2021-05-25  2:18   ` Andrew Lunn
2021-05-25 11:54     ` Vladimir Oltean
2021-05-25 13:16       ` Andrew Lunn
2021-05-25 13:21         ` Vladimir Oltean
2021-05-25 13:43           ` Andrew Lunn
2021-05-26 11:52             ` Vladimir Oltean
2021-05-25  2:27   ` Florian Fainelli
2021-05-24 23:22 ` [PATCH net-next 12/13] net: dsa: sja1105: expose the SGMII PCS as an mdio_device Vladimir Oltean
2021-05-25  2:33   ` Andrew Lunn
2021-05-25  2:35   ` Florian Fainelli
2021-05-25 11:50     ` Vladimir Oltean
2021-05-24 23:22 ` [PATCH net-next 13/13] net: dsa: sja1105: add support for the SJA1110 SGMII/2500base-x PCS Vladimir Oltean
2021-05-25  2:39   ` Florian Fainelli
2021-05-25 11:47     ` Vladimir Oltean
2021-05-25  2:03 ` [PATCH net-next 00/13] Add NXP SJA1110 support to the sja1105 DSA driver Andrew Lunn
2021-05-26 12:51   ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210524232214.1378937-9-olteanv@gmail.com \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.