Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <99dff4f2-cfe1-4a3d-a10b-313b9e7a29b3@os.amperecomputing.com>
Date:   Wed, 29 Nov 2023 16:03:53 +0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 RESEND 1/2] i2c: aspeed: Fix unhandled Tx done with NAK
Content-Language: en-CA
To:     Andrew Jeffery <andrew@codeconstruct.com.au>,
        Brendan Higgins <brendan.higgins@linux.dev>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Joel Stanley <joel@jms.id.au>,
        Andi Shyti <andi.shyti@kernel.org>,
        Wolfram Sang <wsa@kernel.org>,
        Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com>,
        Guenter Roeck <linux@roeck-us.net>, linux-i2c@vger.kernel.org,
        openbmc@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org,
        linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc:     Cosmo Chou <chou.cosmo@gmail.com>,
        Open Source Submission <patches@amperecomputing.com>,
        Phong Vo <phong@os.amperecomputing.com>,
        "Thang Q . Nguyen" <thang@os.amperecomputing.com>
References: <20231128075236.2724038-1-quan@os.amperecomputing.com>
 <20231128075236.2724038-2-quan@os.amperecomputing.com>
 <4a9fe86f0349106adaa4e0c04c5839bab631f26c.camel@codeconstruct.com.au>
From:   Quan Nguyen <quan@os.amperecomputing.com>
In-Reply-To: <4a9fe86f0349106adaa4e0c04c5839bab631f26c.camel@codeconstruct.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?b0svbXNvTXczaDlDMVpjUVZSNjdFcUh5ZVJXUEd6Z1AzdHdtYXRQbDZKOSs4?=
 =?utf-8?B?Q0ZMaWFsSTJwNzFKMnM4T2k3Z2h6ZnZpcFdRb2JYRjhOWEFwOTZPK2ZSWk5s?=
 =?utf-8?B?T1FGa280OGtrRmNJM1hGa09XUDdYdCtnbVFvSTdsdmY2cW1jNHY3TEdsWlk5?=
 =?utf-8?B?Qno4NnJZZkkrV0hqbzhBbG5vNHlNWTNTS3dkUEtaZlh1VGZOazdPRGwxVSs0?=
 =?utf-8?B?OGhHeXJWZlhmOStmMnZqbXcyNGdNQnM1R3RwbnQvRm1PVnpDS3lId3ZReElz?=
 =?utf-8?B?UnV5VGtwVTBIOW5WU2grUVROMkFJYjAvSW1EMXNTSFliZWdXQitmNGpXSC9o?=
 =?utf-8?B?RHFvL2NZeE5udjlrSUVvclVxaTlCVjBBNGdkRmZlY2tKdFNUb200UmdjTkdx?=
 =?utf-8?B?emVXaUdWTWxDNkg3ZGd0TEJkUm10RHdYcUlWeFRYbjc5bEQyQ2gxMi9Na2xh?=
 =?utf-8?B?YXhPMmZiTXN1R0tKYjgwbHp3S3EySVBlSkhUZUVpbmpIK0hsaHF5d3JaaTZI?=
 =?utf-8?B?bWFSemVqOFZwVHF3ZmxRWjFhY3FsK0dDeXd3TWQ3c1pOcE91NXhJQjdxTTB2?=
 =?utf-8?B?bEpsSEhremFOTW8zaXhEMkorbWhkdHhwZ1pXV0ExZTY1ZnNMYWRNWXU1dDJy?=
 =?utf-8?B?dm1xd2FjSVk0eWVZWk40UFNiNUF4RUpibExqY2VsZVlVYk5UZ2FvUy9YdWh0?=
 =?utf-8?B?MnQzZS9GL0hWN2d6K0UrMXZXREkrbXViMjQ2U3FLdlhiYVM0RFBGQ0pveERQ?=
 =?utf-8?B?RGlnL2dRRzZSZXd5a2N4d3VJdTl0a0ZSKzlRVWFOeVdHa0V1NlQvUHF5ZkVK?=
 =?utf-8?B?TFhac2dCMHJRN1R0OXVxT0NGaFlNcVEranNkQ3dPbFB4TTF0Nm9PV3JzTFRD?=
 =?utf-8?B?OWMwandQQmt1eDRjekRzbzlUbkFwT01PdHBmYmpkUzBKV2xtMjdGZjhveGFm?=
 =?utf-8?B?NDdwL09PdUo5RVgrOCtzQlNoNVIyRi9YMTR3YnVWdXkxam9DbUF1QjVhOGc2?=
 =?utf-8?B?NHlKTk9UalF2UnJiYnVpK0l4L2dNZ0hveGNQcWcrNkFqRW1Zb0hxN3F4NlNq?=
 =?utf-8?B?ekdqRGt4SmlUVWFpVTF3U2g4alZtZkgyRmE1WC9keHlUZW5uQUZOS0g3VDdP?=
 =?utf-8?B?TENTUUJCeFJXZnREL3h2Y011VkpNNDZBNnd3eWtUREZaUkcvN2Qzb25ZaE52?=
 =?utf-8?B?TldQRGlzd0hDMUpQRVhYMEpVRUVacnVlYzNnOXYzTXpVYklBMGI2eTRtSm1z?=
 =?utf-8?B?M003ZWpweEg2bHo5Q05mN0Fvc1BqUnlkUU5VRkcrOG5jVEl0YzRDMWRON2VK?=
 =?utf-8?B?MzhVVmQ5R1dmSmg2TStMZTIrUy9DRWFwalBRWTlTM3dTYmZEV2RVc3dpaHhk?=
 =?utf-8?B?V29VaXBDV1J5SHNUS053cFdTWWRVNDBxZVNObFhqVWxyRTVqN0FLMkQwU2JS?=
 =?utf-8?B?cEI4NmxMeHJPaCs0MUZzYU5qMTRuWGZYc0Yzc2lmWTJjYzlWNmpRZksyUkJJ?=
 =?utf-8?B?ejR3cWpPZEdMK2tDbUQ3MkdZMHRhMDZ2SWUzcGpIZjlNUnRkaU55ZDltdWFu?=
 =?utf-8?B?UWt3M0s5SG1OL3NxdU9zZkJ6S28rN2tscFFLem5HZCtoUUNjWG4vQnFubDBm?=
 =?utf-8?B?cDM0cU4yVERQZjVGLzRTdWhvS0pOTGg1RnF5VFRmWHc2WGhWRk1SNi9Fc2c5?=
 =?utf-8?B?eEF5NU80YjJzUEEwb3NCTDZ5bWR3ZGpBckdmQlVRSlNBOXlhTlcwUTh4aUFq?=
 =?utf-8?B?SUdQbG1YUDI5dFFDZEdaNVh1K201S3JEdjVzcGhrV2F1L3dWQkg4MkN0cjB2?=
 =?utf-8?B?Y3l5NU1yWjJvbHAva0hMaDVpNFhRbWlYSXlMM21yRUNwU3F5OU0wM2hTQVpv?=
 =?utf-8?B?QVJtNjhpdzJLMVZwbVpJSDFlTnlaR2hSYXp2dTFrNSsweExrN0RKd2t3K1J2?=
 =?utf-8?B?LzBYOG9jU2lrY0NkUU56bEs1VEp1N0JqVm1NakFFelgrbDdZRk5DRFE2RWo5?=
 =?utf-8?B?OFk4dEV4WXhpck5TZVRvRkNtZjFQbDRhdDFmNEpKWE5aRUU5c2Z3K0ZpK2tI?=
 =?utf-8?B?QzdmR1V6VzRlS3lmNzR2L21QZ2IrOVE4N1lnU216bUFOcDlmZ2swOWtHb1kz?=
 =?utf-8?B?ekUwWTl1YnMvVzFHR3RQbkI0RXQzZHBWalZ0RHQwY1BzL1hOTGlHMnRoWldo?=
 =?utf-8?Q?DNvZETRKSgqjASWGe73Er1g=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ea4f85f8-ce31-4754-d044-08dbf0ba1ff0
