[Nut-upsdev] [nut-commits] svn commit r1041 - in trunk: . drivers

[Arjen de Korte]

>> - If the UPS sends reports on the interrupt pipeline, we consider that
>> enough proof that it is still there. At the same time, we assume that it
>> keeps us informed of *all* important status changes, so that doing a
>> HU_WALKMODE_QUICK_UPDATE is redundant then.
> This latter assumption is probably not valid in all cases. For
> example, since the interrupt value of
> UPS.PowerSummary.BelowRemainingCapacityLimit was broken on Belkin, we
> decided to go with UPS.BELKINStatus.BELKINBatteryStatus instead, which
> is a variable that is *not* sent on the interrupt pipeline.
>
> In general, not every UPS that uses the interrupt pipeline can be
> trusted to send all important values on it.

I was already afraid of that, so I decided to explicitly mention this in
the ChangeLog. You have a good point here. But so far, the only subdriver
that uses the HU_WALKMODE_QUICK_UPDATE (by setting HU_FLAG_QUICK_POLL on
relevant elements) is mge-hid. So for all but that one, the behaviour
remains the same. I know that at least my Evolution 650 is quite verbose
on the interrupt pipeline when something important happens (it will push
even more parameters than we sollicit from it with a
HU_WALKMODE_QUICK_UPDATE), so apparently MGE uses it (though I have not
checked other models of course).

In order to make the HU_WALKMODE_QUICK_UPDATE more useful, we probably
need to set HU_FLAG_QUICK_POLL on "usb.status" elements for more
subdrivers. For instance, on the "ups.status" for
UPS.BELKINStatus.BELKINPowerStatus and
UPS.BELKINStatus.BELKINBatteryStatus in belkin-hid.c (all of them). I'm
reluctant to do this, since I can't test if this increased polling of
these items doens't break these subdrivers.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57