we are using C291 CPU in PKCAL mode (firmware running) plus the driver by NXP on the host system. Our host kernel is 2.6 Montavista Linux on the MIPS platform. Our kernel is fully preemptive with PREEMPT_RT patch. Its a no go situation, to disable the preemption in our product. The driver is already running, and executing handshake with the FW.
We have one problem however: The design of the driver manages synchronization of access to the buffer pool memory and ring pairs by spinlocks. But when sending and CMD (by C291 CLI) or data for encryption by test framework (by bash script over sysfs), one gets a problem with:
Bug: Scheduling while atomic... (inside a test_thread).
According to kernel docs, one can not sleep once spinlock is taken, since deadlock might occur. The problem is that test thread is using a schedule_timeout function to implement the waiting for encryption responses, which causes the bug since the test thread has taken the spin_lock. My idea is to use mutex instead of spin_lock which should not have this problem. I hope for not too big penalty of the mutex, since it never "spins" but gives up the CPU immediately after it cant acquire the lock.
The questions here are: Is this intended behaviour? (I assume no...) Why are there spin_locks used in the implementation where the same threads that hold a spin_lock are put to sleep? Did issues like this ever occur during the development with kernel which is used in the reference design (3.sth)?
I already got two answers on previous, more platform specific questions like: Please contact Proffesional NXP services...
I think this question is more general and aims for the architecture of the driver itself, thats why it could be answered here...