X-MS-Exchange-CrossTenant-AuthSource: SN4PR01MB7455.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2023 09:03:59.4725
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eLUzdXXcjMg27yui4oFrJoCJ2fPnXeiserFz3GjZQT4vyNsJydAtTtIBJTTBNK5QJjoMtCROzEytyKvjUQky7yZID6ywuNjv8pFGDCDuHAs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR01MB6302
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,
        SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 29 Nov 2023 01:04:10 -0800 (PST)


On 29/11/2023 07:19, Andrew Jeffery wrote:
> On Tue, 2023-11-28 at 14:52 +0700, Quan Nguyen wrote:
>> Under normal conditions, after the last byte is sent by the Slave, the
>> TX_NAK interrupt is raised.  However, it is also observed that
>> sometimes the Master issues the next transaction too quickly while the
>> Slave IRQ handler is not yet invoked and the TX_NAK interrupt for the
>> last byte of the previous READ_PROCESSED state has not been ack’ed.
>> This TX_NAK interrupt is then raised together with SLAVE_MATCH interrupt
>> and RX_DONE interrupt of the next coming transaction from Master. The
>> Slave IRQ handler currently handles the SLAVE_MATCH and RX_DONE, but
>> ignores the TX_NAK, causing complaints such as
>> "aspeed-i2c-bus 1e78a040.i2c-bus: irq handled != irq. Expected
>> 0x00000086, but was 0x00000084"
>>
>> This commit adds code to handle this case by emitting a SLAVE_STOP event
>> for the TX_NAK before processing the RX_DONE for the coming transaction
>> from the Master.
>>
>> Fixes: f9eb91350bb2 ("i2c: aspeed: added slave support for Aspeed I2C driver")
>> Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
>> ---
>> v2:
>>    + Split to separate series [Joel]
>>    + Added the Fixes line [Joel]
>>    + Revised commit message [Quan]
>>
>> v1:
>>    + First introduced in
>> https://lore.kernel.org/all/20210519074934.20712-1-quan@os.amperecomputing.com/
>> ---
>>   drivers/i2c/busses/i2c-aspeed.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
>> index 28e2a5fc4528..79476b46285b 100644
>> --- a/drivers/i2c/busses/i2c-aspeed.c
>> +++ b/drivers/i2c/busses/i2c-aspeed.c
>> @@ -253,6 +253,11 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>>   
>>   	/* Slave was requested, restart state machine. */
>>   	if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
>> +		if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
>> +		    bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
>> +			irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
>> +			i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
>> +		}
> 
> So we're already (partially) processing this a bit later on line 287:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-aspeed.c?h=v6.7-rc3#n287
> 

