Hi,
Jerry Zhang writes:
> Commit 1b9ba000 ("Allow function drivers to pause control
> transfers") states that USB_GADGET_DELAYED_STATUS is only
> supported if data phase is 0 bytes.
>
> It seems that when the length is not 0 bytes, there is no
> need to explicitly delay the data stage since the
Hi Felipe,
Can we get this patch into 4.19-rc6? The patch is simple and well
understood and solves a real problem -- functionfs control requests
will not work without it.
Thanks,
Jerry
On Mon, Jul 2, 2018 at 12:48 PM Jerry Zhang wrote:
>
> Commit 1b9ba000 ("Allow function drivers to pause
On Wed, Jul 18, 2018 at 03:26:30PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 18, 2018 at 02:25:01PM +0200, Johan Hovold wrote:
> > CP2104 and the ECI interface of CP2105 support further baud rates than
> > the ones specified in AN205 table 1, and we can use the same equations
> > as for
As all the properties of the usbtmc driver can now be
controlled on a per file descriptor basis by ioctl functions
the sysfs interface is of limited use.
We are not aware about applications that are using the sysfs
parameter TermChar, TermCharEnabled or auto_abort.
Signed-off-by: Guido Kiener
Remove redundant code and fix debug messages.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 25 -
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index 2827969ccc11..821f3e47b6b3 100644
--- a/drivers/usb/class/usbtmc.c
+++
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
index dc4f7706b4c2..2827969ccc11 100644
--- a/drivers/usb/class/usbtmc.c
+++
Reserve a suitable range of ioctl numbers for USBTMC driver.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
Documentation/ioctl/ioctl-number.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ioctl/ioctl-number.txt
Add ioctl USBTMC_IOCTL_API_VERSION to get current API version
of usbtmc driver.
This is to allow an instrument library to determine whether
the driver API is compatible with the implementation.
The API may change in future versions. Therefore the macro
USBTMC_API_VERSION should be incremented
On Fri, Jul 13, 2018 at 04:35:33PM -0400, Alan Stern wrote:
> On Fri, 13 Jul 2018, Bin Liu wrote:
>
> > Hi,
> >
> > I got a report saying that when overcurrent happens in one of the hub
> > downstream ports, USB_PORT_STAT_OVERCURRENT is not set in portstatus,
> > instead
On Wed, Jul 18, 2018 at 02:25:01PM +0200, Johan Hovold wrote:
> CP2104 and the ECI interface of CP2105 support further baud rates than
> the ones specified in AN205 table 1, and we can use the same equations
> as for CP2102N to determine and report back the actual baud rates used.
>
> Note that
On Wed, Jul 18, 2018 at 02:24:59PM +0200, Johan Hovold wrote:
> From: Karoly Pados
>
> CP2102N devices support a lot more baudrates than earlier chips by
> SiLabs. These devices are not constrained anymore by the table in AN205,
> and are able to generate almost any baudrate in the supported
On Wed, Jul 18, 2018 at 02:25:00PM +0200, Johan Hovold wrote:
> The CP2102N equations for determining the actual baud rate can be used
> also for other device types, so let's factor it out.
>
> Note that this removes the now unused cp210x_is_cp2102n() helper.
>
> Signed-off-by: Johan Hovold
>
On Wed, Jul 18, 2018 at 02:24:58PM +0200, Johan Hovold wrote:
> Newer cp210x devices support higher line speeds than the older ones
> which supported a discrete set of speeds up to 921.6 kbaud.
>
> To support these higher speeds, we have for some time mapped speeds
> lower than 1 Mbaud to the
On Wed, Jul 18, 2018 at 02:24:57PM +0200, Johan Hovold wrote:
> Older cp210x devices only support a fixed set of line speeds to which a
> requested speed is mapped. Reimplement this mapping using a table
> instead of a long if-else construct.
>
> Signed-off-by: Johan Hovold
> ---
>
On Wed, Jul 18, 2018 at 3:37 PM, Johan Hovold wrote:
> On Wed, Jul 18, 2018 at 03:34:34PM +0300, Andy Shevchenko wrote:
>> On Wed, Jul 18, 2018 at 3:25 PM, Johan Hovold wrote:
>> Looks like ping-pong type of changes.
>> I think the factoring of this particular piece of code can be done in
>>
On Wed, Jul 18, 2018 at 03:34:34PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 18, 2018 at 3:25 PM, Johan Hovold wrote:
> > The CP2102N equations for determining the actual baud rate can be used
> > also for other device types, so let's factor it out.
> >
> > Note that this removes the now unused
On Wed, Jul 18, 2018 at 3:25 PM, Johan Hovold wrote:
> The CP2102N equations for determining the actual baud rate can be used
> also for other device types, so let's factor it out.
>
> Note that this removes the now unused cp210x_is_cp2102n() helper.
> +static speed_t
This was all triggered by a patch from Karoly to enable line-speeds
higher than 2 Mbaud for CP2102N devices.
The end result is support for further baud rates for CP2104, CP2105 and
CP2102N devices with the actual baud rates used now being properly
reported back to user space.
Johan
Johan
Newer cp210x devices support higher line speeds than the older ones
which supported a discrete set of speeds up to 921.6 kbaud.
To support these higher speeds, we have for some time mapped speeds
lower than 1 Mbaud to the speeds supported by older devices, while
allowing the device to pick the
CP2104 and the ECI interface of CP2105 support further baud rates than
the ones specified in AN205 table 1, and we can use the same equations
as for CP2102N to determine and report back the actual baud rates used.
Note that this could eventually be generalised also to CP2108, which
uses a
The CP2102N equations for determining the actual baud rate can be used
also for other device types, so let's factor it out.
Note that this removes the now unused cp210x_is_cp2102n() helper.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 50 -
Older cp210x devices only support a fixed set of line speeds to which a
requested speed is mapped. Reimplement this mapping using a table
instead of a long if-else construct.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/cp210x.c | 99 +
1 file changed,
From: Karoly Pados
CP2102N devices support a lot more baudrates than earlier chips by
SiLabs. These devices are not constrained anymore by the table in AN205,
and are able to generate almost any baudrate in the supported range
with only minimal errors. This has also been verified with a scope on
Hi Karoly,
and sorry for not getting back to you sooner on this.
On Thu, Jul 05, 2018 at 04:12:17PM +, Karoly Pados wrote:
> Hi,
>
> > Karoly, how did your line-speed tests with cp2102n go?
>
> I indeed tested this. I first built a version of the module where I skip
> calling
To allow applications to determine the status and progress of
the last asynchronous USBTMC_IOCTL_WRITE call, the ioctl
USBTMC_IOCTL_WRITE_RESULT copies the current out_transfer_size
to the provided __u32 pointer and returns current out_status.
Signed-off-by: Guido Kiener
Reviewed-by: Steve
- use consistent error value ETIMEOUT instead of ETIME
Tested-by: Dave Penkler
Reviewed-by: Steve Bayless
Signed-off-by: Guido Kiener
---
drivers/usb/class/usbtmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
Add ioctl USBTMC_IOCTL_AUTO_ABORT to configure auto_abort for
each specific file handle.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 23 ---
include/uapi/linux/usb/tmc.h | 1 +
2 files changed, 17 insertions(+), 7 deletions(-)
Add ioctls USBTMC_IOCTL_GET_TIMEOUT / USBTMC_IOCTL_SET_TIMEOUT to
get/set I/O timeout for specific file handle.
Different operations on an instrument can take different lengths of
time thus it is important to be able to set the timeout slightly
longer than the expected duration of each operation
Add 'struct usbtmc_file_data' for each file handle to cache last
srq_byte (=Status Byte with SRQ) received by usbtmc_interrupt(..)
usbtmc488_ioctl_read_stb returns cached srq_byte when available for
each file handle to avoid race conditions of concurrent applications.
SRQ now sets EPOLLPRI
Use new usbtmc_generic_read function to maximize bandwidth
during long data transfer. Also fix reading of zero length
packet (ZLP) or trailing short packet.
The maximum input transfer size is limited to INT_MAX (=2GB).
Also remove redundant return in send_request_dev_dep_msg_in().
Signed-off-by:
Submitted urbs are not allowed when system is suspended.
Thus the submitted urb waiting at interrupt pipe is killed
during suspend callback and submitted again when system resumes.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 16 +++-
1
Add parameter 'tag' to function usbtmc_ioctl_abort_bulk_out_tag()
for future versions.
Use USBTMC_BUFSIZE (4k) instead of USBTMC_SIZE_IOBUFFER (2k).
Using USBTMC_SIZE_IOBUFFER is deprecated.
Insert a sleep of 50 ms between subsequent
CHECK_ABORT_BULK_OUT_STATUS control requests to avoid
32 bit applications can only call ioctl functions on 64 bit systems
when the field .compat_ioctl is defined for file operations.
Tested-by: Dave Penkler
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 12
1 file changed, 12 insertions(+)
add USBTMC_IOCTL_CONFIG_TERMCHAR to control TermChar handling
for next read(). Controls field 'TermChar' and Bit 1 of field
'bmTransferAttributes' of REQUEST_DEV_DEP_MSG_IN BULK-OUT header.
Allows enabling/disabling of terminating a read on reception of
term_char individually for each read
add USBTMC488_IOCTL_TRIGGER to send TRIGGER Bulk-OUT header
according to Subclass USB488 Specification
The usbtmc trigger command is equivalent to the IEEE 488 GET (Group
Execute Trigger) action. While the "*TRG" command can be sent as
data to perform the same operation, in some situations an
The ioctl USBTMC_IOCTL_CLEANUP_IO kills all submitted urbs to OUT
and IN bulk, and clears all received data from IN bulk. Internal
transfer counters and error states are reset.
An application should use this ioctl after an asnychronous transfer
was canceled and/or error handling has finished.
ioctl USBTMC_IOCTL_CANCEL_IO stops and kills all flying urbs of
last USBTMC_IOCTL_READ and USBTMC_IOCTL_WRITE function calls.
A subsequent call to USBTMC_IOCTL_READ or
USBTMC_IOCTL_WRITE_RESULT returns -ECANCELED with
information about current transferred data.
Signed-off-by: Guido Kiener
The new ioctl USBTMC_IOCTL_WRITE sends a generic message to bulk OUT.
This ioctl is used for vendor specific or asynchronous I/O as well.
The message is split into chunks of 4k (page size).
Message size is aligned to 32 bit boundaries.
With flag USBTMC_FLAG_ASYNC the ioctl is non blocking.
With
Use common timeout macro USB_CTRL_GET_TIMEOUT (=5s) for all
usb_control_msg() function calls.
The macro USBTMC_TIMEOUT should only be used as default value for
Bulk IN/OUT transfers.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 8
1 file
Wait until an SRQ (service request) is received on the interrupt pipe
or until the given period of time is expired. In contrast to the
poll() function this ioctl does not return when other (a)synchronous
I/O operations fail with EPOLLERR.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
Use new usbtmc_generic_write function to maximize bandwidth
during long data transfer.
The maximum output transfer size is limited to INT_MAX (=2GB).
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
---
drivers/usb/class/usbtmc.c | 176 +++--
1 file
Remove calculation of max_size (=wMaxPacketSize) and wrong
condition (actual == max_size) in while loop. A device clear
should always flush the complete Bulk-IN FIFO.
Insert a sleep of 50 ms between subsequent CHECK_CLEAR_STATUS
control requests to avoid stressing the instrument with
repeated
Add USBTMC_IOCTL_CTRL_REQUEST to send arbitrary requests on the
control pipe. Used by specific applications of IVI Foundation,
Inc. to implement VISA API functions: viUsbControlIn/Out.
The maximum length of control request is set to 4k.
Signed-off-by: Guido Kiener
Reviewed-by: Steve Bayless
Add parameter 'tag' to function usbtmc_ioctl_abort_bulk_in_tag()
for future versions.
Remove calculation of max_size (=wMaxPacketSize) and wrong
condition (actual == max_size) in while loop. An abort operation
should always flush the complete Bulk-IN until a short packet is
received.
Return
add USBTMC_IOCTL_EOM_ENABLE to specify EOM bit for next write()
call. Sets Bit 0 of field 'bmTransferAttributes' of DEV_DEP_MSG_OUT
Bulk-OUT Header.
Allows fine grained control over end of message handling on a
per file descriptor basis.
Reviewed-by: Steve Bayless
Tested-by: Dave Penkler
The USBTMC_IOCTL_READ call provides for generic synchronous and
asynchronous reads on bulk IN to implement vendor specific library
routines.
Depending on transfer_size the function submits one or more urbs (up
to 16) each with a size of up to 4kB.
The flag USBTMC_FLAG_IGNORE_TRAILER can be used
The working group "VISA for Linux" of the IVI Foundation
www.ivifoundation.org specifies common rules, shared libraries and
drivers to implement the specification of "VPP-4.3: The VISA Library"
on Linux to be compatible with implementations on other operating systems.
The USBTMC protocol is part
add ioctl USBTMC_IOCTL_MSG_IN_ATTR that returns the specific
bmTransferAttributes field of the last DEV_DEP_MSG_IN Bulk-IN
header. This header is received by the read() function. The
meaning of the (u8) bitmap bmTransferAttributes is:
Bit 0 = EOM flag is set when the last transfer of a USBTMC
The TPL support is used to identify targeted devices during
EH2.0 and EH3.0 certification test, the user can add "tpl-support"
at dts to enable this feature.
Signed-off-by: Peter Chen
---
drivers/usb/host/xhci-plat.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
50 matches
Mail list logo
