hverkuil: it looks like your mail provider has blacklisted kernel.org 
https://lore.kernel.org/linux-media/20250325-dynamic-sexy-bobcat-0b7d69@houat/ never reached you, and I got an SMTP rejection mail from your provider 
mripard: I did get it through the linux-media mailinglist. I get other mails from kernel.org addresses, so it might be a fluke. Try sending a test message to me, see if it is still a problem.
hverkuil: just sent one to you
Haven't seen it yet. If you get a rejection email then please forward it to hansverk@cisco.com.
hverkuil: done for the first one, I will if there's a second one
Hi, I'm working on developing a new kernel driver that we want to upstream to the Linux kernel.
Currently, we're developing this driver using an FPGA board with proprietary bitfiles that we cannot share publicly.
The IP that our driver supports isn't yet available on the market, though it's expected to be released in the coming months.
Additionally, the firmware for this device cannot be provided publicly and will only be available to clients.
When submitting to the kernel community, is it mandatory to provide a publicly available test board for validation, or would a detailed technical report with comprehensive testing documentation be sufficient for the upstreaming process?"
mripard: tor.source.kernel.org appears to be blocked. I wonder if my provider thinks this is a tor server. But 'tor' probably refers to Toronto.
yaouaissa: a board is not mandatory. subsystem maintainers don't typically have access to all hardware supported by their subsystem
what kind of device is that ?
pinchartl: it's a video device
as in video capture ? processing ? encoding/decoding ?
yaouaissa: if the kernel driver requires that firmware is uploaded to the device before it can function, then the requirement is that said firmware binary is made available in https://web.git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
The reasoning is that there is no point in mainlining a driver if you cannot use it without an NDA or something like that.
Based on what you described, that is probably the main sticking point.
pinchartl: encoding/decoding
hverkuil: it's the case, the firmawre is loaded to the device, without, the driver is useless.
yaouaissa: is the firmware freely redistributable in binary form ?
and does it run on an MCU dedicated to the codec, or on a generic-purpose CPU/MCU that also handles other tasks ?
pinchartl: the firmware run on a dedicated MCU ( integrated with the codec ).
pinchartl: Unfortunatly, the SoC vendors who can publish the firmawre. 
is the firmware tuned/optimized/modified for each SoC ?
pinchartl: each soc has features, like in some case, we can have firmware that enables only the jpeg or for AVC-ONLY.
you can't make a universal firmware that would detect the features of the IP and act accordingly ?
Hi, I'm having issue reproducing the kernel test robot error here : https://lore.kernel.org/linux-media/202503291609.9gCJpjjk-lkp@intel.com/. Is that because my arch is 64 bits even if I cross compile to 32 ? ? I tried to cross compile using its reproduce instructions found in the mail
https://download.01.org/0day-ci/archive/20250329/202503291609.9gCJpjjk-lkp@intel.com/reproduce.
I guess it's because of my u64 mipi_freq var that is then divided, but I'd like to make sure I didn't make any similar mistakes elsewhere
bemug46: did you cross-compile to sh4 ?
Apparently lkp downloaded it for me in ~/0day with the last command
pinchartl: i will discuss this with the team, thank you.
pinchartl nevermind I only have 2 files in ~/0day : 14.2.0  and gcc-14.2.0-nolibc
yaouaissa: you're welcome. I think a single firmware would greatly simplify usage of the codec
I guess they are cross compilers
$ file ./build_dir/vmlinux
./build_dir/vmlinux: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, BuildID[sha1]=eb985dfa906a3f0d2adf8018bb8b78310652b681, not stripped
Sounds good
I tried with allyesconfig to use the same config as the bot and still can't reproduce, the vd55g1 is compiled correctly
  CC      drivers/media/i2c/vd55g1.o