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]
Date: Wed, 20 Mar 2024 09:09:02 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Johan Hovold <johan@...nel.org>, Bjorn Andersson <andersson@...nel.org>
Cc: 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 19/03/2024 08:25, Johan Hovold wrote:
> On Mon, Mar 18, 2024 at 09:48:30PM -0500, Bjorn Andersson wrote:
>>
>> On Wed, 06 Mar 2024 10:56:46 +0100, Johan Hovold wrote:
>>> This series addresses a few problems with the sc8280xp PCIe
>>> implementation.
>>>
>>> The DWC PCIe controller can either use its internal MSI controller or an
>>> external one such as the GICv3 ITS. Enabling the latter allows for
>>> assigning affinity to individual interrupts, but results in a large
>>> amount of Correctable Errors being logged on both the Lenovo ThinkPad
>>> X13s and the sc8280xp-crd reference design.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [4/5] arm64: dts: qcom: sc8280xp: add missing PCIe minimum OPP
>>       commit: 2b621971554a94094cf489314dc1c2b65401965c
> 
> I noticed that you applied both of these for 6.10, but this one is a fix
> that should go into 6.9.

Well, mixing fixes for different cycles in one patchset was always
discouraged. In case of some subsystems you would receive clear
response, that you must split fixes out of the patchset.

Fixes being first in the patchset would be probably accepted by the rest
of subsystems, but putting it in the middle of the patchset is wrong.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