All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: "wsa@kernel.org" <wsa@kernel.org>,
	"mbizon@freebox.fr" <mbizon@freebox.fr>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] i2c: mpc: Use atomic read and fix break condition
Date: Thu, 9 Dec 2021 19:47:36 +0000	[thread overview]
Message-ID: <d9a9d4db-9e21-288d-40d5-0eef198146fb@alliedtelesis.co.nz> (raw)
In-Reply-To: <YbHKsI35uHz9PjwO@ninjato>


On 9/12/21 10:21 pm, wsa@kernel.org wrote:
>> we'd hit the 100us timeout in the poll). But I see no evidence of that
>> actually happening (and no idea what arbitration lost means w.r.t i2c).
> On a bus with multiple masters, it means the other master has won the
> arbitration because the address it wants to talk to contains more 0 bits.
>
>> I don't know that there is a maximum clock stretch time (we certainly
>> know there are misbehaving devices that hold SCL low forever). The SMBUS
>> protocol adds some timeouts but as far as I know i2c says nothing about
>> how long a remote device can hold SCL.
> The above is all correct.
>
> Even with the unclear situation about the 100us, I think this should go
> to for-current soon, right?
Please and thank you.

      reply	other threads:[~2021-12-09 19:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  4:21 [PATCH] i2c: mpc: Use atomic read and fix break condition Chris Packham
2021-12-07 10:13 ` Maxime Bizon
2021-12-07 22:24   ` Chris Packham
2021-12-09  9:21     ` wsa
2021-12-09 19:47       ` Chris Packham [this message]

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=d9a9d4db-9e21-288d-40d5-0eef198146fb@alliedtelesis.co.nz \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbizon@freebox.fr \
    --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.