Thank you very much - I'll look into it!
But does that mean that this would still make connecting an SPI module that requires additional GPIOs impossible?

If this is a limitation of the new gpiochip API I'd have to go back to the old sysfs API - but first I would suspect a bug in my code.

Maybe I'll also need to investigate that further to see where that segfault comes from. What I observed until now: If you use the SPI and GPIO module in parallel, the only limitation is that you cannot access the hard-wired CE-pins of the SPI interface (and probably also not MISO/MOSI/SCK, I haven't tried that yet) through your GPIO implementation.

So if you start your application on a Pi with --spi=0:0:/dev/spidev0.0, GPIO 8 is bound to its role of being CE0, so using -g/dev/gpiochip0 and accessing GPIO_PIN(0, 8) does not work. That may just be a problem with tests/periph_spi not checking some return values. So in that specific test application, you have to use -1 0 instead of 0 8 for the bus initialization. Other GPIOs which are not part of the SPI bus are fine, using an arbitrary pin, e.g. GPIO27, by initializing with 0 27 works, and that line is even pulled low when communicating on the bus (this is part of what this PR does).

To me, such a limitation on the Linux side would make perfectly sense. It would only be nice if both modules coordinate their use of the pins somehow. Maybe it's possible to use the gpiochip API (haven't used it before) to see if some lines are already in use. Otherwise, I don't know how to learn from /dev/spidev0.0 that it points to lines 8-11 on /dev/gpiochip0, or vice-versa.

I did some more testing.

First, the good news:

• With a freshly setup Raspberry Pi and repository, I cannot reproduce the segfault anymore (I tried it on a Raspberry Pi 3B and a 3B+)
• Using SPI_HWCS(0) and GPIO_PIN(0, 8) makes no difference anymore. So you can use both variants to specify the chip select line, even if they are mapped to the same pin (Raspberry Pi 3B+).
  • Even switching back and forth between both seems to work (using init 0 0 0 -1 0 and init 0 0 0 0 8 in the perip_spi test application)
• Using this SX1276 LoRa transceiver, I could verify that using arbitrary GPIOs for chip select works (that HAT has a wiring error connecting CS to GPIO25, so it didn't work before, but does now; tested on Raspberry Pi 3B).
  • During that test, I found another small bug in my code regarding the cont flag of spi_transfer_bytes, which wasn't handled correctly with GPIO-based CS lines. That is fixed in the additional commit. Now, transactions with multiple calls to spi_transfer_bytes should work as well.

The bad news:

• If you take one of the SPI data lines (MISO, MOSI, CLK) and pass it as cs parameter to spi_init_cs using the GPIO_PIN macro, that line will no longer be usable through the /dev/spidev* interface, which in general makes communication with peripherals impossible. This state remains until you restart the Linux host (tested on Raspberry Pi 3B, 3B+).

So while the problem of mapping hardware chip select lines to their representation in the gpiochip is gone, that issue remains for the MISO, MOSI, and CLK lines. The only solution would be forbidding to gpio_initializing these pins when RIOT is started with SPI support. But that would introduce some mutual dependencies between the GPIO and the SPI implementation, and I don't know if that's desirable. And again, it is hard to find out which of the gpiochip lines are those special SPI lines. And as using MISO, MOSI, or CLK as CS line makes no sense in general, I think a note in the documentation will be sufficient here.

Thank you a lot for the patch!
Sorry it took me so long to get back to it.
Let's hope we can get this merged soon upstream too.

That'd be great. I'm using your GPIO implementation and this patch cherry-picked onto a 2019-10-based branch in my project for some time now and it seems to be quite stable for that scenario.