Hi Rob, Am 07.12.18 um 00:49 schrieb Rob Herring: > On Wed, Nov 21, 2018 at 02:11:40PM +0100, Stefan Wahren wrote: >> This patch adds the devicetree binding for Raspberry Pi customer OTP >> driver. >> >> Signed-off-by: Stefan Wahren <stefan.wahren@xxxxxxxx> >> --- >> .../nvmem/raspberrypi,bcm2835-customer-otp.txt | 22 ++++++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/nvmem/raspberrypi,bcm2835-customer-otp.txt >> >> diff --git a/Documentation/devicetree/bindings/nvmem/raspberrypi,bcm2835-customer-otp.txt b/Documentation/devicetree/bindings/nvmem/raspberrypi,bcm2835-customer-otp.txt >> new file mode 100644 >> index 0000000..041ff17 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/nvmem/raspberrypi,bcm2835-customer-otp.txt >> @@ -0,0 +1,22 @@ >> +Customer OTP Memory for Raspberry Pi >> + >> +The VC4 firmware exposes a mailbox interface that allows the ARM core >> +to access the customer part of the OTP memory. >> + >> +The OTP node must be a child node of the Raspberry Pi firmware node. >> + >> +Required properties : >> +- compatible : Should be "raspberrypi,bcm2835-customer-otp" > Why do we need this child node? Can't the parent instantiate this? > > Are there OTP fields you want to expose in DT? the customer part of the OTP is reserved (initialized with zero) for user who wants to use the Raspberry Pi (mostly the Compute Module) in their custom designs. So i cannot provide any nvmem cells yet because it is up to the user to define them (e.g. hardware related values like serial numbers, MAC addresses for additional network interfaces or calibration values). But yes i consider the binding and the ability to define nvmem cells via devicetree as a great feature. Currently the Foundation suggests to use the mailbox interface from userspace [1], but i prefer a more common way like nvmem. [1] - https://www.raspberrypi.org/documentation/hardware/industrial/README.md
