]> git.itanic.dy.fi Git - linux-stable/commit
spi: spi-mem: add statistics support to ->exec_op() calls
authorThéo Lebrun <theo.lebrun@bootlin.com>
Fri, 16 Feb 2024 16:42:19 +0000 (17:42 +0100)
committerMark Brown <broonie@kernel.org>
Mon, 26 Feb 2024 13:55:15 +0000 (13:55 +0000)
commite63aef9c9121e5061cbf5112d12cadc9da399692
tree2c5126cd2a7b704a359ae75fc1ff33c299f9e277
parent0f3841a5e1152eca1a58cfbd9ceb6d311aa7e647
spi: spi-mem: add statistics support to ->exec_op() calls

Current behavior is that spi-mem operations do not increment statistics,
neither per-controller nor per-device, if ->exec_op() is used. For
operations that do NOT use ->exec_op(), stats are increased as the
usual spi_sync() is called.

The newly implemented spi_mem_add_op_stats() function is strongly
inspired by spi_statistics_add_transfer_stats(); locking logic and
l2len computation comes from there.

Statistics that are being filled: bytes{,_rx,_tx}, messages, transfers,
errors, timedout, transfer_bytes_histo_*.

Note about messages & transfers counters: in the fallback to spi_sync()
case, there are from 1 to 4 transfers per message. We only register one
big transfer in the ->exec_op() case as that is closer to reality.

This patch is NOT touching:
 - spi_async, spi_sync, spi_sync_immediate: those counters describe
   precise function calls, incrementing them would be lying. I believe
   comparing the messages counter to spi_async+spi_sync is a good way
   to detect ->exec_op() calls, but I might be missing edge cases
   knowledge.
 - transfers_split_maxsize: splitting cannot happen if ->exec_op() is
   provided.

Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://msgid.link/r/20240216-spi-mem-stats-v2-1-9256dfe4887d@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/spi/spi-mem.c