linux-stable.git/drivers/mailbox, branch v5.18.3

mailbox: forward the hrtimer if not queued and under a lock

2022-06-09T08:30:33+00:00

[ Upstream commit bca1a1004615efe141fd78f360ecc48c60bc4ad5 ]

This reverts commit c7dacf5b0f32957b24ef29df1207dc2cd8307743,
"mailbox: avoid timer start from callback"

The previous commit was reverted since it lead to a race that
caused the hrtimer to not be started at all. The check for
hrtimer_active() in msg_submit() will return true if the
callback function txdone_hrtimer() is currently running. This
function could return HRTIMER_NORESTART and then the timer
will not be restarted, and also msg_submit() will not start
the timer. This will lead to a message actually being submitted
but no timer will start to check for its compleation.

The original fix that added checking hrtimer_active() was added to
avoid a warning with hrtimer_forward. Looking in the kernel
another solution to avoid this warning is to check hrtimer_is_queued()
before calling hrtimer_forward_now() instead. This however requires a
lock so the timer is not started by msg_submit() inbetween this check
and the hrtimer_forward() call.

Fixes: c7dacf5b0f32 ("mailbox: avoid timer start from callback")
Signed-off-by: Björn Ardö 
Signed-off-by: Jassi Brar 
Signed-off-by: Sasha Levin

mailbox: pcc: Fix an invalid-load caught by the address sanitizer

2022-06-09T08:30:32+00:00

[ Upstream commit 369e4ef87a8f5da7c348ec2c61ec5cd726e8337a ]

`pcc_mailbox_probe` doesn't initialize all memory that has been allocated
before the first time that one of it's members `txdone_irq` may be
accessed.

This leads to a an invalid load any time that this member is accessed:
[    2.429769] UBSAN: invalid-load in drivers/mailbox/pcc.c:684:22
[    2.430324] UBSAN: invalid-load in drivers/mailbox/mailbox.c:486:12
[    4.276782] UBSAN: invalid-load in drivers/acpi/cppc_acpi.c:314:45

Link: https://bugzilla.kernel.org/show_bug.cgi?id=215587
Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe")
Signed-off-by: Mario Limonciello 
Reviewed-by: Sudeep Holla 
Signed-off-by: Jassi Brar 
Signed-off-by: Sasha Levin

mailbox: ti-msgmgr: Operate mailbox in polled mode during system suspend

2022-03-13T01:33:30+00:00

During the system suspend path we must set all queues to operate in
polled mode as it is possible for any protocol built using this mailbox,
such as TISCI, to require communication during the no irq phase of suspend,
and we cannot rely on interrupts there.

Polled mode is implemented by allowing the mailbox user to define an
RX channel as part of the message that is sent which is what gets polled
for a response. If polled mode is enabled, this will immediately be
polled for a response at the end of the mailbox send_data op before
returning success for the data send or timing out if no response is
received.

Finally, to ensure polled mode is always enabled during system suspend,
iterate through all queues to set RX queues to polled mode during system
suspend and disable polled mode for all in the resume handler.

Signed-off-by: Dave Gerlach 
Signed-off-by: Jassi Brar

mailbox: ti-msgmgr: Refactor message read during interrupt handler

2022-03-13T01:33:23+00:00

Refactor the portion of code that actually reads received messages from
a queue into its own function, ti_msgmgr_queue_rx_data, that is called
by the interrupt handler instead of reading directly from the handler.

Signed-off-by: Dave Gerlach 
Signed-off-by: Jassi Brar

mailbox: imx: support i.MX93 S401 MU

2022-03-13T01:31:09+00:00

Add i.MX93 S401 MU cfg

Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar

mailbox: imx: support dual interrupts

2022-03-13T01:31:03+00:00

i.MX93 S401 MU support two interrupts: tx empty and rx full.

 - Introduce a new flag IMX_MU_V2_IRQ for the dual interrupt case
 - Update Copyright

Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar

mailbox: imx: extend irq to an array

2022-03-13T01:30:55+00:00

To i.MX93 S401 MU, there are two interrupts: rx full and tx empty.
So extend irq to an array to prepare i.MX93 S401 MU support.

Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar

mailbox: imx: add i.MX8 SECO MU support

2022-03-13T01:27:15+00:00

i.MX8/8X SECO firmware IPC is an implementation of passing messages.
But current imx-mailbox driver only support one word  message,
i.MX8/8X linux side firmware has to request four TX, four RX and a
TXDB to support IPC to SECO firmware. This is low efficent and
more interrupts triggered compared with one TX and one RX.

To make SECO MU work,
  - parse the size of msg.
  - Only enable TR0/RR0 interrupt for transmit/receive message.
  - For TX/RX, only support one TX channel and one RX channel
  - For RX, support receive msg of any size, limited by hardcoded value
    of 30.

Signed-off-by: Franck LENORMAND 
Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar

mailbox: imx: introduce rxdb callback

2022-03-13T01:27:08+00:00

Add a rxdb callback to prepare for i.MX8 SECO MU rxdb which has a
different logic.

Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar

mailbox: imx: enlarge timeout while reading/writing messages to SCFW

2022-03-13T01:26:55+00:00

Mailbox driver needs to wait and read all the words in response to a
SCFW API call, else the protocol gets messed up and results in kernel hang.
When the responses are longer than 3 words its possible that SCFW will
take some time to fill up the rest of the words in the MU, a timeout of
100us is arbritrary and too short. While waiting for Linux to consume the
first 3 words of the response SCFW can be busy doing other stuff and hence
Linux needs to wait for the rest of the words.
Similar restriction applies when writing messages that are longer than
3 words.
This patch increases the timeout to 5secs while waiting for response
or writing long messages to SCFW.

Signed-off-by: Ranjani Vaidyanathan 
Signed-off-by: Peng Fan 
Signed-off-by: Jassi Brar