OSDN Git Service

Merge patch series "mailbox,soc: mpfs: add support for fallible services"
authorConor Dooley <conor.dooley@microchip.com>
Mon, 3 Apr 2023 18:21:09 +0000 (19:21 +0100)
committerConor Dooley <conor.dooley@microchip.com>
Mon, 3 Apr 2023 18:27:06 +0000 (19:27 +0100)
commit5ee40e8d7630b9f3665c9cd990ac00e6e4bc7957
tree8b9edf46333c8d25b00e5d08722db9a82848f301
parent49f965b6fbca63904d7397ce96066fa992f401a3
parent8f943dd12eeff71857b9a1ca45adbaaba379bf30
Merge patch series "mailbox,soc: mpfs: add support for fallible services"

Conor Dooley <conor@kernel.org> says:

Here are some fixes for the system controller on PolarFire SoC that I
ran into while implementing support for using the system controller to
re-program the FPGA. A few are just minor bits that I fixed in passing,
but the bulk of the patchset is changes to how the mailbox figures out
if a "service" has completed.

Prior to implementing this particular functionality, the services
requested from the system controller, via its mailbox interface, always
triggered an interrupt when the system controller was finished with
the service.

Unfortunately some of the services used to validate the FPGA images
before programming them do not trigger an interrupt if they fail.
For example, the service that checks whether an FPGA image is actually
a newer version than what is already programmed, does not trigger an
interrupt, unless the image is actually newer than the one currently
programmed. If it has an earlier version, no interrupt is triggered
and a status is set in the system controller's status register to
signify the reason for the failure.

In order to differentiate between the service succeeding & the system
controller being inoperative or otherwise unable to function, I had to
switch the controller to poll a busy bit in the system controller's
registers to see if it has completed a service.
This makes sense anyway, as the interrupt corresponds to "data ready"
rather than "tx done", so I have changed the mailbox controller driver
to do that & left the interrupt solely for signalling data ready.
It just so happened that all of the services that I had worked with and
tested up to this point were "infallible" & did not set a status, so the
particular code paths were never tested.

Link: https://lore.kernel.org/r/20230307202257.1762151-1-conor@kernel.org
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>