From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A91238D3EB for ; Tue, 28 Jul 2026 04:57:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785214623; cv=none; b=eGY3PT1lGWgX9+NSFYJPgK63UVQbZd+jeK6JzU6eV0wfKh7twqEuBGm+1jnTran0zL18yd4thrhExoBXTNJ9AnvGBj2ox40SJ1r2Zgd94K4Nb8djm87zv22Nc3OECjNVbRFpDYWvFRlwq1lwJ9RvLpwlBH9wDCj3kkzKYrU+XQk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785214623; c=relaxed/simple; bh=hOizCD2I6BSt33P6V69HLMaGu7nCr9thzDudHGWN4es=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=k+bor9yM6Ev+6Q6jqwKDySMHqCgMcbk09ZSSwpxop0uOcjnQgBgY/DZnhtXii9DFutDEtGtmYXtPaty8ZvMc4JCHC7W0Tnnt7nvyvH0EYM5qP/g5OHqLR0AGj3Z2kejV+iqNIClHXdOQrdYr9GWPkTcrxp7IJWt5PuPDNGRPFnc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=mF7IchNz; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=S+WoihrQ; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="mF7IchNz"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="S+WoihrQ" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66S3ajlS2692925 for ; Tue, 28 Jul 2026 04:57:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= Qw7DVRkEEx03oALxXwFUYY32n4E2OOmQdIvTxIEA50s=; b=mF7IchNzUxnpeVVE CV3BLuUq58hYR04MpybciSLhDQ7Rm7YdSucWiIRyknCXTNztAHS8Ad8N7VfUZeFN cgX4p5sSCp1noY1Qpp2ppcwx6h4HVCxN/YjQ9uid8x2pd+qp3VOv62bfmfLCL5hv Pm7YsssKIQ1V9WZ/5iHm2Me0cSYbGBz6WebUnVZuSa/Vj7PcNL97mdPYvbDrd4RE GZU++r6DNVZGMr247EGNRwQ4ZQkkQN1PRtkoq5yRFupQO5YO+NgCBPk1/qu2kXen ngbtOQ1NbvSt7oXKddCLmp2sZVIkwfQXb9cOSLFkMLuixN2uelV+XCrXWVl57232 2eojww== Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fpbp5jfx2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 28 Jul 2026 04:57:01 +0000 (GMT) Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-38e7ff7b375so3872552a91.1 for ; Mon, 27 Jul 2026 21:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785214621; x=1785819421; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Qw7DVRkEEx03oALxXwFUYY32n4E2OOmQdIvTxIEA50s=; b=S+WoihrQqXLo+zp3fagIJzVgK917VJIK5uRw0v/z21esjQ6Os+njyrdRbIPA1VrfCs L7SyRJWFB2aFgNcIaAtoM65vv8SBaQROteQ1gNO0ulyrpK7auZK876yUF3AT7m/3N1TN vyKZCJJdXFNi8weq/dTvBIcIzeuQI6I4W0ud+B+CxT181AnqiZ7TizED87U47s9UMWIg 51c7hJs0b/d+CSLc/iTlkrXiqiRY1ZVmp1Q1hvNpGbEslFwxFDhm5oZVYdTHS2gH/SDE 9wRZ+mMl4ZDLRrFqYH9ALxnRTINc0Azd69OV5RAxxJoXQQsIM2hfp8x9KrD22lzC2dfL olEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785214621; x=1785819421; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Qw7DVRkEEx03oALxXwFUYY32n4E2OOmQdIvTxIEA50s=; b=HVvV13Td4cuCShDkYbahWMFzpCBiNtWIf+AFz0DY3FsGxHUfy6qU0BXMZXQjcFGjqy fP0PBQaN+5M+JpgRWRSg6Mew/6JxXw67+v6WPaaHV3kB0tU2PAHgjSpZSzlAokzURhiV UnDjeAUZ0jpMgcCdn85yXpp55e4qWMdNiJJyAn6AzAy2mgbKSwfohkfal3umLR2goCnH sWvOo7NF10iX+5YiiUivXmRInHrZ07jJGs1Hp2q1GhDEdTSGzGv7qcxJRMsnGgtPDY5a tpaN7NeEurUmubHwfSPeN32RKcGd9odHB0xM5wQA3mmqZujaL2bWRaANMUV8AvQPlJaA J+qg== X-Forwarded-Encrypted: i=1; AHgh+RrBSvnV+EG/rDA/R1xWwn+EkGifvjFMzdz0eXNShCg7xqTcxVaHvQz4APBYAajDON6c2qXct6MFvMz5ErM=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6JdDSy2Q3mPocgODhlnTFHVE+D9QXOFIrif/PmBg4PFWp6BWr UDcCQ+UduzOx8YfWkdCF0uRg1wSKlaYNm/Zjj3kVEwrD1BQjDpFzV/RZvzWme7rYrrmL57Bnicf NuHTMSbya9HZniPxXFecbf10ZfZ7ZZiTuLiXSw1vnN2svd3qe9fpQhAyKa0DpGOC/O28= X-Gm-Gg: AR+sD12mUHxo2W6ohpvPxs+J6excKruuoDYWb1brVjKY4AJPO73LPfDFwQnEyoiuBXr o3y26MWWavdjnQ9GtWHoa4SMae8RBAsXGRcpaAqrpLBRTMjxOMUIa2osL7OcT4uUyV2KwgmFVx9 t7pmNEbE90aOykCGKqbPYE4bBe7YSsbV9L7JgaCyhH4lT+LAmX0AUyJtCN/INk+8fqwZY0/9cB1 b+ZTh3W0CEN5Fr4EEjvFP5DIYGrfwi8VhU8DegXHeNDFv7R9aDP4I9iwxA2OfBfeBfv2AjyGOvL BtolKRQUgKd2RkbiHxN/hyoYQDR4Jjm50tooNCYx9iw7pWIFeG7vw2aGHbdcPrYC5brG9qxuLjj Cpg1+E5KPEfFwej7TZYw8giWphTwUzg+aMg== X-Received: by 2002:a05:6a21:1645:b0:3c3:a20f:f729 with SMTP id adf61e73a8af0-3c8aafb4adbmr1134450637.7.1785214620568; Mon, 27 Jul 2026 21:57:00 -0700 (PDT) X-Received: by 2002:a05:6a21:1645:b0:3c3:a20f:f729 with SMTP id adf61e73a8af0-3c8aafb4adbmr1134423637.7.1785214620119; Mon, 27 Jul 2026 21:57:00 -0700 (PDT) Received: from [10.217.219.72] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cbbb66ca388sm4050781a12.28.2026.07.27.21.56.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2026 21:56:59 -0700 (PDT) Message-ID: Date: Tue, 28 Jul 2026 10:26:55 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/2] i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts To: Andi Shyti Cc: Aniket Randive , Viken Dadhaniya , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Wolfram Sang References: <20260720-master-v6-0-671261b05c61@oss.qualcomm.com> <20260720-master-v6-1-671261b05c61@oss.qualcomm.com> <0c0d1406-949b-49ee-b203-3833b9f8433b@oss.qualcomm.com> Content-Language: en-US From: Mukesh Savaliya In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI4MDA0MyBTYWx0ZWRfX6kthdgPECIbt Kd14cUp+y6Vc1jKAk3OglQQLU/otKlAa9vkYMfBHgF26SoMOUoN5mr+aaB2Jy1SWxF+sjp8jpUu lbRyyTiL17+EecnsAggwuNAK3ueted0= X-Authority-Analysis: v=2.4 cv=XuDK/1F9 c=1 sm=1 tr=0 ts=6a68369d cx=c_pps a=0uOsjrqzRL749jD1oC5vDA==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=eoimf2acIAo5FJnRuUoq:22 a=EUspDBNiAAAA:8 a=VvBNldowPlQVTM_YT94A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=mQ_c8vxmzFEMiUWkPHU9:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI4MDA0MyBTYWx0ZWRfX5mrn4h4DFpkC 2IkMiacKHhr/GQTlmJQgHp6glbcq76aPjsxZvJfnbwnTC1744xdVFQeqnsHh2tq0Kl8KwE1Jm7s 1rkSNLcnjoGEsMZjcBMsiYQgCAToLdbZvATb9mzbGcCUBXOqpfzFb23+ieWzDJOHCndzs9U5U/Y yD1v03YinbVoDmzkdwPqC9l5xeJDIw7KhCGQG7YqTcgDG8MLzSdmagfv1EbV1L9k3mpYL41hZca B1PuwtIpp/KaAS9Hf77V/VmW+tT0vX20MfLHEQr9qfVG46c+FFBZ/VWKbFoVipx5cjeGGxoqybx 3VP8oabmMP5zQmNbdhQ/qKcTSCjQMJ8jlW2N0ZEweWyJJmnpQ02X08Ip3nERjmnXHNQ2AH3yuN/ a+PIETtLQB/Sp6fG70fXh+T/Q1BzQOBot26HpybZRJWZssbxY+cofsBeJSjU8V6WXI81o4ufj+r ylHdYadlXbfiB4XvLdw== X-Proofpoint-ORIG-GUID: LHunmPf7blkKqX8MsVSMyf8CFRCkSqdY X-Proofpoint-GUID: LHunmPf7blkKqX8MsVSMyf8CFRCkSqdY X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-28_01,2026-07-27_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 impostorscore=0 phishscore=0 clxscore=1015 suspectscore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607280043 Thanks Andi ! On 7/28/2026 2:12 AM, Andi Shyti wrote: > Hi Mukesh, > > thanks for the nice discussion! > > On Mon, Jul 27, 2026 at 09:45:23AM +0530, Mukesh Savaliya wrote: >> On 7/27/2026 1:41 AM, Andi Shyti wrote: >>> On Mon, Jul 20, 2026 at 05:11:19PM +0530, Aniket Randive wrote: >>>> The transfer timeout for an I2C controller should reflect the actual >>>> message length and bus frequency rather than a static 1-second value. >>>> A static timeout causes unnecessary delays on error paths for short >>>> messages, and may be insufficient for very long transfers. >>>> >>>> Add i2c_update_timeout() to i2c-core which computes a transfer-specific >>>> timeout and stores it directly in the standard adap->timeout field. The >>>> formula accounts for 9 bits per byte (8 data + 1 ACK) at the configured >>>> bus frequency. The caller supplies a safety multiplier and a minimum >>>> floor so that each driver retains full control over its timing policy >>>> without those values becoming public API. >>>> >>>> Storing the result in adap->timeout makes it visible to all consumers of >>>> that field, including the arbitration-loss retry loop in __i2c_transfer(). >>> >>> this patch does not take into account a timeout set by userspace >>> through the I2C_TIMEOUT ioctl. That value would be silently >>> overwritten by the driver. >>> >> >> Can we make timeout handling a kernel responsibility and avoid placing this >> burden on userspace ? Every userspace client already accesses the bus >> through the adapter/core layer, so the kernel has full visibility into >> factors such as bus frequency, transfer size, and controller characteristics >> to compute a sensible default timeout. >> >> Also, if both a userspace provided timeout and a kernel-calculated timeout >> are specified, which one should win? Having two independent timeout >> mechanisms could easily lead to ambiguity and inconsistent behavior. > > There is no explicit policy for this today, and I am not against > a driver selecting a timeout according to its own requirements. > > However, once userspace explicitly sets I2C_TIMEOUT, I would > expect that value to take precedence. Otherwise, the ioctl > succeeds but the value can later be silently overwritten by > the driver. > >>>> Signed-off-by: Aniket Randive >>> >>> ... >>> >>>> +/** >> >> [...] >> >>>> +} >>>> +EXPORT_SYMBOL_GPL(i2c_update_timeout); >>> >>> I'm wondering whether changing the adapter timeout from the I2C >>> core is the right approach. >>> >>> Perhaps i2c_update_timeout() could return the calculated value >>> instead, but then do not see much value in exposing such a small >>> calculation through the I2C core. >>> >>> I know you were advised to move this into the core, but it does >>> not seem particularly useful there and, as it stands, it looks >>> somewhat controversial. >>> >>> Unless there is another good reason for keeping it in the core, >>> I would drop this helper and keep the calculation in the driver. >>> >> >> There may not always be a userspace application available to configure the >> timeout. > Agree. > That is fine. I do not expect userspace to configure the timeout > during normal operation. The ioctl is mostly useful for > debugging > > The driver can still provide its own default when userspace has > not selected one. > yes, agree. >> My suggestion was that the I²C core could derive the timeout based on the >> bus frequency, transfer length, and a reasonable safety margin. This would >> provide a generic solution that works across all clients without requiring >> userspace involvement. > > Is there a standard formula which works for every I2C controller? > My thinking was that we are trying to derive a timeout for transfer completion, so the transfer length and bus frequency should already give us the theoretical on-the-wire transfer time. For example, the transfer time could be estimated from the number of its transferred, including protocol overhead, and then converted into a timeout value: bit_usec = mul_u64_u32_div(len * 9, USEC_PER_SEC, bus_freq_hz); On top of that, we could add a fixed margin to account for interrupt and system scheduling latency before converting the result to jiffies. The exact margin is open for discussion. I was considering something on the order of a few hundred milliseconds (e.g. 500 ms), but perhaps that is still too optimistic on some systems? Alternatively, the core could provide a calculated baseline timeout (transfer time + fixed margin) and allow userspace to add an optional extra offset when needed. That way the default behavior remains automatic and works for most clients, while systems with unusual latency requirements can still increase the timeout without every userspace client having to determine an appropriate value itself. Do you see cases where a transfer-time-based timeout with a generous system-latency margin would still be insufficient? > The timeout may depend on controller specific behaviour, hardware > limitations, clock stretching, FIFO handling and whether the > driver uses interrupts or polling. A calculation based only on > the transfer length and bus frequency does not seem generic > enough to cover all of that. > >> To account for variations in system load, we could optionally expose a DT >> property for an offset or scaling coefficient to tune the computed timeout. >> Even with such tuning, I believe this approach would be significantly better >> than the current fixed 1-second (HZ) timeout. > > I do not think a safety margin or scaling coefficient belongs in > devicetree. Devicetree should describe the hardware, not a > software timeout policy. > > If a controller has a real hardware timeout parameter, that can > be described by the DT. Otherwise, I think the timeout policy > should remain in the driver. > Fully agree, this DT property option is not valid unless its controller implemented. > Thanks, > Andi > >>> Thanks, >>> Andi >>> >>>> + >>