On Mon, Sep 30, 2019 at 10:13 AM Andrew Murray <andrew.murray@xxxxxxx> wrote:
>
> On Wed, Sep 25, 2019 at 07:33:35AM -0500, Rob Herring wrote:
> > On Wed, Sep 25, 2019 at 5:24 AM Andrew Murray <andrew.murray@xxxxxxx> wrote:
> > >
> > > On Tue, Sep 24, 2019 at 04:46:21PM -0500, Rob Herring wrote:
> > > > Convert altera host bridge to use the common
> > > > pci_parse_request_of_pci_ranges().
> > > >
> > > > Cc: Ley Foon Tan <lftan@xxxxxxxxxx>
> > > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx>
> > > > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > > > Cc: rfi@xxxxxxxxxxxxxxxxxxxxxx
> > > > Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
> > > > ---
> >
> > > > @@ -833,9 +800,8 @@ static int altera_pcie_probe(struct platform_device *pdev)
> > > > return ret;
> > > > }
> > > >
> > > > - INIT_LIST_HEAD(&pcie->resources);
> > > > -
> > > > - ret = altera_pcie_parse_request_of_pci_ranges(pcie);
> > > > + ret = pci_parse_request_of_pci_ranges(dev, &pcie->resources,
> > >
> > > Does it matter that we now map any given IO ranges whereas we didn't
> > > previously?
> > >
> > > As far as I can tell there are no users that pass an IO range, if they
> > > did then with the existing code the probe would fail and they'd get
> > > a "I/O range found for %pOF. Please provide an io_base pointer...".
> > > However with the new code if any IO range was given (which would
> > > probably represent a misconfiguration), then we'd proceed to map the
> > > IO range. When that IO is used, who knows what would happen.
> >
> > Yeah, I'm assuming that the DT doesn't have an IO range if IO is not
> > supported. IMO, it is not the kernel's job to validate the DT.
>
> Sure. Is it worth mentioning in the commit message this subtle change
> in behaviour?
Will do.
> > > I wonder if there is a better way for a host driver to indicate that
> > > it doesn't support IO?
> >
> > We can probably test for this in the schema.
> >
> > ranges:
> > items:
> > minItems: 7
> > items:
> > - not: { const: 0x01000000 }
> >
> > Or "- enum: [ 0x42000000, 0x02000000 ]"
> >
> > Of course, in theory, the bus, dev, fn fields could be non-zero and we
> > could use minium/maximum to handle those, but in practice I think they
> > are rarely used for FDT.
>
> Many controllers also appear to set the top bit (relocatable), e.g.
> 0x82000000...
That begs the question how many should set the relocatable bit and don't...
Anyways, it's still a smallish set of possible values and worthwhile
to describe which ones a controller supports.
> At present there are no PCI bindings that use the YAML schema, if I've
> understood correctly.
Probably so, there has been at least one under review. Intel LGM IIRC.
We do need a common PCI schema too. Hopefully someone beats me to it.
Rob
