[RFC RFT PATCH v1 0/1] ARM: orion5x: convert D-Link DNS-323 to the Device Tree

[Arnd Bergmann]

On Sun, May 8, 2022 at 4:06 PM Mauri Sandberg <maukka at ext.kapsi.fi> wrote:
> On 28.4.2022 23.56, Arnd Bergmann wrote:
> > On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka at ext.kapsi.fi> wrote:
> >> On 27.4.2022 21.10, Arnd Bergmann wrote:
> >>> On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka at ext.kapsi.fi> wrote:
> >>>> - sata_mv fails to initialise with -22 (-EINVAL)
> >>>
> >>> No idea, I'd try inserting a printk in every code path that can return -EINVAL
> >>> from there
> >>>
>
> With debugging the reason for -EINVAL remains a bit mystery.
>   - sata_mv calls ata_host_activate() [1]
>   - later on, in request_threaded_irq(), there are sanity checks [2]
>   - that fail with irq_settings_can_request() returning 0 [3]
>
> I cannot really put my finger on why the irq cannot be requested in DT
> approach.

Are you sure the marvell,orion-intc driver is successfully probed
at this point? If not, the interrupt won't be there.

I see that the "sata_mv" driver can be used either as a platform
driver for the orion5x on-chip controller, or as a PCI driver for
an add-on chip connected to the external bus. It sounds like
your system has both. Do you know which one fails?

The PCI driver cannot work unless the PCI host works correctly,
and that in turn requires a correct devicetree description for it.

> >> Is there a way to describe the PCIe bus in the
> >> device tree? The initalisation of that bus is done for rev A1 only.
> >
> > I'm not too familiar with the platform, but my interpretation is that the
> > DT support here is incomplete:
> >
> > The DT based PCI probe using drivers/pci/controller/pci-mvebu.c
> > is not hooked up in orion5x.dtsi, and the traditional pci code does
> > not work with DT.
>
> Can the existing pci code still be used to init the PCI bus and describe
> the rest in the DT or is it a futile attempt?
>
> > I see that orion5x has two separate blocks --  a PCIe host that is
> > similar to the kirkwood one, and a legacy PCI host that needs
> > a completely separate driver.
> >
> > Which of the two do you actually need here?
> >
>
> I really cannot say which one is it. How can I tell? The functions given
> in struct hw_pci find their way to drivers/pci/probe.c eventually and
> use pci_scan_root_bus_bridge(). Nothing seems to utilising mvebu or
> kirkwood explicitly at least.
>
> Here's the output from lspci if the ids reveal anything.
>
> # lspci -v -k
> 00:00.0 Class 0580: 11ab:5181
> 01:00.0 Class 0580: 11ab:5181
> 00:01.0 Class 0100: 11ab:7042 sata_mv

The first two seem to be the host bridges, but unfortunately they
 seem both have the same device ID, despite being very different
devices.  The first one (00:00.0) should be the PCIe driver, the
second one (01.00.0) the legacy PCI one. In this case, the 11ab:7042
device is a PCIe device, and it's on the bus (00) of the first host
bridge. I think this should work with drivers/pci/controller/pci-mvebu.c
if you add the bits for probing.

Thomas Petazzoni originally wrote the new driver, and I think he was
planning at one point to use it for orion5x. I don't know if there were
any major problems preventing this at the time, or if it just needs to
get hooked up in the dtsi file.

         Arnd