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: Wed, 20 Mar 2024 10:52:36 +0100
From: Johan Hovold <johan@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Johan Hovold <johan+linaro@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof WilczyƄski <kw@...ux.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	linux-arm-msm@...r.kernel.org, linux-pci@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: (subset) [PATCH v4 0/5] arm64: dts: qcom: sc8280xp: PCIe fixes
 and GICv3 ITS enable

On Wed, Mar 20, 2024 at 10:16:16AM +0100, Krzysztof Kozlowski wrote:
> On 20/03/2024 09:40, Johan Hovold wrote:

> > 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...

That's not a general rule at all.

> > 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.

FFS, I'm posting a series adding a new feature, which depends on first
addressing a few related bugs. I post everything together so that it can
be evaluated and tested together. That's perfectly fine, and not that
different from how we post driver and dts changes in one series to
facilitate review. Some maintainers don't like that either, then we deal
with that.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