summaryrefslogtreecommitdiffstats
path: root/samples/hidraw
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2019-09-11 17:52:18 +0200
committerMichael Ellerman <mpe@ellerman.id.au>2019-09-12 09:27:05 +1000
commit6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8 (patch)
treee2680d33f9b4590f7e3ecf70c7af8310a333d433 /samples/hidraw
parent92c94dfb69e350471473fd3075c74bc68150879e (diff)
downloadlinux-6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8.tar.gz
linux-6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8.tar.bz2
linux-6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8.zip
powerpc/xive: Fix bogus error code returned by OPAL
There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call to return the 32-bit value 0xffffffff when OPAL has run out of IRQs. Unfortunatelty, OPAL return values are signed 64-bit entities and errors are supposed to be negative. If that happens, the linux code confusingly treats 0xffffffff as a valid IRQ number and panics at some point. A fix was recently merged in skiboot: e97391ae2bb5 ("xive: fix return value of opal_xive_allocate_irq()") but we need a workaround anyway to support older skiboots already in the field. Internally convert 0xffffffff to OPAL_RESOURCE which is the usual error returned upon resource exhaustion. Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/156821713818.1985334.14123187368108582810.stgit@bahia.lan
Diffstat (limited to 'samples/hidraw')
0 files changed, 0 insertions, 0 deletions