[PATCH 4/4] ppc: Fix PCI interrupt routing to match what qemu does

[BALATON Zoltan]

From: Benjamin Herrenschmidt

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This should be commited after this change in QEMU:
http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg03740.html

diff --git a/drivers/pci.c b/drivers/pci.c
index 7ad5202..c998280 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -1565,7 +1565,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
                         ncells += pci_encode_phys_addr(props + ncells, 0, 0, addr, 0, 0);
                         props[ncells++] = intno;
                         props[ncells++] = dnode;
-                        props[ncells++] = arch->irqs[intno - 1];
+                        props[ncells++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3];
                         props[ncells++] = 1;
 #else
                         /* Keep compiler quiet */

[Mark Cave-Ayland]

On 20/11/16 19:45, BALATON Zoltan wrote:
> From: Benjamin Herrenschmidt
> Signed-off-by: Benjamin Herrenschmidt
>
> drivers/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> This should be commited after this change in QEMU:
> http://lists.nongnu.org/archive/html/qemu-devel/2016-11/msg03740.html
>
> diff --git a/drivers/pci.c b/drivers/pci.c
> index 7ad5202..c998280 100644
> --- a/drivers/pci.c
> +++ b/drivers/pci.c
> @@ -1565,7 +1565,7 @@ static void ob_pci_host_set_interrupt_map(phandle_t host)
>                          ncells += pci_encode_phys_addr(props + ncells, 0, 0, addr, 0, 0);
>                          props[ncells++] = intno;
>                          props[ncells++] = dnode;
>                    props[ncells++] = arch->irqs[intno - 1];
>                    props[ncells++] = arch->irqs[((intno - 1) + (addr >> 11)) & 3];
>                    props[ncells++] = 1;
>
> #else
>                          /* Keep compiler quiet */

It looks like the QEMU counterpart to this has been queued for 2.8, so
as my set of boot tests show no regressions I've pushed this to git
master. Once the QEMU mirror syncs overnight I'll send a pull request to
update the corresponding OpenBIOS binaries.

ATB,

Mark.

[BALATON Zoltan]

On Wed, 23 Nov 2016, Mark Cave-Ayland wrote:
> It looks like the QEMU counterpart to this has been queued for 2.8, so
> as my set of boot tests show no regressions I've pushed this to git
> master. Once the QEMU mirror syncs overnight I'll send a pull request to
> update the corresponding OpenBIOS binaries.

Any chance to also test and include the other three patches in that pull? 
With those f0da78e can also be reverted, at least RTL8139 seem to work 
without that after my patches as the OS can find and init the card 
correctly.

Regards,
BALATON Zoltan

[Mark Cave-Ayland]

On 24/11/16 01:59, BALATON Zoltan wrote:
> On Wed, 23 Nov 2016, Mark Cave-Ayland wrote:
> > It looks like the QEMU counterpart to this has been queued for 2.8, so
> > as my set of boot tests show no regressions I've pushed this to git
> > master. Once the QEMU mirror syncs overnight I'll send a pull request to
> > update the corresponding OpenBIOS binaries.
>
> Any chance to also test and include the other three patches in that
> pull? With those f0da78e can also be reverted, at least RTL8139 seem to
> work without that after my patches as the OS can find and init the card
> correctly.

Not for 2.8 I'm afraid. Running a full set of OpenBIOS tests takes a lot
of time which I just don't have right now (or at least until the
holidays) whereas the single patch was isolated enough to just PPC mac99
which is considerably less work. If the other changes were applied and
did happen to have any unexpected side-effects before then I'd be
completely stuck :(

ATB,

Mark.