<rockosov>
I have a question regarding the unifykey custom amlogic driver.
<rockosov>
I understand that this driver is quite proprietary, but it plays a crucial role in the core functionality of Amlogic BL31.
<rockosov>
My question is: do you think it should be upstreamed to the LKML? We have a version of the driver that has been ported upstream, and we can submit it along with the necessary changes for meson-sm.
<rockosov>
Looking forward to your thoughts!
<narmstrong>
rockosov: could you send me the patches privately? Does it fit into a current kernel subsystem? If not, adding a new custom vendor-specific interface is not something we do easily nowadays
<rockosov>
narmstrong: As of now, we haven't modified the Amlogic interface to maintain backward compatibility. It currently functions as a character device with several IOCTLs and sysfs nodes. While we can consider integrating it into a known subsystem, I don't have a clear idea of which would be the best fit at this moment. Additionally, I'm not familiar with popular key-value storage subsystems (do
<rockosov>
they exist at all by the way?)
<narmstrong>
rockosov: nvmem ?
<rockosov>
I thought nvmem is more about efuse and other common backends
<narmstrong>
well nvmem is about reading a block of read-only/writable-once memory from a hidden/external subsystem
<narmstrong>
in dt you can specify offsets for well-known data, I guess all keys could be seen as a memory block with offsets defined for each key ? and in DT you could link them to consumers for example
<phh>
rockosov: no way in hell those horrifying /sys pass mainline ^^
<narmstrong>
yeah it won't
<phh>
narmstrong: do you know to which extent can nvmem be named? like having /dev/nvmem/by-name like /dev/block/by-name (sorry that's android naming idk about usuak gnu/linux naming)
<f_>
does mainline accept proprietary drivers at all?
<phh>
f_: wdym proprietary?
<f_>
> <rockosov> I understand that this driver is quite proprietary, but it plays a crucial role in the core functionality of Amlogic BL31.
<phh>
k
<f_>
> <rockosov> My question is: do you think it should be upstreamed to the LKML? [...]
<phh>
proprietary in that sense is that it's something that is software not hardware, and a custom storage system
<phh>
like if you took an amlogic SoC, and did everything using mainline u-boot/linux, you wouldn't have anything remotely close to that thing
<f_>
Not as in closed-source?
<phh>
yeah it's open-source
<f_>
Gotcha, thanks
<narmstrong>
phh: nop, it would be in /sys/bus/nvmem
<narmstrong>
rockosov: is there kernel users of the key? or it is exclusively user space ?
<phh>
narmstrong: and it would be readable from like /sys/bus/nvmem/serialno/content ?
<phh>
narmstrong: we have bt/wifi/eth mac addresses in there, but theorically it's up to bootloader to patch dts
<narmstrong>
phh: sure, you have "cells" defined in DT, like : /sys/bus/nvmem/devices/amlkey/cells/wifi-mac
<phh>
k sounds great then
<rockosov>
narmstrong: However, nvmem describes memory and linear memory blocks. The UnifyKey backend does not represent key-value pairs as a single linear memory block; instead, it stores them in a chaotic order.
<narmstrong>
rockosov: by name right ?
<rockosov>
Yep, by name
<narmstrong>
rockosov: can you query the key names at runtime ? from an smc call ?
<rockosov>
They are defined in the device tree, we knows all key names. If storage has keys not defined in the DT, we will not know them
<narmstrong>
ok so I guess you could create an nvmem device per-key
<narmstrong>
it could be childs of sm node
<rockosov>
narmstrong: And we can ignore nvmem iface for linear memory dump?
<rockosov>
narmstrong: Ah, I see. Each key will be a separate nvmem device
<narmstrong>
rockosov: each nvmem device would provide a linear dump of a single key
<narmstrong>
and then in DT you can add "layouts" of each key, to provide for example mac addresses & other
<narmstrong>
like any nvmem dt intergace
iprusov_ has quit [Quit: WeeChat 3.5]
iprusov has joined #linux-amlogic
<phh>
is it worth asking nvmem maintainers to confirm?
<narmstrong>
sure, not sure if he will answer
<narmstrong>
but you could try: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
<rockosov>
narmstrong: He is from Linaro, right? :)
<narmstrong>
yep
<rockosov>
narmstrong: You may ping him internally if any :) But to speak seriously, we will try to prepare RFC for nvmem.
<narmstrong>
sure I'll ask him, I'll ask if it's ok for: - an nvmem device per key for a key:value storage, - a secure-monitor subnode for each known key
<phh>
for the part that it's kinda proprietary (for a lack of better word), you think it's not an issue?
<narmstrong>
I think it's fine
<phh>
k thanks
<narmstrong>
rockosov: sure, code is much better, you can try to prepare a very simple nvmem driver, make sure the DT bindings are very explicit, it should be quite easy to prepare
exkc has joined #linux-amlogic
<rockosov>
narmstrong: Okay, we will send RFC. It would be better to discuss approaches in the patch series context :)
<narmstrong>
rockosov: sure, don't hesitate to send me a patchset in private if you have some doubts