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 0198F3E6DC9 for ; Fri, 24 Jul 2026 11:46:44 +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=1784893608; cv=none; b=X63yZklGqycJGXjSGTlpDcjWWPUwQrnB+q8Mc8RVG+3P+AOwjbzI8e2frN5JFz+lyFj5QcKGPzXOurXC2/0cDM1WwGd9CjICef3Eu0QZcEGB5Qe2vIoeLHXsTnLkF9PGibMPZQRgQB+PwASttKF9YJVgChjJ6QAyKQJcfQfavH0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784893608; c=relaxed/simple; bh=8n53eoM2Ce+D1YY4Gy6RGiqQe9rphv7FbaKlkvmUtCs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=THjOT2kvAJTUd8q3yQ2Xanbo6hV/lv8g7rKOQJ9bXk/hlbb1pJr5+t2Wo70lOz0743f6ZhyH1JK0q6+PVB4AEwzaVvTJR4HDjELKdiNkCU/Bj2pnZ0Va3yZYt2HC7tpcnZ/yCztFhxcUUEvZKtnITNm/PcGLf6OdJ5WJLkcrtBQ= 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=MjDcms/X; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=YL0eiMtf; 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="MjDcms/X"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="YL0eiMtf" 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 66OADT313889294 for ; Fri, 24 Jul 2026 11:46:43 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= 3SF5gXgEdawXvlfPdk58fGjZD60SZQ4PNrCV5dhNWsY=; b=MjDcms/X+ZpI52OI 16NnNQLq0uHJclC587yRKX+/HSDGfcCu6+m2/5vw6NvD4zkhvxtwoxjDMq2MqwUP 8zRbvJOaFbhX6Ete19Mgm3rei1yn5vJ/yyuCnNf/KccD6bLzdFGWTogkc9vxBDRO /aM89aF6X3R9hGTCTY1xqWGfpjS2eLT0X4VK9GeX/k48K7aqzG0tOoMwVAoBtS8d ZC0dbDSNG1z2fesRq7Pup/EYxpAa+31Reo9N3eyTQvu7MszCggsx2fj+dYZbHmZj E139o9+TTR4nmK0qhGrhju++fMY+MaFPiA5bXMf717LXIq1GzRZ8Ns+zd0w/LKi7 nRCqEA== Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fm5f68gb2-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 24 Jul 2026 11:46:43 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2cf7dd9fd91so4187515ad.1 for ; Fri, 24 Jul 2026 04:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784893602; x=1785498402; 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=3SF5gXgEdawXvlfPdk58fGjZD60SZQ4PNrCV5dhNWsY=; b=YL0eiMtfTuS0YsdL7F2y6K+u24oeyGxjZm1gOOnDRTYku2ZKexBIqXzGpqASrTjphP Gbyx3C0PDdTjZseywLyaTkkRV8o6BLPAOwXV86MC95AKRXYpQTdxjnn1CvKHo7ZNx7am CxL5KJqt4sZlvbubauru0gWN2vYyxsUhng5gC9idLlcFYDc6ZxIr9cMu6AB2KmS8AdOA eg7tnRoSMkHkYt5MrsgfZ6g8y7ExBkYeM7dgmRYNMEIZo04RmsZFYfxgGnUKv9wIyp3v g9+mjwsdohZ46hCf8o5pSgvG8NuLOz29NP9UPyooZ1RkLL90oc2CUKGPwb6y7cfsH1/R c4Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784893602; x=1785498402; 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=3SF5gXgEdawXvlfPdk58fGjZD60SZQ4PNrCV5dhNWsY=; b=SCUz7LSvfiMCMXmL32JXAD4Y1e67iCwuc1lx0i6TUYImiQYX+7jGA8xq2Xwv2xC+vs hESNo1ndXPKTj7SXs85153Wo6/tBekHhAMb4M0VGeWpwIZOcubfWNx43vhRU9U/2LWcQ M/gQOCGnRc/2GginzcPUKnyUFb+M3YMg6URK+U/HkA9Hwn4ZwxU+V2P1qqF8evSDPXYR y1JM/kiGWiX/6896XQRHHir5XpKwwBGJvxwE/k/acqcgHPs7Apr9z+0e/nQLJpHSk3Pl puXKqTaPDnJp3w6KccN/osNHQ2whJCjuTunO9uEMb+eIzdsplXsuwjwuFrPpPAt2mo9F /W3A== X-Forwarded-Encrypted: i=1; AHgh+Rp2xXYw0WK6bRf9UVNBQdoQ9Oe0xAhFtykv0eVkLcJjTEXT9iwiDce7kajXoIFepRPIbhYhaFPSFN0ioe0=@vger.kernel.org X-Gm-Message-State: AOJu0YwO0h0UpRLpD8Q4fopWHtac9NFUj/FYM9ZFVrjp3hxoeEJXSmA8 Sx5Ix5d5m9JcP7gxQaEo8R0pbRKfdQnq9nZsh94ylj4LVxSPBU7qiJkjyfDVEOQWyCpmX8UMStE ydgd4WeqpGLhjxM84odiF6T75q7lmUZZgQNNkjzwe4upg6p7MoR32DDi3TzcKJZOYqe8= X-Gm-Gg: AR+sD12Kbkduqk70CgoVpS7sawsgpSmPv1SlgBN04fUQ/BiVW3+gaNfk1xEWUm96STB fUMtXTT0fVLKXGWFmt/T1YSbKsekY1jdVcrmHGJz4efi03oXH0yMmBUUX3pvpErpd3cOs5A3G03 SNQ22Rf1Z43rGHo1Z9xcHnrOjVWB6ZRfoLVXv7KsEXNvNixZSGMc6vibMle80mbAwzcMB4hOnql L0EWaYMKEoaV6IcuiDkI81o+HWkXsf03k20B9iCe4AbVpsvylg4ekTolr+bIY3rZSMCY6Hh/dVk WBxrcbKeZPErVOieBJ1nj1JyET5K5ZWBfZW1PL4XkKCLEaTog/0HJ/r/EA6Rii0TGnN2RGVkOXa SmX4f9DcK5/k7Y+0Wl1hbMkDf3OGGzYEs X-Received: by 2002:a17:903:1246:b0:2ca:4cfd:a6df with SMTP id d9443c01a7336-2cfa6f821aamr82763765ad.43.1784893602481; Fri, 24 Jul 2026 04:46:42 -0700 (PDT) X-Received: by 2002:a17:903:1246:b0:2ca:4cfd:a6df with SMTP id d9443c01a7336-2cfa6f821aamr82763465ad.43.1784893601895; Fri, 24 Jul 2026 04:46:41 -0700 (PDT) Received: from [10.217.218.21] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2cf8efd828asm50332545ad.19.2026.07.24.04.46.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jul 2026 04:46:41 -0700 (PDT) Message-ID: <603b01b5-382c-4da9-93e0-9571721806ae@oss.qualcomm.com> Date: Fri, 24 Jul 2026 17:16:35 +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: Mukesh Savaliya , Andi Shyti , Viken Dadhaniya Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <20260720-master-v6-0-671261b05c61@oss.qualcomm.com> <20260720-master-v6-1-671261b05c61@oss.qualcomm.com> <65d7144c-855a-4b3b-93e1-c18c12f199ac@oss.qualcomm.com> Content-Language: en-US From: Aniket RANDIVE In-Reply-To: <65d7144c-855a-4b3b-93e1-c18c12f199ac@oss.qualcomm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzI0MDEwNyBTYWx0ZWRfX/Th66QPw/DyJ vaTg3BknIIYIC4hK65/v53C9hqV4tfjru7XER/2adHiljAOfWd8xyOt0MYnVeEwDBPYhJ8PKnxd zwTl8m5PIC2vQqJOk4K4mkzMOA7hJCA= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzI0MDEwNyBTYWx0ZWRfX17rITTZ267Da QTf+zBADoZUq8Z8+Cdb0upCebRdW8HqbeZiHmeeAvnQYFO7CHWClWFwoQxQZiEM3RpJOkVnyLgL +FWPYmQkWoVpHSMqVKS4Qp2ejC1KFZruBJwu6BlnGsuTDoCE59wnS9mAV40mmSBC6xbbL4JgHpL u03mSew50t33eWbnFJ6cxt82BcG2Dit0rA7JEiaC5QXoVJkW5vK03ijxqbMLnF7Gma2maeBgaMM LIy/9dXtPKQ5wG4jOkrQeVIsNhpDgrA/ru4g+kVpYk069zg4EcjkY5XypjMCbKPc6ZVeGy8Y8LU e62U3z30Z2gwBOIkUx21ch4NGggc3VypsCvkIheEP4lOgmWmfm9ymZXc9j2x5wtdfoGNlHnqBlt /ZXrMEA4gdfaOjH0lFzJWeze99ycwuKjQ+PrR5oq9UPOMQHc+Xd4CZSANI1TCej8u70qHNrMIwe OoT0L4FpmxChb8GaVGA== X-Proofpoint-GUID: SaSPEPrmOSapy4mHLEjxjeBneewp8ooV X-Authority-Analysis: v=2.4 cv=BNeDalQG c=1 sm=1 tr=0 ts=6a6350a3 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==: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=0liSH36yjE6c7cn47D0A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=uG9DUKGECoFWVXl0Dc02:22 X-Proofpoint-ORIG-GUID: SaSPEPrmOSapy4mHLEjxjeBneewp8ooV 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-24_02,2026-07-22_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 bulkscore=0 impostorscore=0 priorityscore=1501 adultscore=0 phishscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607240107 On 7/22/2026 10:55 AM, Mukesh Savaliya wrote: > > > On 7/20/2026 5:11 PM, 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. >> > in short write as should be relative to the bus speed and data length > instead of any hard coded values. OK. will update the commit message. Thanks, Aniket >> 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(). >> >> Signed-off-by: Aniket Randive >> --- >>   drivers/i2c/i2c-core-base.c | 24 ++++++++++++++++++++++++ >>   include/linux/i2c.h         |  3 +++ >>   2 files changed, 27 insertions(+) >> >> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c >> index 3ec04787a737..3280652e20d8 100644 >> --- a/drivers/i2c/i2c-core-base.c >> +++ b/drivers/i2c/i2c-core-base.c >> @@ -29,6 +29,7 @@ >>   #include >>   #include >>   #include >> +#include >>   #include >>   #include >>   #include >> @@ -2000,6 +2001,29 @@ void i2c_parse_fw_timings(struct device *dev, >> struct i2c_timings *t, bool use_de >>   } >>   EXPORT_SYMBOL_GPL(i2c_parse_fw_timings); > can i2c-core-base.c calculate within and store into adap->timeout ? > Current adap->timeout = HZ can be removed if we add coefficient and > safety factor default ? > > Any other thoughts ? > I think keeping the timeout calculation in the core layer is reasonable, but the core may not have enough information to derive a universally correct timeout value. Different controllers and platforms can operate at different bus frequencies and may require different timeout margins depending on hardware characteristics, clocking, latency. Because of this, a single default coefficient or safety factor in the core could be too aggressive for some platforms and unnecessarily large for others. My preference would be for the core to perform the timeout calculation while allowing bus drivers to provide the required parameters (e.g. floor timeout and safety coefficient). This keeps the calculation centralized while still giving individual controllers the flexibility to tune the timeout based on their hardware requirements. Using a fixed default coefficient/safety factor in the core and removing the existing adap->timeout = HZ fallback may risk regressions on platforms that require a larger timeout margin. Thanks, Aniket >> +/** >> + * i2c_update_timeout - compute and set a dynamic transfer timeout on >> an adapter >> + * @adap: the i2c_adapter whose timeout field will be updated >> + * @bus_freq_hz: I2C bus clock frequency in Hz >> + * @len: transfer length in bytes >> + * @safety_coeff: multiplier applied over the theoretical wire time >> + * @min_usec: minimum timeout floor in microseconds >> + * >> + * Computes a transfer-specific timeout from the message length and bus >> + * frequency, applies a safety multiplier and a minimum floor, then >> stores >> + * the result in adap->timeout (in jiffies).  The caller supplies the >> policy >> + * constants so they remain internal to the driver. >> + */ >> +void i2c_update_timeout(struct i2c_adapter *adap, u32 bus_freq_hz, >> +            size_t len, unsigned int safety_coeff, >> +            unsigned int min_usec) >> +{ >> +    u64 bit_usec = mul_u64_u32_div(len * 9, USEC_PER_SEC, bus_freq_hz); >> + >> +    adap->timeout = usecs_to_jiffies(bit_usec * safety_coeff + >> min_usec); >> +} >> +EXPORT_SYMBOL_GPL(i2c_update_timeout); > why is this exported ? you have alrady added in i2c.h ? Adding in i2c.h file only provides the prototype required for compilation. Since the implementation present in i2c-core-base.c and is called from i2c Geni driver, the symbol must also be exported when the core and driver are built as separate modules. Otherwise modpost reports an undefined symbol for i2c_update_timeout(). Therefore the header declaration and EXPORT_SYMBOL_GPL() serve different purposes and both are required. Thanks, Aniket >> + >>   /* >> ------------------------------------------------------------------------- */ >>   int i2c_for_each_dev(void *data, int (*fn)(struct device *dev, void >> *data)) >> diff --git a/include/linux/i2c.h b/include/linux/i2c.h >> index 14ab4d3055af..b52974eb7e58 100644 >> --- a/include/linux/i2c.h >> +++ b/include/linux/i2c.h >> @@ -912,6 +912,9 @@ void i2c_put_adapter(struct i2c_adapter *adap); >>   unsigned int i2c_adapter_depth(struct i2c_adapter *adapter); >>   void i2c_parse_fw_timings(struct device *dev, struct i2c_timings *t, >> bool use_defaults); >> +void i2c_update_timeout(struct i2c_adapter *adap, u32 bus_freq_hz, >> +            size_t len, unsigned int safety_coeff, >> +            unsigned int min_usec); >>   /* Return the functionality mask */ >>   static inline u32 i2c_get_functionality(struct i2c_adapter *adap) >> >