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

Arjen de Korte wrote:
> 
> Author: adkorte-guest
> Date: Fri Aug 10 20:23:27 2007
> New Revision: 1041
> 
> Log:
> * drivers/usbhid.[ch]:
> - Moved the struct & data for ups.status processing to usbhid.c, since
this is only used in there. Subdrivers report the status through text messages,
they don't set the status bits directly.
> - Rewrote (flattened) the upsdrv_updateinfo() and hid_ups_walk() functions,
so that it is easier to follow/understand what is happening. Also limit the
amount of status update to once every upsdrv_updateinfo and not for each status
report we get. This is enough, since we don't handle requests from clients
when we're talking/listening to the UPS.
> - 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. 

-- Peter
> - Added a ups_infoval_set() function that is doing the actual setting of
values we got from the UPS. This is convenient, so that if we change something
in the way we deal with those, it is all in one location.

>> - 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