On 2019-10-14 15:00, Remi Pommarel wrote:
On Mon, Oct 14, 2019 at 02:45:34PM +0100, Marc Zyngier wrote:
Hi Remi,
On 2019-10-14 14:06, Remi Pommarel wrote:
> Hi Lorenzo, Marc,
[...]
> Sure, I think this could be considered a fix for the following
commit :
> Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI
> bridge config space")
>
> Moreover, Marc, I am also a bit supprised that you did not have to
use
> [1] to even be able to boot.
No, I don't have that one, and yet the system boots fine (although
PCI
doesn't get much use on this box). I guess I'm lucky...
> Also if you want to be completely immune to this kind of SError
(that
> could theoretically happen if the link goes down for other reasons
than
> being retrained) you would have to use mainline ATF along with
[2]. But
> the chances to hit that are low (could only happen in case of link
> errors).
Now you've got me worried. Can you point me to that ATF patch? I'm
quite
curious as to how you recover from an SError on a v8.0 CPU given
that it
has no syndrome information and may as well signal "CPU on fire!"...
The patch is at [1]. Please note that this is done quite similarly
for
rcar.
[1]
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541
That patch, without any other information, looks quite flaky. Unless
there
is a strong guarantee that ESR_EL3.ISS==2 only when the PCIe controller
goes wrong, it looks like this only papers over the issue...
That's pretty much independent from the patch at hand in this thread,
but
I certainly wouldn't trust this ATF patch without some more information
about how the fault is reported to the CPU.
M.
--
Jazz is not dead. It just smells funny...
