]> git.baikalelectronics.ru Git - kernel.git/commit
powerpc/pseries/eeh: Allow zero to be a valid PE configuration address
authorOliver O'Halloran <oohall@gmail.com>
Fri, 18 Sep 2020 09:30:49 +0000 (19:30 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Tue, 6 Oct 2020 12:22:25 +0000 (23:22 +1100)
commit4bfbfc39a33c2e11559439a926c4e8d6dfb972e1
tree334bf06731356f93cbaf5a9212c5d78a0caef5c8
parent7e4ca5ad48ffbf9d91c82a90eef3504e4a1b96ad
powerpc/pseries/eeh: Allow zero to be a valid PE configuration address

There's no real reason why zero can't be a valid PE configuration address.
Under qemu each sPAPR PHB (i.e. EEH supporting) has the passed-though
devices on bus zero, so the PE address of bus <dddd>:00 should be zero.

However, all previous versions of Linux will reject that, so Qemu at least
goes out of it's way to avoid it. The Qemu implementation of
ibm,get-config-addr-info2 RTAS has the following comment:

> /*
>  * We always have PE address of form "00BB0001". "BB"
>  * represents the bus number of PE's primary bus.
>  */

So qemu puts a one into the register portion of the PE's config_addr to
avoid it being zero. The whole is pretty silly considering that RTAS will
return a negative error code if it can't map the device's config_addr to a
PE.

This patch fixes Linux to treat zero as a valid PE address. This shouldn't
have any real effects due to the Qemu hack mentioned above. And the fact
that Linux EEH has worked historically on PowerVM means they never pass
through devices on bus zero so we would never see the problem there either.

Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200918093050.37344-8-oohall@gmail.com
arch/powerpc/platforms/pseries/eeh_pseries.c