Re: [RFC PATCH 0/2] firmware: qcom: scm: QSEECOM app loading and listener support

[Dawid Wrobel]

On 1.11.2026 17:01, Haozhen Li wrote:

> This work builds upon the QSEECOM transport logic developed by Dawid Wrobel
> and samcday [1] 

I would have preferred you filed your updates to my code as a PR to my
repo at https://github.com/wrobelda/linux/tree/qcom-qseecom-tee/

While my work is indeed AI-assisted, I made a substantial effort to
design it properly and review and fix the code by hand where it
mattered, yet I still don't consider it admissible here for mainline
inclusion yet. Notably, there's also a substantial amount of
documentation I have written by hand specifically to submit it along the
qseecom code. I was looking to file an RFC here this month myself for
all this.

The code in this RFC is, at rough estimate, 80-90% mine. While you did
retain Copyright notice in the source file, I believe the guidelines say
you should have tagged the Co-developed-by: together with a
Signed-off-by:, which you should have asked for from me.

You also mention Sam Day, who filed a PR against my TEE driver, but he
wasn't CC-ed, so I am doing that.

> adapted to modern mainline interfaces (qcom_tzmem, lockdep, and proper
kerneldoc constraints).

What exactly did you adapt, because as far as I am concerned, my code
*already* does exactly all that?

Lastly, as Konrad pointed out, these interfaces need an in-kernel
consumer. My work provides one:

- a QSEECOM TEE driver, which uses the interfaces in this RFC:
  https://github.com/wrobelda/linux/tree/qcom-qseecom-tee
- a Goodix SPI fingerprint sensor driver:
  https://github.com/wrobelda/linux/tree/goodix-fp-spi
- a user-space stack (two supplicant daemons and an fprintd patch),
  described at https://github.com/wrobelda/goodix-fp-spi-linux

As mentioned, I will appreciate your patches as PRs to my repo,
as the FOSS etiquette dictates and let me file a proper RFC once
I decide it's good to go.

-- 
With Kind Regards,
Dawid Wrobel