RESEND: Re: Is anyone maintaining (or even using) usbtmc?

[Zimmermann Christoph]

i've asked also some of your questions two month ago.

i'm a tmc driver user only. i use it to develop my firmware for a
cypress fx2 based tmc device.

i've made some bugreporting to greg and to the mailinglist (now i'm not
sure anymore if all my mails arrived on the mailinglist. the gmame
archive does not list all mails. the other archives are even worse).

since then two ore tree small patches are sent to the mailinglist. but
none seemed to adress my bugs (one patch was about a memory leak)

> If the answer is no (as I suspect it is), then I might give fixing it
> a shot the week after next, when I'll be camping out in Virginia with
> this thing for awhile.  In that case, I have another question:

do it. greg is the maintainer of the whole usb stuff and is working
really hard. so i understand that he only has little time on "our"
usbtmc bugs. in my opionion it's good when you do it to help greg with
it. he still is the maintainer and has to sign of your patches.

the other thing is, that i belive, please correct me, that greg don't
has an usbtmc device to test with. for me it seems that there is lack
of testing in the usbtmc driver. thats why i assume this.

as i wrote in my older mails, i've never worked on the kernel source. i
can do some testing with different devices (in our lab we have serveral
tmc devices).

> Is anyone using usbtmc, or, more specifically, does anyone care about
> backward compatibility?

it doesn't look like that. i don't care if the interface changes. i'm
still working with the old agilent one until the mainline one works.

> Finally, I see no way to read the USB488 status byte or detect a
> status interrupt.
>
> >
> >> Is anyone using usbtmc, or, more specifically, does anyone care
> >> about backward compatibility?
> >
> > What do you want to change in the driver interface?
>
> The main compatibility-breaking change is that I'd like to see
> close/reopen go through the whole resynchronization procedure so that
> the device starts in a sane state.  Currently I restore sanity by
> doing a bunch of reads and ignoring ETIMEDOUT.
> If not, then I'll be less careful to preserve the interface, even
> though I'm not really sure that there's much of interest to preserve.

to read the USB488 status byte i guess that there is still an ioctl
function for it (was there in the opensource agilent driver) but you
can get the status byte with a normal "*STB?" query.

the lack of interrupt status reporting is an important one. so you have
to quess, or do stupid polling, until your device is finished working.
the normal way is to set "opc?" and do something else until the
response from the interrupt endpoint arrives.

christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/