Re: [PATCH 0/2] staging: nvec_power: quiesce EC queries for system suspend

[Gustavo Arantes <dev.gustavoa@gmail.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

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