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

[Rafael J. Wysocki]

On Mon, Mar 10, 2025 at 9:31 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote:
>
> On Mon, Mar 10, 2025 at 9:01 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> >
> > 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.
>
> Sure, I'll do this.

OK

> But it just felt like an inefficient way to get to close to where my series is.

I'm not sure where it is TBH.

> Instead of you just saying you don't like
> about my series and giving me some feedback on how to fix it.

You got feedback on it:

https://lore.kernel.org/linux-pm/CAJZ5v0grG7eSJ7_c73i9-bXaFhm5rfE2WmxtR6yLB-MGkd7sVg@xxxxxxxxxxxxxx/

And no response.

Also here:

https://lore.kernel.org/linux-pm/CAJZ5v0g9A1pZ5FjPAjdLY5ybNmefnBVVMJM7h3czW38p1fTfqQ@xxxxxxxxxxxxxx/

And there was a bunch of feedback from other people (and 0-day) on the
last patch.

> > > 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.
>
> Ok, I'll point out the issues I see in this series and hopefully you
> can point out the issues in my series and we can move forward with
> mine if you agree with the additional issues my series is working
> through.

Sure, but please address the feedback so far and send a new version.