search for: reconnect_ups

Displaying 4 results from an estimated 4 matches for "reconnect_ups".

2007 Jun 21
2
[nut-commits] svn commit r971 - in trunk: . drivers
...d changes to > > Modified: trunk/drivers/usbhid-ups.c > ============================================================================== > --- trunk/drivers/usbhid-ups.c (original) > +++ trunk/drivers/usbhid-ups.c Thu Jun 21 07:43:46 2007 > @@ -987,7 +987,7 @@ > > static void reconnect_ups(void) > { > - if (hd == NULL) > + while (hd == NULL) ^^^^^^^^^^^^^^^^^^ If the communication to the UPS is lost (and can't be established again), it will stay in this loop forever and therefor never leave the upsdrv_updateinfo() function. This is bad for two reasons: #1 The d...
2007 Jun 21
1
tripplite_usb.c reconnection
On 6/21/07, Arjen de Korte <nut+devel at de-korte.org> wrote: > Charles, > > The same remarks as for the reconnect_ups() patch for usbhid-ups.c go for > the function with the same name in tripplite_usb.c. This is also blocking > and thereby locking up the communication between driver and server. I > don't think this is intentional, since the MAX_RECONNECT_TRIES in > usb_comm_fail() is effectively a...
2007 Aug 23
1
[nut-commits] svn commit r1073 - in trunk: . drivers
...to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups() could be changed to something like: hd = HIDOpenDevice(&udev, &curDevice, reopen_matcher, MODE_REOPEN); if (hd == NULL) { /* reopening failed, try opening new device */ hd = HIDOpenDevice(&udev, &curDevice, regex_matcher, MODE_OPEN); } if (hd == NULL) { return 0; } Note...
2007 Jun 21
0
tripplite_usb.c
Charles, The same remarks as for the reconnect_ups() patch for usbhid-ups.c go for the function with the same name in tripplite_usb.c. This is also blocking and thereby locking up the communication between driver and server. I don't think this is intentional, since the MAX_RECONNECT_TRIES in usb_comm_fail() is effectively a no-op then. I also s...