NxpNfcRdLib Linux timespec bugs (and proposed patch)

[christianhack]

We have just attempted to upgrade to v05.19.00 of the reader library (using SW369319). We had been using v05.02.00.

There are a number of simple bugs we have discovered in the Linux abstraction layer, some of which have been introduced since previous versions by the someone just blindly changing all the uses of timespec and not testing them. In some cases the timespec needs to be an absolute time and in others it needs to be a relative time. They have all been changed to assume a relative time.

phOsal_EventPend() has had a bug introduced by removing the code adding the wait time required and supplying the timespec structure as just the time. This means pthread_cond_timewait returns immediately. This was fine in v05.02.00 but was introduced somewhere along the way to v05.19.00. Without a public repo I'm unable to pinpoint where or why or do a pull request or similar. What is the best process to submit bug fixes and improvements?

Similarly phOsal_SemPend() needs an absolute time rather than a relative time as does phOsal_MutexLock

With these bugs, the library would hang almost immediately in phacDiscLoop_Run and was very unreliable. Is the library ever tested because it appears it couldn't have been with such glaring issues?

Patch attached.

[AlexanderB]

Hello christianhack‌,

thank you very much for reporting the issue and also for the proposed patch.

R&D has delivered a fix and this will be in the next NXP NFC Reader Library release.

Best regards,

Alexander

[AlexanderB]

Hello christianhack‌,

I can assure you that we at NXP read the posts and try to take care of all of them. Sorry that you haven't gotten an  answer yet. I am also not the one who can answer that, but I will maker sure that the correct person is informed and we will update you on this :-)

Best regards,

Alexander

[vicentegomez]

Hi all 

The R & D  has this report since you reported, they are working to fix them on the next release.

Thanks for the information

Regards

Vicente Gomez

[christianhack]

So I see 5.21.00 released in December 2018 still has this problem. The OS abstraction layer for Linux is fundamentally broken and was broken sometime between 5.02.00 and 5.19.00 - no version control is accessible to tell when or why it was changed.

pthread_cond_timedwait() requires an absolute timespec passed to it. There is even code to read the current system time which is then overwritten with the timeout i.e. the system time read is mostly pointless. Because a relative time is supplied, the timed waits all expire immediately as they end up being epoch + x seconds.

Same for sem_timedwait(), pthread_mutex_timedlock(). 

Does anyone at NXP read these posts? Does anyone use the library on Linux? It would seem not.

[christianhack]

Anyone? I find it hard to believe no else is seeing this problem. Is no one using this latest library (or recent versions)?

Any response from NXP?