public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Yann Sionneau <yann@sionneau.net>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yann Sionneau <ysionneau@kalray.eu>,
	Jonathan Borne <jborne@kalray.eu>
Subject: Re: [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0
Date: Fri, 11 Aug 2023 17:01:28 +0300	[thread overview]
Message-ID: <ZNY/OL4ZKiTL3lF3@smile.fi.intel.com> (raw)
In-Reply-To: <20230811124624.12792-2-yann@sionneau.net>

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)

> +					len = i2c_dw_recv_len(dev, tmp);
> +				else
> +					i2c_dw_abort(dev);

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-08-11 14:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-11 12:46 [PATCH 1/2] i2c: designware: fix __i2c_dw_disable in case master is holding SCL low Yann Sionneau
2023-08-11 12:46 ` [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0 Yann Sionneau
2023-08-11 14:01   ` Andy Shevchenko [this message]
2023-08-17 14:42     ` Yann Sionneau
2023-08-17 15:51       ` Andy Shevchenko
2023-08-11 13:59 ` [PATCH 1/2] i2c: designware: fix __i2c_dw_disable in case master is holding SCL low Andy Shevchenko
2023-08-17 14:39   ` Yann Sionneau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZNY/OL4ZKiTL3lF3@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=jborne@kalray.eu \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=yann@sionneau.net \
    --cc=ysionneau@kalray.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox