Reentrant and thread safe are two different things!
If you want more than one driver instance, the code needs to be reentrant.
This means it must not have global variables.
The HAL API lacks a fundamental principle. Each API method needs to have a per instance handle.
Please do not use AD9371 API in a multithreaded environment as API functions are not thread safe. It rely upon many user supplied global data structures.
Even though you can identify a code flow with specific to a chip, it's not guaranteed to continue with same thread as soon as scheduling happens. Consider a case where a thread identify a chip and scheduler reschedule the next thread running the same piece of code for other chip.
Thread safety requires a bunch of things, such as locking access to API calls that require exclusive access to devices (like SPI). We're comfortable with all of that, but as mhennerich points out, we need that per-instance handle, or some kind of context. Whenever we pass in a spiSettings_t, or a mykonos_device_t, we can fake that out. For those functions that don't take such an argument, we're stuck.
Simply not supporting multiple AD9371 is not an option.
We have raised this issue with concerned team. We will be able to provide you estimated timeframe in few days.
Would someone please update this thread, if this has actually been addressed? Very interested in this as the Ettus N310 has two AD9371 chips on it.