All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Beleswar Prasad Padhi <b-padhi@ti.com>
Cc: andersson@kernel.org, afd@ti.com, hnagalla@ti.com,
	u-kumar1@ti.com, jm@ti.com, jan.kiszka@siemens.com,
	christophe.jaillet@wanadoo.fr, jkangas@redhat.com,
	eballetbo@redhat.com, linux-remoteproc@vger.kernel.org,
	linux-kernel@vger.kernel.org, martyn.welch@collabora.com
Subject: Re: [PATCH v12 04/36] remoteproc: k3-m4: Don't assert reset in detach routine
Date: Mon, 19 May 2025 08:37:06 -0600	[thread overview]
Message-ID: <aCtCEvGlqIIDYtcn@p14s> (raw)
In-Reply-To: <057cffb6-3ff6-4795-8501-7695d7ebc6fa@ti.com>

On Sat, May 17, 2025 at 06:53:29PM +0530, Beleswar Prasad Padhi wrote:
> 
> On 5/16/2025 9:15 PM, Mathieu Poirier wrote:
> > On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> > > The rproc_detach() function invokes __rproc_detach() before
> > > rproc_unprepare_device(). The __rproc_detach() function sets the
> > > rproc->state to "RPROC_DETACHED".
> > > 
> > > However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHED"
> > > state in its .unprepare ops to identify IPC-only mode; which leads to
> > > resetting the rproc in detach routine.
> > > 
> > > Therefore, correct the IPC-only mode detection logic to look for
> > > "RPROC_DETACHED" in k3_m4_rproc_unprepare() function.
> > > 
> > This driver has been upstream for 9 whole months, it is hard for me to believe
> > this but was just noticed.  Martyn from Collabora should be CC'ed on this, and I
> > will also need the required R-b/T-b tags.
> 
> 
> Cc: Martyn Welch martyn.welch@collabora.com
> 
> Requesting Andrew/Judith for review and test too.
> 
> > 
> > Typically bug fixes are not part of refactoring exercises.
> 
> 
> Typically, yes. But the refactor depends on this fix. This
> k3_m4_rproc_unprepare() function is entirely refactored to common driver in
> [PATCH v12 26/36].
>
> So, If the refactor is picked without this patch fix, the mainline M4 driver
> would be fixed, but the older stable kernels would always have this bug. Let
> me know what you think.
> 

I suggest you send this patch on its own and then the series (without this
patch) with a note in the cover letter that it depends on the fix.  That way we
get the best of both worlds.

> Thanks,
> Beleswar
> 
> >   I suggest to apply
> > this set without this patch - you can then work on fixing this bug.
> > 
> > Thanks,
> > Mathieu
> > 
> > > Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
> > > Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
> > > ---
> > > v12: Changelog:
> > > 1. New patch. Fixup a state detection logic.
> > > 
> > >   drivers/remoteproc/ti_k3_m4_remoteproc.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > > index a16fb165fcedd..6cd50b16a8e82 100644
> > > --- a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > > +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> > > @@ -228,7 +228,7 @@ static int k3_m4_rproc_unprepare(struct rproc *rproc)
> > >   	int ret;
> > >   	/* If the core is going to be detached do not assert the module reset */
> > > -	if (rproc->state == RPROC_ATTACHED)
> > > +	if (rproc->state == RPROC_DETACHED)
> > >   		return 0;
> > >   	ret = kproc->ti_sci->ops.dev_ops.put_device(kproc->ti_sci,
> > > -- 
> > > 2.34.1
> > > 

  reply	other threads:[~2025-05-19 14:37 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13  5:44 [PATCH v12 00/36] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 01/36] remoteproc: k3-r5: Drop check performed in k3_r5_rproc_{mbox_callback/kick} Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 02/36] remoteproc: k3-dsp: Drop check performed in k3_dsp_rproc_{mbox_callback/kick} Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 03/36] remoteproc: k3-r5: Refactor sequential core power up/down operations Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 04/36] remoteproc: k3-m4: Don't assert reset in detach routine Beleswar Padhi
