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

[Saravana Kannan]

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. But it just felt like an inefficient way to get to
close to where my series is. Instead of you just saying you don't like
about my series and giving me some feedback on how to fix it.

> > 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.

Thanks,
Saravana