Re: [PATCH 0/7] media: i2c: st-vd55g1: Genericize driver and add VD55G0 support

[Benjamin Mugnier]

Hi Sergey,

Le 15/09/2026 à 12:07, Sergey Lebedev a écrit :
> Benjamin,
> 
> First, an apology: I wrote that badly. Reading it back I can see it lands as
> a request to move vd55g1 to request_firmware, and it was never meant as one.
> You have had to defend a position I was not attacking, and that is my fault
> rather than yours.

No worries, It didn't feel like an attack of any sort ;)

> 
> What I meant, and should have written: the VD55G0 firmware has to reach users
> somehow, and I do not mind which of the two mechanisms carries it. Your three
> reasons settle the mechanism for me - built in, and no more about it. Peter
> preferred linux-firmware and I relayed that with his agreement; whether your
> answer changes his view is his to say, not mine.
> 
>> I'm not sure I get you. Is this a licence problem of some sort ? Could
>> you rephrase ?
> 
> Yes, and it is not about the API at all. It is about who may put ST's
> firmware into the kernel tree.

Ah I got you. I'm not a licence expert in any way but since we already
disclosed the firmware patch in our out of tree driver as GPL2 [1], then
I guess it's free to use it as long as you respect GPL2, whether you're
from ST or not.

[1]
https://github.com/STMicroelectronics/vd55g0-linux-driver/blob/master/vd55g0_patches.h

> 
> vd55g1.c raises no question. ST holds the copyright and ST put its own array
> in its own file, GPL-2.0, 3512 bytes, no request_firmware path anywhere.
> Nothing had to be granted, by anyone, to anyone.
> 
> VD55G0 is not in that position today. The bytes this series would carry were
> extracted from a third-party out-of-tree driver, by people who are not ST.
> That is the same question whether they land as a C array or as a file in
> linux-firmware - the mechanism does not change who owns them. linux-firmware
> only makes it audible, because WHENCE asks for the grant out loud, where a
> built-in array lets the same question pass without being asked.
> 
> So there are three routes, and only one of them is clean:
> 
>   built in, sent by someone outside ST - which is the series as it stands.
>   Works technically. Leaves the provenance question unasked rather than
>   answered.
> 
>   linux-firmware - needs an explicit grant from ST in WHENCE, and you have
>   now ruled out the API change it would require. So: closed.
> 
>   ST upstreams VD55G0 itself, with its own array, exactly as you did for
>   vd55g1. Nobody outside ST has to ask for anything, because nothing is being
>   redistributed by anyone who does not own it.
> 
>> By the way we didn't upstream the vd55g0 because it requires a bit of
>> cleaning, but this is something that could also be done.
> 
> That is the one I would hope for, and it is worth more than getting my own
> machine working. It is the only route that ends the question rather than
> moving it. And it puts VD55G0 on the same footing as its sibling, rather than
> leaving it the part with an awkward history.
> 
> If the cleaning is what stands in the way, say what would help and I will do
> what I can. I cannot clean code I do not have. I can carry the mechanical
> half of it - checkpatch and sparse, builds across configurations, dt-binding
> checks, a review pass. And I can test on hardware you may not have: a Surface
> Pro 11 where the VD55G0 is the face-unlock sensor, so it is exercised by
> something real rather than by a capture tool. Peter's series in this thread
> already does a good deal of the genericising, if any of it is useful as a
> starting point.

I still stand against the refactoring and generalisation. I can
elaborate on that point if needed.

Now about mainlining vd55g0 out of tree module, my current priorities
won't allow me to do it anytime soon, but if you want to start from the
out of tree module and clean the driver to submit it I'll be happy to
assist. On top of my head we need to remove the KERNEL_VERSION guards
and move to streams api. Having the vd55g1 as reference is also a good
idea. I can test on device trees platforms.

> 
> Whether GPL-2.0 on the surrounding code carries a blob with it is still a
> licence question, and still not one I will answer.
> 
> Sergey
> 

-- 
Regards,
Benjamin