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 A76043E3145 for ; Thu, 30 Jul 2026 11:53:23 +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=1785412405; cv=none; b=N71l096Pa5rNUMS2R+0Q2cKURzOjk5c9HajKndmUhVbbM+Gm2CeCEnP6Ux73pKKStn+0svKHvuXMGkNbeXAyM2K395Z/06JJBWVQrXITQ/aIIFZ82Ymlyo1Hrhu75W4N3EymrnJUUziNTppb+638ZPIphJLwnb4EeuAzKQ3AmLk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785412405; c=relaxed/simple; bh=5OoeEvG/dPwryXNgdMEmncOH12rZ+80/DKy8v95024o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fwl6dOGo/Jhuexf9oJ74iqT6bcbVxAsJ8Tp0BDhttrrCVs1zGMoto9bpfpToT8WXSu9UiGSLDGSsUGqVX8ZGjCOfY0mHHpUk1dBbIp+HVRCjtWRVO0L1H1pY3KL/aEsZuBAL377rlMalBxDoa0lBM8ofTYpJkGhupEuIRBm239c= 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=YHTspZH5; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=VdSstWV0; 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="YHTspZH5"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="VdSstWV0" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66UBHPQg917816 for ; Thu, 30 Jul 2026 11:53:22 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= ErxhSvVhI8PKtxVKYTOJ15TBdUc3fX8hWfsvKH7O764=; b=YHTspZH5lvvR2Hbk gOg1b+SLZM8Z1HjFRYFNZUSRZc/uY8ildrJCZPGrXmoDTXScUD/bAj/MbSQEaRI/ dU0cHXT3U1P33KZbT+fYMnHwGV3QnPubfpCFEpDtDHrubNjOH08k9HW2VY2sVLcu KRrzPq/+Lozs0zO7WpSRZ07RQh53MeM3DYrXIpmYWoYl1lX2kQF2UjvIQY5pJPfd yu4YBmdNujOrguJ/iet1DsMqDAZ3UXMHPzHsJvTVWff1Qzq2YshJJu77xbupronn b9ZBenu0TCVp6LFHXqK0FII5fuf8+hH6nqgkc7ZT70uF5WXqAFF7dFL7I0BEsxLC Es1Llg== Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fr5m08406-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 30 Jul 2026 11:53:22 +0000 (GMT) Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-84885a4fcabso2623148b3a.3 for ; Thu, 30 Jul 2026 04:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1785412401; x=1786017201; 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=ErxhSvVhI8PKtxVKYTOJ15TBdUc3fX8hWfsvKH7O764=; b=VdSstWV0IPpVuTlTF8he2QT8/OAYUZ2EX+vQEG4DxMZsL9VnwD2DBgzhWSP4WKBOzT 97K+Dv8ghseg9BAsi6HV+3A8hbu176eeSSlaHkj+sldBkTFzaZX0QkFqDRU8kWZeQ/bC WZRRAoAbj9686Mr+WjSR29/KUr+aZzUGUfm5tinjtGHOi3aAW9+ZbMUJmrhThefLzOZK ip3oO/i+RZwjhr24s2SLLgc2n0XHzu+ypiZ+Bz4mQx5eF0TGDf8DuvoSklMyyx0qE63J TyockPExwpaLKSzhVfow31rRgJo2bhs384skcXdK4lB79uN58CqyACr1/hr3sX5SS4wj ROhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785412401; x=1786017201; 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=ErxhSvVhI8PKtxVKYTOJ15TBdUc3fX8hWfsvKH7O764=; b=jnubz5AHMaSI8LjRdYlJp/488yYPXj+MuZst+QH3vWtlijQlFEajkD/H9SI/3EeV0Z HAABrXOKizS447rzewP8CIjPp+ng7pofFIjZNMD6o3aSqle1cREnd9O0A8rTpU4NUj9M WlJu/auTpLzJt1RwiIgYKzMu7s+qMdDvw7Bj0pIFEuw99BgPANp/0CNb7Kutsd3N0ymN UGr+GDM+0tWaPRowkb3nryCuazCCBaalX6HLlzAcrWodedd4Q/8w5tJgqlaQjqxrHXzX r23jyzWGbVuvNnNKyMnooyeDw3pQUsHATb5N104nx+5VYI9qIJdVU4ynrJgOq7JOKIPJ IAYA== X-Forwarded-Encrypted: i=1; AHgh+RqaWbPyv3n1NI0Tqnbkcv8Stve7oZYfyeAXtUlq+fy47bdlqR6LZNJbTGL75sEWQsGCCiBmO0bQ8YpSE/k=@vger.kernel.org X-Gm-Message-State: AOJu0YzxbIWIIe6fljs7xKAtfzViBXfheVzRYpi07sNhUX0AN/RvYO0O +xbd2bRNo8fY4KAj70l/gTeYjkzqjE2o5ZxCYW/Oct1h8pwUiiHoK1KD4dCly1UbU3kupAvjd4b dR8MVYcvBSMqAmc+q8xnWFew9fFcg+NqiKcMcxofdvSyFC6DWz0dsAm5gAJRGKuz5178= X-Gm-Gg: AR+sD10srNWMewV49FJ1QZIbAB5tVGmzbcXOwbqs+XwOT1wBaBYbYOcoAsFfQifAkct HJf0Pv5AsmveTiLX0QDDyz840y67ryKhzzrvlJZGDvZ/vvA/ZBf1K/ZqWgLXlru5xSJLzL5430y QPzU8CfDxg3/WBsYH/QvR56BFKVdnHh1OLcTU1Wax5eA/nWwL2VVSeoxezLVehsOhMgxOIwhGuI z7BTbMDK3T98kcFFYA7us6K3gokHyexkebAM4+sM8MQOJwlophMlt57Sx/wyn2ms42KpasXX/dR CWqni2l7VoYboT4Maj92tU5WEdAtXpfHp92aWwkbnnzxwPIQMWdchhIwSA/Yho+5WD1HKl2dxyg 0kgWZmTWP+ag3jYI1Fg1klCiZ24ons/KO X-Received: by 2002:a05:6a00:400b:b0:848:4ff5:5316 with SMTP id d2e1a72fcca58-84ebc22bc30mr2281097b3a.19.1785412401353; Thu, 30 Jul 2026 04:53:21 -0700 (PDT) X-Received: by 2002:a05:6a00:400b:b0:848:4ff5:5316 with SMTP id d2e1a72fcca58-84ebc22bc30mr2281077b3a.19.1785412400868; Thu, 30 Jul 2026 04:53:20 -0700 (PDT) Received: from [10.217.218.73] ([202.46.22.19]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84ea7344ca8sm2615829b3a.21.2026.07.30.04.53.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2026 04:53:20 -0700 (PDT) Message-ID: Date: Thu, 30 Jul 2026 17:23:14 +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 , Mukesh Savaliya Cc: Andi Shyti , 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: Aniket RANDIVE In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: CI51MqD2UBomKY4H5yzGA8cnn9BIqOEc X-Proofpoint-ORIG-GUID: CI51MqD2UBomKY4H5yzGA8cnn9BIqOEc X-Proofpoint-Spam-Info: AW1haW4tMjYwNzMwMDA4OSBTYWx0ZWRfXwxF86JXGbhlL muiHtWKBPCkh/QBVwLmFICeszjzRCvDnhWP7qWUUUA9YXGCpstwpSlQJYl4Vilo3juOQ4Cwud0C v6ojj2KvSMLXjOqM/o0uN0viMoOCZ4s= X-Authority-Analysis: v=2.4 cv=esPvCIpX c=1 sm=1 tr=0 ts=6a6b3b32 cx=c_pps a=rEQLjTOiSrHUhVqRoksmgQ==:117 a=fChuTYTh2wq5r3m49p7fHw==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=mCY9CKRV9xF68oVvIlMA:9 a=QEXdDO2ut3YA:10 a=2VI0MkxyNR6bbpdq8BZq:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzMwMDA4OSBTYWx0ZWRfX55+tMtqlvpke 98oN2FIgl9o0Pk4pdz0R8hP2DRYrnV8X5rZnMmE2UvRJ+1uvQ5rYq9xpgeWrbNagsq74PSYIz1E Geb/4yTMHV+gMd2VLfLJvWk2ythWXLeeVoaQP1w2Y/6C17fNBHKlu+55ILeG+IjmV7nAQFivRBR hWeNkc10kmkb34TrfhqypH6wB5wzCeP831iuqKWnxrrYzucuEzkbsHYps4pHadNEj6Ap3DCmKrj gBoMy9wHJzJUO2oyoGSrHD8mwZf+SK9LcAdf71Hq12AGZyXZB3WgqbiB7UQ3QosbDxssc0CWB26 zd5G0gmPPwS/RpH8VsX0saGJIwCdj3tz3Edi8qXKIFdjfmhmXNQJ8BSe3zpywtvy2gEqkBnQxxR /pfcroByJr8GLKcTZGFoturzyTrFfRaqE+6Y/c4SkDQf+eC94P/6ci3rca5+38IwyOZVCISgxya sO+tegz2OuUxC7i7YwA== 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-30_03,2026-07-29_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607300089 Thanks Andi and Wolfram for the detailed feedback. From the discussion, I understand there are concerns about introducing a generic timeout policy in the I2C core due to potential regressions, platform-specific behavior and interaction with existing timeout mechanisms. My primary goal is to reduce the excessive timeout delays rather than to change the generic I2C core timeout policy. Given the feedback so far, would maintainers prefer that if i drop the core helper entirely and keep the dynamic timeout calculation local to the qcom-geni driver or should we continue exploring an opt-in core-based approach? I'd appreciate maintainers' feedback on the preferred direction so I can align the next revision accordingly. Thanks, Aniket 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. > >> 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? > >> 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? > >> >> 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. > >>>> 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. > >> 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... > > Happy hacking, > > Wolfram >