[PATCH v2 0/2] mailbox: add Axiado AX3005 mailbox driver

The Axiado AX3005 SoC integrates a mailbox controller that provides
inter-processor communication channels between the host CPU and the
on-chip co-processor.

The controller exposes 16 fixed-function channels split into two
groups: 8 TX channels and 8 RX channels. Each channel has a
hardware FIFO and a control/status register, while TX and RX
channels reside in separate MMIO register regions.

Only the RX channels expose interrupts to the host CPU.
TX completion is detected by polling the FIFO empty status, so
txdone_poll is used instead of txdone_irq. RX delivery uses a
threaded IRQ per channel because draining a mailbox message word by
word is not appropriate in hard IRQ context.

The ax3005.dtsi mailbox node will follow in a separate patch once
the AX3005 devicetree series currently under review has been merged.

This series consists of:
1. dt-bindings: mailbox: add Axiado AX3005 mailbox
2. mailbox: add Axiado AX3005 mailbox driver

The corresponding MAINTAINERS entry is added incrementally by the
two patches: the binding path in patch 1 and the driver path in
patch 2.

Testing:
Tested on AX3005 using an out-of-tree MCTP-over-mailbox transport
driver, not yet submitted upstream, as the mailbox client. The test
exercised channel 0 for TX and channel 8 for RX.

Verified end to end by issuing a PLDM Firmware Update command from
OpenBMC over MCTP and routing it through this mailbox driver to the
on-chip coprocessor. The firmware update completed successfully,
and the resulting image passed verification.

Signed-off-by: Swark Yang <[email protected]>
---
Changes in v2:
    - dt-bindings: addressed review from Krzysztof Kozlowski
	- dropped the unneeded '|' block-scalar indicator from
	  description fields, dropped the redundant minItems on
	  interrupts, and dropped the default-valued
	  status = "okay" from the example.
    - driver: a further round of internal review turned up a few
      more issues worth folding into this v2 rather than leaving
      them for a v3:
	- Widened the RX wait timeout margin (500us -> 1000us);
	  the previous value had no measured basis for the largest
	  (256-byte) messages.
	- Unified TX/RX message-length validation against a single
	  field (mb->drv_data->msg_size) instead of two fields
	  (chan_msg_size) that always happened to agree.
	- Added a per-channel FIFO error counter exposed via
	  debugfs, alongside the existing rate-limited dev_warn();
	  a ratelimited log alone can silently suppress lines under
	  a burst, losing the true count.
	- Stopped discarding already-queued good data on an
	  overflow/underflow flag alone: clear, log, and count the
	  error, then let the existing length-validated read decide
	  if what's queued is usable. Only an invalid message length
	  or a read timeout now triggers a flush.
	- Only flush the FIFO in startup()/shutdown() when an error
	  is actually detected, not unconditionally -- a blind flush
	  was discarding messages the peer legitimately sent before
	  this side started up.
	- Used devm_kzalloc() instead of devm_kmalloc() for
	  rx_buffer.
	- Fixed a checkpatch --strict alignment warning in the RX
	  wait poll.
	- Dropped the TX/RX channel-type guard added in the previous
	  round, as it prevented standalone loopback testing of the
	  mailbox controller without a coprocessor.
- Link to v1: https://lore.kernel.org/r/20260729-upstream-axiado-ax3005-mailbox-upstream-v1-0-8961b7350338@axiado.com

---
Swark Yang (2):
      dt-bindings: mailbox: add Axiado AX3005 mailbox
      mailbox: add Axiado AX3005 mailbox driver

 .../bindings/mailbox/axiado,ax3005-mailbox.yaml    |  96 +++++
 MAINTAINERS                                        |   8 +
 drivers/mailbox/Kconfig                            |  10 +
 drivers/mailbox/Makefile                           |   2 +
 drivers/mailbox/axiado-mailbox.c                   | 395 +++++++++++++++++++++
 5 files changed, 511 insertions(+)
---
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
change-id: 20260728-upstream-axiado-ax3005-mailbox-upstream-86feaa7edf49

Best regards,
-- 
Swark Yang <[email protected]>