Message ID | 20231010084455.1718830-1-alain.volmat@foss.st.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp49164vqb; Tue, 10 Oct 2023 01:46:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHWjiI6Z4VKaewbFhEcY9eeSzb4HWBiu+44PiwYK67NegyNSS4Zvg0EFMMUejh/BIGMTbP4 X-Received: by 2002:a25:cf8b:0:b0:d81:5af9:5208 with SMTP id f133-20020a25cf8b000000b00d815af95208mr18229657ybg.31.1696927596063; Tue, 10 Oct 2023 01:46:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696927595; cv=none; d=google.com; s=arc-20160816; b=SO18xNWCgEh1xdhpXZ5ypP91XaSzm+8w17GO/OgQ/4nC+3wbCCffF5QIqkU05Es6rW X+GVKBAYyzsUl/OqoeLlcpMBAYuqPHpKebYFf/kSQc5oD3YGfzdiMoCLgbkYdJTINwPo zcc+5+WgFqYkstiRYVBIrYchLfqprTkdfLmeOb7mUI+HgqmuaRVXS14Tw0wPr6YAFPX5 XU4a95rlf2Mdw5dXklgItCtjNqWRlsYrFxTHKIG6z4ZjsCZ6v7K4GPXCuMwoRNLPuAHc wYJKqoei9MvfE4vO4GG5k1o2Qvm3pLbcGC7B6erz2IhE86eVgW2L6Nu4RLVLYXIYYGr+ QU+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=WCYc/RI9/IQKqdbx4Vx6AK1sToKJiRmvRA3d8JVp7Qw=; fh=/63+0sauR/yXaKgIO6ljv2N+6vjqQYxnKdIiehNgEB8=; b=gWsXNHnIwOQs9NPdoQCVhK4MOXpDO1rAlqR+7Nk0+kNQiB4Ow1wdZpQN9Y/yvWRVpd sWujObqPDO6lLXXEB38u/XjN4NjkwaLC2/S/XLymrz5UCgIx02NyYl0wFPxpmAoX3c1W gnJZppdOjm4ZpP42Mqaf+sG6WuJ0OufFuFkdn+ShYyv6Ggw7FMlz5i/MSVaYw8V0SWRC i+vPrcohIejfkRApNp63r16gT1qZMBzNb6bGRahH7a7c2WOTx7dwy4NHX/B12yHmZhhm Q3bEWQqriiFMaJGaEVOymkLuU0qDBuu8touZwvJq6YqoDCIzEvsQfPWv8rYvag8meJiI t8Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=5IFLin8E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id a72-20020a63904b000000b00563deb65f93si11737345pge.200.2023.10.10.01.46.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 01:46:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=5IFLin8E; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id DA22E804C216; Tue, 10 Oct 2023 01:45:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229827AbjJJIpv (ORCPT <rfc822;rua109.linux@gmail.com> + 20 others); Tue, 10 Oct 2023 04:45:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229525AbjJJIpr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Oct 2023 04:45:47 -0400 Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BF0DA4; Tue, 10 Oct 2023 01:45:46 -0700 (PDT) Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 39A8CLJo030787; Tue, 10 Oct 2023 10:45:35 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:content-type; s=selector1; bh=WCYc/RI 9/IQKqdbx4Vx6AK1sToKJiRmvRA3d8JVp7Qw=; b=5IFLin8EWof5QceBowCG9xH kXg9kRB2d8p9vCDeQZ7kQzdSeqW6yKD3Ko/YuaJ825POvawRWwysDOWWoBp9vlNW aeoeZcUt105kuJGalCDU0d0s1q9CVeY+TdYd9EQgvRHrKVs2xS5rs0ef0MrqUDFu 5hbgE8HfOAqDRKAM5YKmN9QJhGH7J5rwZ7W9WRHbM3AnFZs79ChCwkh2rELmbMVn wPxaoeIp23cVp80gkktzXjyiqa32be6NYiBtQKHm3YSEx60VIVAMulz8/191gSnY 75FI1s8xsG3X8xYMKRe5SEjvj6Eq8zTYPDxecvhdXBC3vfunYh51gdIgt7Gw8/g= = Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3tkhfe110p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Oct 2023 10:45:35 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BFA4610005E; Tue, 10 Oct 2023 10:45:34 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id AF6E321A902; Tue, 10 Oct 2023 10:45:34 +0200 (CEST) Received: from localhost (10.129.178.213) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Tue, 10 Oct 2023 10:45:34 +0200 From: Alain Volmat <alain.volmat@foss.st.com> To: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com>, Alain Volmat <alain.volmat@foss.st.com>, Andi Shyti <andi.shyti@kernel.org>, "Maxime Coquelin" <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, M'boumba Cedric Madianga <cedric.madianga@gmail.com>, Wolfram Sang <wsa@kernel.org> CC: <stable@vger.kernel.org>, Pierre-Yves MORDRET <pierre-yves.mordret@st.com>, <linux-i2c@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v2] i2c: stm32f7: Fix PEC handling in case of SMBUS transfers Date: Tue, 10 Oct 2023 10:44:54 +0200 Message-ID: <20231010084455.1718830-1-alain.volmat@foss.st.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.129.178.213] X-ClientProxiedBy: SHFCAS1NODE2.st.com (10.75.129.73) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-10_04,2023-10-09_01,2023-05-22_02 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 10 Oct 2023 01:45:56 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779357550584704540 X-GMAIL-MSGID: 1779357550584704540 |
Series |
[v2] i2c: stm32f7: Fix PEC handling in case of SMBUS transfers
|
|
Commit Message
Alain Volmat
Oct. 10, 2023, 8:44 a.m. UTC
In case of SMBUS byte read with PEC enabled, the whole transfer is split into two commands. A first write command, followed by a read command. The write command does not have any PEC byte and a PEC byte is appended at the end of the read command. (cf Read byte protocol with PEC in SMBUS specification) Within the STM32 I2C controller, handling (either sending or receiving) of the PEC byte is done via the PECBYTE bit in register CR2. Currently, the PECBYTE is set at the beginning of a transfer, which lead to sending a PEC byte at the end of the write command (hence losing the real last byte), and also does not check the PEC byte received during the read command. This patch corrects the function stm32f7_i2c_smbus_xfer_msg in order to only set the PECBYTE during the read command. Fixes: 9e48155f6bfe ("i2c: i2c-stm32f7: Add initial SMBus protocols support") Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> --- v2: - add more details about the issue within the commit log - removal of blank line between Fixes and Signed-off-by drivers/i2c/busses/i2c-stm32f7.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
Comments
Hi Alain, On Tue, Oct 10, 2023 at 10:44:54AM +0200, Alain Volmat wrote: > In case of SMBUS byte read with PEC enabled, the whole transfer > is split into two commands. A first write command, followed by > a read command. The write command does not have any PEC byte > and a PEC byte is appended at the end of the read command. > (cf Read byte protocol with PEC in SMBUS specification) > > Within the STM32 I2C controller, handling (either sending > or receiving) of the PEC byte is done via the PECBYTE bit in > register CR2. > > Currently, the PECBYTE is set at the beginning of a transfer, > which lead to sending a PEC byte at the end of the write command > (hence losing the real last byte), and also does not check the > PEC byte received during the read command. > > This patch corrects the function stm32f7_i2c_smbus_xfer_msg > in order to only set the PECBYTE during the read command. Thanks for improving the log. > Fixes: 9e48155f6bfe ("i2c: i2c-stm32f7: Add initial SMBus protocols support") > Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> > Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> As this is a fix you should have also included and Cc'ed: Cc: <stable@vger.kernel.org> # v4.18+ No need to resend. Acked-by: Andi Shyti <andi.shyti@kernel.org> Thanks, Andi
On Tue, Oct 10, 2023 at 10:44:54AM +0200, Alain Volmat wrote: > In case of SMBUS byte read with PEC enabled, the whole transfer > is split into two commands. A first write command, followed by > a read command. The write command does not have any PEC byte > and a PEC byte is appended at the end of the read command. > (cf Read byte protocol with PEC in SMBUS specification) > > Within the STM32 I2C controller, handling (either sending > or receiving) of the PEC byte is done via the PECBYTE bit in > register CR2. > > Currently, the PECBYTE is set at the beginning of a transfer, > which lead to sending a PEC byte at the end of the write command > (hence losing the real last byte), and also does not check the > PEC byte received during the read command. > > This patch corrects the function stm32f7_i2c_smbus_xfer_msg > in order to only set the PECBYTE during the read command. > > Fixes: 9e48155f6bfe ("i2c: i2c-stm32f7: Add initial SMBus protocols support") > Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> > Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com> Applied to for-current, thanks! BTW, there are some patches pending from this series for stm32f4/7. Do you have time for an ack? http://patchwork.ozlabs.org/project/linux-i2c/list/?series=359230
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c index 579b30581725..0d3c9a041b56 100644 --- a/drivers/i2c/busses/i2c-stm32f7.c +++ b/drivers/i2c/busses/i2c-stm32f7.c @@ -1059,9 +1059,10 @@ static int stm32f7_i2c_smbus_xfer_msg(struct stm32f7_i2c_dev *i2c_dev, /* Configure PEC */ if ((flags & I2C_CLIENT_PEC) && f7_msg->size != I2C_SMBUS_QUICK) { cr1 |= STM32F7_I2C_CR1_PECEN; - cr2 |= STM32F7_I2C_CR2_PECBYTE; - if (!f7_msg->read_write) + if (!f7_msg->read_write) { + cr2 |= STM32F7_I2C_CR2_PECBYTE; f7_msg->count++; + } } else { cr1 &= ~STM32F7_I2C_CR1_PECEN; cr2 &= ~STM32F7_I2C_CR2_PECBYTE; @@ -1149,8 +1150,10 @@ static void stm32f7_i2c_smbus_rep_start(struct stm32f7_i2c_dev *i2c_dev) f7_msg->stop = true; /* Add one byte for PEC if needed */ - if (cr1 & STM32F7_I2C_CR1_PECEN) + if (cr1 & STM32F7_I2C_CR1_PECEN) { + cr2 |= STM32F7_I2C_CR2_PECBYTE; f7_msg->count++; + } /* Set number of bytes to be transferred */ cr2 &= ~(STM32F7_I2C_CR2_NBYTES_MASK);