summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/kernel
diff options
context:
space:
mode:
authorOliver O'Halloran <oohall@gmail.com>2020-09-18 19:30:49 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2020-10-06 23:22:25 +1100
commit42de19d5ef71b91765266557705394e52954adb3 (patch)
tree334bf06731356f93cbaf5a9212c5d78a0caef5c8 /arch/powerpc/kernel
parent98ba956f6a3891b233466b8da064f17d16dc2090 (diff)
downloadlinux-42de19d5ef71b91765266557705394e52954adb3.tar.bz2
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
Diffstat (limited to 'arch/powerpc/kernel')
0 files changed, 0 insertions, 0 deletions