RE: usb: usbtmc: Proposal for new ioctl functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Greg,

Before sending patches we want to be sure doing  the right things. I'm not sure how we should deal with the sysfs parameters for USBTMC devices:
See https://github.com/torvalds/linux/blob/master/Documentation/ABI/stable/sysfs-driver-usb-usbtmc
There are some parameters defined for each device instance: TermChar, TermCharEnabled, and auto_abort.
The new driver should include ioctl functions to change these parameters for each file handle and not for each device instance.
So we could reassign the device instance parameters (TermChar, TermCharEnabled) to be default values for each file handle.
Furthermore the new driver will have more ioctl functions to change timeout and EOM flag,
Here are my questions:
1. Are there any (test) scripts that are using the sysfs parameters TermChar, TermCharEnabled where we can check that the new driver is doing the same things?
2. Shall we add new sysfs parameters for timeout and EOM flag? (ioctls are already added)
3. Is there any rule when to use upper/lower case or underscore for these parameters (e.g. Timeout, EOM or end_of_message)?

Well, I'm quite happy with the performance of the new ioctl functions for generic read/write and I don't want to start a lengthy discussion here.
However I need some expert knowledge and hints about the following questions:
1. We can detect short USB packages. A ZLP (Zero Length Package) can happen when the previous package has the maximum packet length.
The driver could be simplified if it would be possible to detect ZLPs. Is there any way (without changing the USB subsystem) to detect ZLPs? 
2. For ultimate performance: Is there any trick where a usb_complete_t function or submitted urb can transfer (copy) received data directly to a userland buffer (e.g. scatter/gather streams) ?

Best regards,

Guido


-----Original Message-----
From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 
Sent: Wednesday, March 28, 2018 7:52 AM
To: Kiener Guido 1DC3 <Guido.Kiener@xxxxxxxxxxxxxxxxx>
Subject: Re: usb: usbtmc: Proposal for new ioctl functions

On Tue, Mar 27, 2018 at 08:57:27PM +0200, Guido.Kiener@xxxxxxxxxxxxxxxxx wrote:
> Hi all,
> 
> This is a follow up mail from the discussion of thread
>  https://marc.info/?l=linux-usb&m=149485247607564&w=2
> 
> Our working group "VISA for Linux" (IVI Foundation, 
> www.ivifoundation.org)
> 
> wants to extend the Linux USBTMC driver 
> (linux/drivers/usb/class/usbtmc.c)
> that can communicate with the T&M instruments.
> 
> To meet our requirements we need some additional ioctl functions that 
> can send control, bulk in/out messages in a generic way.
> 
> Kindly supported by Dave Penkler there is now a github project at 
> https://github.com/dpenkler/linux-usbtmc
> that already supports new functions to set/get timeout, EOM flag (End 
> of Message), and termchar (detection of termination character).
> 
> This project and forked repos are our playground and still under 
> development.
> 
> Our experimental and generic functions are currently developed at the
> fork:
> https://github.com/GuidoKiener/linux-usbtmc
> 
> For a fast read/write we want to implement new generic ioctl functions:
> #define USBTMC_IOCTL_WRITE  _IOWR(USBTMC_IOC_NR, 13, struct
> usbtmc_message)
> #define USBTMC_IOCTL_READ    _IOWR(USBTMC_IOC_NR, 14, struct 
> usbtmc_message)
> #define USBTMC_IOCTL_WRITE_RESULT _IOWR(USBTMC_IOC_NR, 15, __u64) 
> #define USBTMC488_IOCTL_WAIT_SRQ  _IOW(USBTMC_IOC_NR, 23, unsigned int)
> #define USBTMC_IOCTL_CANCEL_IO    _IO(USBTMC_IOC_NR, 35)
> #define USBTMC_IOCTL_CLEANUP_IO   _IO(USBTMC_IOC_NR, 36)
> /* For test purpose only */
> #define USBTMC_IOCTL_SET_OUT_HALT _IO(USBTMC_IOC_NR, 30) #define 
> USBTMC_IOCTL_SET_IN_HALT  _IO(USBTMC_IOC_NR, 31)
> 
> For further description please refer to the readme.md file at 
> https://github.com/GuidoKiener/linux-usbtmc/blob/master/README.md
> 
> Open questions and comments can be just added to the wiki:
> https://github.com/GuidoKiener/linux-usbtmc/wiki
> 
> When our working group is happy with the proposed extensions and the 
> driver tested by several T&M companies then we would like to submit 
> these patches to the Linux kernel.

Great, submit patches like any other developer when you have them ready.
You don't need to do anything special here, that's how Linux is developed. :)

Note, please do not depend on these new apis until _after_ we have merged the patches, as there might be changes required due to the review process finding problems, so please submit changes as soon as possible.

thanks,

greg k-h
��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux