add: split PacketResponseNG status into status and reason

[douniwan5788]

No description provided.

[iceman1001]

Not sure about this one.
In which way do we need both status and reason that one field don't express today?

[douniwan5788]

Not sure about this one. In which way do we need both status and reason that one field don't express today?

The status is a too general error code, it doesn't cover command-specific details. I can see that almost every card type is using something like isok to return another error code. We can unify this to reason.

[iceman1001]

Ok, if we don't handle this fine grained status / reasons on the client side then this exercise is pointless.

Second concern I have is how this change influences going from older firmware to newer and back again.
This has to be proven to work smooth and without hiccups

[douniwan5788]

Ok, if we don't handle this fine grained status / reasons on the client side then this exercise is pointless.

Second concern I have is how this change influences going from older firmware to newer and back again. This has to be proven to work smooth and without hiccups

The original interface reply_ng and reply_mix initialize the reason to -1, and we don't have any PM3_xx code lower than -128. So, the final packet data is exactly the same when not using a reason.

old firmware -> new client
reason will be -1 and it should be interpreted as a 'generic/unknown reason'.

new firmware -> old client
cmds not reply reason : final packet data is exactly the same when not using a reason.
cmds do reply reason : most client code checks status == PM3_SUCCESS, so error statuses should be handled as an unknown error code.