[PATCH 4/5] dt-bindings: power: supply: rk817-charger: Add rockchip,gate-function-disable

[Chris Morgan]

On Tue, Oct 27, 2026 at 11:40:46PM +0100, Heiko Stübner wrote:
> Am Dienstag, 27. Oktober 2026, 16:53:10 Mitteleuropäische Normalzeit schrieb Chris Morgan:
> > On Mon, Oct 26, 2026 at 08:23:40PM +0100, Heiko Stübner wrote:
> > > Hi Chris,
> > > 
> > > Am Montag, 26. Oktober 2026, 18:48:33 Mitteleuropäische Normalzeit schrieb Chris Morgan:
> > > > From: Chris Morgan <macromorgan at hotmail.com>
> > > > 
> > > > Add a boolean attribute for the rk817-charger to control whether or not
> > > > the system power is shutdown in battery off mode. The BSP kernel sets
> > > > this value unless a device-tree attribute is present, and this attribute
> > > > is to replicate that behavior.
> > > 
> > > Devicetree is supposed to describe the hardware, so your description needs
> > > to describe the per-board property this represents.
> > > 
> > > Just because it's in a vendor-BSP is generally not enough justification :-) .
> > > 
> > > This is especially true as you wrote in the cover-letter that no known
> > > board actually needs this right now.
> > > 
> > > 
> > > Heiko
> > 
> > The datasheet describes this as "Whether the system voltage can be
> > shutdown in Bat_off mode" and the register itself is described as
> > SYS_CAN_SD. Maybe call it "rockchip,can-shutdown-bat-off"? Or given the
> > fact that I'm not aware of any boards that would need it today, should
> > I even bother with adding the devicetree override? The only reason I
> > am adding it is in case this "fix" introduces a regression it will
> > allow someone to set this flag, just like the BSP does.
> 
> First of all, I guess defining the terms better would be helpful, i.e.
> I don't know what that "battery off" mode is plus the whole enviroment
> this happens in.
> 
> Secondly, this new flag would cause a regression, because a board needing
> the old way would need to add that flag. But when a board actually
> requiring this turns up with an older devicetree without that new flag
> this breaks backwards compatiblity.
> 
> So if we have a function flag for the pmic, it would need to be the other
> way around.
> 
> As you said this is specific to battery powered devices, of which we don't
> have that many - especially in-tree. Can you maybe look in the vendor-tree
> if any board actually uses that?
> 
> 
> Heiko
> 
> 

In the next revision I'll just enable it, and put a note inline
stating that BSP offered a way to disable this behavior but I have
never observed a device doing so. The documentation around what this
bit does isn't exactly clear but from what I gather it sets the output
voltage of the battery to on even when the PMIC is off. Otherwise, when
the PMIC is off the battery output voltage is off. I see that at least
a few devices from Trim UI experience a power drain while off if this
bit is not cleared. Not sure why keeping the battery *on* fixes a power
drain, but I haven't noticed any other devices experiencing a
regression with this bit cleared, a few devices work better with this
bit cleared, and the BSP did it this way.

So next revision I'll just drop the devicetree pieces and always clear
the bit.

Thank you,
Chris