[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230208154247.avb5ol4kyrx3y6mm@kazuki-mac>
Date: Thu, 9 Feb 2023 00:42:47 +0900
From: Kazuki <kazukih0205@...il.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
"Rafael J. Wysocki" <rafael@...nel.org>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Hector Martin <marcan@...can.st>,
Sven Peter <sven@...npeter.dev>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>
Subject: Re: s2idle breaks on machines without cpuidle support
On Wed, Feb 08, 2023 at 03:34:07PM +0000, Sudeep Holla wrote:
> On Thu, Feb 09, 2023 at 12:19:39AM +0900, Kazuki wrote:
> > On Wed, Feb 08, 2023 at 03:03:06PM +0000, Sudeep Holla wrote:
>
> [...]
>
> > > Well, if we are allowing to boot on such a system, then we must allow
> > > adding a platform specific idle driver. It may be useful once we info
> > > to add deeper than WFI states.
> >
> > Hmmm, I thought for arm64, non-PSCI idle drivers were prohibited? Or am
> > I mistaken here?
>
> I don't know. I am not against it especially now that we have allowed a
> non-PSCI based production system to boot the kernel.
>
> > > Are we ? I thought were making changes to enable it. Or are you saying
> > > we allow to enter into such a state and render the system unusable, if
> > > so we need to fix it.
> >
> > Both as I mentioned in my first email. Apologies if it turned out to
> > be confusing.
>
> Sorry still confusing. Are you saying you can enter s2idle and crash or
> hang the system without changes(especially around this s2idle code) ?
Yes.
Thanks,
Kazuki
Powered by blists - more mailing lists