aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/cxgb4vf/t4vf_hw.c
diff options
context:
space:
mode:
Diffstat (limited to 'drivers/net/cxgb4vf/t4vf_hw.c')
-rw-r--r--drivers/net/cxgb4vf/t4vf_hw.c11
1 files changed, 11 insertions, 0 deletions
diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index e4bec78c8e3f..0f51c80475ce 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -147,9 +147,20 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
147 /* 147 /*
148 * Write the command array into the Mailbox Data register array and 148 * Write the command array into the Mailbox Data register array and
149 * transfer ownership of the mailbox to the firmware. 149 * transfer ownership of the mailbox to the firmware.
150 *
151 * For the VFs, the Mailbox Data "registers" are actually backed by
152 * T4's "MA" interface rather than PL Registers (as is the case for
153 * the PFs). Because these are in different coherency domains, the
154 * write to the VF's PL-register-backed Mailbox Control can race in
155 * front of the writes to the MA-backed VF Mailbox Data "registers".
156 * So we need to do a read-back on at least one byte of the VF Mailbox
157 * Data registers before doing the write to the VF Mailbox Control
158 * register.
150 */ 159 */
151 for (i = 0, p = cmd; i < size; i += 8) 160 for (i = 0, p = cmd; i < size; i += 8)
152 t4_write_reg64(adapter, mbox_data + i, be64_to_cpu(*p++)); 161 t4_write_reg64(adapter, mbox_data + i, be64_to_cpu(*p++));
162 t4_read_reg(adapter, mbox_data); /* flush write */
163
153 t4_write_reg(adapter, mbox_ctl, 164 t4_write_reg(adapter, mbox_ctl,
154 MBMSGVALID | MBOWNER(MBOX_OWNER_FW)); 165 MBMSGVALID | MBOWNER(MBOX_OWNER_FW));
155 t4_read_reg(adapter, mbox_ctl); /* flush write */ 166 t4_read_reg(adapter, mbox_ctl); /* flush write */