Thanks Andrew for the review.

I think it's worth noting that the byte mode is used in this case.

About the code you mentioned, it is for the general process of single 
Slave transmission with NAK which should be interpret as I2C_SLAVE_STOP 
event.

In this case, there is a mix of Slave events:

   + I2C_SLAVE_STOP (due to INTR_TX_NAK, BIT(1) of previous transaction)
   + Followed by I2C_SLAVE_[READ|WRITE]_REQUESTED (due to 
INTR_SLAVE_MATCH and INTR_RX_DONE, BIT(7) and BIT(2), of next transaction)

That is the reason we need to emit the I2C_SLAVE_STOP first for Slave 
backend to process.

>  From the description of the problem in the commit message it sounds
> like the ordering of the interrupt processing is incorrect. 

Yes, this is correct as per my explanation above.

Prior to
> this patch we have the following abstract ordering of interrupt
> processing:
> 
> 1. Process ASPEED_I2CD_INTR_SLAVE_MATCH
> 2. Process ASPEED_I2CD_INTR_TX_NAK when in ASPEED_I2C_SLAVE_READ_PROCESSED
> 

 From my test, the flow is as below:

   1. Process ASPEED_I2CD_INTR_SLAVE_MATCH, slave_state is set to 
ASPEED_I2C_SLAVE_START
   2. As there is INTR_RX_DONE and slave_state is 
ASPEED_I2C_SLAVE_START, depends on the data received, the slave_state 
moves to either ASPEED_I2C_SLAVE_[READ|WRITE]_REQUESTED.
   3. When reach to the if statement to process INTR_TX_NAK, slave_state 
