From: Stefan Wahren <wahrenst@gmx.net>
To: Gregor Herburger <gregor.herburger@linutronix.de>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Ray Jui <rjui@broadcom.com>,
Scott Branden <sbranden@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Srinivas Kandagatla <srini@kernel.org>,
devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
Date: Thu, 9 Apr 2026 17:21:01 +0200 [thread overview]
Message-ID: <fc2c08d8-fb7f-4da0-ad68-dd54aad82af9@gmx.net> (raw)
In-Reply-To: <addd5ZpuUdKBV7Bn@gregor-framework>
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
next prev parent reply other threads:[~2026-04-09 15:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 8:00 [PATCH 0/3] nvmem: Add Raspberry Pi OTP nvmem driver Gregor Herburger
2026-04-08 8:00 ` [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register Gregor Herburger
2026-04-09 8:13 ` Krzysztof Kozlowski
2026-04-08 8:00 ` [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver Gregor Herburger
2026-04-08 16:52 ` Stefan Wahren
2026-04-08 19:47 ` Gregor Herburger
2026-04-08 20:03 ` Stefan Wahren
2026-04-09 8:05 ` Gregor Herburger
2026-04-09 15:21 ` Stefan Wahren [this message]
2026-04-09 8:17 ` Krzysztof Kozlowski
2026-04-08 8:00 ` [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware Gregor Herburger
2026-04-09 8:15 ` Krzysztof Kozlowski
2026-04-09 12:02 ` Gregor Herburger
2026-04-09 12:15 ` Krzysztof Kozlowski
2026-04-09 13:03 ` Gregor Herburger
2026-04-09 13:05 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc2c08d8-fb7f-4da0-ad68-dd54aad82af9@gmx.net \
--to=wahrenst@gmx.net \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=gregor.herburger@linutronix.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=rjui@broadcom.com \
--cc=robh@kernel.org \
--cc=sbranden@broadcom.com \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox