Re: [PATCH v1 0/5] PM: sleep: Improvements of async suspend and resume of devices

[Rafael J. Wysocki]

On Sun, Mar 9, 2025 at 11:38 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
>
> On Thu, Feb 27, 2025 at 8:23 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > On Thu, Feb 27, 2025 at 4:45 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Feb 25, 2025 at 8:46 AM Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote:
> > > >
> > > > Hi Everyone,
> > > >
> > > > Initially, this was an attempt to address the problems described by
> > > > Saravana related to spawning async work for any async device upfront
> > > > in the resume path:
> > > >
> > > > https://lore.kernel.org/linux-pm/20241114220921.2529905-1-saravanak@xxxxxxxxxx/
> > > >
> > > > but then I realized that it could be extended to the suspend path and
> > > > used for speeding it up, which it really does.
> > >
> > > Btw, maybe I didn't  word it correctly, but my patch series was meant
> > > to speed up the non-async case too.
> >
> > If "the non-async case" means the case with "async" suspend/resume
> > disabled entirely, I don't think that the ordering in which devices
> > are processed can be changed just because there are no known
> > dependencies.
> >
> > > I was going to get around sending a v2 of my series, but was caught up
> > > with some other work. But I'm okay if you want to finish up my effort
> > > -- less work for me and I can focus on the other aspects of suspend :)
> > >
> > > Maybe add a Suggested-by: to the patches?
> >
> > Yeah, I can do that.
> >
> > > I definitely want to review the series, but very busy this week with
> > > some other work. I'll get to this next week for sure.
> >
> > That should be fine.
>
> Hi Rafael,
>
> I looked at the full series and it has at least one bug and a few gaps
> that I address in mine.

What bug?

You need to tell me specifically because I'm not aware of any bugs in
this series and unless you tell me what it is and I agree that it is a
bug, I have no reason to believe that there are any.

As for the gaps, there are obvious differences between this patch
series and your work and it would be kind of nice to explain why they
matter in practice, in your view.

> And those are what make my patches have a
> higher diff. Can we just continue with my series instead?

Of course you are free to send a new version of it, but it is unlikely
to be a sufficient replacement for constructive feedback.