From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Atif Ashhar <atifashhar@google.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Andi Shyti <andi.shyti@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
Wolfram Sang <wsa@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] i2c: designware: Release slave SCL hold in __i2c_dw_disable()
Date: Thu, 12 Nov 2026 09:46:16 +0100 [thread overview]
Message-ID: <avV82EfLER5vZost@black.igk.intel.com> (raw)
In-Reply-To: <20261110190559.819337-1-atifashhar@google.com>
Hi guys,
On Tue, Nov 10, 2026 at 07:05:59PM +0000, Atif Ashhar wrote:
> Hi Mika,
>
> On Mon, Nov 09, 2026 at 11:20:06AM +0100, Mika Westerberg wrote:
> > > + if (tx_hold) {
> > > + regmap_read(dev->map, DW_IC_CLR_RD_REQ, &dummy);
> > > + regmap_read(dev->map, DW_IC_CLR_TX_ABRT, &dummy);
> > > + regmap_write(dev->map, DW_IC_DATA_CMD, 0xFF);
> >
> > I'm not super familiar with the slave mode so adding Heikki just in case.
> > Can this cause some unintended traffic on the bus towards the master?
>
> No, it cannot initiate new traffic. DW_IC_STATUS_SLAVE_HOLD_TX_FIFO_EMPTY
> is only asserted when an external master has already addressed this
> controller and initiated a read transfer, and the slave hardware is
> actively stretching SCL low waiting for TX data. When no slave read
> hold is active, i2c_dw_release_slave_hold() returns early without
> writing to DW_IC_DATA_CMD.
>
> Writing 0xff simply satisfies the ongoing master-clocked read byte
> while keeping SDA passively high (released via pull-ups), allowing the
> external master to finish clocking the byte and terminate the transfer
> with NACK/STOP instead of hanging the bus indefinitely.
>
> > Also use 0xff instead.
>
> Ack, I will update 0xFF to 0xff (and wait to see if Heikki has any
> comments before sending v2).
No comments yet, but just out of curiosity, I'll try to test this.
Please go ahead with the v2. I can then give you my Tested-by tag if I
figure out how to reproduce the problem fast enough.
Thanks,
--
heikki
next prev parent reply other threads:[~2026-11-12 8:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 13:37 [PATCH] i2c: designware: Release slave SCL hold in __i2c_dw_disable() Atif Ashhar
2026-11-09 10:20 ` Mika Westerberg
2026-11-10 19:05 ` Atif Ashhar
2026-11-12 8:46 ` Heikki Krogerus [this message]
2026-11-12 14:52 ` [PATCH v2] " Atif Ashhar
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=avV82EfLER5vZost@black.igk.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=atifashhar@google.com \
--cc=jarkko.nikula@linux.intel.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=wsa@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.