[PATCH 1/2] dt-bindings: nvmem: rockchip-efuse: add rockchip,efuse-write-enable property

[Heiko Stuebner]

Am Donnerstag, 16. Juli 2026, 11:43:03 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> On Wed, Jul 15, 2026 at 01:42:56PM +0200, Heiko Stübner wrote:
> > Am Mittwoch, 15. Juli 2026, 13:01:06 Mitteleuropäische Sommerzeit schrieb Hrushiraj Gandhi:
> > > Add an optional boolean property to explicitly opt in to write (OTP
> > > programming) support. eFuse bits are one-time-programmable and
> > > permanently set once written; write support must therefore not be
> > > enabled by default on arbitrary boards.
> > > 
> > > Boards that intend to use software-initiated eFuse programming (e.g.
> > > factory key provisioning) must declare this property and must ensure
> > > the required VQPS programming supply (1.8V to 1.98V per RK3399 TRM)
> > > is present and correctly sequenced during writes.
> > > 
> > > Signed-off-by: Hrushiraj Gandhi <hrushirajg23 at gmail.com>
> > > ---
> > >  .../devicetree/bindings/nvmem/rockchip-efuse.yaml     | 11 +++++++++++
> > >  1 file changed, 11 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
> > > index b80fd8d1ae5b..8a7195245c84 100644
> > > --- a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
> > > +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.yaml
> > > @@ -46,6 +46,17 @@ properties:
> > >        this property is defined.
> > >      $ref: /schemas/types.yaml#/definitions/uint32
> > >  
> > > +  rockchip,efuse-write-enable:
> > > +    type: boolean
> > > +    description:
> > > +      Enable write (programming) support for this eFuse block. eFuse bits
> > > +      are one-time-programmable; setting a bit is permanent and cannot be
> > > +      undone. This property must only be set on boards where irreversible
> > > +      OTP programming from software is an intended use case (e.g. factory
> > > +      provisioning), and where the required VQPS programming voltage
> > > +      (1.8V to 1.98V per RK3399 TRM) is guaranteed to be present and
> > > +      correctly sequenced by the board's power design during writes.
> > 
> > Devicetree is not a configuration space, and I think this really does count
> > as configuration - as the efuse will be writeable on every board.
> > 
> > You mention the VQPS voltage. If I'm reading schematics and application
> > notes correctly, this is a separate input used solely for writing efuses
> > and _needs_ to be 0V (off?) during reads.
> > 
> > You mention "needs to be present and correctly sequenced", who is supposed
> > to turn on/off that regulator?
> > 
> > So you very likely need to define that regulator and can even use its
> > absence as an indicator to disable writes.
> > 
> > 
> > Heiko
> > 
> > 
> You're right, the boolean property was the wrong approach - agreed
> that it's policy, not hardware description. I'll drop it.
> 
> I was planning to model VQPS as a proper optional supply in the
> binding:
> 
>   vqps-supply:
>     description:
>       Supply for the eFuse programming voltage (VQPS), required only
>       on boards where software-initiated OTP programming is intended.
>       Per RK3399 TRM section 21.6.1, table 21-3, VQPS must be 0V
>       during reads and 1.8V~1.98V during A_PGM mode writes. If this
>       supply is absent, the driver leaves the nvmem device read-only.

I don't think the description _in_ the binding needs to be this verbose.

  vqps-supply:
    description:
       Supply for the eFuse programming voltage (VQPS)
....

The text you have above, would be great for the commit message of the
dt-binding patch.


> and in the driver, gate reg_write on whether
> devm_regulator_get_optional() actually finds it:
> 
>   efuse->vqps = devm_regulator_get_optional(dev, "vqps");
>   if (!IS_ERR(efuse->vqps))
>       econfig.reg_write = soc_data->reg_write;

Or alternatively just error out _inside_ the reg_write callback.
But not having a hard preference. I guess nvmem-maintainer will
tell their preference, once that change appears :-) .


> The driver would own sequencing entirely inside
> rockchip_rk3399_efuse_write(): regulator_enable() immediately before
> the A_PGM STROBE loop, regulator_disable() right after - mirroring
> how efuse->clk is already handled around the same window. reg_read
> never touches the regulator, so VQPS stays at 0V for the entire read
> path.

Sounds reasonable


Heiko