Re: (subset) [PATCH v4 0/5] arm64: dts: qcom: sc8280xp: PCIe fixes and GICv3 ITS enable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/03/2024 09:40, Johan Hovold wrote:
> On Wed, Mar 20, 2024 at 09:24:54AM +0100, Krzysztof Kozlowski wrote:
>> On 20/03/2024 09:18, Johan Hovold wrote:
> 
>>> Perhaps you should not comment before reading up on the history of this
>>> series.
>>>
>>> This was all intended for 6.9, but merging was stalled for a number of
>>> reasons so here we are. The patches were also going in through different
>>> trees, so patch 4/5 is the first Qualcomm SoC patch.
>>
>> Again, well, you sent it at few days before merge window, so how do you
>> imagine this being applied for v6.9 and still fulfilling "few linux-next
>> cycles before merge window" requirement? Especially that arm-soc cut off
>> is much earlier :/. I talk about patch 5, of course, because that is not
>> a fix (at least not marked as one). Don't expect in general a arms-co
>> patch to be applied four days before merge window, thus the actual fix -
>> patch #4 - should be split.
> 
> At the time there was still hope that there may be an rc8, and the patch
> in question had been used by a large number of X13s users for several
> weeks, which is a lot more testing than the average Qualcomm patch
> receives, whether it's in linux-next or not.

OK, it does solve some parts of our discussion but does not solve my
earlier comment: Fixes should be separate series. Certain folks have
quite strict requirement on this. Try sending a fix with non-fix
(depending on fix somehow like here) to Mark Brown. He has even template
for such case...

> 
> And patch 5 depends on the earlier patches in the series so it belongs
> in the series, which was also initially posted long before the merge
> window.

The dependency is might not be good enough reason to combine fixes and
non-fixes into one series. Dependency should be explained (in 5th
patch), but it's maintainer's judgement and job to handle this.

And in all this, fact that Bjorn missed certain aspects and applied this
differently than you wanted, is another argument that this should be split.

Best regards,
Krzysztof





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux