linux-kernel - [PATCH 08/16] spi: bcm63xx-hsspi: Handle cs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230106200809.330769-9-william.zhang@broadcom.com>
Date:   Fri,  6 Jan 2023 12:08:00 -0800
From:   William Zhang <william.zhang@...adcom.com>
To:     Linux SPI List <linux-spi@...r.kernel.org>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>
Cc:     anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
        dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
        f.fainelli@...il.com, jonas.gorski@...il.com,
        kursad.oney@...adcom.com, dregan@...l.com,
        William Zhang <william.zhang@...adcom.com>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org
Subject: [PATCH 08/16] spi: bcm63xx-hsspi: Handle cs_change correctly

The kernel SPI interface includes the cs_change flag that alters how
the CS behaves.

If we're in the middle of transfers, it tells us to unselect the
CS momentarily since the target device requires that.

If we're at the end of a transfer, it tells us to keep the CS
selected, perhaps because the next transfer is likely targeted
to the same device.

We implement this scheme in the HSSPI driver in this change.

Prior to this change, the CS would toggle momentarily if cs_change
was set for the last transfer. This can be ignored by some or
most devices, but the Microchip TPM2 device does not ignore it.

With the change, the behavior is corrected and the 'glitch' is
eliminated.

Signed-off-by: Kursad Oney <kursad.oney@...adcom.com>
Signed-off-by: William Zhang <william.zhang@...adcom.com>
---

 drivers/spi/spi-bcm63xx-hsspi.c | 28 +++++++++++++++++++++-------
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-bcm63xx-hsspi.c b/drivers/spi/spi-bcm63xx-hsspi.c
index 2b4cdf7e7002..f2b1b83bd6d4 100644
--- a/drivers/spi/spi-bcm63xx-hsspi.c
+++ b/drivers/spi/spi-bcm63xx-hsspi.c
@@ -290,6 +290,7 @@ static int bcm63xx_hsspi_transfer_one(struct spi_master *master,
 	int status = -EINVAL;
 	int dummy_cs;
 	u32 reg;
+	bool restore_polarity = true;
 
 	/* This controller does not support keeping CS active during idle.
 	 * To work around this, we use the following ugly hack:
@@ -317,16 +318,29 @@ static int bcm63xx_hsspi_transfer_one(struct spi_master *master,
 
 		spi_transfer_delay_exec(t);
 
-		if (t->cs_change)
+		/*
+		 * cs_change rules:
+		 * (1) cs_change = 0 && last_xfer = 0:
+		 *     Do not touch the CS. On to the next xfer.
+		 * (2) cs_change = 1 && last_xfer = 0:
+		 *     Set cs = false before the next xfer.
+		 * (3) cs_change = 0 && last_xfer = 1:
+		 *     We want CS to be deactivated. So do NOT set cs = false,
+		 *     instead just restore the original polarity. This has the
+		 *     same effect of deactivating the CS.
+		 * (4) cs_change = 1 && last_xfer = 1:
+		 *     We want to keep CS active. So do NOT set cs = false, and
+		 *     make sure we do NOT reverse polarity.
+		 */
+		if (t->cs_change && !list_is_last(&t->transfer_list, &msg->transfers))
 			bcm63xx_hsspi_set_cs(bs, spi->chip_select, false);
+
+		restore_polarity = !t->cs_change;
 	}
 
-	mutex_lock(&bs->bus_mutex);
-	reg = __raw_readl(bs->regs + HSSPI_GLOBAL_CTRL_REG);
-	reg &= ~GLOBAL_CTRL_CS_POLARITY_MASK;
-	reg |= bs->cs_polarity;
-	__raw_writel(reg, bs->regs + HSSPI_GLOBAL_CTRL_REG);
-	mutex_unlock(&bs->bus_mutex);
+	bcm63xx_hsspi_set_cs(bs, dummy_cs, false);
+	if (restore_polarity)
+		bcm63xx_hsspi_set_cs(bs, spi->chip_select, false);
 
 	msg->status = status;
 	spi_finalize_current_message(master);
-- 
2.37.3