linux-kernel - Re: [PATCH v2 0/6] remoteproc: imx_rproc: Use device managed API to clean up the driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250924203115.GB2711@nxa18884-linux.ap.freescale.net>
Date: Thu, 25 Sep 2025 04:31:15 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Bjorn Andersson <andersson@...nel.org>
Cc: Peng Fan <peng.fan@....com>, Bjorn Andersson <andersson@...nel.org>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Hiago De Franco <hiago.franco@...adex.com>,
	linux-remoteproc@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Frank Li <Frank.Li@....com>, Daniel Baluta <daniel.baluta@....com>
Subject: Re: [PATCH v2 0/6] remoteproc: imx_rproc: Use device managed API to
 clean up the driver

On Wed, Sep 24, 2025 at 11:10:33AM -0600, Mathieu Poirier wrote:
>On Wed, 24 Sept 2025 at 09:35, Peng Fan <peng.fan@....nxp.com> wrote:
>>
...
>> Sorry for early ping - I just wanted to check if there's any chance for this
>> patchset to be included in 6.18, along with the other cleanup patchset [1].
>
>It seems very unlikely.  I am currently looking into how the PM
>runtime framework behaves to address my own questions about this patch
>[1].  Furthermore, I am worried about the usage of the device
>management framework when it comes to freeing memory.  I will get back
>to you with comments on that front when I know we are doing the right
>thing with the PM runtime framework.

I see. Not sure Ulf could help clarify or review, then you might take less
time.

>
>I dropped the 3rd cleanup patchset.  More than once I asked you to
>submit only one patchset at a time and you still refuse to take notice
>of my request.

I apologize - I now recall your earlier request to hold off on submitting
further patches until the table_sz clearing patch was clarified. I
misunderstood and appreciate your patience.

Could you please clarify whether there's a general rule in remoteproc that
developers should only have one patchset or patch under review at a time? If
so, would it be possible to document this guideline in the kernel documentation?
That would help avoid confusion for contributors.

I ask because I have other patches queued that are independent of the current
series, such as:
 - Reintroducing the table_sz clearing
 - Misc cleanup in remoteproc core

I understand you may be busy and have limited bandwidth. Would it be feasible
to offload part of the review work to Bjorn? I rarely see Bjorn reviewing i.MX
patches. Alternatively, could we consider bringing in a third maintainer to
help accelerate the review process?

Thanks again for your time and guidance.

Thanks,
Peng

>
>Mathieu
>
>[1]. "remoteproc: imx_rproc: Fix runtime PM cleanup order and error handling"
>
>>
>> Both patchsets have received Reviewed-by tags, have been tested, and
>> successfully passed builds (arm64 gcc) with each patch applied incrementally.
>>
>> [1] https://lore.kernel.org/linux-remoteproc/20250920-imx_rproc_c2-v2-0-3351c4c96df5@nxp.com/T/#ma16bb8a38300f6eb333ee04f00d57805aee3c114
>>
>> Thanks
>> Peng
>>
>> >
>> > drivers/remoteproc/imx_rproc.c | 128 ++++++++++++++++++-----------------------
>> > 1 file changed, 57 insertions(+), 71 deletions(-)
>> >---
>> >base-commit: c3067c2c38316c3ef013636c93daa285ee6aaa2e
>> >change-id: 20250916-imx_rproc_c2-2b9ad7882f4d
>> >
>> >Best regards,
>> >--
>> >Peng Fan <peng.fan@....com>
>> >
>