[PATCH 0/3] mailbox: Allow direct registration to a channel

[PATCH 0/3] mailbox: Allow direct registration to a channel

[Elliot Berman]

Two mailbox controllers have channel/client binding mechanisms that are
controller-specific and not using the devicetree binding mechanisms. Mailbox
channel/client is conceptually done in two steps: selecting the channel
and binding the selected to channel to a client. Channel selection is sometimes
controller specific (pcc and omap are examples). The channel/client binding
code is all the same.

This small series de-duplicates and refactors the channel/client binding
into a common framework function: "mbox_bind_client" which all of the
channel selection mechanisms can use.

I found this duplicate code while working on the support for Gunyah hypervisor
message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
however it is a straightforward conversion here.

[1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/

Elliot Berman (3):
  mailbox: Allow direct registration to a channel
  mailbox: omap: Use mbox_bind_client
  mailbox: pcc: Use mbox_bind_client

 drivers/mailbox/mailbox.c      | 96 ++++++++++++++++++++++++----------
 drivers/mailbox/omap-mailbox.c | 22 ++------
 drivers/mailbox/pcc.c          | 82 ++++++++++++++++-------------
 include/linux/mailbox_client.h |  1 +
 4 files changed, 118 insertions(+), 83 deletions(-)


base-commit: 09e41676e35ab06e4bce8870ea3bf1f191c3cb90
-- 
2.39.1

[PATCH 2/3] mailbox: omap: Use mbox_bind_client

[Elliot Berman]

Use generic mbox_bind_client() to bind omap mailbox channel to a client.

mbox_bind_client is identical to the replaced lines, except that it:
 - Does the operation under con_mutex which prevents possible races in
   removal path
 - Sets TXDONE_BY_ACK if omap uses TXDONE_BY_POLL. omap uses
   TXDONE_BY_IRQ, so this check is not applicable.
 - Calls chan->mbox->ops->startup, if available. omap doesn't have, so
   this is not applicable.

Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
---
 drivers/mailbox/omap-mailbox.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 098c82d87137..dfe82a5ff403 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -417,8 +417,6 @@ struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
 	struct device *dev = cl->dev;
 	struct omap_mbox *mbox = NULL;
 	struct omap_mbox_device *mdev;
-	struct mbox_chan *chan;
-	unsigned long flags;
 	int ret;
 
 	if (!dev)
@@ -441,23 +439,11 @@ struct mbox_chan *omap_mbox_request_channel(struct mbox_client *cl,
 	if (!mbox || !mbox->chan)
 		return ERR_PTR(-ENOENT);
 
-	chan = mbox->chan;
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->msg_free = 0;
-	chan->msg_count = 0;
-	chan->active_req = NULL;
-	chan->cl = cl;
-	init_completion(&chan->tx_complete);
-	spin_unlock_irqrestore(&chan->lock, flags);
-
-	ret = chan->mbox->ops->startup(chan);
-	if (ret) {
-		pr_err("Unable to startup the chan (%d)\n", ret);
-		mbox_free_channel(chan);
-		chan = ERR_PTR(ret);
-	}
+	ret = mbox_bind_client(mbox->chan, cl);
+	if (ret)
+		return ERR_PTR(ret);
 
-	return chan;
+	return mbox->chan;
 }
 EXPORT_SYMBOL(omap_mbox_request_channel);
 
-- 
2.39.1

[PATCH 3/3] mailbox: pcc: Use mbox_bind_client

[Elliot Berman]

Use generic mbox_bind_client() to bind omap mailbox channel to a client.

mbox_bind_client is identical to the replaced lines, except that it:
 - Does the operation under con_mutex which prevents possible races in
   removal path
 - Sets TXDONE_BY_ACK if pcc uses TXDONE_BY_POLL and the client knows
   when tx is done. TXDONE_BY_ACK is already set if there's no interrupt,
   so this is not applicable.
 - Calls chan->mbox->ops->startup. This is usecase for requesting irq:
   move the devm_request_irq into the startup callback and unregister it
   in the shutdown path.

Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
---
 drivers/mailbox/pcc.c | 82 ++++++++++++++++++++++++-------------------
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 105d46c9801b..3a025415c5d5 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -283,7 +283,7 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
 	struct pcc_chan_info *pchan;
 	struct mbox_chan *chan;
 	struct device *dev;
-	unsigned long flags;
+	int rc;
 
 	if (subspace_id < 0 || subspace_id >= pcc_chan_count)
 		return ERR_PTR(-ENOENT);
@@ -296,30 +296,9 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
 	}
 	dev = chan->mbox->dev;
 
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->msg_free = 0;
-	chan->msg_count = 0;
-	chan->active_req = NULL;
-	chan->cl = cl;
-	init_completion(&chan->tx_complete);
-
-	if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
-		chan->txdone_method = TXDONE_BY_ACK;
-
-	spin_unlock_irqrestore(&chan->lock, flags);
-
-	if (pchan->plat_irq > 0) {
-		int rc;
-
-		rc = devm_request_irq(dev, pchan->plat_irq, pcc_mbox_irq, 0,
-				      MBOX_IRQ_NAME, chan);
-		if (unlikely(rc)) {
-			dev_err(dev, "failed to register PCC interrupt %d\n",
-				pchan->plat_irq);
-			pcc_mbox_free_channel(&pchan->chan);
-			return ERR_PTR(rc);
-		}
-	}
+	rc = mbox_bind_client(chan, cl);
+	if (rc)
+		return ERR_PTR(rc);
 
 	return &pchan->chan;
 }
