Thread (1 message) 1 message, 1 author, 2021-08-15

Re: [RFC PATCH 1/2] dt-bindings: PCI: Add Apple PCI controller

From: Marc Zyngier <maz@kernel.org>
Date: 2021-08-15 09:12:50
Also in: linux-pci, lkml

Hi Mark,

On Sun, 15 Aug 2021 09:10:53 +0100,
Mark Kettenis [off-list ref] wrote:
Hi Marc,

What can I do to make progress with my binding proposal? It seems we're stuck
on the MSI issue where you and robh disagree. I still think your idea of
describing the MSIs as a range makes much more sense than describing them
individually and bunching them together with the host bridge port interrupts.
It looks like I missed an email from Rob, which explains why we're in
limbo (it was left unread and unmarked, which in my flow means "read
once I have too much time on my hands"). Apologies for that, I'll try
and reply tonight (travelling at the moment).
    Op 15-08-2021 09:09 schreef Marc Zyngier [off-list ref]:

    Hi Alyssa,
   
    On Sun, 15 Aug 2021 05:25:24 +0100,
    Alyssa Rosenzweig [off-list ref] wrote:
   
        Document the properties used by the Apple PCI controller. This is a
        fairly standard PCI controller, although it is not derived from any
        known non-Apple IP.
       
        Signed-off-by: Alyssa Rosenzweig [off-list ref]
   
    I would rather you post something as an extension to Mark's work, for
    multiple reasons:
   
    - Mark's patch is still being discussed, and is the current
    reference (specially given that it is already in use in OpenBSD and
    u-boot).
   
    - we cannot have multiple bindings. There can only be one, shared
    across implementations. Otherwise, you need a different kernel
    depending on whether you are booting from m1n1 or u-boot.
   
    - what you have here is vastly inconsistent (you are describing the
    MSIs twice, using two different methods).

That's probably my fault. The current u-boot device tree is a bit of a
Frankenstein thing to ease the transition from my initial binding to the
current proposal. I should clean that up at some point.
That would certainly help. There are a lot of moving pieces at the
moment, and it is getting hard to get a clear picture of what is using
what.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help