From patchwork Wed May 22 14:15:22 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gregor Herburger X-Patchwork-Id: 13670895 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 046B81465BC; Wed, 22 May 2024 14:16:25 +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=1716387388; cv=none; b=jtj9XvWG9Is2zz6krmYcyCfzTCfZg+VZZ7+hHaHsnVQQUWOp2T2MIv+gZdyqtQU/dgUceMDZ5ENCZ9ZemFs8Yd1UbhhzKLW/ylF5wZIK4cvSfXn4ECDpjw1VyX/0eKG056SzrQ/wN1EjmXhrmmkm+2wULsscicrokmzPViD816g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716387388; c=relaxed/simple; bh=OdhOxUxo6ws9OuAq8sK1Pr2/qxC9hnnL2HWfoYkL7n4=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=iRzMZ71jEwGq2AV28vbC+k7XF6qnukN7YVpZv9qWuYQ2l1ToHVJnXTOx5SYvrTFiFfK6R4WyDDeyTz1h4FAg80cEixdqH8jvbfHGzLHIFQKaifA9h8NZKwXLAyGgtMKE29olLdX9kPoCVXSuUguoNGKbayS6Z3dhYjc3+j/UHdg= 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=Nf6M/LLo; dkim=fail (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b=GS141UtJ 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="Nf6M/LLo"; 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="GS141UtJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tq-group.com; i=@tq-group.com; q=dns/txt; s=key1; t=1716387386; x=1747923386; h=from:date:subject:mime-version:content-transfer-encoding: message-id:references:in-reply-to:to:cc; bh=Tfl546IBEO0vet18Oqldr0Tv/R1S/y+SQ3XW1zcejQQ=; b=Nf6M/LLos4rk93AI+2jf+Ln7OEHrAScS8iVqexjfFm2SifMJzSQLwH/Q UY5B5iYfp8VO71BaZNRtIRJfKQX5u3FNJhnF2513B8xtTBwi4PFSzKVyu ecSDDeYwHsKo0Y2vQr/aZY5H5MPIcn73VnHHDo7G78qBvRXtU0XWItOVZ 5oHlAXv5d+BSLWaSFhTv+kfOdSQjjACPEnqzFQo+zcwXW0Jki4/qN1ggj hITW3cAzwCqqQXuFWG9Aga2BMYUMC4XwLejn8Ttzoz//z4BCxSrlf90X/ tIwAy0dCy9dO6xyowTdm9VJHT4F2bqOg5WgW50tP7kz/9W+/bSsAZXV9o A==; X-CSE-ConnectionGUID: YscveGJETPKoKKC02xgTrw== X-CSE-MsgGUID: qIXnQMSRSsCRi8qGq4gpsA== X-IronPort-AV: E=Sophos;i="6.08,179,1712613600"; d="scan'208";a="37017670" Received: from vmailcow01.tq-net.de ([10.150.86.48]) by mx1.tq-group.com with ESMTP; 22 May 2024 16:16:25 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B1E6D16EB93; Wed, 22 May 2024 16:16:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ew.tq-group.com; s=dkim; t=1716387381; 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=GS141UtJWRF7b9LDZItkIkySgedCFGLNt41g4GhJLCUQ+0GqYXPcZRaeAMRbos4yMGqZiC 6s6M1GbEZf+gtluGNY7LhVxNPAJRuJv51OT4G/xYzpOM0wSFk/GuqA2AkOFXnVI8yLeYTA i/hTqrRstes/1LxvprkBG7rKJeX0nOUprmbvwKBCLBtArjNhjc4UqfB4pkMDKeNXM8s2Em PERmcKYyoH8p/zQyUv35rj3DUh4m+YlYnVbLkTjabecgG/aawWHvWsohUoaViTSMqozhaJ DLWoMhZlpVPHw7YElVkhYDP/z/FQ20/V4D4zdzkLCdXLdGLAuXOqPfU62DeVmw== From: Gregor Herburger Date: Wed, 22 May 2024 16:15:22 +0200 Subject: [PATCH RESEND 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: <20240522-mcp251xfd-gpio-feature-v3-5-8829970269c5@ew.tq-group.com> References: <20240522-mcp251xfd-gpio-feature-v3-0-8829970269c5@ew.tq-group.com> In-Reply-To: <20240522-mcp251xfd-gpio-feature-v3-0-8829970269c5@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, Linus Walleij , Bartosz Golaszewski X-Mailer: b4 0.13.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1716387339; l=4963; i=gregor.herburger@ew.tq-group.com; s=20230829; h=from:subject:message-id; bh=OdhOxUxo6ws9OuAq8sK1Pr2/qxC9hnnL2HWfoYkL7n4=; b=2Jt1DkoJabD9/x+UPAGxL2RWxThooUt+IDplIvifNuLCKJOk24ecuJlX1ReCIv0FEzu2g7tGk 0zV0P6oF8i3Be6mpLVn7S1b9CWq0g22EqtBK3dvulvRX4OLdVZ0eSv7 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)