Received: by 2002:a89:48b:0:b0:1f5:f2ab:c469 with SMTP id a11csp886989lqd; Wed, 24 Apr 2024 22:37:41 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCW+tyh8AB7PrUjYccx1iLVCs58qeI1GnaLPbLDXJnUOSpu0L61Svm57Lq0wloZONQID4bqFK6myCHt3hbHFiCAm6qTqsmn2f6rIiSj/Qw== X-Google-Smtp-Source: AGHT+IFnwduZHzChVzVU6ynhlyld0o/JVBPiIlxhJ/ww+7/8mLC0xtwnnuoq/u8l3ANmSQuS4oVY X-Received: by 2002:a17:906:7c6:b0:a58:7aab:96bf with SMTP id m6-20020a17090607c600b00a587aab96bfmr2773713ejc.18.1714023461417; Wed, 24 Apr 2024 22:37:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1714023461; cv=pass; d=google.com; s=arc-20160816; b=ruzOz6azc4Didu7eiGn3+CtqWmmv+vuRg3vHqP6qg2TmddE86eVfIxsB4tunHN65Y/ F/qfwIgirp3jnuy+CzNo5cvb2xH8m28yn7skQBeacr498vnW//B/fJYOLLHeR6Nq0ZR8 JAg+jpTNtEkwHeDS8dULU6Ej0lwjccySRnjdL95dEGD1LNAi5h99NJtEJPlREu0D6Lh6 XFlI4tzQBmKErqpgN4yTQJHY4fXxq6BSZMjuf/OFP0M547hoNSJ9rzbo6WZEaEBA//TF b3uIJlBeMq0wAQNLtQ14DJSqhPQc0yby7cvHiDyk1ViAA6TL2G3Xi0XB5zQAEAkyBF8y qX0Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:cc:to:from:date:dkim-signature:subject :dkim-signature; bh=x2ZR+RxKM/yGV3UpXGKOOZBBDQ6YDdkkFSm5SsEI2O8=; fh=wDRQOH5oTle5I7CydnHz/zJHunFYfmAMb7VTbfZ+FQg=; b=V25hyjPS72ZwBtKP5YeSm3hx2eIM+A+wcrpXPEHmrmoVryQNCyxQSvIsX9Q35QKXoZ 6zUlNY0EVk+8J07pWmmB16kp47Ftjpgnm3nlcaU1blik/Ne4bAK6yssQEmxgPzkj5mpt 0tAX875THPR5tHuRslZHG8CJidbtDKsLynG2UJfltPW3DM9aZuBq2kqblvAEirpUrPeX dTN6OYaRO70bWYKn+jucjFmZU9sz+UojX+XsR3dPyTnCE5Ke6VrE3WJJYQR53wsEMdww bSfVta8d4PILYMj+up4jDShifxYI3FqX2xiqUNpbn2j8S1CEbLtspg7s4oIuR+yUlQlX ZAjA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@tq-group.com header.s=key1 header.b=WbKBXPKZ; dkim=temperror (no key for signature) header.i=@ew.tq-group.com header.s=dkim header.b=O44VQT3J; 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-158027-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158027-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 b3-20020a17090630c300b00a51a6bf356csi9405618ejb.4.2024.04.24.22.37.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 22:37:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-158027-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=WbKBXPKZ; dkim=temperror (no key for signature) header.i=@ew.tq-group.com header.s=dkim header.b=O44VQT3J; 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-158027-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-158027-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 01B2C1F22484 for ; Thu, 25 Apr 2024 05:37:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2813F3C099; Thu, 25 Apr 2024 05:37:28 +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="WbKBXPKZ"; 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="O44VQT3J" 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 183662B9C8; Thu, 25 Apr 2024 05:37:21 +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=1714023447; cv=none; b=FnuB+l0DtaBP7z6hDyrUfv3UfKws3GU0mVJgXRNr6M4XfK2gyJVcs8aSN6DuAeiJSoS3Cwl9g5Mg9UurrzBZ49qOyNSZLmZgsJoKuoUuMZadQ9kV0ffcECl+ACrtQK+dlxTGwQCR4w7PLqI7lu3WsoGiM9+NFIcNg9Dcau84R0M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714023447; c=relaxed/simple; bh=jZmOl3rou60PlMW9u4r/ORdM+/lfAajXL/HWXhh7L48=; h=Subject:Date:From:To:Cc:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CaYtHfOetoy5VDjhFDS6ze1DZbNC43eRThD9xfSFsPjqV8uDPlN2uRfPpLSm2REpRb1pak7LNaUX9g6yU1O19nqUZ71Q1+4dhbjGU6xG01zF63xy/6y/BeLrtFQKA/DYPlZn1uFnU1EwXwSuCI+mbWJx+PJ/0l2mgy0y4Sqws04= 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=WbKBXPKZ; dkim=fail (0-bit key) header.d=ew.tq-group.com header.i=@ew.tq-group.com header.b=O44VQT3J 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=1714023443; x=1745559443; h=date:from:to:cc:message-id:references:mime-version: content-transfer-encoding:in-reply-to:subject; bh=x2ZR+RxKM/yGV3UpXGKOOZBBDQ6YDdkkFSm5SsEI2O8=; b=WbKBXPKZB2soyiaMmER/UYom8cLLZCEJpl3uQfNz4i7PSZj9GQNNReOc ToSAaBGu8x27me6IbYbUPGAzug7mRv8ZJAmpDeNoYQOy+ux0TjcKBIhjy A+LdduWDIjxKWrVcmtWMBuqw+G8C7Io/HgZEi39rCrTLn3bZ8PnBC7JVG F0qSkjsKFGV5FERFrvmlj/E351v/QSJE0Ecpz6ZGESIU0+ZE4XbMzUA86 Dpiy0bmeSBNoW6dMf4Mswb3X4dwfE5NcLkPw27v3IXVz4QAT6TBYhyI8L 6QcDbiNdinSRI03HC/hCEdisr6diwQ5/WszswvWNlDHP/4WQpIijxgyRA Q==; X-IronPort-AV: E=Sophos;i="6.07,228,1708383600"; d="scan'208";a="36602691" Subject: Re: Re: [PATCH 2/4] can: mcp251xfd: mcp251xfd_regmap_crc_write(): workaround for errata 5 Received: from vmailcow01.tq-net.de ([10.150.86.48]) by mx1.tq-group.com with ESMTP; 25 Apr 2024 07:37:19 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id BBEC71754C3; Thu, 25 Apr 2024 07:37:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ew.tq-group.com; s=dkim; t=1714023435; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=x2ZR+RxKM/yGV3UpXGKOOZBBDQ6YDdkkFSm5SsEI2O8=; b=O44VQT3J6MtRj/ezPHG1zEQv2dl16x3f0IgUHHEGLhP9MW1QNn3QXnJ0+YzTqor4N5juyH vKdoWzxDDywAOTvHeObegS838YXIKrgRuvduVoOlL73AOFj74+N90o2dHuYmVpU6rO9fsB mm23DiqbyxnV5/o2DU/lRUlaYwgBU5cqwobBXnyMtIGPDSI2Mnb6gTKxFYLFAdkemRdz8R iILPRW8JT9hJWNvPFOMaU4lfHe58zi6r9r4lmWbTLVVETDonbWn1qIFNjvy4W5vfEb2Lle GjFGSvONhFL8KYgpRqaBYemFrjT0Q0Ed+FImsXcgrokCeHz5wPF5H/d8AwJ21Q== Date: Thu, 25 Apr 2024 07:37:13 +0200 From: Gregor Herburger To: Marc Kleine-Budde Cc: Manivannan Sadhasivam , Thomas Kopp , Vincent Mailhol , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux@ew.tq-group.com, alexander.stein@ew.tq-group.com Message-ID: References: <20240417-mcp251xfd-gpio-feature-v1-0-bc0c61fd0c80@ew.tq-group.com> <20240417-mcp251xfd-gpio-feature-v1-2-bc0c61fd0c80@ew.tq-group.com> <20240424-worm-of-massive-triumph-2eaf27-mkl@pengutronix.de> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240424-worm-of-massive-triumph-2eaf27-mkl@pengutronix.de> X-Last-TLS-Session-Version: TLSv1.3 On Wed, Apr 24, 2024 at 01:51:37PM +0200, Marc Kleine-Budde wrote: > On 17.04.2024 15:43:55, Gregor Herburger wrote: > > 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 overrite of LAT0/LAT1. > > This change doesn't use single byte write instructions. Yes, because this is not necessary. Single byte write instructions wont't fix the problem. The microchip errata sheet is wrong or at least misleading expressed. From my observation single byte insctructions won't fix the problem. No write to bits [16:24] does fix the problem. I talked to Thomas Kopp from Microchip about that and he confirmed my observations. > > > Never write byte 2 of IOCON register to avoid clearing of LAT0/LAT1. > > I discovered that erratum, it's described in > mcp251xfd_chip_rx_int_enable(): > > /* Configure GPIOs: > * - PIN0: GPIO Input > * - PIN1: GPIO Input/RX Interrupt > * > * PIN1 must be Input, otherwise there is a glitch on the > * rx-INT line. It happens between setting the PIN as output > * (in the first byte of the SPI transfer) and configuring the > * PIN as interrupt (in the last byte of the SPI transfer). > */ > > The problem is that the SPI writes 1 byte at a time, starting at the > lower address. The chip updates the GPIO pin's status after each written > byte. > > This may leads to a glitch if you have an external pull up. The power on > default auf the chip is GPIO/input, the GPIO line is not driven by the > chip and with the external pull up this will result in a high level. > > If you configure the GPIO as an output/high, the driver first writes > bits 0...7, which results in the GPIO line being configured as an > output; the subsequent bits 8...15 configure the level of the GPIO > line. > > This change doesn't take care of this. I'm not sure if this is the same problem. Anyway, with this fix we didn't see any glitches on the gpio lines. > > I'm not sure, if it's better to have 2 dedicated writes to IOCON in the > driver or try to hide it here in the regmap. What would be the alternative? Maybe add a mcp251xfd_write_iocon function to the driver and call there regmap_update_bits twice? > > > Signed-off-by: Gregor Herburger > > --- > > drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c | 35 +++++++++++++++++++++++- > > 1 file changed, 34 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c > > index 92b7bc7f14b9..ab4e372baffb 100644 > > --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c > > +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-regmap.c > > @@ -229,14 +229,47 @@ mcp251xfd_regmap_crc_gather_write(void *context, > > return spi_sync_transfer(spi, xfer, ARRAY_SIZE(xfer)); > > } > > > > +static int > > +mcp251xfd_regmap_crc_write_iocon(void *context, const void *data, size_t count) > > +{ > > + const size_t data_offset = sizeof(__be16) + > > + mcp251xfd_regmap_crc.pad_bits / BITS_PER_BYTE; > > + u16 reg = *(u16 *)data; > > + > > + /* Never write to bits 16..23 of IOCON register to avoid clearing of LAT0/LAT1 > > + * > > + * 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 the byte at 0xe06(IOCON[23:16]) > > + * is for read-only access and writing to it causes the cleraing of LAT0/LAT1. > > + */ > > + > > + /* Write IOCON[15:0] */ > > + mcp251xfd_regmap_crc_gather_write(context, ®, 1, > > + data + data_offset, 2); > > You write 15:0 in 1 go here. See above. > > > + reg += 3; > > + /* Write IOCON[31:24] */ > > + mcp251xfd_regmap_crc_gather_write(context, ®, 1, > > + data + data_offset + 3, 1); > > + > > + return 0; > > +} > > + > > static int > > mcp251xfd_regmap_crc_write(void *context, > > const void *data, size_t count) > > { > > const size_t data_offset = sizeof(__be16) + > > mcp251xfd_regmap_crc.pad_bits / BITS_PER_BYTE; > > + u16 reg = *(u16 *)data; > > > > - return mcp251xfd_regmap_crc_gather_write(context, > > + if (reg == MCP251XFD_REG_IOCON) > > + return mcp251xfd_regmap_crc_write_iocon(context, > > + data, count); > > + else > > + return mcp251xfd_regmap_crc_gather_write(context, > > data, data_offset, > > data + data_offset, > > count - data_offset); > > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung Nürnberg | Phone: +49-5121-206917-129 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 | Best regards, Gregor -- TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany Amtsgericht München, HRB 105018 Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider https://www.tq-group.com/