From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A7DE2989B4 for ; Mon, 17 Nov 2025 15:48:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763394495; cv=none; b=ahbkE2hUobVxAe72ZyRf1l9nHQNzuAKMH5BGbEsMJ/4uKCHwBa/3MLpGY8f+dd4T5Jgi7aXXJ8vuNBzEC2hKfbqEWPKnttWfwq7c9lUW4KLyP+8op8agmk1bQJnBQrGoFMDG5OL+qZzpepOfOucEB/LmwHxq5x44PLzRBMgzRQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763394495; c=relaxed/simple; bh=ROYTcX0lToNnERFrzzVSCpniaTAJj6i4Bcg2Nx6hBo0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aVz90+b7AUzDyr88Gn/35r3DmeTTpVa9Hz6PKEKNzJuJxQNgadJAsGSdF4xUuFYxcCHhCha7qY1p4+aVGT2a1h1+GxgXHx9efJTOTtmgzhuLhQtwsaLQqATUaX3m5ndY2V0elzimZkxTspJVMM0i+fc4euFPrMjkbdweUGC6HkU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=COEwFccW; arc=none smtp.client-ip=209.85.208.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="COEwFccW" Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-378e8d10494so57892741fa.2 for ; Mon, 17 Nov 2025 07:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763394491; x=1763999291; darn=vger.kernel.org; h=content-transfer-encoding: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; bh=c/DUma0uZd8iCNzJFNlwxYelZvsQPcM9gT0Fu/UGP5Y=; b=COEwFccWnTSZZhfIMmxf9dxlSNeit2WGTrtffdB+zcsa5PeFEl+Ewx6wVLeYeTJf7I R8HNcH3LTQuaCYbIPHINb4jbHhK2d0Lcb/JGCjDkDm1BmoizG3cJf3PeJ5p0sVX8o3c/ SdmOXYZIs6WAWS8jFVnPko0njBkg5sMY96DOL8ZuMirBrs+iBCYzkPva2BvkAfDsbBa5 F6Dk2ClIzu1W0nE52d2rVOi6odN60iWsoii10RtMvpyJ00k3LKJMRQ7Sgrsh2XnV2EDV iSoqf0pODs+pklwWmxVhw1oaLenrRALUGhvA8jwUxZb5v3L87wZ+ZsH3DvSv01DFZW80 koiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763394491; x=1763999291; h=content-transfer-encoding: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; bh=c/DUma0uZd8iCNzJFNlwxYelZvsQPcM9gT0Fu/UGP5Y=; b=YCwopwQNeH71P/ASPsv113KckiiI5MyjaIwTlN7c9Z3DSErpSqQOlmQ63T7+DdGJ9E MXhSuqCbVF2LLOxnlUSPRsf2DTF6rCr18328WeLMWKARodKWTddghyK0E2KVPzgv7oq2 1e0uHbGBlQy7DDpHQcu/uOMvaX5v2+DOoxJNX4p4Po+z2inOJszN1ZjJJhh1/J4V8qw+ //CNhCSmbc724WDfkk8u8YAa86bbL7FuuzMXcTfB7dZEoiP0WVpBwloDvv3U6LNiSgNS xmWca42N+1VNRHeqexANXk60ZhBVdYA9A2/eeE9L8hm4YkXETLLwYlNjAqT5cbSrECZv W9dg== X-Forwarded-Encrypted: i=1; AJvYcCWF8iU9t+nZIdSzUfILGIgix4ugARntcKT6YdUst6C1bzfoF9DEt8sd3kYjY2LzqAWC9FXRdv8ZBI+AYlA=@vger.kernel.org X-Gm-Message-State: AOJu0YwcqDDcn6v42fFnCItCJ/BhFg7aoGFtTbmYsZjtL1O8ElySiBSf wHHY8YmgqYFOqiX9x3+IxWyb2vFldujutTS/iwEAIxP5yO8gWBEuKshd X-Gm-Gg: ASbGncu13xh/wlslUADzDAAw42DpV3fg/bwqFrGYsU/o2ZhUoH7A57O0qQGQolvwhpD hAdN8dqRvXxk7HQKCh4Tw9TCH2ZaqrwLwTlu060mK42tlIhdm2Akatj/6kVQALKLfnR/0zu97DQ E/9SaNG5geiiNxZjSTnQLQwEadUzCfomfXzP5MnXOIbl3PbmzJYro82tJvOw/Q1T16iqS7LUkej EHRvmW7NghICptaK93KR9q74yR4iF+Dim5TJlgm+Cd3wQw21Pfakjh7nfX3E0xoNhL/kNk7bUGJ q4bYLbao2KOHU3NdEnf26CdIMw87a0f8cAvLp3wAubOOzl2+rcPWS9h8oMCYC9YqUQqCr5+u0x+ 4xIXb02bTBXgjERd39mRzdtOyJyWJzjUBLoam9CgsO47+f6WKJ/EslnEOmjjzHL2E/3c9ouVE+d M292v1tp0YhwmhLv75fREgVWur0y65FYpBFWcgpSi3iasniTcuL0VRjVHpnw== X-Google-Smtp-Source: AGHT+IEz1qxf+9MTduFUs5dbOjZ/dHS2S6pFFr0IgbhUuNlZhrUTtDy15iSqTT9lE0arzv+pzqRA9A== X-Received: by 2002:a2e:b052:0:b0:37a:75c6:b44 with SMTP id 38308e7fff4ca-37babb47988mr26872821fa.3.1763394490823; Mon, 17 Nov 2025 07:48:10 -0800 (PST) Received: from ?IPV6:2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703? ([2a10:a5c0:800d:dd00:8fdf:935a:2c85:d703]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-37b9ce25408sm28328821fa.20.2025.11.17.07.48.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Nov 2025 07:48:10 -0800 (PST) Message-ID: <52b99bf7-bfea-4cee-aa57-4c13e87eaa0d@gmail.com> Date: Mon, 17 Nov 2025 17:48:08 +0200 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 v4 04/16] dt-bindings: power: supply: BD72720 managed battery To: Rob Herring Cc: Matti Vaittinen , Krzysztof Kozlowski , Mark Brown , Linus Walleij , linux-kernel@vger.kernel.org, Sebastian Reichel , Bartosz Golaszewski , Alexandre Belloni , linux-clk@vger.kernel.org, Michael Turquette , Matti Vaittinen , linux-leds@vger.kernel.org, Pavel Machek , Liam Girdwood , linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, Andreas Kemnade , Conor Dooley , devicetree@vger.kernel.org, linux-rtc@vger.kernel.org, Lee Jones , Stephen Boyd References: <176303119683.3716572.16868393928566655866.robh@kernel.org> <20251114163954.GA3399895-robh@kernel.org> <32303b95-3fd5-44c4-bb7d-e2957a6064fc@gmail.com> <20251117152341.GA1944698-robh@kernel.org> Content-Language: en-US, en-AU, en-GB, en-BW From: Matti Vaittinen In-Reply-To: <20251117152341.GA1944698-robh@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 17/11/2025 17:23, Rob Herring wrote: > On Mon, Nov 17, 2025 at 10:12:01AM +0200, Matti Vaittinen wrote: >> On 14/11/2025 18:39, Rob Herring wrote: >>> On Fri, Nov 14, 2025 at 11:04:27AM +0200, Matti Vaittinen wrote: >>>> On 13/11/2025 12:53, Rob Herring (Arm) wrote: >>>>> >>>>> On Thu, 13 Nov 2025 10:52:19 +0200, Matti Vaittinen wrote: >>>>>> From: Matti Vaittinen >> >> //snip >> >>>> >> For VDR there are only: >> >> rohm,voltage-vdr-thresh-microvolt, > > So "voltage voltage drop rate"? And '-microvolt' says this is voltage > too. :) Hm. Yes. This is a threshold voltage for applying the "zero-correction" algorithm, which uses these "VDR" (a.k.a voltage drop rate) tables. Eg, the algorithm should only used for the correction when battery voltage drops below this threshold. AFAICS, this is usually designed to be slightly higher than the voltage where the system stays still operable. I suppose this could also be "zero-correction-threshold", but this would introduce another "buzzword". >> rohm,volt-drop-soc-bp, >> rohm,volt-drop-temperatures-millicelsius >> >> and >> >> patternProperties: >> '^rohm,volt-drop-[0-9]-microvolt': >> >> So, from the binding point of view (.yaml), it's not _that_ lot. In the .dts >> there will be quite some noise as the tables have several values. >> >> >>> If that >>> happens, either we are doing a poor job of generically describing >>> battery parameters or chargers and batteries are tightly coupled and >>> can't be described independently. >> >> I am under impression that chargers tend to be pretty flexible, and they can >> be configured to work with many different batteries by altering the charging >> profiles. Most of the battery properties (like and charging phases [like >> pre, CC, CV], their limits, currents and voltages etc) are very generally >> usable. So, large subset of charging functionality can be handled with >> standard properties. I believe it is only the fuel-gauging where things get >> more hairy. >> >> I did prepare a series which does the split and adds new compatible for the >> 'rohm,vdr-battery'. (The power-supply class is not yet modified in the >> series, but we would probably want to modify the battery-info getters to >> also accept the 'rohm,vdr-battery' -compatible.) > > I don't think that's the right direction. It's not a Rohm battery. > >> I wonder if I should actually prepare also a series where these properties >> are just placed in the existing static battery node without adding new >> compatible. That way it would be easier to see which way is better. > > That seems like the right thing to do here. > > The main question for me is whether these should even be Rohm specific? > That would probably require a 2nd user to answer for sure. > This is a question Linus W asked as well :) I believe this technique could be applied to other batteries. I, however, am not aware of any other than ROHM charger drivers which implement the algorithm. Furthermore, I was told that the mechanism to measure these "VDR-tables" for batteries is one of those things which should be "kept under your hat". I think ROHM has also patented some stuff related to that. Hence I prefixed these tables by "rohm,". I have no strong objections to dropping the "rohm," though - but I doubt these tables will be heavily used by any other but ROHM chargers. >> If I do that, should I only spin these bindings as RFC to avoid the >> unnecessary noise? > > Only if you think something is not complete and/or the patches should > not be applied. Oh, Ok. Then I will send only one of the approaches - probably the one where properties are added to the simple-battery. Thanks for all the support! Yours, -- Matti --- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~