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

[Sergey Lebedev <lsa.uz@pm.me>]

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.

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.

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.

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