[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a1132ad-23e8-6415-dc8a-417eb64cdee8@linaro.org>
Date: Fri, 28 Jul 2023 18:51:56 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
stanimir.k.varbanov@...il.com, agross@...nel.org,
andersson@...nel.org, konrad.dybcio@...aro.org, mchehab@...nel.org,
hans.verkuil@...co.com, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org
Cc: quic_dikshita@...cinc.com
Subject: Re: [PATCH 33/33] iris: enable building of iris video driver
On 28/07/2023 18:25, Bryan O'Donoghue wrote:
> On 28/07/2023 14:23, Vikash Garodia wrote:
>> From: Dikshita Agarwal <quic_dikshita@...cinc.com>
>>
>> This adds iris driver Makefile and Kconfig, also changes
>> v4l2 platform/qcom Makefile/Kconfig in order to
>> enable compilation of the driver.
>
> This is not a meaningfully bisectable patch.
>
> It should go with the addition of the driver. Its good practice to break
> up incremental changes to a driver in a series but, I don't see why you
> really need to do that when adding a whole new driver.
>
> Just
>
> - Documentation
> - Bindings
> - Driver code
>
> On the other hand if you were switching on IRIS in the default defconfig
> then that should be a separate patch.
>
> If we were say adding inter-frame power-collapse to the existing venus
> as part of a series, then that makes sense as a standalone patch but IMO
> when adding a whole new driver, add it as one.
>
> Its easier to read that way
It wouldn't pass through mailing list filters.
--
With best wishes
Dmitry
Powered by blists - more mailing lists