tree 706d8884262685213d67e4b0ef563956c07b35ab
parent 9cd94277bf1cb60e24827e9b241f6afeb05cab39
author Piotr Pryga <piotr.pryga@nordicsemi.no> 1657544752 +0200
committer Carles Cufí <carles.cufi@nordicsemi.no> 1657721637 +0200

Bluetooth: Controller: fix mayfly unwanted re-init every bt_enable call

Mayfly by design uses a memq for storage of its jobs. The memq
requires head and tail to track the content. It is considered
empty is head equals tail.

When memq instance is initialized then there is a new link
instance stored in head and tail, nevertheless the memq is
still empty.

When new job is enqueued to a memq, the inilial link is used
to store the job. New link, provided by enqueue call, is stored
in the tail for future enqueue.

When enqueued job was served and is dequeued, the link it was
assigned to is returned and stored in the job object.
That link will be used in future for call to enqueue.

Now lets consider a situation when we are just after initalization.
Some default initial link is in empty memq. We enqueue and dequeue
a job. After dequeue, the job object stores the initial link object.
The one that was put into the memq during initialization.
Next Bluetooth stack is disabled and enabled again.

The job is enqueued again, but it still stores the initial link
address. After enqueue the memq head points to initial link object,
that stores new job. Tail points to link deliveded by enqueue call,
that is also the initial link object. The memq is considered to be
empty, nevertheless there was a successful enqueue operation.

The issue is casued by lack of re-initialization of a job object
on init. In most cases these objects are static members of some
functions, hence there is no re-initialization after bt_disable
and bt_enable calls.

The problem is fixed by re-initialization of mayfly only once
on bt_enable() call. Then it doesn't matter what links are stored
in dequeued objects and there is no need to re-initialized mayfly
job objects.

Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>