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

[Benjamin Mugnier <benjamin.mugnier@foss.st.com>]

Hi Sergey,

Le 10/09/2026 à 23:33, Sergey Lebedev a écrit :
> Following up on the firmware blocker I raised on 7 September, since it is
> still the thing that stops anyone but the author from using VD55G0. Relayed
> with Peter Marshall's agreement.
> 
> Peter sourced the firmware the same way I did for testing: the version 2.11
> patch array in Andre Gilerson's out-of-tree VD55G0 driver, which he reports is
> identical to the one in ST's standalone driver. He has published the extracted
> blobs for testing at
> 
>   https://github.com/petm5/vd55g-firmware
> 
> and would prefer submission to linux-firmware over a built-in array, so that
> firmware can be updated independently of the kernel version. I agree that is
> the better end state.
> 
> Worth adding, because it may lower the bar for getting there: the built-in
> arrangement is already in the tree, from ST, for the sibling part.
> drivers/media/i2c/vd55g1.c is Copyright (C) 2025 STMicroelectronics SA under
> SPDX-License-Identifier: GPL-2.0, and it carries vd55g1_patch_array[] - 3512
> bytes, firmware revision 2.9 by its own defines. That file has no
> request_firmware path at all; the built-in array is its only mechanism.

We initially thought of using linux-firmware, and we didn't for several
reasons :
- The firmware is reasonably small.
- The driver source code is directly dependant on the firmware, as some
behaviors may be altered by the firmware. Keeping it in the source code
allows easy synchronisation.
- A lot of mainline sensor do the same thing, with exception for only 4
drivers (ccs included) that use request-firmware.

It has been discussed with maintainers back to the vgxy61.

Unless I'm proven moving to the request_firmware API allows more upsides
than the above points, unfortunately I will not ack a serie that moves
from the builtin patch to the request_firmware API.

> 
> Different sensor and a different binary from the VD55G0 one, which measures
> 6868 bytes at revision 2.11, so it is precedent for the arrangement rather
> than for the blob. But it does mean a built-in for VD55G0 would not be asking
> ST for something they have not already done one part number over, whereas
> linux-firmware needs an explicit redistribution grant in WHENCE from the
> copyright holder.

I'm not sure I get you. Is this a licence problem of some sort ? Could
you rephrase ?

Anyway if we don't move to request_firmware I guess this is a non issue ?

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.

> 
> So the two routes are not equally hard today, and they are not exclusive: a
> built-in now and linux-firmware when ST are ready is not a wasted step.
> 
> Whether GPL-2.0 on the surrounding code carries the blob with it is a licence
> question and not one I will answer.
> 
> Benjamin, Sylvain - this is the one blocker on the series that nobody outside
> ST can clear.
> 
> Sergey
> 

-- 
Regards,
Benjamin