Messages in this thread | | | Date | Thu, 17 Aug 2023 16:42:05 +0200 | Subject | Re: [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0 | From | Yann Sionneau <> |
| |
Hi,
Le 11/08/2023 à 16:01, Andy Shevchenko a écrit : > On Fri, Aug 11, 2023 at 02:46:24PM +0200, Yann Sionneau wrote: >> From: Yann Sionneau <ysionneau@kalray.eu> >> >> Context: >> It's not clear whether Linux SMBus stack supports receiving 0 >> as byte count for SMBus read data block. >> >> Linux supports SMBus v2.0 spec, which says "The byte count may not be 0." >> Which does not seem very clear to me, as a non-native speaker. >> (Note that v3.0 of the spec says "The byte count may be 0.") >> >> Some drivers explicitly return -EPROTO in case of byte count 0. >> >> The issue: >> Regardless of whether Linux supports byte count of 0, if this happens >> the i2c-designware driver goes into an unrecoverable state holding >> SCL low if the IP is synthesized with the IC_EMPTYFIFO_HOLD_MASTER_EN >> parameter. >> >> The fix proposed by this patch: >> Abort the transfer by sending a STOP condition on the bus. >> >> Another approach would be to ignore the issue and let the driver >> timeout and disable the IP. The IP disabling is fixed by the previous >> patch in this patch series. >> The current patch just makes the recovery faster since Abort is sent >> directly without waiting for the timeout to happen. With this patch, >> disabling the IP is not necessary anymore. > ... > >> + if ((tmp <= I2C_SMBUS_BLOCK_MAX) && (tmp != 0)) > if (tmp && tmp <= I2C_SMBUS_BLOCK_MAX)
I find the tmp != 0 "more obvious", I am more used to "just tmp" when it's a pointer or a boolean, but maybe it's just me!
I'll fix that in the V2 :)
> >> + len = i2c_dw_recv_len(dev, tmp); >> + else >> + i2c_dw_abort(dev); Thanks!
| |