From: Alex Elder <alex.elder@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Alex Elder <elder@linaro.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Jonathan Corbet <corbet@lwn.net>, Jassi Brar <jassisinghbrar@gmail.com> Cc: Murali Nalajala <quic_mnalajal@quicinc.com>, Trilok Soni <quic_tsoni@quicinc.com>, Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>, Carl van Schaik <quic_cvanscha@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Bagas Sanjaya <bagasdotme@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v10 07/26] mailbox: Add Gunyah message queue mailbox Date: Thu, 23 Feb 2023 15:11:41 -0600 [thread overview] Message-ID: <10343ac1-8350-5fc0-b358-8a1b7280afcc@linaro.org> (raw) In-Reply-To: <20230214212316.3309053-1-quic_eberman@quicinc.com> On 2/14/23 3:23 PM, Elliot Berman wrote: > Gunyah message queues are a unidirectional inter-VM pipe for messages up > to 1024 bytes. This driver supports pairing a receiver message queue and > a transmitter message queue to expose a single mailbox channel. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > Documentation/virt/gunyah/message-queue.rst | 8 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/gunyah-msgq.c | 214 ++++++++++++++++++++ > include/linux/gunyah.h | 56 +++++ > 4 files changed, 280 insertions(+) > create mode 100644 drivers/mailbox/gunyah-msgq.c > > diff --git a/Documentation/virt/gunyah/message-queue.rst b/Documentation/virt/gunyah/message-queue.rst > index 0667b3eb1ff9..082085e981e0 100644 > --- a/Documentation/virt/gunyah/message-queue.rst > +++ b/Documentation/virt/gunyah/message-queue.rst > @@ -59,3 +59,11 @@ vIRQ: two TX message queues will have two vIRQs (and two capability IDs). > | | | | | | > | | | | | | > +---------------+ +-----------------+ +---------------+ > + > +Gunyah message queues are exposed as mailboxes. To create the mailbox, create > +a mbox_client and call `gh_msgq_init`. On receipt of the RX_READY interrupt, > +all messages in the RX message queue are read and pushed via the `rx_callback` > +of the registered mbox_client. > + > +.. kernel-doc:: drivers/mailbox/gunyah-msgq.c > + :identifiers: gh_msgq_init > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile > index fc9376117111..5f929bb55e9a 100644 > --- a/drivers/mailbox/Makefile > +++ b/drivers/mailbox/Makefile > @@ -55,6 +55,8 @@ obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o > > obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o > > +obj-$(CONFIG_GUNYAH) += gunyah-msgq.o > + > obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o > > obj-$(CONFIG_SPRD_MBOX) += sprd-mailbox.o > diff --git a/drivers/mailbox/gunyah-msgq.c b/drivers/mailbox/gunyah-msgq.c > new file mode 100644 > index 000000000000..03ffaa30ce9b > --- /dev/null > +++ b/drivers/mailbox/gunyah-msgq.c You use a dash in this source file name, but an underscore everywhere else. Unless there's a good reason to do this, please be consistent (use "gunyah_msgq.c"). > @@ -0,0 +1,214 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/mailbox_controller.h> > +#include <linux/module.h> > +#include <linux/interrupt.h> > +#include <linux/gunyah.h> > +#include <linux/printk.h> > +#include <linux/init.h> > +#include <linux/slab.h> > +#include <linux/wait.h> > + > +#define mbox_chan_to_msgq(chan) (container_of(chan->mbox, struct gh_msgq, mbox)) > + > +static irqreturn_t gh_msgq_rx_irq_handler(int irq, void *data) > +{ > + struct gh_msgq *msgq = data; > + struct gh_msgq_rx_data rx_data; > + enum gh_error err; > + bool ready = true; > + > + while (ready) { > + err = gh_hypercall_msgq_recv(msgq->rx_ghrsc->capid, > + (uintptr_t)&rx_data.data, sizeof(rx_data.data), > + &rx_data.length, &ready); > + if (err != GH_ERROR_OK) { > + if (err != GH_ERROR_MSGQUEUE_EMPTY) Srini mentioned something about this too. In many (all?) cases, there is a device pointer available, so you should use dev_*() functions rather than pr_*(). In this particular case, I'm not sure why/when the mbox.dev pointer would be null. Also, dev_*() handles the case of a null device pointer, and it reports the device name (just as you do here). > + pr_warn("Failed to receive data from msgq for %s: %d\n", > + msgq->mbox.dev ? dev_name(msgq->mbox.dev) : "", err); > + break; > + } > + mbox_chan_received_data(gh_msgq_chan(msgq), &rx_data); > + } > + > + return IRQ_HANDLED; > +} > + > +/* Fired when message queue transitions from "full" to "space available" to send messages */ > +static irqreturn_t gh_msgq_tx_irq_handler(int irq, void *data) > +{ > + struct gh_msgq *msgq = data; > + > + mbox_chan_txdone(gh_msgq_chan(msgq), 0); > + > + return IRQ_HANDLED; > +} > + > +/* Fired after sending message and hypercall told us there was more space available. */ > +static void gh_msgq_txdone_tasklet(struct tasklet_struct *tasklet) > +{ > + struct gh_msgq *msgq = container_of(tasklet, struct gh_msgq, txdone_tasklet); > + > + mbox_chan_txdone(gh_msgq_chan(msgq), msgq->last_ret); > +} > + > +static int gh_msgq_send_data(struct mbox_chan *chan, void *data) > +{ > + struct gh_msgq *msgq = mbox_chan_to_msgq(chan); > + struct gh_msgq_tx_data *msgq_data = data; > + u64 tx_flags = 0; > + enum gh_error gh_error; Above you named the variable "err". It helps readability if you use a very consistent naming convention for variables of a certain type when they are used a lot. > + bool ready; > + > + if (msgq_data->push) > + tx_flags |= GH_HYPERCALL_MSGQ_TX_FLAGS_PUSH; > + > + gh_error = gh_hypercall_msgq_send(msgq->tx_ghrsc->capid, msgq_data->length, > + (uintptr_t)msgq_data->data, tx_flags, &ready); > + > + /** > + * unlikely because Linux tracks state of msgq and should not try to > + * send message when msgq is full. > + */ > + if (unlikely(gh_error == GH_ERROR_MSGQUEUE_FULL)) > + return -EAGAIN; > + > + /** > + * Propagate all other errors to client. If we return error to mailbox > + * framework, then no other messages can be sent and nobody will know > + * to retry this message. > + */ > + msgq->last_ret = gh_remap_error(gh_error); > + > + /** > + * This message was successfully sent, but message queue isn't ready to > + * receive more messages because it's now full. Mailbox framework Maybe: s/receive/accept/ > + * requires that we only report that message was transmitted when > + * we're ready to transmit another message. We'll get that in the form > + * of tx IRQ once the other side starts to drain the msgq. > + */ > + if (gh_error == GH_ERROR_OK && !ready) > + return 0; > + > + /** > + * We can send more messages. Mailbox framework requires that tx done > + * happens asynchronously to sending the message. Gunyah message queues > + * tell us right away on the hypercall return whether we can send more > + * messages. To work around this, defer the txdone to a tasklet. > + */ > + tasklet_schedule(&msgq->txdone_tasklet); > + > + return 0; > +} > + > +static struct mbox_chan_ops gh_msgq_ops = { > + .send_data = gh_msgq_send_data, > +}; > + > +/** > + * gh_msgq_init() - Initialize a Gunyah message queue with an mbox_client > + * @parent: optional, device parent used for the mailbox controller > + * @msgq: Pointer to the gh_msgq to initialize > + * @cl: A mailbox client to bind to the mailbox channel that the message queue creates > + * @tx_ghrsc: optional, the transmission side of the message queue > + * @rx_ghrsc: optional, the receiving side of the message queue > + * > + * At least one of tx_ghrsc and rx_ghrsc should be not NULL. Most message queue use cases come with s/should be/must be/ > + * a pair of message queues to facilitate bidirectional communication. When tx_ghrsc is set, > + * the client can send messages with mbox_send_message(gh_msgq_chan(msgq), msg). When rx_ghrsc > + * is set, the mbox_client should register an .rx_callback() and the message queue driver will s/should register/must register/ A general comment on this code is that you sort of half define a Gunyah message queue API. You define an initialization function and an exit function, but you also expose the fact that you use the mailbox framework in implementation. This despite avoiding defining it as an mbox in the DTS file. It might be hard to avoid that I guess. But to me it would be nice if there were a more distinct Gunyah message queue API, which would provide a send_message() function, for example. And in that case, perhaps you would pass in the tx_done and/or rx_data callbacks to this function (since they're required). All that said, this is (currently?) only used by the resource manager, so making a beautiful API might not be that important. Do you envision this being used to communicate with other VMs in the future? > + * push all available messages upon receiving the RX ready interrupt. The messages should be Maybe: s/push/deliver/ > + * consumed or copied by the client right away as the gh_msgq_rx_data will be replaced/destroyed > + * after the callback. > + * > + * Returns - 0 on success, negative otherwise > + */ > +int gh_msgq_init(struct device *parent, struct gh_msgq *msgq, struct mbox_client *cl, > + struct gunyah_resource *tx_ghrsc, struct gunyah_resource *rx_ghrsc) > +{ > + int ret; > + > + /* Must have at least a tx_ghrsc or rx_ghrsc and that they are the right device types */ > + if ((!tx_ghrsc && !rx_ghrsc) || > + (tx_ghrsc && tx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_TX) || > + (rx_ghrsc && rx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_RX)) > + return -EINVAL; > + > + if (gh_api_version() != GUNYAH_API_V1) { > + pr_err("Unrecognized gunyah version: %u. Currently supported: %d\n", > + gh_api_version(), GUNYAH_API_V1); > + return -EOPNOTSUPP; > + } > + > + if (!gh_api_has_feature(GH_API_FEATURE_MSGQUEUE)) > + return -EOPNOTSUPP; Can Gunyah even function if it doesn't have the MSGQUEUE feature? Will there ever be a Gunyah implementation that does not support it? Perhaps this test could be done in gunyah_init() instead. For that matter, you could verify the result of gh_api_version() at that time also. > + > + msgq->tx_ghrsc = tx_ghrsc; > + msgq->rx_ghrsc = rx_ghrsc; > + > + msgq->mbox.dev = parent; > + msgq->mbox.ops = &gh_msgq_ops; > + msgq->mbox.num_chans = 1; > + msgq->mbox.txdone_irq = true; > + msgq->mbox.chans = kcalloc(msgq->mbox.num_chans, sizeof(*msgq->mbox.chans), GFP_KERNEL); From what I can tell, you will always use exactly one mailbox channel. So you could just do kzalloc(sizeof()...). > + if (!msgq->mbox.chans) > + return -ENOMEM; > + > + if (msgq->tx_ghrsc) { if (tx_ghrsc) { The irq field is assumed to be valid. Are there any sanity checks you could perform? Again this is only used for the resource manager right now, so maybe it's OK. > + ret = request_irq(msgq->tx_ghrsc->irq, gh_msgq_tx_irq_handler, 0, "gh_msgq_tx", ret = request_irq(tx_ghrsc->irq, ... > + msgq); > + if (ret) > + goto err_chans; > + } > + > + if (msgq->rx_ghrsc) { > + ret = request_threaded_irq(msgq->rx_ghrsc->irq, NULL, gh_msgq_rx_irq_handler, > + IRQF_ONESHOT, "gh_msgq_rx", msgq); > + if (ret) > + goto err_tx_irq; > + } > + > + tasklet_setup(&msgq->txdone_tasklet, gh_msgq_txdone_tasklet); > + > + ret = mbox_controller_register(&msgq->mbox); > + if (ret) > + goto err_rx_irq; > + > + ret = mbox_bind_client(gh_msgq_chan(msgq), cl); > + if (ret) > + goto err_mbox; > + > + return 0; > +err_mbox: > + mbox_controller_unregister(&msgq->mbox); > +err_rx_irq: > + if (msgq->rx_ghrsc) > + free_irq(msgq->rx_ghrsc->irq, msgq); > +err_tx_irq: > + if (msgq->tx_ghrsc) > + free_irq(msgq->tx_ghrsc->irq, msgq); > +err_chans: > + kfree(msgq->mbox.chans); > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_msgq_init); > + > +void gh_msgq_remove(struct gh_msgq *msgq) > +{ Is there any need to un-bind the client? > + mbox_controller_unregister(&msgq->mbox); > + > + if (msgq->rx_ghrsc) > + free_irq(msgq->rx_ghrsc->irq, msgq); > + > + if (msgq->tx_ghrsc) > + free_irq(msgq->tx_ghrsc->irq, msgq); > + > + kfree(msgq->mbox.chans); > +} > +EXPORT_SYMBOL_GPL(gh_msgq_remove); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("Gunyah Message Queue Driver"); > diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h > index cb6df4eec5c2..2e13669c6363 100644 > --- a/include/linux/gunyah.h > +++ b/include/linux/gunyah.h > @@ -8,11 +8,67 @@ > > #include <linux/bitfield.h> > #include <linux/errno.h> > +#include <linux/interrupt.h> > #include <linux/limits.h> > +#include <linux/mailbox_controller.h> > +#include <linux/mailbox_client.h> > #include <linux/types.h> > > +/* Follows resource manager's resource types for VM_GET_HYP_RESOURCES */ > +enum gunyah_resource_type { > + GUNYAH_RESOURCE_TYPE_BELL_TX = 0, > + GUNYAH_RESOURCE_TYPE_BELL_RX = 1, > + GUNYAH_RESOURCE_TYPE_MSGQ_TX = 2, > + GUNYAH_RESOURCE_TYPE_MSGQ_RX = 3, > + GUNYAH_RESOURCE_TYPE_VCPU = 4, The maximum value here must fit in 8 bits. I guess there's no risk right now of using that up, but you use negative values in some cases elsewhere. > +}; > + > +struct gunyah_resource { > + enum gunyah_resource_type type; > + u64 capid; > + int irq; request_irq() defines the IRQ value to be an unsigned int. > +}; > + > +/** > + * Gunyah Message Queues > + */ > + > +#define GH_MSGQ_MAX_MSG_SIZE 240 > + > +struct gh_msgq_tx_data { > + size_t length; > + bool push; > + char data[]; > +}; > + > +struct gh_msgq_rx_data { > + size_t length; > + char data[GH_MSGQ_MAX_MSG_SIZE]; > +}; > + > +struct gh_msgq { > + struct gunyah_resource *tx_ghrsc; > + struct gunyah_resource *rx_ghrsc; > + > + /* msgq private */ > + int last_ret; /* Linux error, not GH_STATUS_* */ > + struct mbox_controller mbox; > + struct tasklet_struct txdone_tasklet; Can the msgq_client be embedded here too? (I don't really know whether msgq and msgq_client are one-to one.) > +}; > + > + > +int gh_msgq_init(struct device *parent, struct gh_msgq *msgq, struct mbox_client *cl, > + struct gunyah_resource *tx_ghrsc, struct gunyah_resource *rx_ghrsc); > +void gh_msgq_remove(struct gh_msgq *msgq); I suggested: int gh_msgq_send(struct gh_msgq, struct gh_msgq_tx_data *data); -Alex > + > +static inline struct mbox_chan *gh_msgq_chan(struct gh_msgq *msgq) > +{ > + return &msgq->mbox.chans[0]; > +} > + > /******************************************************************************/ > /* Common arch-independent definitions for Gunyah hypercalls */ > + > #define GH_CAPID_INVAL U64_MAX > #define GH_VMID_ROOT_VM 0xff >
WARNING: multiple messages have this Message-ID (diff)
From: Alex Elder <alex.elder@linaro.org> To: Elliot Berman <quic_eberman@quicinc.com>, Alex Elder <elder@linaro.org>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Jonathan Corbet <corbet@lwn.net>, Jassi Brar <jassisinghbrar@gmail.com> Cc: Murali Nalajala <quic_mnalajal@quicinc.com>, Trilok Soni <quic_tsoni@quicinc.com>, Srivatsa Vaddagiri <quic_svaddagi@quicinc.com>, Carl van Schaik <quic_cvanscha@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Bagas Sanjaya <bagasdotme@gmail.com>, Catalin Marinas <catalin.marinas@arm.com>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v10 07/26] mailbox: Add Gunyah message queue mailbox Date: Thu, 23 Feb 2023 15:11:41 -0600 [thread overview] Message-ID: <10343ac1-8350-5fc0-b358-8a1b7280afcc@linaro.org> (raw) In-Reply-To: <20230214212316.3309053-1-quic_eberman@quicinc.com> On 2/14/23 3:23 PM, Elliot Berman wrote: > Gunyah message queues are a unidirectional inter-VM pipe for messages up > to 1024 bytes. This driver supports pairing a receiver message queue and > a transmitter message queue to expose a single mailbox channel. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > --- > Documentation/virt/gunyah/message-queue.rst | 8 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/gunyah-msgq.c | 214 ++++++++++++++++++++ > include/linux/gunyah.h | 56 +++++ > 4 files changed, 280 insertions(+) > create mode 100644 drivers/mailbox/gunyah-msgq.c > > diff --git a/Documentation/virt/gunyah/message-queue.rst b/Documentation/virt/gunyah/message-queue.rst > index 0667b3eb1ff9..082085e981e0 100644 > --- a/Documentation/virt/gunyah/message-queue.rst > +++ b/Documentation/virt/gunyah/message-queue.rst > @@ -59,3 +59,11 @@ vIRQ: two TX message queues will have two vIRQs (and two capability IDs). > | | | | | | > | | | | | | > +---------------+ +-----------------+ +---------------+ > + > +Gunyah message queues are exposed as mailboxes. To create the mailbox, create > +a mbox_client and call `gh_msgq_init`. On receipt of the RX_READY interrupt, > +all messages in the RX message queue are read and pushed via the `rx_callback` > +of the registered mbox_client. > + > +.. kernel-doc:: drivers/mailbox/gunyah-msgq.c > + :identifiers: gh_msgq_init > diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile > index fc9376117111..5f929bb55e9a 100644 > --- a/drivers/mailbox/Makefile > +++ b/drivers/mailbox/Makefile > @@ -55,6 +55,8 @@ obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o > > obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o > > +obj-$(CONFIG_GUNYAH) += gunyah-msgq.o > + > obj-$(CONFIG_SUN6I_MSGBOX) += sun6i-msgbox.o > > obj-$(CONFIG_SPRD_MBOX) += sprd-mailbox.o > diff --git a/drivers/mailbox/gunyah-msgq.c b/drivers/mailbox/gunyah-msgq.c > new file mode 100644 > index 000000000000..03ffaa30ce9b > --- /dev/null > +++ b/drivers/mailbox/gunyah-msgq.c You use a dash in this source file name, but an underscore everywhere else. Unless there's a good reason to do this, please be consistent (use "gunyah_msgq.c"). > @@ -0,0 +1,214 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2022-2023 Qualcomm Innovation Center, Inc. All rights reserved. > + */ > + > +#include <linux/mailbox_controller.h> > +#include <linux/module.h> > +#include <linux/interrupt.h> > +#include <linux/gunyah.h> > +#include <linux/printk.h> > +#include <linux/init.h> > +#include <linux/slab.h> > +#include <linux/wait.h> > + > +#define mbox_chan_to_msgq(chan) (container_of(chan->mbox, struct gh_msgq, mbox)) > + > +static irqreturn_t gh_msgq_rx_irq_handler(int irq, void *data) > +{ > + struct gh_msgq *msgq = data; > + struct gh_msgq_rx_data rx_data; > + enum gh_error err; > + bool ready = true; > + > + while (ready) { > + err = gh_hypercall_msgq_recv(msgq->rx_ghrsc->capid, > + (uintptr_t)&rx_data.data, sizeof(rx_data.data), > + &rx_data.length, &ready); > + if (err != GH_ERROR_OK) { > + if (err != GH_ERROR_MSGQUEUE_EMPTY) Srini mentioned something about this too. In many (all?) cases, there is a device pointer available, so you should use dev_*() functions rather than pr_*(). In this particular case, I'm not sure why/when the mbox.dev pointer would be null. Also, dev_*() handles the case of a null device pointer, and it reports the device name (just as you do here). > + pr_warn("Failed to receive data from msgq for %s: %d\n", > + msgq->mbox.dev ? dev_name(msgq->mbox.dev) : "", err); > + break; > + } > + mbox_chan_received_data(gh_msgq_chan(msgq), &rx_data); > + } > + > + return IRQ_HANDLED; > +} > + > +/* Fired when message queue transitions from "full" to "space available" to send messages */ > +static irqreturn_t gh_msgq_tx_irq_handler(int irq, void *data) > +{ > + struct gh_msgq *msgq = data; > + > + mbox_chan_txdone(gh_msgq_chan(msgq), 0); > + > + return IRQ_HANDLED; > +} > + > +/* Fired after sending message and hypercall told us there was more space available. */ > +static void gh_msgq_txdone_tasklet(struct tasklet_struct *tasklet) > +{ > + struct gh_msgq *msgq = container_of(tasklet, struct gh_msgq, txdone_tasklet); > + > + mbox_chan_txdone(gh_msgq_chan(msgq), msgq->last_ret); > +} > + > +static int gh_msgq_send_data(struct mbox_chan *chan, void *data) > +{ > + struct gh_msgq *msgq = mbox_chan_to_msgq(chan); > + struct gh_msgq_tx_data *msgq_data = data; > + u64 tx_flags = 0; > + enum gh_error gh_error; Above you named the variable "err". It helps readability if you use a very consistent naming convention for variables of a certain type when they are used a lot. > + bool ready; > + > + if (msgq_data->push) > + tx_flags |= GH_HYPERCALL_MSGQ_TX_FLAGS_PUSH; > + > + gh_error = gh_hypercall_msgq_send(msgq->tx_ghrsc->capid, msgq_data->length, > + (uintptr_t)msgq_data->data, tx_flags, &ready); > + > + /** > + * unlikely because Linux tracks state of msgq and should not try to > + * send message when msgq is full. > + */ > + if (unlikely(gh_error == GH_ERROR_MSGQUEUE_FULL)) > + return -EAGAIN; > + > + /** > + * Propagate all other errors to client. If we return error to mailbox > + * framework, then no other messages can be sent and nobody will know > + * to retry this message. > + */ > + msgq->last_ret = gh_remap_error(gh_error); > + > + /** > + * This message was successfully sent, but message queue isn't ready to > + * receive more messages because it's now full. Mailbox framework Maybe: s/receive/accept/ > + * requires that we only report that message was transmitted when > + * we're ready to transmit another message. We'll get that in the form > + * of tx IRQ once the other side starts to drain the msgq. > + */ > + if (gh_error == GH_ERROR_OK && !ready) > + return 0; > + > + /** > + * We can send more messages. Mailbox framework requires that tx done > + * happens asynchronously to sending the message. Gunyah message queues > + * tell us right away on the hypercall return whether we can send more > + * messages. To work around this, defer the txdone to a tasklet. > + */ > + tasklet_schedule(&msgq->txdone_tasklet); > + > + return 0; > +} > + > +static struct mbox_chan_ops gh_msgq_ops = { > + .send_data = gh_msgq_send_data, > +}; > + > +/** > + * gh_msgq_init() - Initialize a Gunyah message queue with an mbox_client > + * @parent: optional, device parent used for the mailbox controller > + * @msgq: Pointer to the gh_msgq to initialize > + * @cl: A mailbox client to bind to the mailbox channel that the message queue creates > + * @tx_ghrsc: optional, the transmission side of the message queue > + * @rx_ghrsc: optional, the receiving side of the message queue > + * > + * At least one of tx_ghrsc and rx_ghrsc should be not NULL. Most message queue use cases come with s/should be/must be/ > + * a pair of message queues to facilitate bidirectional communication. When tx_ghrsc is set, > + * the client can send messages with mbox_send_message(gh_msgq_chan(msgq), msg). When rx_ghrsc > + * is set, the mbox_client should register an .rx_callback() and the message queue driver will s/should register/must register/ A general comment on this code is that you sort of half define a Gunyah message queue API. You define an initialization function and an exit function, but you also expose the fact that you use the mailbox framework in implementation. This despite avoiding defining it as an mbox in the DTS file. It might be hard to avoid that I guess. But to me it would be nice if there were a more distinct Gunyah message queue API, which would provide a send_message() function, for example. And in that case, perhaps you would pass in the tx_done and/or rx_data callbacks to this function (since they're required). All that said, this is (currently?) only used by the resource manager, so making a beautiful API might not be that important. Do you envision this being used to communicate with other VMs in the future? > + * push all available messages upon receiving the RX ready interrupt. The messages should be Maybe: s/push/deliver/ > + * consumed or copied by the client right away as the gh_msgq_rx_data will be replaced/destroyed > + * after the callback. > + * > + * Returns - 0 on success, negative otherwise > + */ > +int gh_msgq_init(struct device *parent, struct gh_msgq *msgq, struct mbox_client *cl, > + struct gunyah_resource *tx_ghrsc, struct gunyah_resource *rx_ghrsc) > +{ > + int ret; > + > + /* Must have at least a tx_ghrsc or rx_ghrsc and that they are the right device types */ > + if ((!tx_ghrsc && !rx_ghrsc) || > + (tx_ghrsc && tx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_TX) || > + (rx_ghrsc && rx_ghrsc->type != GUNYAH_RESOURCE_TYPE_MSGQ_RX)) > + return -EINVAL; > + > + if (gh_api_version() != GUNYAH_API_V1) { > + pr_err("Unrecognized gunyah version: %u. Currently supported: %d\n", > + gh_api_version(), GUNYAH_API_V1); > + return -EOPNOTSUPP; > + } > + > + if (!gh_api_has_feature(GH_API_FEATURE_MSGQUEUE)) > + return -EOPNOTSUPP; Can Gunyah even function if it doesn't have the MSGQUEUE feature? Will there ever be a Gunyah implementation that does not support it? Perhaps this test could be done in gunyah_init() instead. For that matter, you could verify the result of gh_api_version() at that time also. > + > + msgq->tx_ghrsc = tx_ghrsc; > + msgq->rx_ghrsc = rx_ghrsc; > + > + msgq->mbox.dev = parent; > + msgq->mbox.ops = &gh_msgq_ops; > + msgq->mbox.num_chans = 1; > + msgq->mbox.txdone_irq = true; > + msgq->mbox.chans = kcalloc(msgq->mbox.num_chans, sizeof(*msgq->mbox.chans), GFP_KERNEL); From what I can tell, you will always use exactly one mailbox channel. So you could just do kzalloc(sizeof()...). > + if (!msgq->mbox.chans) > + return -ENOMEM; > + > + if (msgq->tx_ghrsc) { if (tx_ghrsc) { The irq field is assumed to be valid. Are there any sanity checks you could perform? Again this is only used for the resource manager right now, so maybe it's OK. > + ret = request_irq(msgq->tx_ghrsc->irq, gh_msgq_tx_irq_handler, 0, "gh_msgq_tx", ret = request_irq(tx_ghrsc->irq, ... > + msgq); > + if (ret) > + goto err_chans; > + } > + > + if (msgq->rx_ghrsc) { > + ret = request_threaded_irq(msgq->rx_ghrsc->irq, NULL, gh_msgq_rx_irq_handler, > + IRQF_ONESHOT, "gh_msgq_rx", msgq); > + if (ret) > + goto err_tx_irq; > + } > + > + tasklet_setup(&msgq->txdone_tasklet, gh_msgq_txdone_tasklet); > + > + ret = mbox_controller_register(&msgq->mbox); > + if (ret) > + goto err_rx_irq; > + > + ret = mbox_bind_client(gh_msgq_chan(msgq), cl); > + if (ret) > + goto err_mbox; > + > + return 0; > +err_mbox: > + mbox_controller_unregister(&msgq->mbox); > +err_rx_irq: > + if (msgq->rx_ghrsc) > + free_irq(msgq->rx_ghrsc->irq, msgq); > +err_tx_irq: > + if (msgq->tx_ghrsc) > + free_irq(msgq->tx_ghrsc->irq, msgq); > +err_chans: > + kfree(msgq->mbox.chans); > + return ret; > +} > +EXPORT_SYMBOL_GPL(gh_msgq_init); > + > +void gh_msgq_remove(struct gh_msgq *msgq) > +{ Is there any need to un-bind the client? > + mbox_controller_unregister(&msgq->mbox); > + > + if (msgq->rx_ghrsc) > + free_irq(msgq->rx_ghrsc->irq, msgq); > + > + if (msgq->tx_ghrsc) > + free_irq(msgq->tx_ghrsc->irq, msgq); > + > + kfree(msgq->mbox.chans); > +} > +EXPORT_SYMBOL_GPL(gh_msgq_remove); > + > +MODULE_LICENSE("GPL"); > +MODULE_DESCRIPTION("Gunyah Message Queue Driver"); > diff --git a/include/linux/gunyah.h b/include/linux/gunyah.h > index cb6df4eec5c2..2e13669c6363 100644 > --- a/include/linux/gunyah.h > +++ b/include/linux/gunyah.h > @@ -8,11 +8,67 @@ > > #include <linux/bitfield.h> > #include <linux/errno.h> > +#include <linux/interrupt.h> > #include <linux/limits.h> > +#include <linux/mailbox_controller.h> > +#include <linux/mailbox_client.h> > #include <linux/types.h> > > +/* Follows resource manager's resource types for VM_GET_HYP_RESOURCES */ > +enum gunyah_resource_type { > + GUNYAH_RESOURCE_TYPE_BELL_TX = 0, > + GUNYAH_RESOURCE_TYPE_BELL_RX = 1, > + GUNYAH_RESOURCE_TYPE_MSGQ_TX = 2, > + GUNYAH_RESOURCE_TYPE_MSGQ_RX = 3, > + GUNYAH_RESOURCE_TYPE_VCPU = 4, The maximum value here must fit in 8 bits. I guess there's no risk right now of using that up, but you use negative values in some cases elsewhere. > +}; > + > +struct gunyah_resource { > + enum gunyah_resource_type type; > + u64 capid; > + int irq; request_irq() defines the IRQ value to be an unsigned int. > +}; > + > +/** > + * Gunyah Message Queues > + */ > + > +#define GH_MSGQ_MAX_MSG_SIZE 240 > + > +struct gh_msgq_tx_data { > + size_t length; > + bool push; > + char data[]; > +}; > + > +struct gh_msgq_rx_data { > + size_t length; > + char data[GH_MSGQ_MAX_MSG_SIZE]; > +}; > + > +struct gh_msgq { > + struct gunyah_resource *tx_ghrsc; > + struct gunyah_resource *rx_ghrsc; > + > + /* msgq private */ > + int last_ret; /* Linux error, not GH_STATUS_* */ > + struct mbox_controller mbox; > + struct tasklet_struct txdone_tasklet; Can the msgq_client be embedded here too? (I don't really know whether msgq and msgq_client are one-to one.) > +}; > + > + > +int gh_msgq_init(struct device *parent, struct gh_msgq *msgq, struct mbox_client *cl, > + struct gunyah_resource *tx_ghrsc, struct gunyah_resource *rx_ghrsc); > +void gh_msgq_remove(struct gh_msgq *msgq); I suggested: int gh_msgq_send(struct gh_msgq, struct gh_msgq_tx_data *data); -Alex > + > +static inline struct mbox_chan *gh_msgq_chan(struct gh_msgq *msgq) > +{ > + return &msgq->mbox.chans[0]; > +} > + > /******************************************************************************/ > /* Common arch-independent definitions for Gunyah hypercalls */ > + > #define GH_CAPID_INVAL U64_MAX > #define GH_VMID_ROOT_VM 0xff > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-23 21:12 UTC|newest] Thread overview: 222+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-14 21:12 [PATCH v10 00/26] Drivers for Gunyah hypervisor Elliot Berman 2023-02-14 21:12 ` Elliot Berman 2023-02-14 21:12 ` [PATCH v10 01/26] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman 2023-02-14 21:12 ` Elliot Berman 2023-02-23 23:41 ` Alex Elder 2023-02-23 23:41 ` Alex Elder 2023-03-01 0:00 ` Elliot Berman 2023-03-01 0:00 ` Elliot Berman 2023-02-14 21:12 ` [PATCH v10 02/26] dt-bindings: Add binding for gunyah hypervisor Elliot Berman 2023-02-14 21:12 ` Elliot Berman 2023-02-14 21:12 ` [PATCH v10 03/26] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman 2023-02-14 21:12 ` Elliot Berman 2023-02-23 21:58 ` Alex Elder 2023-02-23 21:58 ` Alex Elder 2023-03-02 1:40 ` Elliot Berman 2023-03-02 1:40 ` Elliot Berman 2023-03-02 7:18 ` Arnd Bergmann 2023-03-02 7:18 ` Arnd Bergmann 2023-02-14 21:12 ` [PATCH v10 04/26] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman 2023-02-14 21:12 ` Elliot Berman 2023-02-20 13:59 ` Srinivas Kandagatla 2023-02-20 13:59 ` Srinivas Kandagatla 2023-02-24 0:09 ` Alex Elder 2023-02-24 0:09 ` Alex Elder 2023-03-02 1:21 ` Elliot Berman 2023-03-02 1:21 ` Elliot Berman 2023-02-14 21:18 ` Elliot Berman 2023-02-14 21:18 ` Elliot Berman 2023-02-14 21:21 ` [PATCH v10 05/26] virt: gunyah: Identify hypervisor version Elliot Berman 2023-02-14 21:21 ` Elliot Berman 2023-02-14 21:23 ` [PATCH v10 06/26] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman 2023-02-14 21:23 ` Elliot Berman 2023-02-24 0:15 ` Alex Elder 2023-02-24 0:15 ` Alex Elder 2023-02-24 21:24 ` Elliot Berman 2023-02-24 21:24 ` Elliot Berman 2023-02-14 21:23 ` [PATCH v10 07/26] mailbox: Add Gunyah message queue mailbox Elliot Berman 2023-02-14 21:23 ` Elliot Berman 2023-02-16 4:07 ` kernel test robot 2023-02-16 4:07 ` kernel test robot 2023-02-20 13:59 ` Srinivas Kandagatla 2023-02-20 13:59 ` Srinivas Kandagatla 2023-02-23 0:15 ` Elliot Berman 2023-02-23 0:15 ` Elliot Berman 2023-02-23 10:25 ` Srinivas Kandagatla 2023-02-23 10:25 ` Srinivas Kandagatla 2023-02-23 23:15 ` Elliot Berman 2023-02-23 23:15 ` Elliot Berman 2023-02-24 7:49 ` Srinivas Kandagatla 2023-02-24 7:49 ` Srinivas Kandagatla 2023-02-23 18:24 ` Alex Elder 2023-02-23 18:24 ` Alex Elder 2023-02-23 21:11 ` Alex Elder [this message] 2023-02-23 21:11 ` Alex Elder 2023-02-24 21:57 ` Elliot Berman 2023-02-24 21:57 ` Elliot Berman 2023-02-14 21:23 ` [PATCH v10 08/26] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman 2023-02-14 21:23 ` Elliot Berman 2023-02-16 6:43 ` Greg Kroah-Hartman 2023-02-16 6:43 ` Greg Kroah-Hartman 2023-02-16 17:40 ` Elliot Berman 2023-02-16 17:40 ` Elliot Berman 2023-02-17 7:37 ` Greg Kroah-Hartman 2023-02-17 7:37 ` Greg Kroah-Hartman 2023-02-22 22:52 ` Elliot Berman 2023-02-22 22:52 ` Elliot Berman 2023-02-20 18:10 ` Srinivas Kandagatla 2023-02-20 18:10 ` Srinivas Kandagatla 2023-02-22 23:18 ` Elliot Berman 2023-02-22 23:18 ` Elliot Berman 2023-02-23 10:29 ` Srinivas Kandagatla 2023-02-23 10:29 ` Srinivas Kandagatla 2023-02-23 23:13 ` Elliot Berman 2023-02-23 23:13 ` Elliot Berman 2023-02-28 0:52 ` Alex Elder 2023-02-28 0:52 ` Alex Elder 2023-02-28 22:49 ` Elliot Berman 2023-02-28 22:49 ` Elliot Berman 2023-02-23 23:28 ` Alex Elder 2023-02-23 23:28 ` Alex Elder 2023-02-24 22:39 ` Elliot Berman 2023-02-24 22:39 ` Elliot Berman 2023-02-14 21:23 ` [PATCH v10 09/26] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman 2023-02-14 21:23 ` Elliot Berman 2023-02-16 6:39 ` Greg Kroah-Hartman 2023-02-16 6:39 ` Greg Kroah-Hartman 2023-02-16 17:18 ` Elliot Berman 2023-02-16 17:18 ` Elliot Berman 2023-02-21 7:50 ` Srinivas Kandagatla 2023-02-21 7:50 ` Srinivas Kandagatla 2023-02-23 21:36 ` Alex Elder 2023-02-23 21:36 ` Alex Elder 2023-02-23 23:10 ` Elliot Berman 2023-02-23 23:10 ` Elliot Berman 2023-02-14 21:23 ` [PATCH v10 10/26] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman 2023-02-14 21:23 ` Elliot Berman 2023-02-21 10:46 ` Srinivas Kandagatla 2023-02-21 10:46 ` Srinivas Kandagatla 2023-02-22 0:27 ` Elliot Berman 2023-02-22 0:27 ` Elliot Berman 2023-02-23 10:08 ` Srinivas Kandagatla 2023-02-23 10:08 ` Srinivas Kandagatla 2023-02-23 22:40 ` Elliot Berman 2023-02-23 22:40 ` Elliot Berman 2023-02-24 10:29 ` Srinivas Kandagatla 2023-02-24 10:29 ` Srinivas Kandagatla 2023-02-24 13:20 ` Arnd Bergmann 2023-02-24 13:20 ` Arnd Bergmann 2023-02-24 22:48 ` Elliot Berman 2023-02-24 22:48 ` Elliot Berman 2023-02-28 1:06 ` Alex Elder 2023-02-28 1:06 ` Alex Elder 2023-02-28 9:19 ` Arnd Bergmann 2023-02-28 9:19 ` Arnd Bergmann 2023-02-21 13:06 ` Srivatsa Vaddagiri 2023-02-21 13:06 ` Srivatsa Vaddagiri 2023-02-14 21:24 ` [PATCH v10 11/26] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-21 11:07 ` Srinivas Kandagatla 2023-02-21 11:07 ` Srinivas Kandagatla 2023-02-14 21:24 ` [PATCH v10 12/26] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-16 6:38 ` Greg Kroah-Hartman 2023-02-16 6:38 ` Greg Kroah-Hartman 2023-02-16 17:24 ` Elliot Berman 2023-02-16 17:24 ` Elliot Berman 2023-02-21 12:28 ` Srinivas Kandagatla 2023-02-21 12:28 ` Srinivas Kandagatla 2023-02-21 12:43 ` Srivatsa Vaddagiri 2023-02-21 12:43 ` Srivatsa Vaddagiri 2023-02-24 0:43 ` Elliot Berman 2023-02-24 0:43 ` Elliot Berman 2023-02-24 10:36 ` Srinivas Kandagatla 2023-02-24 10:36 ` Srinivas Kandagatla 2023-02-21 12:45 ` Srivatsa Vaddagiri 2023-02-21 12:45 ` Srivatsa Vaddagiri 2023-02-24 0:34 ` Alex Elder 2023-02-24 0:34 ` Alex Elder 2023-02-25 1:03 ` Elliot Berman 2023-02-25 1:03 ` Elliot Berman 2023-02-24 10:19 ` Fuad Tabba 2023-02-24 10:19 ` Fuad Tabba 2023-02-24 18:08 ` Elliot Berman 2023-02-24 18:08 ` Elliot Berman 2023-02-24 18:58 ` Sean Christopherson 2023-02-24 18:58 ` Sean Christopherson 2023-02-27 9:55 ` Fuad Tabba 2023-02-27 9:55 ` Fuad Tabba 2023-02-14 21:24 ` [PATCH v10 13/26] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-16 6:35 ` Greg Kroah-Hartman 2023-02-16 6:35 ` Greg Kroah-Hartman 2023-02-16 17:20 ` Elliot Berman 2023-02-16 17:20 ` Elliot Berman 2023-02-20 9:15 ` Srivatsa Vaddagiri 2023-02-20 9:15 ` Srivatsa Vaddagiri 2023-02-20 9:54 ` Srivatsa Vaddagiri 2023-02-20 9:54 ` Srivatsa Vaddagiri 2023-02-21 13:06 ` Srivatsa Vaddagiri 2023-02-21 13:06 ` Srivatsa Vaddagiri 2023-02-21 14:17 ` Srinivas Kandagatla 2023-02-21 14:17 ` Srinivas Kandagatla 2023-02-23 0:50 ` Elliot Berman 2023-02-23 0:50 ` Elliot Berman 2023-02-23 9:21 ` Srinivas Kandagatla 2023-02-23 9:21 ` Srinivas Kandagatla 2023-02-14 21:24 ` [PATCH v10 14/26] samples: Add sample userspace Gunyah VM Manager Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-14 21:24 ` [PATCH v10 15/26] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-21 14:51 ` Srinivas Kandagatla 2023-02-21 14:51 ` Srinivas Kandagatla 2023-02-21 21:22 ` Elliot Berman 2023-02-21 21:22 ` Elliot Berman 2023-02-22 10:21 ` Srinivas Kandagatla 2023-02-22 10:21 ` Srinivas Kandagatla 2023-02-23 1:55 ` Elliot Berman 2023-02-23 1:55 ` Elliot Berman 2023-02-14 21:24 ` [PATCH v10 16/26] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman 2023-02-14 21:24 ` Elliot Berman 2023-02-16 0:22 ` kernel test robot 2023-02-16 0:22 ` kernel test robot 2023-02-16 11:09 ` kernel test robot 2023-02-16 11:09 ` kernel test robot 2023-02-21 14:55 ` Srinivas Kandagatla 2023-02-21 14:55 ` Srinivas Kandagatla 2023-02-14 21:25 ` [PATCH v10 17/26] docs: gunyah: Document Gunyah VM Manager Elliot Berman 2023-02-14 21:25 ` Elliot Berman 2023-02-23 23:55 ` Alex Elder 2023-02-23 23:55 ` Alex Elder 2023-02-14 21:25 ` [PATCH v10 18/26] virt: gunyah: Translate gh_rm_hyp_resource into gunyah_resource Elliot Berman 2023-02-14 21:25 ` Elliot Berman 2023-02-21 17:47 ` Srinivas Kandagatla 2023-02-21 17:47 ` Srinivas Kandagatla 2023-02-14 21:25 ` [PATCH v10 19/26] gunyah: vm_mgr: Add framework to add VM Functions Elliot Berman 2023-02-14 21:25 ` Elliot Berman 2023-02-17 13:23 ` Srivatsa Vaddagiri 2023-02-17 13:23 ` Srivatsa Vaddagiri 2023-02-21 13:07 ` Srivatsa Vaddagiri 2023-02-21 13:07 ` Srivatsa Vaddagiri 2023-02-21 17:58 ` Srinivas Kandagatla 2023-02-21 17:58 ` Srinivas Kandagatla 2023-02-22 14:08 ` Srinivas Kandagatla 2023-02-22 14:08 ` Srinivas Kandagatla 2023-02-24 23:44 ` Elliot Berman 2023-02-24 23:44 ` Elliot Berman 2023-02-14 21:25 ` [PATCH v10 20/26] virt: gunyah: Add resource tickets Elliot Berman 2023-02-14 21:25 ` Elliot Berman 2023-02-14 21:25 ` [PATCH v10 21/26] virt: gunyah: Add IO handlers Elliot Berman 2023-02-14 21:25 ` Elliot Berman 2023-02-14 21:26 ` [PATCH v10 22/26] virt: gunyah: Add proxy-scheduled vCPUs Elliot Berman 2023-02-14 21:26 ` Elliot Berman 2023-02-14 21:26 ` [PATCH v10 23/26] virt: gunyah: Add hypercalls for sending doorbell Elliot Berman 2023-02-14 21:26 ` Elliot Berman 2023-02-14 21:26 ` [PATCH v10 24/26] virt: gunyah: Add irqfd interface Elliot Berman 2023-02-14 21:26 ` Elliot Berman 2023-02-14 21:26 ` [PATCH v10 25/26] virt: gunyah: Add ioeventfd Elliot Berman 2023-02-14 21:26 ` Elliot Berman 2023-02-14 21:26 ` [PATCH v10 26/26] MAINTAINERS: Add Gunyah hypervisor drivers section Elliot Berman 2023-02-14 21:26 ` Elliot Berman 2023-02-23 21:59 ` [PATCH v10 00/26] Drivers for Gunyah hypervisor Alex Elder 2023-02-23 21:59 ` Alex Elder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=10343ac1-8350-5fc0-b358-8a1b7280afcc@linaro.org \ --to=alex.elder@linaro.org \ --cc=andersson@kernel.org \ --cc=arnd@arndb.de \ --cc=bagasdotme@gmail.com \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=elder@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=jassisinghbrar@gmail.com \ --cc=konrad.dybcio@linaro.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=quic_cvanscha@quicinc.com \ --cc=quic_eberman@quicinc.com \ --cc=quic_mnalajal@quicinc.com \ --cc=quic_pheragu@quicinc.com \ --cc=quic_svaddagi@quicinc.com \ --cc=quic_tsoni@quicinc.com \ --cc=robh+dt@kernel.org \ --cc=srinivas.kandagatla@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.