There are a few unused bits in the request/response headers which could be used for this.

This would also be a great time to make a few other changes to the packet headers:

1) Separate header CRC vs. body CRC.  Right now, you can't know if you have the packet length correct until you've read the entire packet with the unverified length.

2) Actually use a CRC instead of a checksum.  The design doc for host command v3 said CRC, but somehow we (I) implemented a checksum.  Which has caused problems in at least one case where 0x00 bytes were getting inserted into a packet.

I'll propose a design for this.

Working on a design doc.

We'll need to add host command protocol V4 to do this, because existing protocol request/response handlers are paranoid about verifying the reserved bytes == 0.

To keep the init sequence simple, we'll keep supporting command protocol V3, at least for EC_CMD_GET_PROTOCOL_INFO.  Once an AP driver determines via that command that V4 is supported, it can decide to start sending V4 packets.

The EC changes are fairly straightforward and well-contained.  

The AP changes can be phased in over time, since it'll be a while before we can drop V3 support in the EC (just as it was a while before we could drop V2 support).

Design doc in progress here: https://docs.google.com/a/google.com/document/d/1AcH2DH9lzceRncpNKj32l0W1ueaN2EXfQZWfSRRbyfY/edit?usp=sharing

Not ready for review yet, but want to make sure it's linked in the bug so we don't lose it.

I'm curious if this is still planned?

I'd still like to do it, if we can find resources to do so.

This came up recently where retries would have solved the problem.  <https://patchwork.kernel.org/patch/9996149/>.  I'm sure it will come up again...