RE: [PATCH V1 2/3] dt-bindings: power: sbs-battery: add polling interval property

[LI Qingwu]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> Sent: Monday, December 29, 2025 8:47 PM
> To: LI Qingwu <Qing-wu.Li@xxxxxxxxxxxxxxxxxxxxxxx>; sre@xxxxxxxxxx;
> robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx;
> linux-pm@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx
> Cc: GEO-CHHER-bsp-development
> <bsp-development.geo@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [PATCH V1 2/3] dt-bindings: power: sbs-battery: add polling interval
> property
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On 29/12/2025 10:50, LI Qingwu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
> >> Sent: Monday, December 29, 2025 5:16 PM
> >> To: LI Qingwu <Qing-wu.Li@xxxxxxxxxxxxxxxxxxxxxxx>; sre@xxxxxxxxxx;
> >> robh@xxxxxxxxxx; krzk+dt@xxxxxxxxxx; conor+dt@xxxxxxxxxx;
> >> linux-pm@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> >> linux-kernel@xxxxxxxxxxxxxxx
> >> Cc: GEO-CHHER-bsp-development
> >> <bsp-development.geo@xxxxxxxxxxxxxxxxxxxx>
> >> Subject: Re: [PATCH V1 2/3] dt-bindings: power: sbs-battery: add
> >> polling interval property
> >>
> >> This email is not from Hexagon’s Office 365 instance. Please be
> >> careful while clicking links, opening attachments, or replying to this email.
> >>
> >>
> >> On 29/12/2025 09:56, LI Qingwu wrote:
> >>> Add the optional sbs,monitoring-interval-ms property for
> >>> SBS-compliant batteries to configure a periodic polling interval on
> >>> systems without interrupt support. The driver periodically checks
> >>> the battery status and notifies userspace of changes when this
> >>> property is set, and ignores it when a GPIO interrupt is available.
> >>>
> >>> The property defaults to 0 to preserve existing behaviour.
> >>>
> >>> Signed-off-by: LI Qingwu <Qing-wu.Li@xxxxxxxxxxxxxxxxxxxxxxx>
> >>> ---
> >>>  .../bindings/power/supply/sbs,sbs-battery.yaml           | 9
> +++++++++
> >>>  1 file changed, 9 insertions(+)
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yam
> >>> l
> >>> b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yam
> >>> l index 90b9d3d882a4..fbdd5dd5dda8 100644
> >>> ---
> >>> a/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yam
> >>> l
> >>> +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-battery
> >>> +++ .y
> >>> +++ aml
> >>> @@ -59,6 +59,15 @@ properties:
> >>>        master implementation.
> >>>      type: boolean
> >>>
> >>> +  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
2. I should remove this from device tree entirely and use a module
   parameter instead.

Please clarify which direction is acceptable?

Best regards,
Qingwu

> Best regards,
> Krzysztof