On Thu, Sep 25, 2025 at 04:31:15AM +0800, Peng Fan wrote: > On Wed, Sep 24, 2025 at 11:10:33AM -0600, Mathieu Poirier wrote: > >On Wed, 24 Sept 2025 at 09:35, Peng Fan <peng....@oss.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. >
It is fortunate that time was taken to understand the problem and fix it correctly. Otherwise we'd still have a problem and more patches, possibly wrong as well, would have been needed. > > > >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. > Most people tend to address one problem at a time, especially when subsequent patchsets have dependencies on the previous ones. I'm not sure there is a need to document something like that. > 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'm fine with those, as long as you address just one proble at any given time. > > 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? > How fast do you want to go? By and large, I reply to patchsets within a week, sometimes two when things are busy. And when I can't meet those standards, I send out an email to the mailing list with the review order of the patches in my queue. What else are you expecting? Bjorn is maintaining over a dozen subsystems - I stepped forward to maintain remoteproc/rpmsg to help with the volume. > 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-3351c4c96...@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....@nxp.com> > >> > > >
