New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Widevine related device tree options support #6379
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a generic comment I think we'd like to change this to transfer lists, transfer elements in the future. But until that is in place DT works.
Added a new commit to resolve comments. |
I think this is good now, please add my tag, rebase it and squash the patches accordingly so we merge it. Thanks!
|
c6fd863
to
444564f
Compare
Rebased and squashed the patches. |
@qazwsxedcrfvtg14 please address the checkpatch issues (CI / Code style job). You may use the sentence you put in this PR ("On the new ChromeOS mediatek platform, we will use the device tree to pass hardware unique key and the parameters for widevine TA."). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these DT bindings (DT node pathes as /options/
and property names) generic? Are they OP-TEE specific (e.g optee-hardware-unique-key
) ? If these are to be deprecated once Firmware Handoff Transfer List is merged, is it worth merging this change now?
The commit message lacks a description, see CI Code Style result that also reports another issue).
43fc6bf
to
77915f0
Compare
Resolved the comments. BTW, I'm not sure about the status of "Firmware Handoff Transfer List"... |
I'm not sure about our future plans for that, but it's not in the timeline for this change, so please proceed with this change as-is. |
Please check first that such |
The DT bindings being added here are being documented in OP-TEE as you pointed out, so I would figure OP-TEE maintainers would be the ones maintaining the evolution/consistency of that if anything else gets added there in the future. Originally we tried to get these documented in the linux kernel, but got pushback on that which is why they ended up in OP-TEE....and I think that stance will continue to be taken where DT bindings should get added to kernel documentation unless there is pushback on that end, in which case they'd end up in OP-TEE. |
7b5bf12
to
e59bff8
Compare
df3a5ac
to
e2fa2b1
Compare
90669a8
to
d3a0066
Compare
Rebased and resolved the conflicts with master branch. |
d3a0066
to
bfb5f9d
Compare
Resolved the comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather wait the DT bindings are acked before merging this change.
I still find curious that Widevine mandates the whole OP-TEE to rely on a HUK provided by DT "/options/op-tee/widevine" node without other strict constraints on how this HUK is derived. I also think it puts some restrictions on integration of other TAs when the Widevine TA is to be supported, which maybe makes sense.
I'm adding the "enhancement" tag, so this won't be closed automatically and since I want this to be merged in one or another way at some point. I do believe this will take some time to sort out. We've just this week had a first call between stakeholders interested in this and we concluded that we have to start with working out the Linux kernel side of things. The secure side, will be a topic in the future when the Linux kernel side of story seems to fall in place. For more information (and a recording of the meeting), please see the topics discussed here. |
c7efeb3
to
9f85553
Compare
9f85553
to
711bed1
Compare
711bed1
to
64a52f9
Compare
The device tree binding is merged in the optee_docs: And rebased the PR. |
@jforissier @jenswi-linaro anything else you'd like to add? |
16227e7
to
d09effd
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
On the new ChromeOS mediatek platform, we will use the device tree to pass hardware unique key and the parameters for widevine TAs. Signed-off-by: Yi Chou <yich@google.com> Reviewed-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Jens Wiklander <jens.wiklander@linaro.org> Acked-by: Jerome Forissier <jerome.forissier@linaro.org>
d09effd
to
8634308
Compare
Can we get this PR merged now? |
@Narflex yes, sorry for the delay. |
On the new ChromeOS mediatek platform, we will use the device tree to pass hardware unique key and the parameters for widevine TA.
BTW, should we also put the device tree binding document in the OP-TEE repo?
Because the Linux upstream says the OP-TEE only DT bindings don't belong in the kernel.
https://lore.kernel.org/all/20230918194235.GA1548023-robh@kernel.org/