Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Message-ID: <a1cd2239-d8b7-412e-bca6-ebcf3a19ed65@os.amperecomputing.com>
Date:   Fri, 1 Dec 2023 18:47:30 +0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] mctp i2c: Requeue the packet when arbitration is lost
Content-Language: en-CA
To:     Jeremy Kerr <jk@codeconstruct.com.au>,
        Matt Johnston <matt@codeconstruct.com.au>,
        "David S . Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, openbmc@lists.ozlabs.org,
        Open Source Submission <patches@amperecomputing.com>
Cc:     Phong Vo <phong@os.amperecomputing.com>,
        Thang Nguyen <thang@os.amperecomputing.com>,
        Dung Cao <dung@os.amperecomputing.com>
References: <20231130075247.3078931-1-quan@os.amperecomputing.com>
 <473048522551f1cae5273eb4cd31b732d6e33e53.camel@codeconstruct.com.au>
 <706506b7-a89c-4dfc-b233-be7822eb056e@os.amperecomputing.com>
 <852eaa7b5040124049e51ceba2d13a5799cb6748.camel@codeconstruct.com.au>
 <3e8b18e6-673c-4ee6-a56b-08641c605efc@os.amperecomputing.com>
 <10491ca5819563f98e2f4414836fd4da0c84c753.camel@codeconstruct.com.au>
From:   Quan Nguyen <quan@os.amperecomputing.com>
In-Reply-To: <10491ca5819563f98e2f4414836fd4da0c84c753.camel@codeconstruct.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WUF0TnBjSURmcUVYNENoNEhRYXBoNkVDQ1VOYUd5TGZYVnZTM0t5MUtBQmdJ?=
 =?utf-8?B?aWRVVXBacEhEU29oWllOYm9CcnMzWHgwZVc3WCtFcnhVdmlIUitseFpPUEl3?=
 =?utf-8?B?Y0RXa0JBT0RWLzB3c1J5QW1tOUZpOUFRVmxZL0pyVG9GVjNEU3Y1K0dzbjNQ?=
 =?utf-8?B?QkFwV2FJL01MSmtScWlKRmE3aVQ2NnQrbjIwNmd1alRLUkQ0MGw4UW0rckF6?=
 =?utf-8?B?Ym9wNjN6SE14TEtSdG56aGJDZ1kxMkRiOW4xUklzVTlXVWUrQVVjZHpVNGFV?=
 =?utf-8?B?UHNVcEZBaWt6WnBEOGMzOGdLRFcwN20veGNCUzA0eFpScTZkNEdjTWhFdTdI?=
 =?utf-8?B?VndKcjNWUE1kbFVzcFRQcFNma1ZxTElYTENHZnNhYzhCM2NTN3c2eG8zZndi?=
 =?utf-8?B?emZ3Y0wySThZUzYvWmRrc2RQNStGcDgxNE1zRlhjR0lVZk96Q2k5M3dNVllI?=
 =?utf-8?B?VUJ5Nm1jRWo0TXlPWWF5YlVhNjYxYjBRdnZDZHlCZjZhelpOTmZpdFN6Qlo3?=
 =?utf-8?B?Ry9FVm84WE5iNU1EMUlvczJCWDE0MHZVQzcrNzEwc2xpdC9FK0xiUVZuOUZr?=
 =?utf-8?B?QlNXTEEvdGx0bDI0eEJGMTB6OURNVXI5T1dkdURYTWMyVEhndnlnR2c5YUlV?=
 =?utf-8?B?Rks5Qlh3NFJ3dTg5OHhGUTFJOW15RjhhVkYyNmZFSUk5SUx6Vnk4M0E2Y1VW?=
 =?utf-8?B?UTFKTS9CaUpoTFZBcXBRWjNlazVGTUgrTFpnem56MGNZSjR1d1RrZHNZaGsw?=
 =?utf-8?B?TTZKK3oyTHVhWVZlemg5bWlpUzN2Q24rYUJlc1BFTXlFT3NSck5WRjZjbzVo?=
 =?utf-8?B?UUhCdC95T25oK1N4UnNsSmpXRUJtakg1cU9Idy9NVHFSd0VKTmM5b0UrSWxQ?=
 =?utf-8?B?a1RyeG5RVjRXYktvYjhVVjNHR25MNURrNXY2QUd1ckpHckpQRVA2MWFRQ0wx?=
 =?utf-8?B?MVYzZ1paenBKOVlldVlvU3RGNk5OT0JaWlpHN1grZzlyVFZCZUJKWWxSYlZi?=
 =?utf-8?B?YkZOVnBLRkU1U1hhMzFlMDVxZDZlZ3BKQ2t3K0tkZ0hyb1cwdTl0MExlM2Fi?=
 =?utf-8?B?Sm56YkhsQ1RnWlBIV3JlcElIZTVweWtwcnhnY3dmQjdZcjVNZ0EzOHRNWmls?=
 =?utf-8?B?RjJUSjZvNzRoeTZHU1oramtGTEFTMGZCeXkwRnlSeWFXRStWaVlVcFRJcFB3?=
 =?utf-8?B?M0dqZUREWlB0L2tYTTBvdmFXbC9laGpxZm5uQnlQSGpjK2JKdjhpYlEyZm9y?=
 =?utf-8?B?cys3USthaXBqYkZVa0NWRnVoaGxzRzlTdzJxY0t6RnFkNlQ0eS9kM21sSHF5?=
 =?utf-8?B?WExrRUNtNHJhZUlyWXRlVC95aldoZjdhR3F4cTdPcjhZZHRPMTVBVDVTa0lw?=
 =?utf-8?B?OFVlZ29WT2JMU1FjSGJVSnVvYkFEVCs4L2d0WUIwazRZdU54U1NJYzJWL2tx?=
 =?utf-8?B?RWpXanJPejRQNG9BODNjMFNsZWwyNkVzRlhrdzRaZ2JEZnFnS2RET3lUVFpL?=
 =?utf-8?B?T1MvbC9mQ0N0eGI1aTRDR21NOXk2azdMZFIrRUc2NzlrY3Q3STlRWFZhbkJa?=
 =?utf-8?B?djBvV3o0Y0RYTXNLSU5pNlA1eTg3VFk5YUhGUUFnMWxJdW9QN29rMjVEMjJs?=
 =?utf-8?B?WWtSaTh6T2Y4Y2tnTTFCQjdJZ3A0bmRabFZJRllvQ2ZUUEFJNFNBdEtEQzBt?=
 =?utf-8?B?b0ZWSWVicGZ6SWR0dVhXYzhFMnluVnpBSzRoS0pDNDNPK1FlK0NvNXdIbzFL?=
 =?utf-8?B?MEViQ2ZKTWthcmhaVWhGczh0aDFmUm9RL2FlK0lvL05Oc1JTUU1WK2dQL1dw?=
 =?utf-8?B?ZlpPdE1ud1dDR3NzVDhZbWJWbmQ2QXFlMGxISWg1amo0Y3pDS3dYNUthbmVo?=
 =?utf-8?B?cE5JQWF0dzNKcmpHN0ZnV205ZlJTTzlESFl2d1Q5RVM3a0xxODd1R0lRVU9q?=
 =?utf-8?B?cTRmcDRVRUVBcENBRkZRTlpjTEpNb0NuRVBDYWt2ZHM2b0hObXMxN1dEOG04?=
 =?utf-8?B?a3ZVZVRKQ0docTVmT0loM1dmSURmZVR4L1pmbmVLWTFpS1lwTFlyRFZzUm9z?=
 =?utf-8?B?bnZIbWpmY0UyejNDM3JURWFvZVc4TTgrWFNyRENMQUEzU1dCUlZmNzBvcnJi?=
 =?utf-8?B?WS9DcXBYbkJ6RTB0Uk96VCtuK1U2b0xOdTZmMHBQUlVTYXJBR3BOSnpERWZK?=
 =?utf-8?Q?fbylirROov361hSgWNHxPTI=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eeda1e2c-faf2-42c6-8794-08dbf263529e
