STM I3C logs error on "expected" failure cases.

[jgrowdenTT]

Describe the bug

MCTP documents multiple ways of how an I3C controller can recieve data from a target I3C device. In the polling approach documented in MCTP I3C binding specification section 5.2.2.4, the controller may attempt a read while accepting no data returned as valid, in case the target had no data to relay. In this case, the target shall NACK the address byte if no data is available.

As far as I can tell, all these requirements are met by the STM I3C implementation. However, the handling of these cases pops multiple error logs in STM I3C controller.

Namely, on each poll with no data from target, the following errors are reported.

E: TX/RX FIFO underrun/overrun
E: Address NACK
E: Failed to transfer messages, err=-5

The errors are not stating anything unexpected, let alone erroneous, is occuring in the system. While trivial to remove the prints, I would imagine these system expecations I've documented here do not unilaterally apply across all use cases.

Regression

• This is a regression.

Steps to reproduce

1. west build -p -b nucleo_u385rg_q tests/subsys/pmci/mctp/i3c -- -DCONFIG_I3C_LOG_LEVEL_OFF=n
2. west flash <...>
3. Examine test output:

Expecation:
No Error logs noted, test cases pass

Actual:
Spam of error messages (see "Relevant log output")

Relevant log output

E: TX/RX FIFO underrun/overrun
E: Address NACK
E: Failed to transfer messages, err=-5

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

MAC OS

Nucleo U385RG Q with I3C1 I3C2 loopbacked based on the test pinctrl. (C7-36 <-> C10 28 and C10 22 <-> C10 25)

Additional Context

No response

[edersondisouza]

I would add that this most certainly affect multiple I3C drivers, so the solution must be a general one.

[dcpleung]

Since the hardware is responsible for TX/RX and ACK/NACK, we can add a new flag to I3C_MSG_* to signal that the message is expecting a NACK. Or we can add a return value -ENODEV to doxygen of i3c_transfer() to signal the NACK. Drivers need to be updated to return -ENODEV when NACK is encountered. The caller of i3c_transfer() can then process the resulting NACK accordingly. Of course, the driver will need to be updated to not print NACK as an error.

[dcpleung]

API related changes are in #117367.

The STM32 driver will need to be modified to support this so this use case can be handled properly.