From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C04AA330672; Fri, 20 Feb 2026 11:58:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771588703; cv=none; b=pOH2pU9ql6kC+zFXaESMbSTrtUv73s0nK7tw0B9vvKv7eQSjl27FspifPXXuO827EKQ+kWhbkkD1v9H9D7NahhOVoz+gMNHsVTvSAxGNvocsP+cTgMx0QPX6P9khBNqDRAUgPDYdCofOFzu1RCbg+u7Zujb0UoU5auvGy0zDZU4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771588703; c=relaxed/simple; bh=zxJ10CPWNenVjOytvEp2o8sITibPES2ZbboQs8lwLBQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BBX5bzApP6kgexD+vZhhAdoSTfi+zrJiBk2IN8IFhmIaD7hRRyFpvBIFU2xZXHTfIT1z3NuqgIXImXp/NzfnOBVzdzCx312+gxoSnRD7HcyJT+MFR5Od5COeEBKQBXGmdoxSWdGbsW2ZG13AmnSamff3ntb0EvF869PS+ZOS5Dw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H3LBGCre; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H3LBGCre" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9102BC116C6; Fri, 20 Feb 2026 11:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771588703; bh=zxJ10CPWNenVjOytvEp2o8sITibPES2ZbboQs8lwLBQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=H3LBGCre+QnYZCgpiFlnCLZlGip5xhDmJZJ4rJvQeDi9ffJQMQryqoMsmgbYgUgk9 IqD9ySuu+lL+WTVhEMIx7BKkECAxKPjs1cDbDl7N9+Q5wm5OgXNWXs0gJMOWXwWQDA XfybsvujIGtqxp6wVRgAjyZbJhMIiWZj8SY1LZ/P3cnu2sziC/MXkH7tFyyz8PzAWq hLEF/z1hDqBNr7nak1jfAuv2KhrfTK5zqFrukEKil3oKvbEVouMUC7mMYB3htzCk9H MWxQQQTKPGIcWvbbmt9KuLKovkBazn4FPWNMi3otc10QQ2L98qgmV6tDzP1QVxMofn TOpVADeeelEEg== Message-ID: <23cd47a7-75a6-4ed7-af8e-c0ecedcda6ef@kernel.org> Date: Fri, 20 Feb 2026 12:58:16 +0100 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/5] Battery temperature ADC plumbing on Qualcomm platforms To: Luca Weiss , Jonathan Cameron , David Lechner , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , "Rafael J. Wysocki" , Daniel Lezcano , Zhang Rui , Lukasz Luba , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Laxman Dewangan , Bjorn Andersson , Konrad Dybcio , Jens Reidel , Casey Connolly Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org References: <20260220-bat-temp-adc-v2-0-fe34ed4ea851@fairphone.com> From: Hans de Goede Content-Language: en-US, nl In-Reply-To: <20260220-bat-temp-adc-v2-0-fe34ed4ea851@fairphone.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi All, On 20-Feb-26 10:19, Luca Weiss wrote: > This implements a solution to get battery temperature readings working > on (for example) smartphones with Qualcomm SoCs. > > The solution chosen in downstream Qualcomm kernels is exposing > ADC_BAT_THERM_PU* in the ADC driver as temperature channels with the > lookup table ("struct vadc_map_pt") for the specific NTC found in a > device's battery patched to adjust the lookup table. Patching a kernel > per-device is obviously nothing we can put upstream. > > The high level solution proposed here: > * ADC driver provides temperature channel in (milli)volt as IIO channel > * generic-adc-thermal driver converts voltage to temperature based on > provided lookup table from DT (driver has one IIO channel input, one > IIO channel output) > * The fuel gauge driver can use that temperature IIO channel to expose > battery temperature via the power supply device Nice, I agree that this seems the best way forward, especially taking into account that the generic-adc-thermal driver now already supports the IIO -> IIO path case. Regards, Hans