Received: by 2002:ab2:7855:0:b0:1f9:5764:f03e with SMTP id m21csp378628lqp; Wed, 22 May 2024 07:18:13 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVDAip0DUfSLQqKyG+AJKO3gMLoSwbWESPe+81ZEopZ0w0vnS3RJT2LbVUAD7KP4tcBeSObuOvfBf56nJVfYff7e4exYFlAaOe8n5kLAw== X-Google-Smtp-Source: AGHT+IFxeKYS/igECjdImF4Ce3rr9DL8H4wHH1GIlNB7qRsbk8IHO1INGCCnS1tMa+JGvFAFvotw X-Received: by 2002:a17:907:6d07:b0:a60:3fc8:bd9d with SMTP id a640c23a62f3a-a603fc8bf9dmr1035529866b.0.1716387493273; Wed, 22 May 2024 07:18:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716387493; cv=pass; d=google.com; s=arc-20160816; b=AcsL831w1Y3prNI+9rCszSYCsIZsmqu+lKGiJB2vUejcx8oXLbIXvQAjkvfkmihFpn fwOni9ywCgmwlAvsQWrjRwQvykw6giCC/AbWhv3pTSg7/jHOqZkTiIJLXlLluSb3FdzH iC/swrpepXXsao/BdJVhhYAQkeeoJAJBCPz92DhjovajuPiLlq0DYUospXfqDM3ce7IV LsZuXsJcKEPj0F9Mne4MhCzaSjt+PrpQ1aWIK6uX5QnG0DHQ5XcBMs19CN5tZPpshXgc 7VzKZLqu48i4AJXyN6x9qSF+w8TMnvVvtBAMmswAV0h799HVsLr7Ui89YPQF8vg5fii8 FIRQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature:dkim-signature; bh=Tfl546IBEO0vet18Oqldr0Tv/R1S/y+SQ3XW1zcejQQ=; fh=P3sMAbFRIkWBmPB0o0w75mawDZ6JyCZpMjJ0oYP1Rdc=; b=oZbwJZ+N0ZeXYQ5xVafU9cKbJ6AOz8G7h9AgTifQ9snYK427ll6bc6Mo4gahSsIDQP 9xYS3QVXW7Dc/nRmuUOvsu9kkMj+HVVgZ5dNvSnDakr0bv7qcGpHhNJYJzaxKryUVoPM HdijevO+lKKIoMuMwk4PHgCrue7+SrO8aUv36G7N9cQA9hBRV/mjKdBF8GLkqY1GRApZ qq4iTZEjqHJVdggDrB3Ms4s1mtqKL6cjzOmV7iEJ+VERL8UYw9KyxQTNxcsAnRnxXrNG Sb6KzAfhhGif+gDNQCm7xG6xXvNCaCE00H1Tv3yISzOnZySZCD9YwxL9R6SL1G+QkNdR bhow==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b="Nf6M/LLo"; dkim=temperror (no key for signature) header.i=@ew.tq-group.com header.s=dkim header.b=GS141UtJ; arc=pass (i=1 spf=pass spfdomain=ew.tq-group.com dkim=pass dkdomain=tq-group.com dmarc=pass fromdomain=ew.tq-group.com); spf=pass (google.com: domain of linux-kernel+bounces-186345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186345-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id a640c23a62f3a-a5a7c7f7122si1040117266b.175.2024.05.22.07.18.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 May 2024 07:18:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-186345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b="Nf6M/LLo"; dkim=temperror (no key for signature) header.i=@ew.tq-group.com header.s=dkim header.b=GS141UtJ; arc=pass (i=1 spf=pass spfdomain=ew.tq-group.com dkim=pass dkdomain=tq-group.com dmarc=pass fromdomain=ew.tq-group.com); spf=pass (google.com: domain of linux-kernel+bounces-186345-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-186345-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tq-group.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id D0AE91F223F6 for ; Wed, 22 May 2024 14:18:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EBD8C146A80; Wed, 22 May 2024 14:16:29 +0000 (UTC) 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" 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 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: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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 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) -- 2.34.1