is already moves to either ASPEED_I2C_SLAVE_[READ|WRITE]_REQUESTED, not 
in ASPEED_I2C_SLAVE_READ_PROCESSED anymore. This eventually evaluate as 
false and the if statement is bypass. IOW, this INTR_TX_NAK is not process.

> With this patch we have:
> 
> 1. If ASPEED_I2CD_INTR_SLAVE_MATCH then process ASPEED_I2CD_INTR_TX_NAK when in ASPEED_I2C_SLAVE_READ_PROCESSED
> 2. Process ASPEED_I2CD_INTR_SLAVE_MATCH
> 3. Process ASPEED_I2CD_INTR_TX_NAK when in ASPEED_I2C_SLAVE_READ_PROCESSED
> 

With this patch:

   0. The I2C_SLAVE_STOP is emitted to backend Slave driver first to 
complete the previous transaction. And let the rest process as before 
this patch.

   1. Process ASPEED_I2CD_INTR_SLAVE_MATCH, slave_state is set to 
ASPEED_I2C_SLAVE_START
   2. As there is INTR_RX_DONE and slave_state is 
ASPEED_I2C_SLAVE_START, depends on the data received, the slave_state 
moves to either ASPEED_I2C_SLAVE_[READ|WRITE]_REQUESTED.
   3. When reach to the if statement to process INTR_TX_NAK, slave_state 
is already moves to either ASPEED_I2C_SLAVE_[READ|WRITE]_REQUESTED, not 
in ASPEED_I2C_SLAVE_READ_PROCESSED anymore. This eventually evaluated as 
false and the if statement is bypass. IOW, this INTR_TX_NAK is not process.

> That feels a bit complex and redundant. What I think we can have is:
> 
> 1. Process ASPEED_I2CD_INTR_TX_NAK when in ASPEED_I2C_SLAVE_READ_PROCESSED
> 1. Process ASPEED_I2CD_INTR_SLAVE_MATCH
> 
> Moving back from the abstract to the concrete, implementing what I
> believe we need would look something like this patch:
> 
> diff --git a/drivers/i2c/busses/i2c-aspeed.c b/drivers/i2c/busses/i2c-aspeed.c
> index 28e2a5fc4528..98dd0f35c9d3 100644
> --- a/drivers/i2c/busses/i2c-aspeed.c
> +++ b/drivers/i2c/busses/i2c-aspeed.c
> @@ -251,6 +251,14 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>   
>          command = readl(bus->base + ASPEED_I2C_CMD_REG);
>   
> +       /* Complete any active read */
> +       if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
> +           bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
> +               irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
> +               i2c_slave_event(slave, I2C_SLAVE_STOP, &value);
> +               bus->slave_state = ASPEED_I2C_SLAVE_STOP;
> +       }
> +

It is not confirmed through test yet but I'm afraid the switch case part 
will emit another I2C_SLAVE_STOP event in case there is no mix of 
interrupts.

>          /* Slave was requested, restart state machine. */
>          if (irq_status & ASPEED_I2CD_INTR_SLAVE_MATCH) {
>                  irq_handled |= ASPEED_I2CD_INTR_SLAVE_MATCH;
> @@ -284,11 +292,6 @@ static u32 aspeed_i2c_slave_irq(struct aspeed_i2c_bus *bus, u32 irq_status)
>                  irq_handled |= ASPEED_I2CD_INTR_NORMAL_STOP;
>                  bus->slave_state = ASPEED_I2C_SLAVE_STOP;
>          }
> -       if (irq_status & ASPEED_I2CD_INTR_TX_NAK &&
> -           bus->slave_state == ASPEED_I2C_SLAVE_READ_PROCESSED) {
> -               irq_handled |= ASPEED_I2CD_INTR_TX_NAK;
> -               bus->slave_state = ASPEED_I2C_SLAVE_STOP;
> -       }
>   
>          switch (bus->slave_state) {
>          case ASPEED_I2C_SLAVE_READ_REQUESTED:
> 
> Thoughts? I haven't tested it, it's just something to throw darts at.
> 
> Andrew
>