[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5c52b138-38ef-42c9-9f81-c605df68792e@kernel.org>
Date: Tue, 30 Dec 2025 10:46:16 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: LI Qingwu <Qing-wu.Li@...ca-geosystems.com.cn>,
"sre@...nel.org" <sre@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc: GEO-CHHER-bsp-development <bsp-development.geo@...ca-geosystems.com>
Subject: Re: [PATCH V1 2/3] dt-bindings: power: sbs-battery: add polling
interval property
On 30/12/2025 10:40, LI Qingwu wrote:
>>>>>
>>>>> + sbs,monitoring-interval-ms:
>>>>> + description:
>>>>> + Polling interval in milliseconds for battery status monitoring on
>>>>> + systems without interrupt support. The driver periodically checks
>>>>> + the battery status and notifies userspace of changes. Ignored when
>>>>> + GPIO interrupt is available.
>>>>
>>>>
>>>> You described the desired Linux feature or behavior, not the actual hardware.
>>>> The bindings are about the latter, so instead you need to rephrase
>>>> the property and its description to match actual hardware
>>>> capabilities/features/configuration etc.
>>>>
>>>
>>> Thanks for the quick feedback!
>>> How about this?
>>>
>>> sbs,monitoring-interval-ms:
>>> description:
>>> Polling interval in milliseconds for battery status monitoring.
>>> Intended for hardware designs where the battery's interrupt signal
>>> is not connected, necessitating periodic status checks to detect
>>> changes.
>>
>>
>> Nothing changed. It's exactly the same.
>>
>> Explain me how "polling interval" by Linux driver is a hardware value?
>> What was not clear in my feedback?
>>
>
> Thank you for the feedback. I apologize, but I am still not clear on
> the correct approach.
>
> I understand that "polling interval" is software policy and should not
> be in device tree. However, I am unsure whether:
>
> 1. I should rephrase the property to describe the hardware fact (e.g.,
> "battery alert signal is not wired"), or
Isn't this already described in the binding implicitly by missing
interrupt? Or the device is not using dedicated interrupt pins and only
SMBus Alert? But if the latter, then alert is always available.
> 2. I should remove this from device tree entirely and use a module
> parameter instead.
Module parameters are usually not the way to configure anything. Look at
other devices and how they do it. Usually this is sysfs interface.
Regardless, I don't give you advice nor instruction how to implement
this. I just do not agree with current phrasing for DT. If you come with
proper hardware description for DT, it could be fine. If you want to
remove it from DT completely, I am fine as well.
Best regards,
Krzysztof
Powered by blists - more mailing lists