Re: [PATCH v2 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver

[Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>]

Hello Shenwei,

On 10/6/25 16:33, Shenwei Wang wrote:
> 
> Hi Arnaud,
> 
>> -----Original Message-----
>> From: Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
>> Sent: Monday, October 6, 2025 4:53 AM
>> To: Shenwei Wang <shenwei.wang@nxp.com>; Bjorn Andersson
>> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; Rob
>> Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
>> Dooley <conor+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>; Sascha
>> Hauer <s.hauer@pengutronix.de>; Linus Walleij <linus.walleij@linaro.org>;
>> Bartosz Golaszewski <brgl@bgdev.pl>
>> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>; linux-
>> remoteproc@vger.kernel.org; devicetree@vger.kernel.org; imx@lists.linux.dev;
>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org; dl-linux-imx
>> <linux-imx@nxp.com>; openamp-rp@lists.openampproject.org
>> Subject: [EXT] Re: [PATCH v2 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver
>>>> Then, the RPMsg device should be probed either by the remote
>>>> processor using the name service announcement mechanism or if not
>>>> possible by your remoteproc driver.
>>>>
>>> The idea is to probe the GPIO driver successfully only after the remote
>> processor is online and has sent the name service announcement.
>>> Until then, the GPIO driver will remain in a deferred state, ensuring that all
>> consumers of the associated GPIOs are also deferred.
>>> The implementation you provided below does not guarantee that the
>>> related consumers will be properly deferred. This is the most important
>> behavior for a GPIO/I2C controllers.
>>
>>
>> As long as you keep the GPIO/I2C device as a child of the remote processor node,
>> you should not have deferred probe issues.
>> The|of_platform_populate()|function ensures
>> that the I2C/GPIO devices are probed when the remote processor is started.
>> Calling|devm_gpiochip_add_data|in the RPMsg driver probe should also
>> prevent such issues.
>>
> 
> Here, deferred probing is not an issue -it's an intentional feature. We need to ensure that all consumers of the GPIO/I2C controllers remain
> in the deferred state until the remote processor is fully online.
> 
> For instance, consider a regulator node that references a GPIO line from the RPMSG GPIO controller. The regulator will stay in the deferred state
> until the remote processor comes online and its services are announced and received.

I think there is a misunderstanding. My intention was just to mention
that in my proposal, the deferred mechanism should also work as
expected. This is the case for the rpmsg_i2c I mentioned as an example.
Anyway the main point here is to break the dependency between your 
remoteproc driver and the rpmsg GPIO driver. In your remoteproc
driver, you should just call of_platform_populate, and let's the 
compatible mechanism find the associated independent driver defined
in the rpmsg_gpio.c


 From my perspective the sequence should be
1) the remoteproc driver starts the remote processor
2) the remoteproc driver parses the child node with of_platform_populate
3) the rpmsg_gpio platform driver is probed by the of_platform_populate
     - parse the DT node and store configuration in data structure
     - register an rpmsg_gpio driver
4) the rpmsg gpio driver is probed (by the rpmsg bus).
     - register the GPIO and irq chips

Until step 4, the users should be automatically deferred

That said, regarding your implementation, the fact that you have created 
a single rpmsg endpoint for several rpmsg services complexify this 
approach , creating a dependency not only between rpmsg and remoteproc 
but also among rpmsg devices. Having a single rpmsg endpoint associated 
with a single rpmsg service would simplify things.

Of course, I am just sharing my opinion and expectations here. For the 
next steps, I will let the maintainers, Mathieu and Bjorn, provide their 
advice and guidance.

Thanks,
Arnaud

> 
> Thanks,
> Shenwei
> 
>> Regards,
>> Arnaud
>>
>>>
>>> Thanks,
>>> Shenwei
>>>
>>>> To better understand my proposal you can have a look to [1]and [2].
>>>> Here is another example for an rpmsg_i2c( ST downstream implementation):
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit