[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231012150616.n6gpovgb6qsg5d7e@zenone.zhora.eu>
Date: Thu, 12 Oct 2023 17:06:16 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Alain Volmat <alain.volmat@...s.st.com>
Cc: Pierre-Yves MORDRET <pierre-yves.mordret@...s.st.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
M'boumba Cedric Madianga <cedric.madianga@...il.com>,
Wolfram Sang <wsa@...nel.org>, stable@...r.kernel.org,
Pierre-Yves MORDRET <pierre-yves.mordret@...com>,
linux-i2c@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] i2c: stm32f7: Fix PEC handling in case of SMBUS
transfers
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@...s.st.com>
> Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@...s.st.com>
As this is a fix you should have also included and Cc'ed:
Cc: <stable@...r.kernel.org> # v4.18+
No need to resend.
Acked-by: Andi Shyti <andi.shyti@...nel.org>
Thanks,
Andi
Powered by blists - more mailing lists