[Nut-upsdev] tripplite_usb.c reconnection

[Charles Lepple]

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 no-op then. I also seems to duplicate
> some things in usb_comm_fail(), like upsdrv_cleanup().

Thanks for pointing this out - I had forgotten that this code was
pretty much copied fron usbhid-ups/newhidups, and thus needed to be
fixed as well.

However, I'm not sure I caught the resolution of the problem. Should I
just take out the retry? The retry logic is a little simpler in
tripplite_usb in that reconnect_ups() only gets called in one place
(usb_comm_fail()).

I would almost prefer to have the driver not do any reconnection, but
have the hotplug rule start the driver whenever something is plugged
in (similar to HAL, but not necessarily dependent on it). This
eliminates any polling, and when there is nothing connected, it is
clearly visible to the server. Since USB is more stateful than RS-232,
I think this simplifies a lot of the corner cases.

-- 
- Charles Lepple