From: Elliot Berman <quic_eberman@quicinc.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Bjorn Andersson <quic_bjorande@quicinc.com>, 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>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Andy Gross <agross@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Jassi Brar <jassisinghbrar@gmail.com>, <linux-arm-kernel@lists.infradead.org>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, "Will Deacon" <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, "Arnd Bergmann" <arnd@arndb.de>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Amol Maheshwari <amahesh@qti.qualcomm.com>, Kalle Valo <kvalo@kernel.org>, <devicetree@vger.kernel.org>, <linux-doc@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v6 10/21] gunyah: rsc_mgr: Add resource manager RPC core Date: Tue, 1 Nov 2022 17:12:58 -0700 [thread overview] Message-ID: <3d2858fe-ea3e-159c-faff-5052cba1e08c@quicinc.com> (raw) In-Reply-To: <Y2FfKCKZ3N8rOqcT@kroah.com> On 11/1/2022 11:02 AM, Greg Kroah-Hartman wrote: > On Wed, Oct 26, 2022 at 11:58:35AM -0700, Elliot Berman wrote: >> The resource manager is a special virtual machine which is always >> running on a Gunyah system. It provides APIs for creating and destroying >> VMs, secure memory management, sharing/lending of memory between VMs, >> and setup of inter-VM communication. Calls to the resource manager are >> made via message queues. >> >> This patch implements the basic probing and RPC mechanism to make those >> API calls. Request/response calls can be made with gh_rm_call. >> Drivers can also register to notifications pushed by RM via >> gh_rm_register_notifier >> >> Specific API calls that resource manager supports will be implemented in >> subsequent patches. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> --- >> MAINTAINERS | 2 +- >> drivers/virt/gunyah/Kconfig | 15 + >> drivers/virt/gunyah/Makefile | 3 + >> drivers/virt/gunyah/rsc_mgr.c | 602 +++++++++++++++++++++++++++++++++ >> drivers/virt/gunyah/rsc_mgr.h | 34 ++ >> include/linux/gunyah_rsc_mgr.h | 26 ++ >> 6 files changed, 681 insertions(+), 1 deletion(-) >> create mode 100644 drivers/virt/gunyah/rsc_mgr.c >> create mode 100644 drivers/virt/gunyah/rsc_mgr.h >> create mode 100644 include/linux/gunyah_rsc_mgr.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 586539eadd3b..e072a0d2e553 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -8945,7 +8945,7 @@ F: Documentation/virt/gunyah/ >> F: arch/arm64/gunyah/ >> F: drivers/mailbox/gunyah-msgq.c >> F: drivers/virt/gunyah/ >> -F: include/linux/gunyah.h >> +F: include/linux/gunyah*.h >> >> HABANALABS PCI DRIVER >> M: Oded Gabbay <ogabbay@kernel.org> >> diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig >> index 127156a678a6..4de88d80aa7b 100644 >> --- a/drivers/virt/gunyah/Kconfig >> +++ b/drivers/virt/gunyah/Kconfig >> @@ -10,3 +10,18 @@ config GUNYAH >> >> Say Y/M here to enable the drivers needed to interact in a Gunyah >> virtual environment. >> + >> +config GUNYAH_RESORUCE_MANAGER >> + tristate "Gunyah Resource Manager" >> + select MAILBOX >> + select GUNYAH_MESSAGE_QUEUES >> + depends on GUNYAH >> + default y > > You only have "default y" if your machine can not boot without it. > Please do not add that here. > There's a guideline in Documentation/kbuild/kconfig-language.rst to provide some sane defaults for subdriver behavior. Here, CONFIG_GUNYAH is default n. It's unlikely for someone to want to have Linux with base Gunyah support (hypercalls and hypervisor detection) without also having the Resource Manager driver. If it's better, I could change to default m? >> + help >> + The resource manager (RM) is a privileged application VM supporting >> + the Gunyah Hypervisor. Enable this driver to support communicating >> + with Gunyah RM. This is typically required for a VM running under >> + Gunyah wanting to have Gunyah-awareness. >> + >> + Say Y/M here if unsure. >> + >> diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile >> index 2ac4ee64b89d..2c18b0a56413 100644 >> --- a/drivers/virt/gunyah/Makefile >> +++ b/drivers/virt/gunyah/Makefile >> @@ -1 +1,4 @@ >> obj-$(CONFIG_GUNYAH) += gunyah.o >> + >> +gunyah_rsc_mgr-y += rsc_mgr.o >> +obj-$(CONFIG_GUNYAH_RESORUCE_MANAGER) += gunyah_rsc_mgr.o >> diff --git a/drivers/virt/gunyah/rsc_mgr.c b/drivers/virt/gunyah/rsc_mgr.c >> new file mode 100644 >> index 000000000000..a9fde703cbbe >> --- /dev/null >> +++ b/drivers/virt/gunyah/rsc_mgr.c >> @@ -0,0 +1,602 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved. >> + */ >> + >> +#define pr_fmt(fmt) "gh_rsc_mgr: " fmt > > This is a driver, you should never need this as you should be using the > dev_*() calls, not pr_*() calls as you always have access to a struct > device, right? > > So you can drop this. > > Ack >> + >> +#include <linux/of.h> >> +#include <linux/slab.h> >> +#include <linux/mutex.h> >> +#include <linux/sched.h> >> +#include <linux/gunyah.h> >> +#include <linux/module.h> >> +#include <linux/of_irq.h> >> +#include <linux/kthread.h> >> +#include <linux/notifier.h> >> +#include <linux/workqueue.h> >> +#include <linux/completion.h> >> +#include <linux/gunyah_rsc_mgr.h> >> +#include <linux/platform_device.h> >> + >> +#include "rsc_mgr.h" >> + >> +/* Resource Manager Header */ >> +struct gh_rm_rpc_hdr { >> + u8 version : 4, hdr_words : 4; >> + u8 type : 2, fragments : 6; > > Ick, that's hard to read. One variable per line please? Ack. > And why the bit packed stuff? Are you sure this is the way to do this? > Why not use a bitmask instead? > I felt bit packed implementation is cleaner and easier to map to understanding what the fields are used for. >> + u16 seq; >> + u32 msg_id; >> +} __packed; >> + >> +/* Standard reply header */ >> +struct gh_rm_rpc_reply_hdr { >> + struct gh_rm_rpc_hdr rpc_hdr; >> + u32 err_code; >> +} __packed; >> + >> +/* RPC Header versions */ >> +#define GH_RM_RPC_HDR_VERSION_ONE 0x1 >> + >> +/* RPC Header words */ >> +#define GH_RM_RPC_HDR_WORDS 0x2 >> + >> +/* RPC Message types */ >> +#define GH_RM_RPC_TYPE_CONT 0x0 >> +#define GH_RM_RPC_TYPE_REQ 0x1 >> +#define GH_RM_RPC_TYPE_RPLY 0x2 >> +#define GH_RM_RPC_TYPE_NOTIF 0x3 >> + >> +#define GH_RM_MAX_NUM_FRAGMENTS 62 >> + >> +#define GH_RM_MAX_MSG_SIZE (GH_MSGQ_MAX_MSG_SIZE - sizeof(struct gh_rm_rpc_hdr)) >> + >> +/** >> + * struct gh_rm_connection - Represents a complete message from resource manager >> + * @payload: Combined payload of all the fragments (msg headers stripped off). >> + * @size: Size of the payload. >> + * @ret: Linux return code, set in case there was an error processing connection >> + * @msg_id: Message ID from the header. >> + * @type: GH_RM_RPC_TYPE_RPLY or GH_RM_RPC_TYPE_NOTIF. >> + * @num_fragments: total number of fragments expected to be received. >> + * @fragments_received: fragments received so far. >> + * @rm_error: For request/reply sequences with standard replies. >> + * @seq: Sequence ID for the main message. >> + * @seq_done: Signals caller that the RM reply has been received >> + */ >> +struct gh_rm_connection { >> + void *payload; >> + size_t size; >> + int ret; >> + u32 msg_id; >> + u8 type; >> + >> + u8 num_fragments; >> + u8 fragments_received; >> + >> + /* only for req/reply sequence */ >> + u32 rm_error; >> + u16 seq; >> + struct completion seq_done; >> +}; >> + >> +struct gh_rm_notif_complete { >> + struct gh_rm_connection *conn; >> + struct work_struct work; >> +}; >> + >> +struct gh_rsc_mgr { >> + struct gunyah_resource tx_ghrsc, rx_ghrsc; >> + struct gh_msgq msgq; >> + struct mbox_client msgq_client; >> + struct gh_rm_connection *active_rx_connection; >> + int last_tx_ret; >> + >> + struct idr call_idr; >> + struct mutex call_idr_lock; >> + >> + struct mutex send_lock; >> + >> + struct work_struct recv_work; >> +}; >> + >> +static struct gh_rsc_mgr *__rsc_mgr; > > Sorry, no, you don't get to just limit yourself to one of these. Please > make this properly handle any number of "resource managers", static > variables like this is not ok. > There will only ever be one resource manager. optee, psci, and qcom_scm use a similar approach. >> +SRCU_NOTIFIER_HEAD_STATIC(gh_rm_notifier); > > Why do you need a notifier list? > > Who will register for this? For what? Why? > The majority of notifications that RM sends to Linux will be related to VM state, e.g. "VM crashed." I've not added the handling in VM manager yet to reduce the number of patches in this series. It was used in the previous series for the console driver. I can remove for now and re-introduce it once VM manager makes use? >> +static int gh_rm_drv_probe(struct platform_device *pdev) >> +{ >> + struct gh_rsc_mgr *rsc_mgr; >> + int ret; >> + >> + rsc_mgr = devm_kzalloc(&pdev->dev, sizeof(*rsc_mgr), GFP_KERNEL); >> + if (!rsc_mgr) >> + return -ENOMEM; >> + platform_set_drvdata(pdev, rsc_mgr); >> + >> + mutex_init(&rsc_mgr->call_idr_lock); >> + idr_init(&rsc_mgr->call_idr); >> + mutex_init(&rsc_mgr->send_lock); >> + >> + ret = gh_msgq_platform_probe_direction(pdev, GUNYAH_RESOURCE_TYPE_MSGQ_TX, 0, >> + &rsc_mgr->tx_ghrsc); >> + if (ret) >> + return ret; >> + >> + ret = gh_msgq_platform_probe_direction(pdev, GUNYAH_RESOURCE_TYPE_MSGQ_RX, 1, >> + &rsc_mgr->rx_ghrsc); >> + if (ret) >> + return ret; >> + >> + rsc_mgr->msgq_client.dev = &pdev->dev; > > So your client device is the platform device, and not a new bridge > device that you create instead? Why? > Answered below >> + rsc_mgr->msgq_client.tx_block = true; >> + rsc_mgr->msgq_client.rx_callback = gh_rm_msgq_rx_data; >> + rsc_mgr->msgq_client.tx_done = gh_rm_msgq_tx_done; >> + >> + ret = gh_msgq_init(&pdev->dev, &rsc_mgr->msgq, &rsc_mgr->msgq_client, >> + &rsc_mgr->tx_ghrsc, &rsc_mgr->rx_ghrsc); >> + if (ret) >> + return ret; >> + >> + __rsc_mgr = rsc_mgr; >> + >> + return 0; >> +} >> +static struct platform_driver gh_rm_driver = { >> + .probe = gh_rm_drv_probe, >> + .remove = gh_rm_drv_remove, >> + .driver = { >> + .name = "gh_rsc_mgr", >> + .of_match_table = gh_rm_of_match, >> + }, > > Wait, why is this a platform driver? This is binding to a real device > on a real bus, not a random platform description in DT, right? This a binding for a real device and not a "random platform description" in DT to get the driver probed. > Or is it controlled by your DT? I can't figure that out here, sorry. There is some info in Patch 2 about why the DT node exists and how it looks. Essentially, The DT node is provided by Gunyah during boot and describes how Linux can communicate with resource manager. Thanks, Elliot
WARNING: multiple messages have this Message-ID (diff)
From: Elliot Berman <quic_eberman@quicinc.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Bjorn Andersson <quic_bjorande@quicinc.com>, 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>, Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>, Andy Gross <agross@kernel.org>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Jassi Brar <jassisinghbrar@gmail.com>, <linux-arm-kernel@lists.infradead.org>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Jonathan Corbet <corbet@lwn.net>, "Will Deacon" <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, "Arnd Bergmann" <arnd@arndb.de>, Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Amol Maheshwari <amahesh@qti.qualcomm.com>, Kalle Valo <kvalo@kernel.org>, <devicetree@vger.kernel.org>, <linux-doc@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v6 10/21] gunyah: rsc_mgr: Add resource manager RPC core Date: Tue, 1 Nov 2022 17:12:58 -0700 [thread overview] Message-ID: <3d2858fe-ea3e-159c-faff-5052cba1e08c@quicinc.com> (raw) In-Reply-To: <Y2FfKCKZ3N8rOqcT@kroah.com> On 11/1/2022 11:02 AM, Greg Kroah-Hartman wrote: > On Wed, Oct 26, 2022 at 11:58:35AM -0700, Elliot Berman wrote: >> The resource manager is a special virtual machine which is always >> running on a Gunyah system. It provides APIs for creating and destroying >> VMs, secure memory management, sharing/lending of memory between VMs, >> and setup of inter-VM communication. Calls to the resource manager are >> made via message queues. >> >> This patch implements the basic probing and RPC mechanism to make those >> API calls. Request/response calls can be made with gh_rm_call. >> Drivers can also register to notifications pushed by RM via >> gh_rm_register_notifier >> >> Specific API calls that resource manager supports will be implemented in >> subsequent patches. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> --- >> MAINTAINERS | 2 +- >> drivers/virt/gunyah/Kconfig | 15 + >> drivers/virt/gunyah/Makefile | 3 + >> drivers/virt/gunyah/rsc_mgr.c | 602 +++++++++++++++++++++++++++++++++ >> drivers/virt/gunyah/rsc_mgr.h | 34 ++ >> include/linux/gunyah_rsc_mgr.h | 26 ++ >> 6 files changed, 681 insertions(+), 1 deletion(-) >> create mode 100644 drivers/virt/gunyah/rsc_mgr.c >> create mode 100644 drivers/virt/gunyah/rsc_mgr.h >> create mode 100644 include/linux/gunyah_rsc_mgr.h >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 586539eadd3b..e072a0d2e553 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -8945,7 +8945,7 @@ F: Documentation/virt/gunyah/ >> F: arch/arm64/gunyah/ >> F: drivers/mailbox/gunyah-msgq.c >> F: drivers/virt/gunyah/ >> -F: include/linux/gunyah.h >> +F: include/linux/gunyah*.h >> >> HABANALABS PCI DRIVER >> M: Oded Gabbay <ogabbay@kernel.org> >> diff --git a/drivers/virt/gunyah/Kconfig b/drivers/virt/gunyah/Kconfig >> index 127156a678a6..4de88d80aa7b 100644 >> --- a/drivers/virt/gunyah/Kconfig >> +++ b/drivers/virt/gunyah/Kconfig >> @@ -10,3 +10,18 @@ config GUNYAH >> >> Say Y/M here to enable the drivers needed to interact in a Gunyah >> virtual environment. >> + >> +config GUNYAH_RESORUCE_MANAGER >> + tristate "Gunyah Resource Manager" >> + select MAILBOX >> + select GUNYAH_MESSAGE_QUEUES >> + depends on GUNYAH >> + default y > > You only have "default y" if your machine can not boot without it. > Please do not add that here. > There's a guideline in Documentation/kbuild/kconfig-language.rst to provide some sane defaults for subdriver behavior. Here, CONFIG_GUNYAH is default n. It's unlikely for someone to want to have Linux with base Gunyah support (hypercalls and hypervisor detection) without also having the Resource Manager driver. If it's better, I could change to default m? >> + help >> + The resource manager (RM) is a privileged application VM supporting >> + the Gunyah Hypervisor. Enable this driver to support communicating >> + with Gunyah RM. This is typically required for a VM running under >> + Gunyah wanting to have Gunyah-awareness. >> + >> + Say Y/M here if unsure. >> + >> diff --git a/drivers/virt/gunyah/Makefile b/drivers/virt/gunyah/Makefile >> index 2ac4ee64b89d..2c18b0a56413 100644 >> --- a/drivers/virt/gunyah/Makefile >> +++ b/drivers/virt/gunyah/Makefile >> @@ -1 +1,4 @@ >> obj-$(CONFIG_GUNYAH) += gunyah.o >> + >> +gunyah_rsc_mgr-y += rsc_mgr.o >> +obj-$(CONFIG_GUNYAH_RESORUCE_MANAGER) += gunyah_rsc_mgr.o >> diff --git a/drivers/virt/gunyah/rsc_mgr.c b/drivers/virt/gunyah/rsc_mgr.c >> new file mode 100644 >> index 000000000000..a9fde703cbbe >> --- /dev/null >> +++ b/drivers/virt/gunyah/rsc_mgr.c >> @@ -0,0 +1,602 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (c) 2022 Qualcomm Innovation Center, Inc. All rights reserved. >> + */ >> + >> +#define pr_fmt(fmt) "gh_rsc_mgr: " fmt > > This is a driver, you should never need this as you should be using the > dev_*() calls, not pr_*() calls as you always have access to a struct > device, right? > > So you can drop this. > > Ack >> + >> +#include <linux/of.h> >> +#include <linux/slab.h> >> +#include <linux/mutex.h> >> +#include <linux/sched.h> >> +#include <linux/gunyah.h> >> +#include <linux/module.h> >> +#include <linux/of_irq.h> >> +#include <linux/kthread.h> >> +#include <linux/notifier.h> >> +#include <linux/workqueue.h> >> +#include <linux/completion.h> >> +#include <linux/gunyah_rsc_mgr.h> >> +#include <linux/platform_device.h> >> + >> +#include "rsc_mgr.h" >> + >> +/* Resource Manager Header */ >> +struct gh_rm_rpc_hdr { >> + u8 version : 4, hdr_words : 4; >> + u8 type : 2, fragments : 6; > > Ick, that's hard to read. One variable per line please? Ack. > And why the bit packed stuff? Are you sure this is the way to do this? > Why not use a bitmask instead? > I felt bit packed implementation is cleaner and easier to map to understanding what the fields are used for. >> + u16 seq; >> + u32 msg_id; >> +} __packed; >> + >> +/* Standard reply header */ >> +struct gh_rm_rpc_reply_hdr { >> + struct gh_rm_rpc_hdr rpc_hdr; >> + u32 err_code; >> +} __packed; >> + >> +/* RPC Header versions */ >> +#define GH_RM_RPC_HDR_VERSION_ONE 0x1 >> + >> +/* RPC Header words */ >> +#define GH_RM_RPC_HDR_WORDS 0x2 >> + >> +/* RPC Message types */ >> +#define GH_RM_RPC_TYPE_CONT 0x0 >> +#define GH_RM_RPC_TYPE_REQ 0x1 >> +#define GH_RM_RPC_TYPE_RPLY 0x2 >> +#define GH_RM_RPC_TYPE_NOTIF 0x3 >> + >> +#define GH_RM_MAX_NUM_FRAGMENTS 62 >> + >> +#define GH_RM_MAX_MSG_SIZE (GH_MSGQ_MAX_MSG_SIZE - sizeof(struct gh_rm_rpc_hdr)) >> + >> +/** >> + * struct gh_rm_connection - Represents a complete message from resource manager >> + * @payload: Combined payload of all the fragments (msg headers stripped off). >> + * @size: Size of the payload. >> + * @ret: Linux return code, set in case there was an error processing connection >> + * @msg_id: Message ID from the header. >> + * @type: GH_RM_RPC_TYPE_RPLY or GH_RM_RPC_TYPE_NOTIF. >> + * @num_fragments: total number of fragments expected to be received. >> + * @fragments_received: fragments received so far. >> + * @rm_error: For request/reply sequences with standard replies. >> + * @seq: Sequence ID for the main message. >> + * @seq_done: Signals caller that the RM reply has been received >> + */ >> +struct gh_rm_connection { >> + void *payload; >> + size_t size; >> + int ret; >> + u32 msg_id; >> + u8 type; >> + >> + u8 num_fragments; >> + u8 fragments_received; >> + >> + /* only for req/reply sequence */ >> + u32 rm_error; >> + u16 seq; >> + struct completion seq_done; >> +}; >> + >> +struct gh_rm_notif_complete { >> + struct gh_rm_connection *conn; >> + struct work_struct work; >> +}; >> + >> +struct gh_rsc_mgr { >> + struct gunyah_resource tx_ghrsc, rx_ghrsc; >> + struct gh_msgq msgq; >> + struct mbox_client msgq_client; >> + struct gh_rm_connection *active_rx_connection; >> + int last_tx_ret; >> + >> + struct idr call_idr; >> + struct mutex call_idr_lock; >> + >> + struct mutex send_lock; >> + >> + struct work_struct recv_work; >> +}; >> + >> +static struct gh_rsc_mgr *__rsc_mgr; > > Sorry, no, you don't get to just limit yourself to one of these. Please > make this properly handle any number of "resource managers", static > variables like this is not ok. > There will only ever be one resource manager. optee, psci, and qcom_scm use a similar approach. >> +SRCU_NOTIFIER_HEAD_STATIC(gh_rm_notifier); > > Why do you need a notifier list? > > Who will register for this? For what? Why? > The majority of notifications that RM sends to Linux will be related to VM state, e.g. "VM crashed." I've not added the handling in VM manager yet to reduce the number of patches in this series. It was used in the previous series for the console driver. I can remove for now and re-introduce it once VM manager makes use? >> +static int gh_rm_drv_probe(struct platform_device *pdev) >> +{ >> + struct gh_rsc_mgr *rsc_mgr; >> + int ret; >> + >> + rsc_mgr = devm_kzalloc(&pdev->dev, sizeof(*rsc_mgr), GFP_KERNEL); >> + if (!rsc_mgr) >> + return -ENOMEM; >> + platform_set_drvdata(pdev, rsc_mgr); >> + >> + mutex_init(&rsc_mgr->call_idr_lock); >> + idr_init(&rsc_mgr->call_idr); >> + mutex_init(&rsc_mgr->send_lock); >> + >> + ret = gh_msgq_platform_probe_direction(pdev, GUNYAH_RESOURCE_TYPE_MSGQ_TX, 0, >> + &rsc_mgr->tx_ghrsc); >> + if (ret) >> + return ret; >> + >> + ret = gh_msgq_platform_probe_direction(pdev, GUNYAH_RESOURCE_TYPE_MSGQ_RX, 1, >> + &rsc_mgr->rx_ghrsc); >> + if (ret) >> + return ret; >> + >> + rsc_mgr->msgq_client.dev = &pdev->dev; > > So your client device is the platform device, and not a new bridge > device that you create instead? Why? > Answered below >> + rsc_mgr->msgq_client.tx_block = true; >> + rsc_mgr->msgq_client.rx_callback = gh_rm_msgq_rx_data; >> + rsc_mgr->msgq_client.tx_done = gh_rm_msgq_tx_done; >> + >> + ret = gh_msgq_init(&pdev->dev, &rsc_mgr->msgq, &rsc_mgr->msgq_client, >> + &rsc_mgr->tx_ghrsc, &rsc_mgr->rx_ghrsc); >> + if (ret) >> + return ret; >> + >> + __rsc_mgr = rsc_mgr; >> + >> + return 0; >> +} >> +static struct platform_driver gh_rm_driver = { >> + .probe = gh_rm_drv_probe, >> + .remove = gh_rm_drv_remove, >> + .driver = { >> + .name = "gh_rsc_mgr", >> + .of_match_table = gh_rm_of_match, >> + }, > > Wait, why is this a platform driver? This is binding to a real device > on a real bus, not a random platform description in DT, right? This a binding for a real device and not a "random platform description" in DT to get the driver probed. > Or is it controlled by your DT? I can't figure that out here, sorry. There is some info in Patch 2 about why the DT node exists and how it looks. Essentially, The DT node is provided by Gunyah during boot and describes how Linux can communicate with resource manager. Thanks, Elliot _______________________________________________ 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:[~2022-11-02 0:13 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-26 18:58 [PATCH v6 00/21] Drivers for gunyah hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 01/21] docs: gunyah: Introduce Gunyah Hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 12:35 ` Bagas Sanjaya 2022-11-02 12:35 ` Bagas Sanjaya 2022-10-26 18:58 ` [PATCH v6 02/21] dt-bindings: Add binding for gunyah hypervisor Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-27 19:57 ` Krzysztof Kozlowski 2022-10-27 19:57 ` Krzysztof Kozlowski 2022-10-28 2:33 ` Jassi Brar 2022-10-28 2:33 ` Jassi Brar 2022-11-01 3:19 ` Elliot Berman 2022-11-01 3:19 ` Elliot Berman 2022-11-01 16:23 ` Jassi Brar 2022-11-01 16:23 ` Jassi Brar 2022-11-01 20:35 ` Elliot Berman 2022-11-01 20:35 ` Elliot Berman 2022-11-01 21:58 ` Jassi Brar 2022-11-01 21:58 ` Jassi Brar 2022-11-02 0:12 ` Elliot Berman 2022-11-02 0:12 ` Elliot Berman 2022-11-02 2:01 ` Jassi Brar 2022-11-02 2:01 ` Jassi Brar 2022-11-02 18:05 ` Elliot Berman 2022-11-02 18:05 ` Elliot Berman 2022-11-02 18:24 ` Jassi Brar 2022-11-02 18:24 ` Jassi Brar 2022-11-02 23:23 ` Elliot Berman 2022-11-02 23:23 ` Elliot Berman 2022-11-03 3:21 ` Jassi Brar 2022-11-03 3:21 ` Jassi Brar 2022-11-03 19:45 ` Elliot Berman 2022-11-03 19:45 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 03/21] gunyah: Common types and error codes for Gunyah hypercalls Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 19:47 ` Dmitry Baryshkov 2022-10-26 19:47 ` Dmitry Baryshkov 2022-10-26 18:58 ` [PATCH v6 04/21] arm64: smccc: Include alternative-macros.h Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 19:46 ` Dmitry Baryshkov 2022-10-26 19:46 ` Dmitry Baryshkov 2022-10-26 20:23 ` Elliot Berman 2022-10-26 20:23 ` Elliot Berman 2022-10-26 20:39 ` Dmitry Baryshkov 2022-10-26 20:39 ` Dmitry Baryshkov 2022-10-26 18:58 ` [PATCH v6 05/21] virt: gunyah: Add hypercalls to identify Gunyah Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 06/21] virt: gunyah: Identify hypervisor version Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 07/21] mailbox: Allow direct registration to a channel Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 08/21] virt: gunyah: msgq: Add hypercalls to send and receive messages Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 09/21] mailbox: Add Gunyah message queue mailbox Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-27 13:55 ` Pavan Kondeti 2022-10-27 13:55 ` Pavan Kondeti 2022-11-01 17:44 ` Elliot Berman 2022-11-01 17:44 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 10/21] gunyah: rsc_mgr: Add resource manager RPC core Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-01 18:02 ` Greg Kroah-Hartman 2022-11-01 18:02 ` Greg Kroah-Hartman 2022-11-02 0:12 ` Elliot Berman [this message] 2022-11-02 0:12 ` Elliot Berman 2022-11-02 2:53 ` Greg Kroah-Hartman 2022-11-02 2:53 ` Greg Kroah-Hartman 2022-11-02 18:04 ` Elliot Berman 2022-11-02 18:04 ` Elliot Berman 2022-11-03 0:22 ` Greg Kroah-Hartman 2022-11-03 0:22 ` Greg Kroah-Hartman 2022-11-03 22:07 ` Elliot Berman 2022-11-03 22:07 ` Elliot Berman 2022-11-03 22:09 ` Elliot Berman 2022-11-03 22:09 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 11/21] gunyah: rsc_mgr: Add subdevices bus Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 12/21] gunyah: rsc_mgr: Add VM lifecycle RPC Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 13/21] gunyah: vm_mgr: Introduce basic VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 5:14 ` Greg Kroah-Hartman 2022-11-02 5:14 ` Greg Kroah-Hartman 2022-11-02 18:45 ` Elliot Berman 2022-11-02 18:45 ` Elliot Berman 2022-11-03 0:24 ` Greg Kroah-Hartman 2022-11-03 0:24 ` Greg Kroah-Hartman 2022-11-04 0:11 ` Elliot Berman 2022-11-04 0:11 ` Elliot Berman 2022-11-04 8:10 ` Arnd Bergmann 2022-11-04 8:10 ` Arnd Bergmann 2022-11-04 22:38 ` Elliot Berman 2022-11-04 22:38 ` Elliot Berman 2022-11-05 4:19 ` Trilok Soni 2022-11-05 4:19 ` Trilok Soni 2022-11-11 0:03 ` Elliot Berman 2022-11-11 0:03 ` Elliot Berman 2022-11-11 6:24 ` Greg Kroah-Hartman 2022-11-11 6:24 ` Greg Kroah-Hartman 2022-11-11 17:08 ` Elliot Berman 2022-11-11 17:08 ` Elliot Berman 2022-11-02 7:31 ` Arnd Bergmann 2022-11-02 7:31 ` Arnd Bergmann 2022-11-02 18:44 ` Elliot Berman 2022-11-02 18:44 ` Elliot Berman 2022-11-03 0:20 ` Greg Kroah-Hartman 2022-11-03 0:20 ` Greg Kroah-Hartman 2022-11-03 22:33 ` Elliot Berman 2022-11-03 22:33 ` Elliot Berman 2022-11-03 9:39 ` Arnd Bergmann 2022-11-03 9:39 ` Arnd Bergmann 2022-11-03 22:10 ` Elliot Berman 2022-11-03 22:10 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 14/21] gunyah: rsc_mgr: Add RPC for sharing memory Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 15/21] gunyah: vm_mgr: Add/remove user memory regions Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 16/21] gunyah: vm_mgr: Add ioctls to support basic non-proxy VM boot Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 17/21] samples: Add sample userspace Gunyah VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 18/21] gunyah: rsc_mgr: Add platform ops on mem_lend/mem_reclaim Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 19/21] firmware: qcom_scm: Use fixed width src vm bitmap Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 18:58 ` [PATCH v6 20/21] firmware: qcom_scm: Register Gunyah platform ops Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-10-26 21:32 ` kernel test robot 2022-10-26 18:58 ` [PATCH v6 21/21] docs: gunyah: Document Gunyah VM Manager Elliot Berman 2022-10-26 18:58 ` Elliot Berman 2022-11-02 13:05 ` Bagas Sanjaya 2022-11-02 13:05 ` Bagas Sanjaya 2022-11-02 18:04 ` Elliot Berman 2022-11-02 18:04 ` Elliot Berman
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=3d2858fe-ea3e-159c-faff-5052cba1e08c@quicinc.com \ --to=quic_eberman@quicinc.com \ --cc=agross@kernel.org \ --cc=amahesh@qti.qualcomm.com \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=devicetree@vger.kernel.org \ --cc=dmitry.baryshkov@linaro.org \ --cc=gregkh@linuxfoundation.org \ --cc=jassisinghbrar@gmail.com \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=kvalo@kernel.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=lorenzo.pieralisi@arm.com \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=quic_bjorande@quicinc.com \ --cc=quic_cvanscha@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 \ --cc=sudeep.holla@arm.com \ --cc=will@kernel.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.