On Wed, Nov 29, 2017 at 2:45 PM, Christian Zigotzky
[off-list ref] wrote:

On 29 November 2017 at 8:46PM, Bjorn Helgaas wrote:

quoted

On Wed, Nov 29, 2017 at 1:28 PM, Christian Zigotzky
[off-list ref] wrote:

quoted

On 23 November 2017 at 2:31PM, Michael Ellerman wrote:

quoted

Hi Christian,

Thanks for your patch.

Christian Zigotzky [off-list ref] writes:

quoted

Hi All,

Just a small patch for the P.A. Semi Nemo board:

-----

diff -rupN a/drivers/pci/probe.c b/drivers/pci/probe.c

--- a/drivers/pci/probe.c    2017-11-16 08:18:40.504012010 +0100
+++ b/drivers/pci/probe.c    2017-11-16 08:17:22.044368405 +0100

@@ -2219,6 +2219,8 @@ static int only_one_child(struct pci_bus

As this is a patch to the PCI code I can't merge it via the powerpc
tree. You would need to send it to linux-pci@vger.kernel.org.

quoted

        if (!parent || !pci_is_pcie(parent))
            return 0;
+    #ifndef CONFIG_PPC_PASEMI_NEMO
+    // SB600 for the Nemo board has non-zero devices on non-root bus.
        if (pci_pcie_type(parent) == PCI_EXP_TYPE_ROOT_PORT)
            return 1;

@@ -2231,6 +2233,7 @@ static int only_one_child(struct pci_bus
        if (parent->has_secondary_link &&
            !pci_has_flag(PCI_SCAN_ALL_PCIE_DEVS))
            return 1;
+    #endif

But the PCI maintainer is not going to accept a patch like this, which
adds a platform specific #ifdef in core code like this.

If you look at the rest of that file I don't think you'll find a single
#ifdef other than for generic configuration symbols.

Are you sure the PCI_SCAN_ALL_PCIE_DEVS logic doesn't work for you? It
sounds like it was added for exactly this problem.

cheers

Hi Michael,

Thanks for your reply. Sorry for my late answer. I removed the patch
above
from the RC1 and compiled the RC1 again. Unfortunately without the patch,
the kernel doesn't recognize any drives and partitions. Do you have
another
idea?

What happens if you boot RC1 with "pci=pcie_scan_all"?  If that works,
we do have some quirks that set that automatically, and we might be
able to add another one for the Nemo.

Can you collect the complete "lspci -vv" and dmesg output for this
system?  I'm curious about why it is special.

Bjorn

Hi Bjorn,

Thank you for your answer. I have tried to boot the kernel 4.15 RC1 (built
without the patch above) with the boot argument "pci=pcie_scan_all" but
without any success.

Just for info:

The CPU is a PA Semi “PWRficient” PA6T-1682M. This device combines dual
1.8GHz PowerPC cores with a 2MB L2 cache, dual channel DDR2 memory
controllers and 24 SerDes
channels. The PowerPC cores adhere to the Power ISA v2.04, and support
64-bit extensions. They feature a double precision FPU and a VMX (AltiVec)
vector unit. They each have a 64kB I-cache and a 64kB D-cache.
The SerDes channels support PCI Express, XAUI and SGMII protocols. The
“ENVOI” I/O subsystem which drives them includes caching, offload and DMA
resources to maximise I/O
performance.
Nemo uses the AMD/ATI SB600 South Bridge to provide various integrated I/O
functions including SATA/PATA ports, USB and audio. The SB600 connects to
the CPU via a PCIe x4 link. This is termed an “A-link II Express” link by
ATI/AMD. The design team determined early in the development of Nemo that
the link’s behaviour as an endpoint does not comply fully with the PCI
Express specification. Specifically, it requires the root complex to use
non-zero device numbers in type 0 configuration cycles to enumerate all the
devices within the SB600. This is related to the PC architecture and is used
to allow SB600 devices appear on logical bus 0.

More information about the Nemo board:

https://en.wikipedia.org/wiki/AmigaOne_X1000
http://www.a-eon.com/?page=x1000
http://www.amigaos.net/hardware/35/amigaone-x1000

Please find attached the complete "lspci -vv" and dmesg output.

Thanks.  Can you collect the "lspci -vv" output as root?  The one you
attached wasn't as root and doesn't include the PCI capability
information, which we need so we can tell which devices appear as
conventional PCI and which as PCIe.

It would also be helpful if you could send plain-text email because
the linux-pci list discards fancy email
(http://vger.kernel.org/majordomo-info.html#taboo).

It looks like the SB600 devices actually appear on bus 05 (not 00),
right?  I see these devices (among others):

  00:10.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
  00:11.0 PCI bridge: PA Semi, Inc PWRficient PCI-Express Port
  01:00.0 VGA compatible controller: [AMD/ATI] Barts XT [Radeon HD 6870]
  05:12.0 SATA controller: [AMD/ATI] SB600 Non-Raid-5 SATA
  05:14.4 PCI bridge: [AMD/ATI] SBx00 PCI to PCI Bridge
  06:05.0 Ethernet controller: RTL-8100/8101L/8139

So 00:10.0 and 00:11.0 are bridges leading to buses 01 and 05-06.
Maybe 00:11.0 is the Downstream Port that leads to this magic "A-Link
II Express" thing?

But I don't think all those SB600 devices on bus 05 are PCIe devices.
It would certainly be unconventional to have a PCIe device (00:11.0)
at the upstream end of a link and conventional PCI devices (05:12.0,
05:13.0, 05:13.1, etc) at the downstream end, with no visible PCIe
port.

The usual thing would be that 00:11.0 would be a Root Port or a Switch
Downstream Port leading to a Link, and the other end of the Link would
terminate in either a Switch Upstream Port or an Upstream Port
embedded in an Endpoint.

We'll have to think about how to handle this.  But the complete "lspci
-vv" output as root will have more useful information.

Bjorn