Has this been submitted upstream for review yet? Generally we want everything to be accepted or on its way there first.

(In reply to Laura Abbott from comment #1)
> Has this been submitted upstream for review yet? Generally we want
> everything to be accepted or on its way there first.

I've never submitted a patch upstream for the kernel, wasn't sure what the proper process was. I figured it might would be added quicker if I submitted it here, since patches have been super slow for the Pine 64 rockchip devices. I will look into getting setup on the mailing list though.

(In reply to Laura Abbott from comment #1)
> Has this been submitted upstream for review yet? Generally we want
> everything to be accepted or on its way there first.

Sorry for the delay, it looks like someone beat me to submitting the patch upstream for enabling the pcie nodes. I tested the patch and it boots successfully, so we would need it and the config changes from my patch to enable the pcie slot. Could we get this added into Fedora possibly, I'm okay with skipping adding the pwm fan nodes, I found another solution for powering the cpu and case fan that's more reliable?

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts?h=next-20190624&id=bba821f5479eaab474b2ec1e230ec8b532089722

*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs.

Fedora 30 has now been rebased to 5.2.9-200.fc30.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31.

If you experience different issues, please open a new bug report for those.

I just checked the 5.2.8-200.fc30(9-200 isn't available yet) and it doesn't have the dts entries or the config options. I checked the latest rawhide kernel, kernel-5.3.0-0.rc5.git0.1.fc32 and it has the dts changes mentioned in my previous comment. But still doesn't have the needed config options enabled, it needs the below config settings set so the module is built.

CONFIG_PCIE_ROCKCHIP_HOST=y
CONFIG_PCIE_ROCKCHIP=y
CONFIG_PHY_ROCKCHIP_PCIE=m

There's been issues with pcie on some rockchips devices which is why it's not currently enabled, it's being worked upon.

(In reply to Peter Robinson from comment #6)
> There's been issues with pcie on some rockchips devices which is why it's
> not currently enabled, it's being worked upon.

I understand, thank you for the update.

*** Bug 1792564 has been marked as a duplicate of this bug. ***

So I think I've finally got towards the bottom of this \o/

There's a shared IRQ bug that's picked up by CONFIG_DEBUG_SHIRQ which isn't enabled in the arm64 defconfig so likely no seen by others. I've reported it to Rockchip for their investigation, it seems they saw something but never got a patch upstream:

https://patchwork.kernel.org/patch/9892991/

Just for reference, and possibly unrelated, but might make it boot faster when pcie is enabled:
https://github.com/96rocks/u-boot/commit/01c5534eb4f9576eb8efb05c234eb310b4e1cd0e

For reference this was the last patch around this issue but it's still not fixed upstream:

https://patchwork.kernel.org/patch/9928629/

Hi all, for what its worth, I'd been using the PCIe SATA card sold by Pine64 with the RockPro64 for a few months now on Arch Linux ARM with no issues, apart from quirks with the card itself (the card supports a max of 6Gb transfer, which is not evenly divided among the ports, so if you use e.g. two drives, you have to pass `libata.force=3.0G` to prevent link saturation). The Arch Linux ARM kernel uses vanilla upstream sources i.e. no patches for RK3399 relating to PCIe[0]. Are there currently still blockers to enabling the 3 PCIe modules necessary for this SoC on Fedora 32?

[0] https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-aarch64

> patches for RK3399 relating to PCIe[0]. Are there currently still blockers
> to enabling the 3 PCIe modules necessary for this SoC on Fedora 32?

I bet that Arch doesn't enable CONFIG_DEBUG_SHIRQ, yes there's still issues, if there wasn't this bug would be closed and it would be enabled. Please actually read the actual details in the bug.

You're right, Arch doesn't enable DEBUG_SHIRQ. I read more into this issue through the LKML discussion links you posted, and understand a bit better what the issue is. My apologies for not doing that before posting.

It's now known the rockchip pcie controller is based on Cadence IP, the ultimate end goal would be to use that driver: https://www.spinics.net/lists/linux-pci/msg100411.html

I'm experiencing this issue on Fedora 34 on both the Workstation and IoT editions on the RockPro64. The NVMe drive doesn't appear in the output of lsblk. If I switch to Armbian, it shows up.

Still needs review and more testing but this looks promising:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210607213328.1711570-1-javierm@redhat.com/

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1176