drivers/usbhid-ups.c: try to detect "Driver stale" situations when in "pollonly" mode#1630
Merged
jimklimov merged 2 commits intonetworkupstools:masterfrom Apr 29, 2025
Merged
Conversation
…h "pollonly" mode, re-read HU_FLAG_SEMI_STATIC and HU_FLAG_STATIC entries to detect "Driver stale" situations [networkupstools#1624]
jimklimov
added
question
need testing
Member
Author
|
UPDATE: PR #2010 introduces state entry timestamping, so if it gets merged - we have another approach to the staleness detection problem generally (can just test in every loop if non-(semi)static values were last written longer than SOME_TIMEOUT ago). |
Member
Author
|
Resyncing with main NUT code base after v2.8.3 release. |
|
✅ Build nut 2.8.3.3051-master completed (commit 4ebe26ede3 by @jimklimov) |
Member
Author
|
CI faults irrelevant (free space problems on an agent). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently the driver code does not seem to have any concept of "staleness" if it is not in interrupt mode (and failing those requests). Unplugging the USB cable has no effect on driver's ability and eagerness to report info about the device, even an hour later. I did not yet test if this is a platform issue (seen with Windows builds) or a generic one.
Not sure in practical terms however, if the trick in this PR helps - e.g. it might be prudent to actively re-request static fields known to have been served during initial startup, to make sure they are still served or the device is AWOL (assuming libusb actually requests that, and does not cache responses), but I am not quickly sure how to do that.
More expert eyes are welcome :)