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.
> 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.
Rob
