From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 98B65401A08 for ; Mon, 3 Aug 2026 11:53:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785757993; cv=none; b=m3SYBoFntpGN6M/5o7ZZBwqVZ1UggooiwJ9SPjx5W5/mFQohHxnYVaTCxv6w5VG2l5tPIR+TeTRoDkbKw3grNj6GuxSUOKR5IfaS6lw2w0QAyjiHZxlnx0UOh+rnl/6x/zk9kX+sZVfipZVTchw0GbbN9UDzItqN92c48fljXbk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785757993; c=relaxed/simple; bh=QPMfb7PH/FW/3fQxDmXCxGhBEzh8VvZFJy2z3YTvdFM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HuAe2ogfogj4BbjP3pDIi3NgnwY1PLAoApwrPEXFrW0Fnv0AMj41OABSLx4qeJ1jKxTQHln4pSLhZyy3N4WEFCLPnvQCmZpZY+Y7uyWsXiK0IXKTw+ouWrlxRcA5meVLdmV0aAGcrBY1Bh06yoBRzcO8hYJkEKtqrem/7kQgzuI= 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=f7iL76D+; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=UESNo0K3; arc=none smtp.client-ip=205.220.180.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="f7iL76D+"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="UESNo0K3" Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 673AoeTB005446 for ; Mon, 3 Aug 2026 11:53:09 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= ANbJ35W2w7wHbP80PHRITYp2hrjcSU+XMTRXmCym8Iw=; b=f7iL76D+hAYHAl7V AW0CBa0F6bQ4TqvRP/BpFeSj8BhEaQq1oFwc9DZp0MGlUOatN/9B1fFMqaeI3tE7 BN0K0BzpwzCkjIc6bZV+kLf6J+ZGgKCXkzhcsT3AWJ77JMRwx8P0kyuf/spgDc7D mJcGGabt5wItyYd71rPQ1ZEUxHnjenLT7bsNhfz9Upt90igWRe4oRisKT+Hfi9jT 3bk9UZ5zvXx7qgjkUoREhgYzcbkhri3JwYTmtdTzSGF8VA+lIBSo2u9holIVaO8c p81mBHXQphzSu/5he5b0cpkgFGQDqCETJK8mImZLdlRJiWv0kDd/OIovud2qPUlk mRWV1Q== Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ftnj79c4d-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Mon, 03 Aug 2026 11:53:09 +0000 (GMT) Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-38e25e4b41cso3722145a91.0 for ; Mon, 03 Aug 2026 04:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785757988; x=1786362788; 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=ANbJ35W2w7wHbP80PHRITYp2hrjcSU+XMTRXmCym8Iw=; b=UESNo0K31N+ACHGoiGrf9ww/DDmqRStN6rNTw8lWTb5x4zVIha2XCscYc7pLzYMgsn w7e7UIZ10ezpnXQEcoGVbGWIUDWtSbKe3g82BR3GzTF5OF+/ShCkJkKL1RFJk7zFMgQJ 9w75v1HzDCCGpINz6hRU782eRUgv0Sl54ggPXt6ZX64fgvl+RvKyw4vV0+kfsB2XPYAP HU6NrzQsy0Fkc/iQieq64TsNTqT8Z89tHgZzUseBMQSkCXyKMa3n15L4oKHs+CBo/rTl r3WFQsqMsETrcOfe9Xv57qqxECNFG2ZBH7/78fQTZwkva9owsUHZ0t78CMwF9FVilHwB Zp9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785757988; x=1786362788; 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=ANbJ35W2w7wHbP80PHRITYp2hrjcSU+XMTRXmCym8Iw=; b=mL11/y4fJvXScUFa25E7Svftqr3FCDAkAWO5n3nmasIml69hMZilOTAxBpdoEgWYn+ KqO4mxdFImNoVlgKSdO94GaYadudtXyxDv7GSYGeB2b+9TOMH5U/r2v1VuBdgDW8y8Ds mI1unscGG6GQ7g4ITC4B1RTBGeTZ4rFnKeE3TpfLB6P7ouT4Zgh2GHYATbDTXJZGtkB7 QneUrGD0qNFxDjeucaQaYFTikRMdsHmJE27/plXPGN9o9tiskSS5BoXFVHG1Zpv2qJ8G C6SFBTFP+kgpbVDvd519SG2BM+k0gxCB0eR4I1rDBZhS6uiU3hWyuVEuvCdHWuVYIf4Y M5yw== X-Forwarded-Encrypted: i=1; AHgh+RqqtPMax/NIE1pgkY/AHIjATnTps6IMdg/ZTQx56Jy54p1adV+8un8RepRaHEUK5Zwoe3fA5vakUWt0Fm8=@vger.kernel.org X-Gm-Message-State: AOJu0YzhTMJVLMsels496chv5QpTZlhf4Y1c14mZeR5jC9jFADBj6wwA BY6ntZeQwxVykK8P97Z5p/4rx04E2rAXLp0TcXiVeD9BUSc8vDsApFA/UFziY2e5YniQ+xo6Fzk Bwe7ELTBBSVpX7t9U6CuwbjAb2owO2ZEqOYexLu7ZBp2Q8iPh5BzL0JSGJnxXZN5RsXI= X-Gm-Gg: AR+sD12qUU/OamZiUKl5+yofi1rgJtC3ozTnZlDheTjPRtAB6hAJ9uaTC47oCNpOhAW 56bt4kJvywo1xdEgtLcs5or9sall1h9kogELlRAiChDP6m+iQa5jNSw5C4ZtvbwPCFCPYdDQiyD RYVnUIA2kRCdrsE1zmIAlGzak7E2Xac7QAccYp2EAjNs9hc6SV2faC/Zs+pcHHPK87LDZTaW96q RlviLLwcTLC/KiFpSpnttz8onbiSPuuztUSxXzUFojcAFNlGMdzG3heGuBEFC0E1alAn/4E3ciA Q28KkTcgFUQu3jICDY6ExiGfe4JllPmhNV1EV4/QFi5+296zM/6ADFrS9yYEYN48GdDtc44OulO 77ncTL/qb1f6WPsB0ma3rXW/A3DHdKZC47+kbfTYyhIqQ6wHTWstyAZc+ccvLEc2D6IeNoWEcuA == X-Received: by 2002:a17:90b:3907:b0:38e:584f:2515 with SMTP id 98e67ed59e1d1-38fbc58dfc0mr9241450a91.37.1785757988501; Mon, 03 Aug 2026 04:53:08 -0700 (PDT) X-Received: by 2002:a17:90b:3907:b0:38e:584f:2515 with SMTP id 98e67ed59e1d1-38fbc58dfc0mr9241426a91.37.1785757987987; Mon, 03 Aug 2026 04:53:07 -0700 (PDT) Received: from ?IPV6:2401:4900:35ff:d6c2:a5e8:b0b6:83b9:a3fe? ([2401:4900:35ff:d6c2:a5e8:b0b6:83b9:a3fe]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-38fb2b999cdsm2008994a91.3.2026.08.03.04.53.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Aug 2026 04:53:07 -0700 (PDT) Message-ID: <9dcc47cd-2470-45b2-9106-51d4636cf60e@oss.qualcomm.com> Date: Mon, 3 Aug 2026 17:22:59 +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: Wolfram Sang Cc: Andi Shyti , 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: 7bit X-Proofpoint-ORIG-GUID: NivecXhYflzDHxjJZiZyo8t0cIZ7N_d7 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODAzMDEwNiBTYWx0ZWRfX2ZOy9ZdDI4zf 1MtfNEOoLov9x2wJR038TIuRX0QY5VDgMjbBNJmv1yCKIFYmehC5YGVGgkJ6EdSgMjKtY8y8nZl FUDuBjgnWFY67gONaLMwuElBfTveJXm7eardq4o2BgjOuiSuFwj75bpGnOnN4fc3Omndz6TBkEM RcauIEuEkNENwhbpSwX8ao8EBSY+teKQc3K8DzaJ4B4zJJrxjshezYdwO0je6TYuLwBL6sjO8aA 55igZMrQZPLG6gtDqrNLQrHuy9D8v02TjrCwf3e/wKxD5AUfkgvwBDJJI3okhOwD8SB7b7wWMej X8BOLw8wwS8tF515HFhBCtq29QONHhJPw2wdV7Ux/sWVXYPP4sone04f2otjz0jp3beeJCWp330 WnurNlO3HEdB0HGM3Bc4hCd9x4oErwECU0z/oQfBdFZup3oyirfpeS9TCsMD8+xmYoxxAqqdzFc B4r93PhTfKSQ0dE6TcQ== X-Proofpoint-GUID: NivecXhYflzDHxjJZiZyo8t0cIZ7N_d7 X-Authority-Analysis: v=2.4 cv=PqSjqQM3 c=1 sm=1 tr=0 ts=6a708125 cx=c_pps a=UNFcQwm+pnOIJct1K4W+Mw==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=_glEPmIy2e8OvE2BGh3C:22 a=dTr6nt17rhk5w4SCxJcA:9 a=QEXdDO2ut3YA:10 a=O8hF6Hzn-FEA:10 a=uKXjsCUrEbL0IQVhDsJ9:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwODAzMDEwNiBTYWx0ZWRfX99sBS0Ew8MDM KSl9CVgJwW/fu5gqZtcj4OFm+2j6TILS0pSsYOXh9lfy4fNNdH+pHqbCXfWv1qzWHFWREHGxOhm ibhu1eMyBmzDdV7w4Qkr2ty9vQk7urM= 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-08-02_06,2026-07-30_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 spamscore=0 priorityscore=1501 adultscore=0 clxscore=1015 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608030106 On 7/29/2026 8:49 PM, Wolfram Sang wrote: > Hi, > >> I agree that the precise timeout is platform dependent and cannot be derived >> exactly from the transfer parameters alone. My intention is not to determine >> the perfect value, but rather to provide a reasonable kernel-side default >> for cases where no timeout has been configured explicitly. > > We have that already. From the I2C core: > > 1572 /* Set default timeout to 1 second if not already set */ > 1573 if (adap->timeout == 0) > 1574 adap->timeout = HZ; > > This may not meet your definition of 'reasonable', though, I understand > that. But you need to be aware that you immediately enter > regression-area if you change this behaviour. > Yes, 1HZ it's not reasonable for smaller transfers. Agree too that changing this may cause regression to few others. >> Since kernel-space clients have no generic mechanism to tune adapter >> timeouts on a per-system basis, deriving a baseline from the transfer length > > This would be easy to add. We could introduce > i2c_client_request_timeout_margin(client, desired_timeout) or something alike > with basically doing: > > client->adapter->timeout = max(client->adapter->timeout, desired_timeout); > > Or? Then we would get the theoretical value of a client. Which is maybe > exceeded by the board specific timeout set by the board designer. It > gets tricky, though, with userspace. Who has precedence then? > Thinking to give precedence to user space here in such case. if no userspace setting timeout, then default will continue with core set timeout. >> I am also suggesting let userspace add something on top of this if the core >> derived final timeout is not sufficient. > > Why can't userspace set an absolute value like now? > So, does it mean user space can override kernel/core calculated timeout ? if yes, i agree to this idea. >> >> This is an option for userspace. Should we expose device attributes for >> kernel space ? > > See above. adap->timeout is easily accessible. > >> Yes, and I fully support keeping I2C_TIMEOUT as the mechanism for userspace >> adjustment. What I am proposing is complementary rather than a replacement. >> The core could calculate a baseline timeout from the transfer >> characteristics and apply a conservative margin, while I2C_TIMEOUT would >> remain available for systems that require additional headroom beyond the >> default calculation. > > If you have two ways of setting a timeout, people might get confused. > In that case, let's decide if userspace configured timeout wins. If not set by user, then set calculated timeout by core layer. I was thinking, user space may not always set the timeout but core layer will always need some timeout value based on formulae aniket has kept. >>>> Do you see cases where a transfer-time-based timeout with a generous >>>> system-latency margin would still be insufficient? >>> >>> Regressions. You could time out too early on boards which worked before. >> >> That is a valid concern. My assumption is that any calculated timeout would >> include a sufficiently conservative margin, based on measurements across a >> range of systems, so that existing working platforms would not regress. > > You simply cannot guarantee this. > Understood now, it may cause regression. >> platform still requires significantly larger values due to exceptional >> latency characteristics, I would expect that requirement to be addressed >> through the existing timeout override mechanism rather than by forcing every >> client to use a large fixed timeout. > > The only way to deal with this is 'opt_in', not 'opt_out'. If you want > to provide different defaults than the existing ones, I think you should > make this available via a kernel config option, so somebody has to make > an active decision "I want that and I know it can regress". > > I am still not convinced this is all worth the hazzle, but let's keep > discussing... > This looks like a reasonable compromise to discuss and converge on. A polished version: 1. Userspace-configured timeout takes precedence over any timeout configured by the kernel. 2. When userspace does not configure a timeout, the kernel-computed timeout is used. 3. To avoid regressions, introduce a Kconfig option for formula-based timeout calculation: A. If the Kconfig option is enabled, derive the timeout using the proposed formula-based approach. B. If the Kconfig option is disabled, retain the existing default timeout behavior (currently 1 second) to preserve backward compatibility. > Happy hacking, > > Wolfram >