> On May 11, 2015, at 8:21 PM, David Higgs <hig...@gmail.com> wrote:
>
> On Mon, May 11, 2015 at 8:07 PM, Alexander Hall <alexan...@beard.se
> <mailto:alexan...@beard.se>>wrote:
> Upgrading to the latest snapshot, I noticed my upd sensors had been
> disturbingly crippled.
>
> uhidev0 at uhub4 port 1 configuration 1 interface 0 "EATON Eaton 3S" rev
> 2.00/1.00 addr 2
> uhidev0: iclass 3/0, 32 report ids
> upd0 at uhidev0
>
> Diff below is what happens from upd.c r1.13 to r1.14.
>
> -hw.sensors.upd0.indicator0=On (ACPresent), OK
> -hw.sensors.upd0.indicator1=On (Charging), OK
> -hw.sensors.upd0.indicator2=Off (Discharging), OK
> -hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
> -hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
> -hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
> +hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
> +hw.sensors.upd0.indicator1=On (ACPresent), OK
>
> Is this an expected fallout? Can I provide more info to assist? Full
> dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.
>
> It seems your device doesn't have a BatteryPresent report, or it is somehow
> getting mangled. Can you run lsusb -v on your device and check if "Battery
> Present" is shown?
>
> If it is not, we'll have to make sensor dependencies less strict. I'll start
> thinking about how to do this.
Alternatively, you could try the following diff, which flattens the sensor
dependency tree when a parent sensor isn’t available.
Thanks.
--david
--- a/upd.c
+++ b/upd.c
@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc
for (i = 0; i < nentries; i++) {
entry = entries + i;
- if (!upd_lookup_usage_entry(desc, size, entry, &item))
+ if (!upd_lookup_usage_entry(desc, size, entry, &item) {
+ /* dependency missing, add children to parent */
+ upd_attach_sensor_tree(sc, desc, size,
+ entry->nchildren, entry->children, queue);
continue;
+ }
DPRINTF(("%s: found %s on repid=%d\n", DEVNAME(sc),
entry->usage_name, item.report_ID));
