[spi_device] Incoming address size cannot be validated

[a-will]

In flash/passthrough modes, the spi_device IP does not give any indication of how long the transaction actually was, so transactions using the wrong address mode may pass through. This might only be of interest for invalidating shortened Sector Erase transactions, where 3 bytes of address was provided when the address mode required 4 bytes of address.

This is tagged for a future release. It falls into the category of robustness in an environment with errors, but it is not critical for the current stepping.

Effort estimate by @hcallahan-lowrisc:

I'm not super confident on this estimate and hence I have leaned towards pessimism. If it is not deferred, recommend to re-evaluate.

estimate 16
remaining 2023-03-23 16

[tjaychen]

just curious, wouldn't this get picked up through payload length or something?
ie, after we get the CSb rise, and software comes to look what was received and discover it's one byte short?

[a-will]

@tjaychen There is no payload for Sector Erase, though :)

And you can't validate the payload length for commands with variable payload lengths.

[tjaychen]

Ah, thanks for the clarification.

[andreaskurth]

Triaged for spi_device. Assigning to M2.5 with Priority:P2 Priority: medium because I think we should make sure the current HW behavior is suitable for production (discuss with product team), although this is "only" about robustness in an environment with errors. If yes, defer back to FutureRelease.

[hcallahan-lowrisc]

I'm not super confident on this estimate and hence I have leaned towards pessimism. If it is not deferred, recommend to re-evaluate.

estimate 16
remaining 2023-03-23 16

[a-will]

This was actually fixed in #21120. I forgot that the address FIFO is written all at once, so there is no need to separately track the number of bytes written -- It will either be 0 or the number indicated by the address mode.