@@ -333,23 +312,12 @@ EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
  */
 void pcc_mbox_free_channel(struct pcc_mbox_chan *pchan)
 {
-	struct pcc_chan_info *pchan_info = to_pcc_chan_info(pchan);
 	struct mbox_chan *chan = pchan->mchan;
-	unsigned long flags;
 
 	if (!chan || !chan->cl)
 		return;
 
-	if (pchan_info->plat_irq > 0)
-		devm_free_irq(chan->mbox->dev, pchan_info->plat_irq, chan);
-
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->cl = NULL;
-	chan->active_req = NULL;
-	if (chan->txdone_method == TXDONE_BY_ACK)
-		chan->txdone_method = TXDONE_BY_POLL;
-
-	spin_unlock_irqrestore(&chan->lock, flags);
+	mbox_free_channel(chan);
 }
 EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
 
@@ -377,8 +345,48 @@ static int pcc_send_data(struct mbox_chan *chan, void *data)
 	return pcc_chan_reg_read_modify_write(&pchan->db);
 }
 
+/**
+ * pcc_startup - Called from Mailbox Controller code. Used here
+ *		to request the interrupt.
+ * @chan: Pointer to Mailbox channel to startup.
+ *
+ * Return: Err if something failed else 0 for success.
+ */
+int pcc_startup(struct mbox_chan *chan)
+{
+	struct pcc_chan_info *pchan = chan->con_priv;
+	int rc;
+
+	if (pchan->plat_irq > 0) {
+		rc = devm_request_irq(chan->mbox->dev, pchan->plat_irq, pcc_mbox_irq, 0,
+				      MBOX_IRQ_NAME, chan);
+		if (unlikely(rc)) {
+			dev_err(chan->mbox->dev, "failed to register PCC interrupt %d\n",
+				pchan->plat_irq);
+			return rc;
+		}
+	}
+
+	return 0;
+}
+
+/**
+ * pcc_shutdown - Called from Mailbox Controller code. Used here
+ *		to free the interrupt.
+ * @chan: Pointer to Mailbox channel to shutdown.
+ */
+void pcc_shutdown(struct mbox_chan *chan)
+{
+	struct pcc_chan_info *pchan = chan->con_priv;
+
+	if (pchan->plat_irq > 0)
+		devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
+}
+
 static const struct mbox_chan_ops pcc_chan_ops = {
 	.send_data = pcc_send_data,
+	.startup = pcc_startup,
+	.shutdown = pcc_shutdown,
 };
 
 /**
-- 
2.39.1

Re: [PATCH 0/3] mailbox: Allow direct registration to a channel

[Sudeep Holla]

On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> Two mailbox controllers have channel/client binding mechanisms that are
> controller-specific and not using the devicetree binding mechanisms. Mailbox
> channel/client is conceptually done in two steps: selecting the channel
> and binding the selected to channel to a client. Channel selection is sometimes
> controller specific (pcc and omap are examples). The channel/client binding
> code is all the same.
> 
> This small series de-duplicates and refactors the channel/client binding
> into a common framework function: "mbox_bind_client" which all of the
> channel selection mechanisms can use.
> 
> I found this duplicate code while working on the support for Gunyah hypervisor
> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> however it is a straightforward conversion here.
> 
> [1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/
> 
> Elliot Berman (3):
>   mailbox: Allow direct registration to a channel

I am unable to find the above patch either in my inbox or in lore[1].
Can you please repost the same ? I would like to test/review w.r.t PCC
driver.

--
Regards,
Sudeep

[1] https://lore.kernel.org/all/20230213232537.2040976-1-quic_eberman@quicinc.com/

Re: [PATCH 0/3] mailbox: Allow direct registration to a channel

[Elliot Berman]

On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
>> Two mailbox controllers have channel/client binding mechanisms that are
>> controller-specific and not using the devicetree binding mechanisms. Mailbox
>> channel/client is conceptually done in two steps: selecting the channel
>> and binding the selected to channel to a client. Channel selection is sometimes
>> controller specific (pcc and omap are examples). The channel/client binding
>> code is all the same.
>>
>> This small series de-duplicates and refactors the channel/client binding
>> into a common framework function: "mbox_bind_client" which all of the
>> channel selection mechanisms can use.
>>
>> I found this duplicate code while working on the support for Gunyah hypervisor
>> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
>> however it is a straightforward conversion here.
>>
>> [1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/
>>
>> Elliot Berman (3):
>>    mailbox: Allow direct registration to a channel
> 
> I am unable to find the above patch either in my inbox or in lore[1].
> Can you please repost the same ? I would like to test/review w.r.t PCC
> driver.
> 

Hi Sudeep,

Not sure why the patch didn't end up your inbox; lore seems to have 
linked it correctly and indicates you were in To:. If I missed 
something, let me know and I'll make sure you're properly included if 
future versions needed.

https://lore.kernel.org/all/20230213232537.2040976-4-quic_eberman@quicinc.com/

Thanks,
Elliot

> --
> Regards,
> Sudeep
> 
> [1] https://lore.kernel.org/all/20230213232537.2040976-1-quic_eberman@quicinc.com/
> 

Re: [PATCH 0/3] mailbox: Allow direct registration to a channel

[Sudeep Holla]

On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
> 
> 
> On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> > On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> > > Two mailbox controllers have channel/client binding mechanisms that are
> > > controller-specific and not using the devicetree binding mechanisms. Mailbox
> > > channel/client is conceptually done in two steps: selecting the channel
> > > and binding the selected to channel to a client. Channel selection is sometimes
> > > controller specific (pcc and omap are examples). The channel/client binding
> > > code is all the same.
> > > 
> > > This small series de-duplicates and refactors the channel/client binding
> > > into a common framework function: "mbox_bind_client" which all of the
> > > channel selection mechanisms can use.
> > > 
> > > I found this duplicate code while working on the support for Gunyah hypervisor
> > > message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> > > however it is a straightforward conversion here.
> > > 
> > > [1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/
> > > 
> > > Elliot Berman (3):
> > >    mailbox: Allow direct registration to a channel
> > 
> > I am unable to find the above patch either in my inbox or in lore[1].
> > Can you please repost the same ? I would like to test/review w.r.t PCC
> > driver.
> > 
> 
> Hi Sudeep,
> 
> Not sure why the patch didn't end up your inbox; lore seems to have linked
> it correctly and indicates you were in To:. If I missed something, let me
> know and I'll make sure you're properly included if future versions needed.
> 
> https://lore.kernel.org/all/20230213232537.2040976-4-quic_eberman@quicinc.com/

No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
link for patch 1/3 if you are able to find it ? Or just repost the series
if you can't.

-- 
Regards,
Sudeep

Re: [PATCH 0/3] mailbox: Allow direct registration to a channel

[Elliot Berman]

On 2/16/2023 1:58 AM, Sudeep Holla wrote:
> On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
>>
>>
>> On 2/15/2023 2:17 AM, Sudeep Holla wrote:
>>> On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
>>>> Two mailbox controllers have channel/client binding mechanisms that are
>>>> controller-specific and not using the devicetree binding mechanisms. Mailbox
>>>> channel/client is conceptually done in two steps: selecting the channel
>>>> and binding the selected to channel to a client. Channel selection is sometimes
>>>> controller specific (pcc and omap are examples). The channel/client binding
>>>> code is all the same.
>>>>
>>>> This small series de-duplicates and refactors the channel/client binding
>>>> into a common framework function: "mbox_bind_client" which all of the
>>>> channel selection mechanisms can use.
>>>>
>>>> I found this duplicate code while working on the support for Gunyah hypervisor
>>>> message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
>>>> however it is a straightforward conversion here.
>>>>
>>>> [1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/
>>>>
>>>> Elliot Berman (3):
>>>>     mailbox: Allow direct registration to a channel
>>>
>>> I am unable to find the above patch either in my inbox or in lore[1].
>>> Can you please repost the same ? I would like to test/review w.r.t PCC
>>> driver.
>>>
>>
>> Hi Sudeep,
>>
>> Not sure why the patch didn't end up your inbox; lore seems to have linked
>> it correctly and indicates you were in To:. If I missed something, let me
>> know and I'll make sure you're properly included if future versions needed.
>>
>> https://lore.kernel.org/all/20230213232537.2040976-4-quic_eberman@quicinc.com/
> 
> No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
> Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
> link for patch 1/3 if you are able to find it ? Or just repost the series
> if you can't.
> 

Huh, not sure what happened there. I got a copy of Patch 1/3 but I also 
don't see it in lore. Resent:

https://lore.kernel.org/all/20230216163804.456714-1-quic_eberman@quicinc.com/

Re: [PATCH 0/3] mailbox: Allow direct registration to a channel

[Sudeep Holla]

On Thu, Feb 16, 2023 at 08:41:05AM -0800, Elliot Berman wrote:
> 
> 
> On 2/16/2023 1:58 AM, Sudeep Holla wrote:
> > On Wed, Feb 15, 2023 at 08:58:10AM -0800, Elliot Berman wrote:
> > > 
> > > 
> > > On 2/15/2023 2:17 AM, Sudeep Holla wrote:
> > > > On Mon, Feb 13, 2023 at 03:25:34PM -0800, Elliot Berman wrote:
> > > > > Two mailbox controllers have channel/client binding mechanisms that are
> > > > > controller-specific and not using the devicetree binding mechanisms. Mailbox
> > > > > channel/client is conceptually done in two steps: selecting the channel
> > > > > and binding the selected to channel to a client. Channel selection is sometimes
> > > > > controller specific (pcc and omap are examples). The channel/client binding
> > > > > code is all the same.
> > > > > 
> > > > > This small series de-duplicates and refactors the channel/client binding
> > > > > into a common framework function: "mbox_bind_client" which all of the
> > > > > channel selection mechanisms can use.
> > > > > 
> > > > > I found this duplicate code while working on the support for Gunyah hypervisor
> > > > > message queues [1]. I've only been able to compile-test omap-maiblox and pcc,
> > > > > however it is a straightforward conversion here.
> > > > > 
> > > > > [1]: https://lore.kernel.org/all/20230120224627.4053418-9-quic_eberman@quicinc.com/
> > > > > 
> > > > > Elliot Berman (3):
> > > > >     mailbox: Allow direct registration to a channel
> > > > 
> > > > I am unable to find the above patch either in my inbox or in lore[1].
> > > > Can you please repost the same ? I would like to test/review w.r.t PCC
> > > > driver.
> > > > 
> > > 
> > > Hi Sudeep,
> > > 
> > > Not sure why the patch didn't end up your inbox; lore seems to have linked
> > > it correctly and indicates you were in To:. If I missed something, let me
> > > know and I'll make sure you're properly included if future versions needed.
> > > 
> > > https://lore.kernel.org/all/20230213232537.2040976-4-quic_eberman@quicinc.com/
> > 
> > No, I do have patch 2/3 and 3/3 in my inbox along with the cover letter.
> > Patch 1/3 is missing in both my inbox and lore. Can you send me the lore
> > link for patch 1/3 if you are able to find it ? Or just repost the series
> > if you can't.
> > 
> 
> Huh, not sure what happened there. I got a copy of Patch 1/3 but I also
> don't see it in lore. Resent:
> 
> https://lore.kernel.org/all/20230216163804.456714-1-quic_eberman@quicinc.com/

Thanks.

You can add(tested PCC driver)

Tested-by: Sudeep Holla <sudeep.holla@arm.com>

-- 
Regards,
Sudeep

[PATCH 1/3] mailbox: Allow direct registration to a channel

[Elliot Berman]

Support virtual mailbox controllers and clients which are not platform
devices or come from the devicetree by allowing them to match client to
channel via some other mechanism.

Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
---
 drivers/mailbox/mailbox.c      | 96 ++++++++++++++++++++++++----------
 include/linux/mailbox_client.h |  1 +
 2 files changed, 69 insertions(+), 28 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4229b9b5da98..adf36c05fa43 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -317,6 +317,71 @@ int mbox_flush(struct mbox_chan *chan, unsigned long timeout)
 }
 EXPORT_SYMBOL_GPL(mbox_flush);
 
+static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
+{
+	struct device *dev = cl->dev;
+	unsigned long flags;
+	int ret;
+
+	if (chan->cl || !try_module_get(chan->mbox->dev->driver->owner)) {
+		dev_dbg(dev, "%s: mailbox not free\n", __func__);
+		return -EBUSY;
+	}
+
+	spin_lock_irqsave(&chan->lock, flags);
+	chan->msg_free = 0;
+	chan->msg_count = 0;
+	chan->active_req = NULL;
+	chan->cl = cl;
+	init_completion(&chan->tx_complete);
+
+	if (chan->txdone_method	== TXDONE_BY_POLL && cl->knows_txdone)
+		chan->txdone_method = TXDONE_BY_ACK;
+
+	spin_unlock_irqrestore(&chan->lock, flags);
+
+	if (chan->mbox->ops->startup) {
+		ret = chan->mbox->ops->startup(chan);
+
+		if (ret) {
+			dev_err(dev, "Unable to startup the chan (%d)\n", ret);
+			mbox_free_channel(chan);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+/**
+ * mbox_bind_client - Request a mailbox channel.
+ * @chan: The mailbox channel to bind the client to.
+ * @cl: Identity of the client requesting the channel.
+ *
+ * The Client specifies its requirements and capabilities while asking for
+ * a mailbox channel. It can't be called from atomic context.
+ * The channel is exclusively allocated and can't be used by another
+ * client before the owner calls mbox_free_channel.
+ * After assignment, any packet received on this channel will be
+ * handed over to the client via the 'rx_callback'.
+ * The framework holds reference to the client, so the mbox_client
+ * structure shouldn't be modified until the mbox_free_channel returns.
+ *
+ * Return: 0 if the channel was assigned to the client successfully.
+ *         <0 for request failure.
+ */
+int mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
+{
+	int ret;
+
+	mutex_lock(&con_mutex);
+	ret = __mbox_bind_client(chan, cl);
+	mutex_unlock(&con_mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(mbox_bind_client);
+
 /**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
@@ -340,7 +405,6 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 	struct mbox_controller *mbox;
 	struct of_phandle_args spec;
 	struct mbox_chan *chan;
-	unsigned long flags;
 	int ret;
 
 	if (!dev || !dev->of_node) {
@@ -372,33 +436,9 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 		return chan;
 	}
 
-	if (chan->cl || !try_module_get(mbox->dev->driver->owner)) {
-		dev_dbg(dev, "%s: mailbox not free\n", __func__);
-		mutex_unlock(&con_mutex);
-		return ERR_PTR(-EBUSY);
-	}
-
-	spin_lock_irqsave(&chan->lock, flags);
-	chan->msg_free = 0;
-	chan->msg_count = 0;
-	chan->active_req = NULL;
-	chan->cl = cl;
-	init_completion(&chan->tx_complete);
-
-	if (chan->txdone_method	== TXDONE_BY_POLL && cl->knows_txdone)
-		chan->txdone_method = TXDONE_BY_ACK;
-
-	spin_unlock_irqrestore(&chan->lock, flags);
-
-	if (chan->mbox->ops->startup) {
-		ret = chan->mbox->ops->startup(chan);
-
-		if (ret) {
-			dev_err(dev, "Unable to startup the chan (%d)\n", ret);
-			mbox_free_channel(chan);
-			chan = ERR_PTR(ret);
-		}
-	}
+	ret = __mbox_bind_client(chan, cl);
+	if (ret)
+		chan = ERR_PTR(ret);
 
 	mutex_unlock(&con_mutex);
 	return chan;
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 65229a45590f..734694912ef7 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -37,6 +37,7 @@ struct mbox_client {
 	void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
 };
 
+int mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl);
 struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
 					      const char *name);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);
-- 
2.39.1