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

[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@xxxxxxxxx>
> > ---
> >  .../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.

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;

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.

Does this approach look reasonable to you, or do you see a problem
with it?

Hrushiraj