OK, so if it's purely about send_command() then why is the locking not being done in that function? Surely the most obvious and robust place to protect the function is within the function itself?
Not having send_command acquire any locks allows me to have variable levels of granularity of locking, for example in the worker thread that fetches RDS data from the chip it allows me to get exclusive access to the chip for the duration of the FIFO draining. Also any band switch for that chip, like AM to FM, etc. require chip to be power cycled which translates to multiple calls to send_command as well, I think having those performed atomically simplifies the driver as well.
Even if such fine granularity could be made to work, I think it is a big change that would need to be tested on the real HW and unfortunately I don't have any now and I don't believe there are or has ever been any users of that driver besides me and the company I used to work for(which no longer ships the device with that chip, so we can exclude them). I am trying to get some sort of evaluation board from SiLabs, but until and if they give it to me, any changes like that can not be verified to work on a real HW.