| Message ID | 156922009207.910857.10785273696571088534.stgit@bahia.lan (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | powerpc/xive: Fix bogus error code returned by OPAL | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch next (6edfc6487b474fe01857dc3f1a9cd701bb9b21c8) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
On Mon, Sep 23, 2019 at 08:29:40AM +0200, Greg Kurz wrote: > 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 > (cherry picked from commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8, > groug: fix arch/powerpc/platforms/powernv/opal-wrappers.S instead of > non-existing arch/powerpc/platforms/powernv/opal-call.c) > Signed-off-by: Greg Kurz <groug@kaod.org> > --- > > This is for 4.14 and 4.19. Thanks for the backport, now queued up. greg k-h
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 8eb3ebca02df..163970c56e2f 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -266,7 +266,7 @@ int64_t opal_xive_get_vp_info(uint64_t vp, int64_t opal_xive_set_vp_info(uint64_t vp, uint64_t flags, uint64_t report_cl_pair); -int64_t opal_xive_allocate_irq(uint32_t chip_id); +int64_t opal_xive_allocate_irq_raw(uint32_t chip_id); int64_t opal_xive_free_irq(uint32_t girq); int64_t opal_xive_sync(uint32_t type, uint32_t id); int64_t opal_xive_dump(uint32_t type, uint32_t id); diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S index 8c1ede2d3f7e..b12a75a0ee8b 100644 --- a/arch/powerpc/platforms/powernv/opal-wrappers.S +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S @@ -301,7 +301,7 @@ OPAL_CALL(opal_xive_set_queue_info, OPAL_XIVE_SET_QUEUE_INFO); OPAL_CALL(opal_xive_donate_page, OPAL_XIVE_DONATE_PAGE); OPAL_CALL(opal_xive_alloc_vp_block, OPAL_XIVE_ALLOCATE_VP_BLOCK); OPAL_CALL(opal_xive_free_vp_block, OPAL_XIVE_FREE_VP_BLOCK); -OPAL_CALL(opal_xive_allocate_irq, OPAL_XIVE_ALLOCATE_IRQ); +OPAL_CALL(opal_xive_allocate_irq_raw, OPAL_XIVE_ALLOCATE_IRQ); OPAL_CALL(opal_xive_free_irq, OPAL_XIVE_FREE_IRQ); OPAL_CALL(opal_xive_get_vp_info, OPAL_XIVE_GET_VP_INFO); OPAL_CALL(opal_xive_set_vp_info, OPAL_XIVE_SET_VP_INFO); diff --git a/arch/powerpc/sysdev/xive/native.c b/arch/powerpc/sysdev/xive/native.c index 0f89ee557b04..aac61374afeb 100644 --- a/arch/powerpc/sysdev/xive/native.c +++ b/arch/powerpc/sysdev/xive/native.c @@ -234,6 +234,17 @@ static bool xive_native_match(struct device_node *node) return of_device_is_compatible(node, "ibm,opal-xive-vc"); } +static s64 opal_xive_allocate_irq(u32 chip_id) +{ + s64 irq = opal_xive_allocate_irq_raw(chip_id); + + /* + * Old versions of skiboot can incorrectly return 0xffffffff to + * indicate no space, fix it up here. + */ + return irq == 0xffffffff ? OPAL_RESOURCE : irq; +} + #ifdef CONFIG_SMP static int xive_native_get_ipi(unsigned int cpu, struct xive_cpu *xc) {
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 (cherry picked from commit 6ccb4ac2bf8a35c694ead92f8ac5530a16e8f2c8, groug: fix arch/powerpc/platforms/powernv/opal-wrappers.S instead of non-existing arch/powerpc/platforms/powernv/opal-call.c) Signed-off-by: Greg Kurz <groug@kaod.org> --- This is for 4.14 and 4.19. arch/powerpc/include/asm/opal.h | 2 +- arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +- arch/powerpc/sysdev/xive/native.c | 11 +++++++++++ 3 files changed, 13 insertions(+), 2 deletions(-)