Received: by 2002:a05:7412:f584:b0:e2:908c:2ebd with SMTP id eh4csp688443rdb; Sun, 3 Sep 2023 06:18:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG4QzbOW1cQqBZ/xeAIhmV0k7vPUXeTr3VSXmU8rizqlFKubvInLoEWK/E49dXnUNCrxGzW X-Received: by 2002:a05:6a20:7fa9:b0:125:4d74:cd6a with SMTP id d41-20020a056a207fa900b001254d74cd6amr10765928pzj.3.1693747083536; Sun, 03 Sep 2023 06:18:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693747083; cv=none; d=google.com; s=arc-20160816; b=rqXdhfSLRshgjv4Y3/EhO5EcI2LuLgVE0MhTNgaHqYJGvDbR1/K34ZpcLzaL392aUB RU0JLZf7c628mTJ3NiP1U/C22ZRxlaMCMbDvPLrp5Ioicnq6l6D9f6vrc6KttAqTWTFt u/7kk3ojL/VlWaBjhaB7958Vjo4NySAvENmaqBGWLO9yy5v5aApVxdry3U0l+8f3rHfH 05Vb06s2N4uQSfewZ1nn2qOiwv1f600RKIcowioMIzhEKl8Uot9JMfFcK53GJ8O30gQh aezP1SB+Fm+ZZABQBbjNW0/mQ7YpVEN5Mz5+hlYehrWZE43E6rspIZavtWNUAlQILdql SJnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=PYcecLXisMqoA8fpbYU0391asg1/BiSrpWYgTtKd70Q=; fh=SwXRDT3wef7eYr+GiOVvHhMXJPt0P6DhPR6I4tBQCDQ=; b=vPeJJpBB9LnW790LxNgjW1C1v63O27+jOPTqRE7pKS+TRa+rhoM0fE41FzbIp4VC8x z+EVtuvEFoexn/FwrIAubbApCq+yLsO+0Zu/YTK9jQpjOuUiZvzcXePHJKiSllLTWcKE Q7qUtbkq11bghjPnrEjdSyCZN5wrV5jLgKtFB3qHVMORPbmhJyrR8cQGKIFMMHdCxnwW 8+Mk3TIJ018RiKaMFBVEiVBpC4GeX84FIbNpmZmiIe1QtAX2sb05q7UcDR2H7b40c7PK 95EhgbEbGSGZ7U7Nqa+nv6Z62TciTWJSD+t9Z5IIWJr8SiwzutLM1npgJEZ2MuUTTKvQ Gj2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uffgnftZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q12-20020a6557cc000000b00564bfbb19e7si6193501pgr.728.2023.09.03.06.17.48; Sun, 03 Sep 2023 06:18:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uffgnftZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234521AbjIBVFY (ORCPT + 99 others); Sat, 2 Sep 2023 17:05:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229590AbjIBVFY (ORCPT ); Sat, 2 Sep 2023 17:05:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB1C1AB; Sat, 2 Sep 2023 14:05:20 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9B719B80471; Sat, 2 Sep 2023 21:05:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D6A4C433C7; Sat, 2 Sep 2023 21:05:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693688718; bh=rk6OUUF0lju8fTJCsQyrCMTMh23x8YQNCTK57B6EXQ8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uffgnftZcfh0vQobjrnOagHZJ/k2irGDSeKLePIBbkNANCFGzY7aKcCnPvG33gg2S 4qcQva1K+qp+6wu54OrL3C67oiQJKOrCDLdlagvWNg8M+RnpBe4epC2JoQ23LjUJgU +zfh6HK1X+0a8amJJHUNxKwmL8wGaTF8yw+AjPkbBOwqQSGTHeH0nW4MIWaTwKpq7W foIw++NlqbXjm5gdy3LlohxMsTYD1RNvFUldKyKtd7e/Jxl/ie1Qn21oDPdfA133YM gCLy/9ka3zDmJ2NN4I5AXDnHMNV1fp0lGsx3z64JRVN3ukBYbOrJcZ8C4FCXawUrYd dhG4o4E6wr5yQ== Date: Sat, 2 Sep 2023 23:05:13 +0200 From: Andi Shyti To: Huangzheng Lai Cc: Orson Zhai , Baolin Wang , Chunyan Zhang , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, huangzheng lai , Xiongpeng Wu Subject: Re: [PATCH 3/8] i2c: sprd: Use global variables to record IIC ack/nack status instead of local variables Message-ID: <20230902210513.3xelrcdtynz45p4o@zenone.zhora.eu> References: <20230817094520.21286-1-Huangzheng.Lai@unisoc.com> <20230817094520.21286-4-Huangzheng.Lai@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230817094520.21286-4-Huangzheng.Lai@unisoc.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org Hi Huangzheng, On Thu, Aug 17, 2023 at 05:45:15PM +0800, Huangzheng Lai wrote: > We found that when the interrupt bit of the IIC controller is cleared, > the ack/nack bit is also cleared at the same time. After clearing the > interrupt bit in sprd_i2c_isr(), incorrect ack/nack information will be > obtained in sprd_i2c_isr_thread(), resulting in incorrect communication > when nack cannot be recognized. To solve this problem, we used a global > variable to record ack/nack information before clearing the interrupt > bit instead of a local variable. > > Signed-off-by: Huangzheng Lai Is this a fix? Then please consider adding Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Cc: # v4.14+ > --- > drivers/i2c/busses/i2c-sprd.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c > index 066b3a9c30c8..549b60dd3273 100644 > --- a/drivers/i2c/busses/i2c-sprd.c > +++ b/drivers/i2c/busses/i2c-sprd.c > @@ -85,6 +85,7 @@ struct sprd_i2c { > struct clk *clk; > u32 src_clk; > u32 bus_freq; > + bool ack_flag; smells a bit racy... however we are in the same interrupt cycle. Do you think we might need a spinlock around here? > struct completion complete; > struct reset_control *rst; > u8 *buf; > @@ -384,7 +385,6 @@ static irqreturn_t sprd_i2c_isr_thread(int irq, void *dev_id) > { > struct sprd_i2c *i2c_dev = dev_id; > struct i2c_msg *msg = i2c_dev->msg; > - bool ack = !(readl(i2c_dev->base + I2C_STATUS) & I2C_RX_ACK); > u32 i2c_tran; > > if (msg->flags & I2C_M_RD) > @@ -400,7 +400,7 @@ static irqreturn_t sprd_i2c_isr_thread(int irq, void *dev_id) > * For reading data, ack is always true, if i2c_tran is not 0 which > * means we still need to contine to read data from slave. > */ > - if (i2c_tran && ack) { > + if (i2c_tran && i2c_dev->ack_flag) { > sprd_i2c_data_transfer(i2c_dev); > return IRQ_HANDLED; > } > @@ -411,7 +411,7 @@ static irqreturn_t sprd_i2c_isr_thread(int irq, void *dev_id) > * If we did not get one ACK from slave when writing data, we should > * return -EIO to notify users. > */ > - if (!ack) > + if (!i2c_dev->ack_flag) > i2c_dev->err = -EIO; > else if (msg->flags & I2C_M_RD && i2c_dev->count) > sprd_i2c_read_bytes(i2c_dev, i2c_dev->buf, i2c_dev->count); > @@ -428,7 +428,6 @@ static irqreturn_t sprd_i2c_isr(int irq, void *dev_id) > { > struct sprd_i2c *i2c_dev = dev_id; > struct i2c_msg *msg = i2c_dev->msg; > - bool ack = !(readl(i2c_dev->base + I2C_STATUS) & I2C_RX_ACK); > u32 i2c_tran; > > if (msg->flags & I2C_M_RD) > @@ -447,7 +446,8 @@ static irqreturn_t sprd_i2c_isr(int irq, void *dev_id) > * means we can read all data in one time, then we can finish this > * transmission too. > */ > - if (!i2c_tran || !ack) { > + i2c_dev->ack_flag = !(readl(i2c_dev->base + I2C_STATUS) & I2C_RX_ACK); there is a question from Chunyan here. I like more val = readl(...); i2c_dev->ack_flag = !(val & I2C_RX_ACK); a matter of taste, your choice. Andi > + if (!i2c_tran || !i2c_dev->ack_flag) { > sprd_i2c_clear_start(i2c_dev); > sprd_i2c_clear_irq(i2c_dev); > } > -- > 2.17.1 >