[Nut-upsdev] megatec over USB - using Andrey Lelikov's approach

Kjell Claesson kjell.claesson at epost.tidanet.se
Sun Dec 31 22:11:45 CET 2006

sön 2006-12-31 klockan 21:23 +0100 skrev Arjen de Korte:
> > I would not give it quite as generic a name as serial_usb.o, because
> > it only implements one of several proprietary serial-over-USB
> > methods. We might support others in the future. How about a naming
> > scheme such as serial_usb_xxx.o, where xxx is some descriptor for the
> > particular method used.
> I agree. In retrospect, it's probably best to 'reserve' serial_usb.o until
> we have something that is really generic and can be used for every method
> we can think off. I don't think there will be too many ways to do
> serial-over-usb, so this should be manageable in the future. Until we can
> merge these different methods in one serial-over-usb API, they should have
> different names.

I also agree with what you have ventilated.

But, nut_usb.c is more or less generic. The only thing it contains that
make it 'bound' to the bcmxcp_usb is the  *open_powerware_usb.

The function nutusb_open is called from the powerware_usb.c then in 
that function the open_powerware_usb is called, this check the vendor 
and product code.

I think this should be that the driver (powerware_usb.c) that contains 
code that is not usable by other drivers like megatech, call this
nutusb_open with an argument, that identify it as powerware.

By rewriting the nutusb_open to handle the ups'es that use 
serial-over-usb, it could be made generic for the register and
sending data. ( That is if the usb_set_descriptor is usable for
all drivers.)

Have not done any deeper thinking about this, so it's OK to flame me.

My time has been limited, but i try to keep up with reading the

Regards and a Happy new year to you all.


More information about the Nut-upsdev mailing list