On 28.4.2022 23.56, Arnd Bergmann wrote:
On Thu, Apr 28, 2022 at 10:01 PM Mauri Sandberg <maukka@xxxxxxxxxxxx> wrote:
On 27.4.2022 21.10, Arnd Bergmann wrote:
On Wed, Apr 27, 2022 at 6:21 PM Mauri Sandberg <maukka@xxxxxxxxxxxx> 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.
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
-- Mauri
[1]
https://elixir.bootlin.com/linux/v5.17/source/drivers/ata/sata_mv.c#L4434
[2] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/manage.c#L2146
[3] https://elixir.bootlin.com/linux/v5.17/source/kernel/irq/settings.h#L100
