linux-kernel - Re: [PATCH v4 0/1] Digiteq Automotive MGB4 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 19 Dec 2022 12:10:49 +0100
From:   Martin Tůma <tumic@...see.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lizhi Hou <lizhi.hou@....com>,
        Martin Tůma <martin.tuma@...iteqautomotive.com>
Subject: Re: [PATCH v4 0/1] Digiteq Automotive MGB4 driver

On 18. 12. 22 19:58, Pavel Machek wrote:
> Hi!
> 
>> From: Martin Tůma <martin.tuma@...iteqautomotive.com>
>>
>> Hi,
>> This patch adds a driver for the Digiteq Automotive MGB4 grabber card.
>> MGB4 is a modular frame grabber PCIe card for automotive video interfaces
>> (FPD-Link and GMSL for now). It is based on a Xilinx FPGA and uses their
>> XDMA IP core for DMA transfers. Additionally, Xilinx I2C and SPI IP cores
>> which already have drivers in linux are used in the design.
>>
>> The driver is a quite standard v4l2 driver, with one exception - there are
>> a lot of sysfs options that may/must be set before opening the v4l2 device
>> to adapt the card on a specific signal (see mgb4.rst for details)
>> as the card must be able to work with various signal sources (or displays)
>> that can not be auto-detected.
> 
> Uff, that's "interesting". What kind of platform does this run on? You
> should be getting non-probeable parameters from deice tree (or APCI).
> 
> Best regards,
> 								Pavel
> 								

Hi,
It is a PCIe card, so it runs on any platform that supports PCIe cards. 
We do use the HW on x86_64 and arm platforms.

The parameters are in no way connected to the platform where the card is 
used, they are properties of the video signal that can change arbitrary 
as you can connect different car infotainments (the signal source) to 
the card (the same applies to the outputs - the car displays). Usually, 
there is no auto-configuration on the signal level, that's why you have 
to provide the various properties externally according to the 
infotainment that you have at the moment connected to the card.

Any kind of device tree or ACPI parameters make no sense for the HW/the 
intended usage.

M.