2025-05-16 15:45   ` Mathieu Poirier
2025-05-17 13:23     ` Beleswar Prasad Padhi
2025-05-19 14:37       ` Mathieu Poirier [this message]
2025-05-20  5:06         ` Beleswar Prasad Padhi
2025-05-20 12:17           ` Hari Nagalla
2025-05-20  9:07       ` Martyn Welch
2025-05-13  5:44 ` [PATCH v12 05/36] remoteproc: k3-r5: Re-order internal memory initialization functions Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 06/36] remoteproc: k3-r5: Re-order k3_r5_release_tsp() function Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 07/36] remoteproc: k3-r5: Refactor Data Structures to Align with DSP and M4 Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 08/36] remoteproc: k3-r5: Use k3_r5_rproc_mem_data structure for memory info Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 09/36] remoteproc: k3-{m4/dsp}: Add a void ptr member in rproc internal struct Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 10/36] remoteproc: k3-m4: Add pointer to rproc struct within k3_m4_rproc Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 11/36] remoteproc: k3-m4: Use k3_rproc_mem_data structure for memory info Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 12/36] remoteproc: k3: Refactor shared data structures Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 13/36] remoteproc: k3: Refactor mailbox rx_callback functions into common driver Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 14/36] remoteproc: k3: Refactor .kick rproc ops " Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 15/36] remoteproc: k3-dsp: Correct Reset logic for devices without lresets Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 16/36] remoteproc: k3-m4: Introduce central function to put rproc into reset Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 17/36] remoteproc: k3: Refactor rproc_reset() implementation into common driver Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 18/36] remoteproc: k3-dsp: Correct Reset deassert logic for devices w/o lresets Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 19/36] remoteproc: k3-m4: Introduce central function to release rproc from reset Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 20/36] remoteproc: k3: Refactor rproc_release() implementation into common driver Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 21/36] remoteproc: k3-m4: Ping the mbox while acquiring the channel Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 22/36] remoteproc: k3: Refactor rproc_request_mbox() implementations into common driver Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 23/36] remoteproc: k3-dsp: Don't override rproc ops in IPC-only mode Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 24/36] remoteproc: k3-dsp: Assert local reset during .prepare callback Beleswar Padhi
2025-05-13  5:44 ` [PATCH v12 25/36] remoteproc: k3: Refactor .prepare rproc ops into common driver Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 26/36] remoteproc: k3: Refactor .unprepare " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 27/36] remoteproc: k3: Refactor .start " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 28/36] remoteproc: k3: Refactor .stop " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 29/36] remoteproc: k3: Refactor .attach " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 30/36] remoteproc: k3: Refactor .detach " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 31/36] remoteproc: k3: Refactor .get_loaded_rsc_table " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 32/36] remoteproc: k3: Refactor .da_to_va rproc " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 33/36] remoteproc: k3: Refactor of_get_memories() functions " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 34/36] remoteproc: k3: Refactor mem_release() " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 35/36] remoteproc: k3: Refactor reserved_mem_init() " Beleswar Padhi
2025-05-13  5:45 ` [PATCH v12 36/36] remoteproc: k3: Refactor release_tsp() " Beleswar Padhi
2025-05-20 17:27 ` [PATCH v12 00/36] Refactor TI K3 R5, DSP and M4 Remoteproc Drivers Mathieu Poirier

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=aCtCEvGlqIIDYtcn@p14s \
    --to=mathieu.poirier@linaro.org \
    --cc=afd@ti.com \
    --cc=andersson@kernel.org \
    --cc=b-padhi@ti.com \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=eballetbo@redhat.com \
    --cc=hnagalla@ti.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jkangas@redhat.com \
    --cc=jm@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=martyn.welch@collabora.com \
    --cc=u-kumar1@ti.com \
    /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: link
Be 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.