linux-kernel - Re: [PATCH 0/4] media: raspberrypi: Support RPi5's CFE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fcea0340-68f0-4a16-9b47-4d9eb91ffb1a@ideasonboard.com>
Date: Tue, 19 Mar 2024 08:29:57 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, Naushir Patuck
 <naush@...pberrypi.com>, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>,
 Sakari Ailus <sakari.ailus@...ux.intel.com>,
 Jacopo Mondi <jacopo.mondi@...asonboard.com>,
 Kieran Bingham <kieran.bingham@...asonboard.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Raspberry Pi Kernel Maintenance <kernel-list@...pberrypi.com>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Florian Fainelli <florian.fainelli@...adcom.com>,
 Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>
Subject: Re: [PATCH 0/4] media: raspberrypi: Support RPi5's CFE

On 19/03/2024 08:23, Krzysztof Kozlowski wrote:
> On 19/03/2024 07:21, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 19/03/2024 08:05, Krzysztof Kozlowski wrote:
>>> On 18/03/2024 16:49, Tomi Valkeinen wrote:
>>>> This series adds support to the CFE hardware block on RaspberryPi 5. The
>>>> CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
>>>> ISP.
>>>>
>>>> This series is currently based on multiple other serieses:
>>>>
>>>> - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
>>>>     pads" for metadata support
>>>> - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
>>>>     CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
>>>> - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
>>>>     End" for some shared uapi headers.
>>>>
>>>> And to run this, one of course needs the basic RPi5 kernel support plus
>>>> relevant dts changes to enable the cfe and camera.
>>>
>>> Which makes it impossible to merge. Please work on decoupling.
>>
>> Yes, it's not for merging as I wrote: "So at the moment we cannot merge
>> this driver, but hopefully the dependencies will get merged before the
>> reviews on this one are done."
>>
>> I believe Sakari's and Jacopo's serieses should be very close to
>> merging, and those should satisfy the needs of the driver itself.
>>
>> The DT bindings example uses a header from RPi5 base support series, and
>> if merging the base support seems to take a long time, I guess I could
>> drop the include and just use numbers instead for RP1_INT_MIPI0 and
>> RP1_CLK_MIPI0_CFG. And change those back later when the base support is
>> merged.
> 
> The problem is that your patches cannot be tested by automated tools.

Yes, I understand. I will send testable and mergeable patches when the 
dependencies are in, and until that this series is do-not-merge. But as 
reviews sometimes take a very long time, I think it's better to start 
sooner than later.

Is there a way to mark a series as "don't bother testing" for automated 
tools? RFC in the subject? I considered making this RFC, but I felt the 
patches themselves are not RFC quality. I've also seen DNI 
(do-not-integrate) used somewhere, but I'm not sure that's universally 
understood.

  Tomi