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

[Haozhen Li <dezige131@foxmail.com>]

Hi Dawid,

I owe you a sincere apology. I should have reached out and coordinated
with you before sending anything based on your work, asked for your
Co-developed-by: and Signed-off-by: tags, and verified the origin
properly. I am truly sorry for stepping on your toes and mishandling
the attribution.

For context, and not as an excuse: my sole goal with this series was
to bring up the fingerprint sensor on my device (huawei,gaokun3 /
sc8280xp), and the codebase I started from was Sam's snapshot [1].
During that process I made the mistake of relying on an AI assistant
for the porting and background research, and failed to verify that it
had traced the upstream lineage back to your active qcom-qseecom-tee
branch. Consequently, my cover letter's claim of "adapted to modern
mainline interfaces" was written relative to Sam's older snapshot and,
as you rightfully pointed out, is simply incorrect regarding your
repository. The core architecture and design, such as the listener
loop and its iteration bounds, are entirely your work, and the
attribution in my RFC fell far short of proper DCO standards.

I am withdrawing this series immediately. Your tee: qseecom driver,
with the Goodix sensor driver on top, is exactly the complete in-tree
consumer Konrad asked for, and your upcoming RFC is unquestionably the
right vehicle to bring this infrastructure to mainline.

I would be honored to contribute back to your tree, entirely at your
discretion:

 - A PR adding defensive checks for image and listener shared buffers
   above the 4 GiB physical mark, using the overflow-safe comparison
   Konrad suggested [2]. For what it is worth, I probed this on
   sc8280xp by OR-ing bit 32 into an otherwise valid image address:
   the firmware rejected the APP_START call with an explicit error
   rather than silently truncating the address, so this is strictly
   defensive hardening, not a fix for a universal firmware defect.

 - Testing on different silicon: I have exercised this transport on
   sc8280xp with a FocalTech fingerprint TA through repeated
   load/shutdown cycles and enroll/verify transactions, and would
   gladly run your tree on this hardware before you file your RFC and
   provide a Tested-by.

On the userspace side, I also maintain an independent D-Bus daemon
implementing net.reactivated.Fprint directly, without patching fprintd
or libfprint. Happy to compare notes if that is ever a useful data
point for the wider fingerprint ecosystem.

Thank you for your candid feedback, for CC-ing Sam, and above all for
the groundwork that made my device bring-up possible in the first
place.

Best regards,
Haozhen Li

[1] https://github.com/samcday/linux
    branch codex/sargo-fingerprint-kernel11-baseline
[2] Konrad's reply on the patch 1 thread