[PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver

Stefan Wahren wahrenst at gmx.net
Thu Apr 9 08:21:01 PDT 2026


Am 09.04.26 um 10:05 schrieb Gregor Herburger:
> On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
>> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
>>> Hi Stefan,
>>>
>>> thanks for the review.
>>>> Is there any reason, why we cannot register this driver in
>>>> rpi_firmware_probe() like hwmon and clk driver?
>>>>
>>>> I like to avoid the complete dt-binding from patch 1.
>>> The private OTP registers are not available on all Raspberries. Afaik
>>> only on 4 and 5. So I think these registers must be described through
>>> the device tree. Therefore the bindings are needed.
>> This binding doesn't represent some kind of hardware, it's just some
>> firmware interface. A proper DT binding would describe the MMIO address
>> range for OTP access.
> I think it does represent real hardware. Although it is hidden through the
> firmware. Not all hardware must be MMIO addresses.
>
> The only driver that does not have a DT node is the hwmon driver. All
> other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
> binding. Looking at the comment in rpi_register_clk_driver this
> seems to be some legacy behaviour for older DTs for the clock driver.
There is a long history of different approaches how to implement the 
VideoCore firmware interface for the Raspberry Pi and not all of them 
are good from today's perspective.

One big problem with DT binding is that the kernel must be compatible 
with all mainline DTS versions. This sounds trivial, but it's not. Since 
we cannot assume that kernel & DTB are updated at the same time. So we 
need to keep these bad solutions from the past.
>> If you need some distinction between the Raspberry Pi generations there are
>> firmware tags to do this.
> So what is your suggestion? What tags do you mean?
Your driver already use firmware tags to access the OTPs via firmware. 
You can ask the Raspberry Pi guys, how to do the distinction in a 
efficient/maintainable way.

My suggestion would be to look at 
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-board-model

and

https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c#L95

The compatible "raspberrypi,bcm2712-firmware" approach is more straight 
forward, but requires a newer DTB. See above.

Best regards



More information about the linux-arm-kernel mailing list