[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151009160910.GF3394@e106497-lin.cambridge.arm.com>
Date: Fri, 9 Oct 2015 17:09:10 +0100
From: Liviu Dudau <Liviu.Dudau@....com>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-arm-kernel@...ts.infradead.org,
Mark Rutland <mark.rutland@....com>,
Jon Medhurst <tixy@...aro.org>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
linux-pci <linux-pci@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Kumar Gala <galak@...eaurora.org>,
Will Deacon <will.deacon@....com>,
LKML <linux-kernel@...r.kernel.org>,
device-tree <devicetree@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Robin Murphy <robin.murphy@....com>
Subject: Re: [PATCH 3/4] arm64: Juno: Add support for the PCIe host bridge on
Juno R1
On Fri, Oct 09, 2015 at 05:49:18PM +0200, Arnd Bergmann wrote:
> On Friday 09 October 2015 16:44:08 Mark Rutland wrote:
> > On Fri, Oct 09, 2015 at 03:11:07PM +0100, Liviu Dudau wrote:
> > > On Fri, Oct 09, 2015 at 08:54:33AM -0500, Rob Herring wrote:
> > > Or maybe I can claim the use of the string on account on being the first on arm64
> > >
> > > I can add a vendor prefix if you want, but pci-host-generic is going to ignore it
> > > *because* it is trying to be a generic driver.
> >
> > The point here is to have the string ready if we need it later, so it's
> > fine that it's not used currently.
> >
> > Rob's suggestion is that the compatible list should look something like:
> >
> > compatible = "arm,juno-r1-pcie", "plda,xpressrich3", "pci-host-ecam-generic";
> >
> > We can match on "pci-host-ecam-generic" for now (and hopefully forever),
> > but if for some reason we need to special-case this host controller (or
> > Juno's integration thereof), we can do that based on the compatible
> > string.
>
> Sounds good to me, it certainly can't hurt.
>
> Arnd
Hmm, I'm sorry, but this time I'm going to disagree.
I understand the principle that the DTS is a description of the hardware and it should
not have any built in knowledge of how a driver works but describe the physical properties
of the device (where such description makes sense, in this case it does).
However, when ARM has created the Juno platform it has also created a standard called
SBSA and has claimed that Juno is compliant with that standard. My current position (and
it used to be MarkR's as well when we have argued internally the pros and cons of having
a bespoke driver for PLDA's XpressRICH3) is that SBSA compliant behaviour *is* the expected
behaviour and if the device doesn't conform it needs to be fixed in firmware.
Otherwise, I could've posted months ago the other public driver[1] that I've wrote that
doesn't depend on firmware and could have been done with this long time ago.
Best regards,
Liviu
1. https://github.com/ARM-software/linux/commit/ca9d82679916c3b6bdb846319e343a43a6bbb31c
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists