> > > *From: *Krzysztof Kozlowski <[email protected]> > *Date: *Thursday, October 15, 2026 at 2:51 AM > *To: *Levinsky, Ben <[email protected]> > *Cc: *[email protected] <[email protected]>; > [email protected] > <[email protected]>; [email protected] > <[email protected]>; > [email protected] <[email protected]>; [email protected] <[email protected]>; > [email protected] <[email protected]>; Simek, Michal > <[email protected]>; > [email protected] <[email protected]>; > [email protected] <[email protected]>; linux-arm- > [email protected] <[email protected]>; linux- > [email protected] <[email protected]>; Shah, Tanmay > <[email protected]> > *Subject: *Re: [PATCH 6/6] remoteproc: amd_mbv_bram: Add RPMsg support > > On Wed, Oct 14, 2026 at 02:34:26PM -0700, Ben Levinsky wrote: > > Register named reserved-memory carveouts and expose the firmware > > resource table after it has been loaded into BRAM. This lets remoteproc > > create virtqueues backed by reserved shared DDR without deriving > > carveout roles from DT node names. Map the shared-memory carveouts with > > the common rproc_mem_entry_ioremap_wc() and rproc_mem_entry_iounmap() > > callbacks. > > > > Use the mailbox framework to send virtqueue notification IDs. Defer > > received notifications to process context before dispatching them to > > the remoteproc virtqueues. Keep mailbox payload storage valid until > > transmit completion and order write-combined vring updates before each > > kick. > > > > For designs where the mailbox and remote processor share a clock, request > > the mailbox channels only after enabling that clock, while the processor > > is still held in reset. Release the channels before disabling the clock > > during stop. > > > > The mailboxes are optional. Without them the driver keeps supporting > > load, start, and stop only. > > > > Select the mailbox framework, the AMD PL Mailbox controller and the > > virtio RPMsg bus, which the driver uses for notifications and RPMsg > > channels. Selecting MAILBOX while depending on GPIOLIB creates a > > Kconfig recursive dependency, because GPIOLIB is selected by drivers > > that are reachable from MAILBOX, so select GPIOLIB as well instead of > > depending on it. The driver always needs GPIO for the reset line. > > Depend on HAS_IOMEM, which the selected mailbox controller and the > > write-combined carveout mappings require. > > > > Assisted-by: LLM sparse > > Signed-off-by: Ben Levinsky <[email protected]> > > --- > > drivers/remoteproc/Kconfig | 6 +- > > drivers/remoteproc/amd_mbv_bram_rproc.c | 231 +++++++++++++++++++++++- > > 2 files changed, 235 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > > index 5b56b2dcc725..9ebbbf76289f 100644 > > --- a/drivers/remoteproc/Kconfig > > +++ b/drivers/remoteproc/Kconfig > > @@ -25,7 +25,11 @@ config REMOTEPROC_CDEV > > > > config AMD_MBV_BRAM_REMOTEPROC > > tristate "AMD MicroBlaze/V BRAM-based remoteproc support" > > - depends on OF && COMMON_CLK && (GPIOLIB || COMPILE_TEST) > > + depends on OF && COMMON_CLK && HAS_IOMEM > > + select GPIOLIB > > + select MAILBOX > > + select AMD_PL_MAILBOX > > You should not select user-visible symbols. > > Best regards, > Krzysztof >
Hi Krzysztof, Understood, thank you. In v2 I will keep the driver's existing dependencies and add "depends on MAILBOX", since the driver calls the mailbox client API, and drop all the selects. The PL mailbox controller and the virtio RPMsg bus are only needed at run time; I will mention them in the Kconfig help text rather than selecting them. Thanks, Ben
