public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@kernel.org>
To: Quan Nguyen <quan@os.amperecomputing.com>
Cc: Corey Minyard <minyard@acm.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
	Brendan Higgins <brendanhiggins@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	openipmi-developer@lists.sourceforge.net,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org, openbmc@lists.ozlabs.org,
	Open Source Submission <patches@amperecomputing.com>,
	Phong Vo <phong@os.amperecomputing.com>,
	"Thang Q . Nguyen" <thang@os.amperecomputing.com>
Subject: Re: [PATCH v7 3/3] i2c: aspeed: Assert NAK when slave is busy
Date: Wed, 15 Jun 2022 22:32:48 +0200	[thread overview]
Message-ID: <YqpB8A2uBi+4epHM@shikoro> (raw)
In-Reply-To: <fc422a06-c035-f6e5-231b-74ea6afe8467@os.amperecomputing.com>

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi Quan,

> When tested with ast2500, it is observed that there's always a
> I2C_SLAVE_WRITE_REQUESTED comes first then other I2C_SLAVE_WRITE_RECEIVED's
> follow for all transactions.

Yes, that's the design of the interface :)

> In case slave is busy, the NAK will be asserted on the first occurrence of
> I2C_SLAVE_WRITE_REQUESTED make host to stop the current transaction (host
> later will retry with other transaction) until slave ready.
> 
> This behavior is expected as we want host to drop all transactions while
> slave is busy on working on the response. That is why we choose to assert
> NAK on the first I2C_SLAVE_WRITE_REQUESTED of the transaction instead of
> I2C_SLAVE_WRITE_RECEIVED.

From Documentation/i2c/slave-interface.rst:

===

About ACK/NACK
--------------

It is good behaviour to always ACK the address phase, so the master knows if a
device is basically present or if it mysteriously disappeared. Using NACK to
state being busy is troublesome. SMBus demands to always ACK the address phase,
while the I2C specification is more loose on that. Most I2C controllers also
automatically ACK when detecting their slave addresses, so there is no option
to NACK them. For those reasons, this API does not support NACK in the address
phase.

===

So, the proper design is to NACK on the first received byte. All EEPROMs
do it this way when they are busy because of erasing a page.

All the best,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-06-15 20:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-22  4:08 [PATCH v7 0/3] Add SSIF BMC driver Quan Nguyen
2022-04-22  4:08 ` [PATCH v7 1/3] ipmi: ssif_bmc: " Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-23  1:51   ` Corey Minyard
2022-05-04  6:45     ` Quan Nguyen
2022-05-04 12:06       ` [Openipmi-developer] " Corey Minyard
2022-06-01  8:23         ` Quan Nguyen
2022-06-02  0:32           ` Corey Minyard
2022-06-02  9:38             ` Quan Nguyen
2022-04-22  4:08 ` [PATCH v7 2/3] bindings: ipmi: Add binding for " Quan Nguyen
2022-04-22  4:16   ` Quan Nguyen
2022-04-22  7:21     ` Krzysztof Kozlowski
2022-04-22  7:56       ` Quan Nguyen
2022-04-25 21:39   ` Rob Herring
2022-04-22  4:08 ` [PATCH v7 3/3] i2c: aspeed: Assert NAK when slave is busy Quan Nguyen
2022-04-22  4:17   ` Quan Nguyen
2022-05-14 14:31   ` Wolfram Sang
2022-05-16  2:32     ` Quan Nguyen
2022-06-15 20:32       ` Wolfram Sang [this message]
2022-06-16  7:16         ` Quan Nguyen
2022-06-16 12:29           ` Wolfram Sang
2022-06-17  7:08             ` Quan Nguyen
2022-07-05  2:45               ` Quan Nguyen
2022-04-22  4:16 ` [PATCH v7 0/3] Add SSIF BMC driver Quan Nguyen

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=YqpB8A2uBi+4epHM@shikoro \
    --to=wsa@kernel.org \
    --cc=andrew@aj.id.au \
    --cc=benh@kernel.crashing.org \
    --cc=brendanhiggins@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=joel@jms.id.au \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=openbmc@lists.ozlabs.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=patches@amperecomputing.com \
    --cc=phong@os.amperecomputing.com \
    --cc=quan@os.amperecomputing.com \
    --cc=robh+dt@kernel.org \
    --cc=thang@os.amperecomputing.com \
    /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