dpaa2: fiken token for open commands and wait for our command

[bz]

Summary

The authentication token for OPEN commands is supposed to be set to 0.
In some cases we re-used the cmd for multiple consecutive OPEN commands
and the previous one returned a token which is then left for the next
command. Make sure all OPEN commands explicitly set the token to 0.

When waiting for a command reply, make sure the reply matches our cmdid
and token (or has a 0-token in the request). This at least seems to
work around other race conditions not yet fully understood (possibly due
to a previous late command reply?).

[bz]

This might also have fixed a

[E, mc_portal_isr:1032, RESMAN]  Authentication error: invalid token:0x26d set on portal 4

I was seeing in the console log.

Also (but sample size == 1 so far) my MC errors are gone on a boot with this; also no NFS server timeout. I'll keep a reboot loop going over night and see.

[bz]

Okay, the 2nd half it not is... but now at least errors are showing up...
``
dpaa2_ni0: dpaa2_ni_miibus_statchg: failed to set DPMAC link state: id=7, error=7
dpni0: link state changed to UP
``

[dsl]

My understanding is that re-setting the command token to zero explicitly isn't what MC expects in most operations (except xxx_CREATE ones when token = 0 means that a newly created object will be assigned to the resource container that hosts the MC command portal currently executing the command), i.e. when you're going to open an object (DPNI, DPMAC, etc.) within a resource container, you must supply an authentication token obtained previously when the resource container was opened.

[bz]

In D38594#878835, @dsl wrote:

My understanding is that re-setting the command token to zero explicitly isn't what MC expects in most operations (except xxx_CREATE ones when token = 0 means that a newly created object will be assigned to the resource container that hosts the MC command portal currently executing the command), i.e. when you're going to open an object (DPNI, DPMAC, etc.) within a resource container, you must supply an authentication token obtained previously when the resource container was opened.

How often do you OPEN objects?

Manual says:
``
32-47 TOKEN Authentication token. For “OPEN” commands and for DPXX_GET_API_VERSION, set this field to zero. ...

``

[dsl]

How often do you OPEN objects?

You're taking current implementation into account only when I re-used dpaa2_cmd extensively without proper locking though. I'm working on a patch to allocate dpaa2_cmd on stack and initialize them ad-hoc. We won't need to lock them, but DPAA2 objects themselves will be opened/closed more frequently.

[bz]

@dsl fixed the entire driver in https://cgit.FreeBSD.org/src/commit/?id=4cd966142822ce24c12751c863a073a8b7cb9c14