X-MS-Exchange-CrossTenant-AuthSource: SN4PR01MB7455.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2023 11:47:40.7068
 (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: OW4vKbk21x9ANkTXErXCKvx7cAgSgBkuh9FfzdXz0eHr0Ck1CEUAE5ob1TFG0rxhEfifRKSAFioJxZcZS4UtuMvE/VjjLX9QS1hprnrmRlk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR01MB7963
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
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 (pete.vger.email [0.0.0.0]); Fri, 01 Dec 2023 03:47:56 -0800 (PST)


On 01/12/2023 15:38, Jeremy Kerr wrote:
> Hi Quan,
> 
>> As per [1], __i2c_transfer() will retry for adap->retries times
>> consecutively (without any wait) within the amount of time specified
>> by adap->timeout.
>>
>> So as per my observation, once it loses the arbitration, the next
>> retry is most likely still lost as another controller who win the
>> arbitration may still be using the bus.
> 
> In general (and specifically with your hardware setup), the controller
> should be waiting for a bus-idle state before attempting the
> retransmission. You may well hit another arbitration loss after that,
> but it won't be from the same bus activity.
> 

Yes, that is the correct behaviour and I think that is why 
__i2c_transfer() return -EAGAIN when arbitration loss.

One example I could find in kernel tree is here [a], and, it seems not 
to totally rely on the retry mechanism implemented in i2c core.

[a] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/omap2/omapfb/displays/connector-dvi.c#n157

Anyway, it's been great to discuss on this topic. To answer your 
questions I did have to dig around and have learn a lot. :-)

My sincere thanks to you,
- Quan