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, 27 Mar 2024 20:37:43 +0100
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Johan Hovold <johan@...nel.org>
Cc: Bjorn Helgaas <helgaas@...nel.org>, Bjorn Andersson
 <andersson@...nel.org>,
 Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Krzysztof WilczyƄski <kw@...ux.com>,
 Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Philipp Zabel <p.zabel@...gutronix.de>, linux-arm-msm@...r.kernel.org,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
 Johan Hovold <johan+linaro@...nel.org>
Subject: Re: [PATCH v2 2/3] PCI: qcom: Read back PARF_LTSSM register

On 15.03.2024 5:47 PM, Johan Hovold wrote:
> On Fri, Mar 15, 2024 at 11:16:59AM +0100, Konrad Dybcio wrote:
>> On 2/16/24 07:52, Johan Hovold wrote:
> 
>>> This makes no sense. As Bjorn already said, you're just polling for the
>>> link to come up (for a second). And unless you have something else that
>>> depends on the write to have reached the device, there is no need to
>>> read it back. It's not going to be cached indefinitely if that's what
>>> you fear.
>>
>> The point is, if we know that the hardware is expected to return "done"
>> within the polling timeout value of receiving the request to do so, we
>> are actively taking away an unknown amount of time from that timeout.
> 
> We're talking about microseconds, not milliseconds or seconds as you
> seem to believe.
> 
>> So, if the polling condition becomes true after 980ms, but due to write
>> buffering the value reached the PCIe hardware after 21 ms, we're gonna
>> hit a timeout. Or under truly extreme circumstances, the polling may
>> time out before the write has even arrived at the PCIe hw.
> 
> So the write latency is not an issue here.

Right, I'm willing to believe the CPU will kick the can down the road
for this long. I'll drop this.

Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