[GIT PULL] Mediatek: 32-bit DT update for v4.15

[ryder.lee@mediatek.com (Ryder Lee)]

Hi,

On Thu, 2017-11-02 at 17:05 +0100, Arnd Bergmann wrote:
> On Thu, Nov 2, 2017 at 12:47 PM, Matthias Brugger
> <matthias.bgg@gmail.com> wrote:
> > Hi Arnd,
> >
> > On 10/31/2017 05:19 AM, Ryder Lee wrote:
> >> Hi Arnd,
> >>
> >> We have 3 root ports in MT7623, but this is a bug in this chip where the
> >> HW designers wired the IRQs in a nonstandard way. We've tried to
> >> statically assign the bus portion of the address part in the parent
> >> interrupt-map before, but this approach cannot handle the case - if we
> >> attach the device in random order.
> >>
> >
> > Ryder, please don't top post :)

Oh. My bad!

> >> Thanks.
> >>
> >> On Mon, 2017-10-30 at 13:42 +0100, Arnd Bergmann wrote:
> >>> On Mon, Oct 23, 2017 at 12:06 AM, Matthias Brugger
> >>> <matthias.bgg@gmail.com> wrote:
> >>>>
> >>>> ----------------------------------------------------------------
> >>>> - mt76233 add PCIe node
> >>>
> >>> Could you clarify what the subnodes in the PCI node are for? It seems odd
> >>> to have "interrupt-map" properties in both the pcie controller and its child
> >>> nodes, and I want to ensure this is following the standard PCIe binding before
> >>> I pull it.
> >>>
> >
> > Arnd, I didn't found the pull request in your next/dt branch.
> > Is there more clarification needed from our side?
> 
> I'm still unsure about it., this looks like exactly the thing that the top-level
> interrupt-map is supposed to handle fine.
> 
> Can you send a pull request for the series without the pci child nodes for the
> moment while we figure out what the exact problem is? We can take
> whatever fix we come up with during the v4.15 -rc cycle then.
> 
> I would assume that either the parent interrupt-map is wrong, or something
> broke the parser, but that it's not actually something that's wrong in the
> hardware design in a way that we can't already handle in a standard way.
> 
> Ryder, can you be more specific how the interrupts are wired up?
> Is there one IRQ per slot that is connected to all of IntA/IntB/IntC/IntD
> and gets propagated through the bridges like that, or is it something else?

Yes, that's what I mean - we only have one IRQ which is connected to all
INTx for each slot, and I'm not sure if there is any better way to solve
this problem. 

>      Arnd
>