Re: [PATCH 1/2] dt-bindings: soc: qcom: qcom,pmic-glink: Document RTC client properties

[Kamal Wadhwa]

On Wed, Aug 26, 2026 at 08:11:36AM +0200, Krzysztof Kozlowski wrote:
> On 20/08/2026 21:23, Kamal Wadhwa wrote:
> > On Thu, Aug 06, 2026 at 07:02:44PM -0500, Bjorn Andersson wrote:
> >>
> >>>
> >>> Assisted-by: Claude:claude-sonnet-5
> >>> Signed-off-by: Raj Aryan <raryan@xxxxxxxxxxxxxxxx>
> >>> Signed-off-by: Kamal Wadhwa <kamal.wadhwa@xxxxxxxxxxxxxxxx>
> >>
> >> As with the driver, the author/s-o-b chain is wrong.
> >>
> > 
> > Ack. will have it this way
> > 
> > Assisted-by: Claude:claude-sonnet-5
> > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Raj Aryan <raryan@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Kamal Wadhwa <kamal.wadhwa@xxxxxxxxxxxxxxxx>
> 
> The original SoB chain was right in such case. You sign only once, so
> first one is dropped. And this is what b4 produces.
> 

Thanks, so will keep it as-is.

> 
> > 
> >>> ---
> >>>  Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 5 +++++
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> >>> index 16ad4f5698fc..38db1ff473c0 100644
> >>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> >>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
> >>> @@ -79,6 +79,11 @@ properties:
> >>>        - const: charge_limit_end
> >>>        - const: charge_limit_delta
> >>>  
> >>> +  allow-set-time:
> >>> +    $ref: /schemas/types.yaml#/definitions/flag
> >>> +    description:
> >>> +      Indicates that the setting of RTC time is allowed by the host CPU.
> >>
> >> What property of the hardware/firmware that this describes would cause
> >> you to set or not set this?
> >>
> >> Also, what would the expected outcome be if I declare that my Hamoa
> >> hardware has pmic-glink with allow-set-time?
> > 
> > Actually Hamoa firmware does not support it yet, so it may get ignored.
> > but if the support was present, the writes will cause the system time
> > to go bad, which relies on the RTC time elapsed during off state to 
> > calculate current system time, incase network is not available.
> > 
> > this was used on rtc-pm8xxx.c driver as well
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/rtc/rtc-pm8xxx.c?h=v7.2#n622
> 
> 
> It's a generic property, so where is it defined?

Thanks. That is correct, the property should have carried "qcom,.." prefix.

seems the orignal property used on rtc-pm8xxx.c too has this problem (as i
copied this from the older driver) it also doesnt seem to have the prefix
added.  I'll raise a different patch to fix that.

> Why isn't it implied by the compatible?

After thinking more about Bjorn's above comment about this property describing
the Hardware/firmware, I have decided to drop this property for now, It seems
unlike the rtc-pm8xxx.c driver's case where firmware actually blocks the
writes, in the current case we were only adding to prevent the RTC core's write
(with the current system time value) to the RTC HW.   

Having said that, we do have usecase where Time service daemon (in Linux
Android) does need this time to be preserved from any writes, as the RTC time
offset is used incase there is no network time available, the time offset will
simply be added on top of the time captured before shutdown. So it seems, we
cannot handle this without actually blocking the writes to RTC time.

But since this time service does not exist in upstream kernel, so can you
please guide what would be a good way to handle this requirement? As we would
prefer to use this driver in Linux Android as well, can we add this as a
default disabled property still? something like "qcom,block-rtc-writes"?

PS:
Very sorry for late update, We actually wanted to enable Hamao as well (along
with Glymer) in the next version of this series, so testing and firmware
updates took some time.

Regards,
Kamal

> 
> 
> Best regards,
> Krzysztof