Skip to content

Further mvebu PCIe patches

Willy Tarreau linux-arm-kernel linux-pci 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 9 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 9 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/9] Further mvebu PCIe patches

Hi,

Quoted 30 lines · Thomas Petazzoni

Hello Russell,

Quoted 17 lines · Russell King - ARM Linux

Here are further PCIe patches which follow on from the previous set of six I sent earlier in September. This set:

* Separates the DT parsing from the use of this parsed data.
* Fixes memory leaks from kasprintf() and refcount leaks of the DT node where we break out from the loop early.
* Uses gpio_set_value_cansleep() so that GPIOs on I2C expanders can be used for the PCIe reset functionality.
* Switch to using devm_kcalloc() instead of devm_kzalloc(), which eliminates the multiplication, moving it into core code.
* Switch to using a gpio descriptor for the reset gpio, which can contain the active level information from DT. (It would be nice if gpiolib automated some of the resource claiming there.)
* Make PERST# vs clock timing to match PCIe specifications. PCIe specs require the clock to be running for 100us prior to releasing reset.
* Add the standard PCIe capability block in root port form to the

Quoted 8 lines

emulated PCIe configuration block. This allows the PCI layer to identify the "host bridge" as a PCIe device, and allows us to take advantage of the code in drivers/pci/pcie, particularly aspm for link power management.
* As a result of identifying ourselves as a PCIe root port, this eliminates the need to special case accesses to non-slot 0 in the driver; the lack of other "slots" is something which the generic PCI code knows about for PCIe root ports.

Quoted 5 lines

Thanks for these patches! They look good. However, I'm away for the Embedded Linux Conference Europe in Dublin right now, and therefore don't have access to my boards to test that it works OK on platforms other than Armada 38x (which you tested). I will try to do this testing next week, hopefully on Friday.

Just FWIW, I could run this series on top of the previous one on top of 4.3-rc4. It ran fine (ie no regressions observed) on :

- Iomega iconnect (kirkwood) with an RT3090 WiFi card (I could verify that the card was detected in lspci, module loaded without error and the interface appeared)

- mirabox (armada370) with a dual-igb NIC (i350), Marvell 88E8053 (sky2), realtek 8168, and bcm5721. For the first one, I only verified that the driver loaded properly and that I could set the links up on the two NICs. For the last 3, I could even check that the NIC could receive traffic.

I could not test on the XPGP board, it didn't boot regardless of the patches, I'll have to redo a clean config. This happens once in a while during "make oldconfig" over a too large version jump.

So far so good!

Cheers,
Willy