summaryrefslogtreecommitdiff
path: root/drivers/thunderbolt/tb_regs.h
diff options
context:
space:
mode:
authorMika Westerberg <mika.westerberg@linux.intel.com>2020-11-10 11:34:07 +0300
committerMika Westerberg <mika.westerberg@linux.intel.com>2020-11-30 14:39:24 +0300
commit661b19473bf3ac0924560f0cbf84c15458b3c8de (patch)
tree32a36bb669b6a4bc3536f3386107a2853a01ec6e /drivers/thunderbolt/tb_regs.h
parent463e48fa544826898791085508459de246fc4c09 (diff)
downloadlinux-661b19473bf3ac0924560f0cbf84c15458b3c8de.tar.xz
thunderbolt: Perform USB4 router NVM upgrade in two phases
The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Diffstat (limited to 'drivers/thunderbolt/tb_regs.h')
-rw-r--r--drivers/thunderbolt/tb_regs.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/drivers/thunderbolt/tb_regs.h b/drivers/thunderbolt/tb_regs.h
index e7d9529822fa..67cb173a2f8e 100644
--- a/drivers/thunderbolt/tb_regs.h
+++ b/drivers/thunderbolt/tb_regs.h
@@ -211,6 +211,7 @@ struct tb_regs_switch_header {
#define ROUTER_CS_9 0x09
#define ROUTER_CS_25 0x19
#define ROUTER_CS_26 0x1a
+#define ROUTER_CS_26_OPCODE_MASK GENMASK(15, 0)
#define ROUTER_CS_26_STATUS_MASK GENMASK(29, 24)
#define ROUTER_CS_26_STATUS_SHIFT 24
#define ROUTER_CS_26_ONS BIT(30)