nvec_power still issues EC queries asynchronously and keeps work queued
across system sleep. This series first serializes the driver's EC
requests, then adds PM hooks so the remaining work items are quiesced
while the parent NVEC controller is suspended.

Patch 1 exports a small core parser helper, moves the battery metadata
queries into a worker, and switches nvec_power over to synchronous EC
requests.

Patch 2 tracks the suspend state per instance, prevents new work from
being queued during suspend, and restarts the polling and metadata work
on resume.

Gustavo Arantes (2):
  staging: nvec_power: make EC queries synchronous
  staging: nvec_power: stop EC queries during system suspend

 drivers/staging/nvec/nvec.c       |   7 +-
 drivers/staging/nvec/nvec.h       |   2 +
 drivers/staging/nvec/nvec_power.c | 122 +++++++++++++++++++++++++-----
 3 files changed, 111 insertions(+), 20 deletions(-)


base-commit: ad6bb64332bb4297110950769ad5af52791e33a2
-- 
2.53.0

Hello Gustavo,

thanks for your patches.

On Thu, 12 Mar 2026, Gustavo Arantes wrote:
> nvec_power still issues EC queries asynchronously and keeps work queued
> across system sleep. This series first serializes the driver's EC
> requests, then adds PM hooks so the remaining work items are quiesced
> while the parent NVEC controller is suspended.

Reading out the battery info during boot takes some time as far as I 
remember, but I haven't tested your patches yet. Is the use of sync 
writes really required in order to realize a clean suspend?

AFAIK, the machine doesn't support suspend currently, partily due to 
missing atomic writes for the EC. Building the driver as a removable 
module may be enough to test the change though.
Are you able to test the change on real hardware?

Best wishes,

Marc

> Patch 1 exports a small core parser helper, moves the battery metadata
> queries into a worker, and switches nvec_power over to synchronous EC
> requests.
>
> Patch 2 tracks the suspend state per instance, prevents new work from
> being queued during suspend, and restarts the polling and metadata work
> on resume.
>
> Gustavo Arantes (2):
>  staging: nvec_power: make EC queries synchronous
>  staging: nvec_power: stop EC queries during system suspend
>
> drivers/staging/nvec/nvec.c       |   7 +-
> drivers/staging/nvec/nvec.h       |   2 +
> drivers/staging/nvec/nvec_power.c | 122 +++++++++++++++++++++++++-----
> 3 files changed, 111 insertions(+), 20 deletions(-)
>
>
> base-commit: ad6bb64332bb4297110950769ad5af52791e33a2
> -- 
> 2.53.0
>

Hello Marc,

thanks for reviewing.

On Sun, 15 Mar 2026, Marc Dietrich wrote:
> Reading out the battery info during boot takes some time as far as I
> remember, but I haven't tested your patches yet. Is the use of sync
> writes really required in order to realize a clean suspend?

You're right, I worked out some math on this, and I agree that the sync
conversion isn't strictly necessary.

The worst case with async writes during suspend is a reply arriving
after work has been cancelled. That reply would just be lost, and since
the poller refreshes everything on resume, there's no corruption or
crash — just one missed update.

The sync approach does avoid that window, but the cost is structural:
the battery metadata init serializes N queries, so the boot-time wall
time goes from roughly one EC round-trip to N * T_rt. With N = 3
(MANUFACTURER, MODEL, TYPE), the relative overhead is always 2x
regardless of how fast the EC is. Without hardware to measure T_rt
I can't tell whether that's 100ms or 2s of added latency, but either
way it's a cost with no real safety benefit.

> Are you able to test the change on real hardware?

Unfortunately I don't have access to Tegra 2 hardware, so this has
only been build-tested and reviewed by inspection. I'd appreciate it
if you or someone on the ac100 list could validate the v2 on a real
device.

If you think the lost-reply window during suspend is benign, I'd
prefer to drop patch 1 and send a v2 with just the PM hooks on top
of the existing async flow. Otherwise, I'm happy to keep the sync
conversion as-is.


Best regards,
Gustavo Arantes