From patchwork Tue May 21 13:04:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gregor Herburger X-Patchwork-Id: 13669422 X-Patchwork-Delegate: kuba@kernel.org Received: from mx1.tq-group.com (mx1.tq-group.com [93.104.207.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D82D7D3EC; Tue, 21 May 2024 13:05:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.104.207.81 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716296751; cv=none; b=YIY3hb8tALTgPt21ZlA0jTN0IJgqFCmyEg05M/gcBi21IBZdEdoilJ4SAISMvFhSDJ3ibwskv33yjpXb/5jTlXaTswO/7wt5dBozXWtcfdZxuHOXg+OTA2/97idxz1IHH0f60Xv8wWMzUMXnlvsiHu96zdLuBdGZsuVpqfeYw+c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716296751; c=relaxed/simple; bh=OdhOxUxo6ws9OuAq8sK1Pr2/qxC9hnnL2HWfoYkL7n4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=Z2kw0UReWo+8f5hatDLhn9tj8sbQGTsbEVZhRn+l4U15d4si1PAfNeFN/lAQnYU0tEbrbb9By2GvUpTKP8mmg9XPMop4Ocukt2uSgp3ide/zhoawklVOULjW1rCxy6incPMV+/gWysdmcmRzd0lTFRrCpaPCi6k3Z6suLgHu64g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ew.tq-group.com; spf=pass smtp.mailfrom=ew.tq-group.com; dkim=pass (2048-bit key) header.d=tq-group.com header.i=@tq-group.com header.b=V2lUAA5I; dkim=fail (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b=DzZgQUMf reason="key not found in DNS"; arc=none smtp.client-ip=93.104.207.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ew.tq-group.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=tq-group.com header.i=@tq-group.com header.b="V2lUAA5I"; dkim=fail reason="key not found in DNS" (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b="DzZgQUMf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1716296750; x=1747832750; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=Tfl546IBEO0vet18Oqldr0Tv/R1S/y+SQ3XW1zcejQQ=; b=V2lUAA5IZZj8uBgUcj3WVoGF/kAIU/z68knS1xDcbxXNsp4bXD4MrAwI m9lXeZ3v7d3hTbspnJfD8UtxGBLlg07F8w5ImmcXLn378zAKtL1r8oRMC G/TEhLRXx0wbIhxpyboKXzetNqntJleW18QI/wALkYOlJV7hrHmoJr2p4 TaiHrXwYZ6RWrGpyNxebhoRLwtMIfANziAkgcYHm+kI1rrZ9hhtGyaqX3 Pa0g1K/usgEqYu9QEc340r44oAJTgcM4/c5/JTf4zMOn/WqNbsZlBugT1 qpR/5gH0nT2wqE7mnlOHSRPeJXJCZN6/iPF779G11iqnBCi/BEkaAsE9P w==; X-CSE-ConnectionGUID: pNvlLZ6xQ8SiPYwwrYRp6w== X-CSE-MsgGUID: v+mi9L5YQP+IrzSYsb9S4A== X-IronPort-AV: E=Sophos;i="6.08,177,1712613600"; d="scan'208";a="36993984" Received: from vmailcow01.tq-net.de ([10.150.86.48]) by mx1.tq-group.com with ESMTP; 21 May 2024 15:05:47 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 973B8175B94; Tue, 21 May 2024 15:05:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ew.tq-group.com; s=dkim; t=1716296743; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Tfl546IBEO0vet18Oqldr0Tv/R1S/y+SQ3XW1zcejQQ=; b=DzZgQUMfaY0zX3E4yXF/Vt7HY0+I3N9yTyuGQxbySCC6zJiTRgc8J08xTomxXg6Z4enBtq cwpE/z/bQPywLFcvypUm1Dk7iHi5D+694mTX66LAuGTtL/AcBpk/gRI3wmULjCewZSTaaD S/cbNBltg4VbYCTcBeapllzRrJ/vpcOb5jPPzvoZ5q0pXnlLdRa2h7nZQ4AZ1u6ruDVPzY 2xMN6JOk2Os8b/p9VCYD1dR80kT7sUgUSu9WrUQNT9XqhiBD9jNkxCb7tnuU6ZSN6vIv6N r7a02HLZ/IHbAiDZ15MKrdNch8doFMOXW2J3ZUW8IiliBsbvn1SdtXS/JC2Luw== From: Gregor Herburger Date: Tue, 21 May 2024 15:04:55 +0200 Subject: [PATCH v3 5/8] can: mcp251xfd: add workaround for errata 5 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Message-Id: <20240521-mcp251xfd-gpio-feature-v3-5-7f829fefefc2@ew.tq-group.com> References: <20240521-mcp251xfd-gpio-feature-v3-0-7f829fefefc2@ew.tq-group.com> In-Reply-To: <20240521-mcp251xfd-gpio-feature-v3-0-7f829fefefc2@ew.tq-group.com> To: Marc Kleine-Budde , Manivannan Sadhasivam , Thomas Kopp , Vincent Mailhol , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux@ew.tq-group.com, gregor.herburger@ew.tq-group.com X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1716296697; l=4963; i=gregor.herburger@ew.tq-group.com; s=20230829; h=from:subject:message-id; bh=OdhOxUxo6ws9OuAq8sK1Pr2/qxC9hnnL2HWfoYkL7n4=; b=V8Dvg7oaErmixrCyA+20gv9faPrzybKXgkaokJN8dVFQnjn/vW3hKKhl1S5aA2WGNWZ5ol5t3 RwGvhH25rP5Bj7hy2Cz/FWnsEfDXVnj/tRCuUEjTSC9RvDkcvz1k7Qn X-Developer-Key: i=gregor.herburger@ew.tq-group.com; a=ed25519; pk=+eRxwX7ikXwazcRjlOjj2/tbDmfVZdDLoW+xLZbQ4h4= X-Last-TLS-Session-Version: TLSv1.3 X-Patchwork-Delegate: kuba@kernel.org According to Errata DS80000789E 5 writing IOCON register using one SPI write command clears LAT0/LAT1. Errata Fix/Work Around suggests to write registers with single byte write instructions. However, it seems that every write to the second byte causes the overwrite of LAT0/LAT1. Never write byte 2 of IOCON register to avoid clearing of LAT0/LAT1. Signed-off-by: Gregor Herburger --- drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c | 89 ++++++++++++++++++++++-- 1 file changed, 83 insertions(+), 6 deletions(-) diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c index 52716cce73ec..8499a303ad77 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c @@ -13,9 +13,9 @@ static const struct regmap_config mcp251xfd_regmap_crc; static int -mcp251xfd_regmap_nocrc_gather_write(void *context, - const void *reg, size_t reg_len, - const void *val, size_t val_len) +_mcp251xfd_regmap_nocrc_gather_write(void *context, + const void *reg, size_t reg_len, + const void *val, size_t val_len) { struct spi_device *spi = context; struct mcp251xfd_priv *priv = spi_get_drvdata(spi); @@ -39,6 +39,45 @@ mcp251xfd_regmap_nocrc_gather_write(void *context, return spi_sync_transfer(spi, xfer, ARRAY_SIZE(xfer)); } +static int +mcp251xfd_regmap_nocrc_gather_write(void *context, + const void *reg_p, size_t reg_len, + const void *val, size_t val_len) +{ + const u16 byte_exclude = MCP251XFD_REG_IOCON + + mcp251xfd_first_byte_set(MCP251XFD_REG_IOCON_GPIO_MASK); + u16 reg = be16_to_cpu(*(u16 *)reg_p) & MCP251XFD_SPI_ADDRESS_MASK; + int ret; + + /* Never write to bits 16..23 of IOCON register to avoid clearing of LAT0/LAT1 + * + * According to MCP2518FD Errata DS80000789E 5 writing IOCON register using one + * SPI write command clears LAT0/LAT1. + * + * Errata Fix/Work Around suggests to write registers with single byte + * write instructions. However, it seems that the byte at 0xe06(IOCON[23:16]) + * is for read-only access and writing to it causes the clearing of LAT0/LAT1. + */ + if (reg <= byte_exclude && reg + val_len > byte_exclude) { + size_t len = byte_exclude - reg; + + /* Write up to 0xe05 */ + ret = _mcp251xfd_regmap_nocrc_gather_write(context, reg_p, reg_len, val, len); + if (ret) + return ret; + + /* Write from 0xe07 on */ + reg += len + 1; + reg = cpu_to_be16(MCP251XFD_SPI_INSTRUCTION_WRITE | reg); + return _mcp251xfd_regmap_nocrc_gather_write(context, ®, reg_len, + val + len + 1, + val_len - len - 1); + } + + return _mcp251xfd_regmap_nocrc_gather_write(context, reg_p, reg_len, + val, val_len); +} + static int mcp251xfd_regmap_nocrc_write(void *context, const void *data, size_t count) { @@ -197,9 +236,9 @@ mcp251xfd_regmap_nocrc_read(void *context, } static int -mcp251xfd_regmap_crc_gather_write(void *context, - const void *reg_p, size_t reg_len, - const void *val, size_t val_len) +_mcp251xfd_regmap_crc_gather_write(void *context, + const void *reg_p, size_t reg_len, + const void *val, size_t val_len) { struct spi_device *spi = context; struct mcp251xfd_priv *priv = spi_get_drvdata(spi); @@ -230,6 +269,44 @@ mcp251xfd_regmap_crc_gather_write(void *context, return spi_sync_transfer(spi, xfer, ARRAY_SIZE(xfer)); } +static int +mcp251xfd_regmap_crc_gather_write(void *context, + const void *reg_p, size_t reg_len, + const void *val, size_t val_len) +{ + const u16 byte_exclude = MCP251XFD_REG_IOCON + + mcp251xfd_first_byte_set(MCP251XFD_REG_IOCON_GPIO_MASK); + u16 reg = *(u16 *)reg_p; + int ret; + + /* Never write to bits 16..23 of IOCON register to avoid clearing of LAT0/LAT1 + * + * According to MCP2518FD Errata DS80000789E 5 writing IOCON register using one + * SPI write command clears LAT0/LAT1. + * + * Errata Fix/Work Around suggests to write registers with single byte + * write instructions. However, it seems that the byte at 0xe06(IOCON[23:16]) + * is for read-only access and writing to it causes the clearing of LAT0/LAT1. + */ + if (reg <= byte_exclude && reg + val_len > byte_exclude) { + size_t len = byte_exclude - reg; + + /* Write up to 0xe05 */ + ret = _mcp251xfd_regmap_crc_gather_write(context, ®, reg_len, val, len); + if (ret) + return ret; + + /* Write from 0xe07 on */ + reg += len + 1; + return _mcp251xfd_regmap_crc_gather_write(context, ®, reg_len, + val + len + 1, + val_len - len - 1); + } + + return _mcp251xfd_regmap_crc_gather_write(context, reg_p, reg_len, + val, val_len); +} + static int mcp251xfd_regmap_crc_write(void *context, const void *data, size_t count)