[PATCH/RFC] usb: dwc2: awake rt305x USB controller
From: Serge Vasilugin The Ralink uboot sets the USB controller into sleep mode. This patch checks this condition and awakes controller before any register access. Signed-off-by: Serge Vasilugin Signed-off-by: John Crispin --- Hi, we have been carrying this patch inside OpenWrt for half a decade. The USB driver that is included in the Ralink SDK does a mdelay(25) after this call but it works without apparently. John drivers/usb/dwc2/platform.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c index 4c0819554bcd..0bc9fd65e29e 100644 --- a/drivers/usb/dwc2/platform.c +++ b/drivers/usb/dwc2/platform.c @@ -419,6 +419,10 @@ static int dwc2_driver_probe(struct platform_device *dev) if (retval) return retval; + /* Enable USB port before any regs access */ + if (dwc2_readl(hsotg->regs + PCGCTL) & 0x0f) + dwc2_writel(0x00, hsotg->regs + PCGCTL); + retval = dwc2_get_dr_mode(hsotg); if (retval) goto error; -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: f_fs: Only return delayed status when len is 0
On Thu, Jul 19, 2018 at 08:48:32AM +0300, Felipe Balbi wrote:
>
> 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 transfer
> > is not completed until the user responds. However, when the
> > length is 0, there is no data stage and the transfer is
> > finished once setup() returns, hence there is a need to
> > explicitly delay completion.
> >
> > This manifests as the following bugs:
> >
> > Prior to 946ef68ad4e4 ('Let setup() return
> > USB_GADGET_DELAYED_STATUS'), when setup is 0 bytes, ffs
> > would require user to queue a 0 byte request in order to
> > clear setup state. However, that 0 byte request was actually
> > not needed and would hang and cause errors in other setup
> > requests.
> >
> > After the above commit, 0 byte setups work since the gadget
> > now accepts empty queues to ep0 to clear the delay, but all
> > other setups hang.
> >
> > Fixes: 946ef68ad4e4 ("Let setup() return USB_GADGET_DELAYED_STATUS")
> > Signed-off-by: Jerry Zhang
>
> Greg, can you pick this one manually?
>
> Acked-by: Felipe Balbi
Yes, I'll pick it up, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: core: handle hub C_PORT_OVER_CURRENT condition
On Thu, 19 Jul 2018, Bin Liu wrote:
> Based on USB2.0 Spec Section 11.12.5,
>
> "If a hub has per-port power switching and per-port current limiting,
> an over-current on one port may still cause the power on another port
> to fall below specific minimums. In this case, the affected port is
> placed in the Power-Off state and C_PORT_OVER_CURRENT is set for the
> port, but PORT_OVER_CURRENT is not set."
>
> so let's check C_PORT_OVER_CURRENT too for over current condition.
>
> Fixes: 08d1dec6f405 ("usb:hub set hub->change_bits when over-current happens")
> Cc:
> Tested-by: Alessandro Antenucci
> Signed-off-by: Bin Liu
> ---
> drivers/usb/core/hub.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index fcae521df29b..1fb266809966 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1142,10 +1142,14 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
>
> if (!udev || udev->state == USB_STATE_NOTATTACHED) {
> /* Tell hub_wq to disconnect the device or
> - * check for a new connection
> + * check for a new connection or over current condition.
> + * Based on USB2.0 Spec Section 11.12.5,
> + * C_PORT_OVER_CURRENT could be set while
> + * PORT_OVER_CURRENT is not. So check for any of them.
>*/
> if (udev || (portstatus & USB_PORT_STAT_CONNECTION) ||
> - (portstatus & USB_PORT_STAT_OVERCURRENT))
> + (portstatus & USB_PORT_STAT_OVERCURRENT) ||
> + (portchange & USB_PORT_STAT_C_OVERCURRENT))
> set_bit(port1, hub->change_bits);
>
> } else if (portstatus & USB_PORT_STAT_ENABLE) {
Acked-by: Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: xhci: Fix memory leak in xhci_endpoint_reset()
From: Zheng Xiaowei
If td_list is not empty the cfg_cmd will not be freed,
call xhci_free_command to free it.
Signed-off-by: Zheng Xiaowei
Cc:
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2f4850f..68e6132 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3051,6 +3051,7 @@ static void xhci_endpoint_reset(struct usb_hcd *hcd,
if (!list_empty(&ep->ring->td_list)) {
dev_err(&udev->dev, "EP not empty, refuse reset\n");
spin_unlock_irqrestore(&xhci->lock, flags);
+ xhci_free_command(xhci, cfg_cmd);
goto cleanup;
}
xhci_queue_stop_endpoint(xhci, stop_cmd, udev->slot_id, ep_index, 0);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] xhci fix for usb-linus
Hi Greg Thanks for picking up xhci patches while I've been away This one small fix could be added to usb-linus still. -Mathias Zheng Xiaowei (1): usb: xhci: Fix memory leak in xhci_endpoint_reset() drivers/usb/host/xhci.c | 1 + 1 file changed, 1 insertion(+) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
we provide editing
Hi, We provide image editing services like - photo cut out; photo clipping path; photo masking; photo shadow creation; photo color correction; photo retouching; beauty model retouching on skin, face, body; glamour retouching; products retouching and other image editing. We are also offering to deliver testing for you, so that you get to know our quality first hand. If you want to explore further, please reply back. Thanks and Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 1/2] dwc3: Describe 'wakeup_work' field of struct dwc3_pci
Describe 'wakeup_work' field of struct dwc3_pci to avoid a warning:
drivers/usb/dwc3/dwc3-pci.c:59: warning: Function parameter or member
'wakeup_work' not described in 'dwc3_pci'
Signed-off-by: Andy Shevchenko
---
drivers/usb/dwc3/dwc3-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index f57e7c94b8e5..3958b7ae6588 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -47,6 +47,7 @@
* @pci: our link to PCI bus
* @guid: _DSM GUID
* @has_dsm_for_pm: true for devices which need to run _DSM on runtime PM
+ * @wakeup_work: work for asynchronous resume
*/
struct dwc3_pci {
struct platform_device *dwc3;
--
2.18.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 2/2] dwc3: Supply device properties via driver data
For now all PCI enumerated dwc3 devices require some properties
to be present. This allows us to unconditionally append them and supply
via driver_data.
No functional change intended.
Signed-off-by: Andy Shevchenko
---
drivers/usb/dwc3/dwc3-pci.c | 145 +++-
1 file changed, 61 insertions(+), 84 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 3958b7ae6588..9d3fff91e1bc 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -68,52 +68,45 @@ static const struct acpi_gpio_mapping acpi_dwc3_byt_gpios[]
= {
{ },
};
+static const struct property_entry dwc3_pci_synopsys_properties[] = {
+ PROPERTY_ENTRY_BOOL("snps,usb3_lpm_capable"),
+ PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
+ PROPERTY_ENTRY_BOOL("snps,dis_enblslpm_quirk"),
+ PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
+ {}
+};
+
+static const struct property_entry dwc3_pci_intel_properties[] = {
+ PROPERTY_ENTRY_STRING("dr_mode", "peripheral"),
+ PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
+ {}
+};
+
+static const struct property_entry dwc3_pci_amd_properties[] = {
+ PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
+ PROPERTY_ENTRY_U8("snps,lpm-nyet-threshold", 0xf),
+ PROPERTY_ENTRY_BOOL("snps,u2exit_lfps_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,u2ss_inp3_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,req_p1p2p3_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,del_p1p2p3_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,del_phy_power_chg_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,lfps_filter_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,rx_detect_poll_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,tx_de_emphasis_quirk"),
+ PROPERTY_ENTRY_U8("snps,tx_de_emphasis", 1),
+ /* FIXME these quirks should be removed when AMD NL tapes out */
+ PROPERTY_ENTRY_BOOL("snps,disable_scramble_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,dis_u3_susphy_quirk"),
+ PROPERTY_ENTRY_BOOL("snps,dis_u2_susphy_quirk"),
+ PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
+ {}
+};
+
static int dwc3_pci_quirks(struct dwc3_pci *dwc)
{
- struct platform_device *dwc3 = dwc->dwc3;
struct pci_dev *pdev = dwc->pci;
- if (pdev->vendor == PCI_VENDOR_ID_AMD &&
- pdev->device == PCI_DEVICE_ID_AMD_NL_USB) {
- struct property_entry properties[] = {
- PROPERTY_ENTRY_BOOL("snps,has-lpm-erratum"),
- PROPERTY_ENTRY_U8("snps,lpm-nyet-threshold", 0xf),
- PROPERTY_ENTRY_BOOL("snps,u2exit_lfps_quirk"),
- PROPERTY_ENTRY_BOOL("snps,u2ss_inp3_quirk"),
- PROPERTY_ENTRY_BOOL("snps,req_p1p2p3_quirk"),
- PROPERTY_ENTRY_BOOL("snps,del_p1p2p3_quirk"),
- PROPERTY_ENTRY_BOOL("snps,del_phy_power_chg_quirk"),
- PROPERTY_ENTRY_BOOL("snps,lfps_filter_quirk"),
- PROPERTY_ENTRY_BOOL("snps,rx_detect_poll_quirk"),
- PROPERTY_ENTRY_BOOL("snps,tx_de_emphasis_quirk"),
- PROPERTY_ENTRY_U8("snps,tx_de_emphasis", 1),
- /*
-* FIXME these quirks should be removed when AMD NL
-* tapes out
-*/
- PROPERTY_ENTRY_BOOL("snps,disable_scramble_quirk"),
- PROPERTY_ENTRY_BOOL("snps,dis_u3_susphy_quirk"),
- PROPERTY_ENTRY_BOOL("snps,dis_u2_susphy_quirk"),
- PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
- { },
- };
-
- return platform_device_add_properties(dwc3, properties);
- }
-
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
- int ret;
-
- struct property_entry properties[] = {
- PROPERTY_ENTRY_STRING("dr_mode", "peripheral"),
- PROPERTY_ENTRY_BOOL("linux,sysdev_is_parent"),
- { }
- };
-
- ret = platform_device_add_properties(dwc3, properties);
- if (ret < 0)
- return ret;
-
if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
pdev->device == PCI_DEVICE_ID_INTEL_BXT_M) {
guid_parse(PCI_INTEL_BXT_DSM_GUID, &dwc->guid);
@@ -122,6 +115,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
if (pdev->device == PCI_DEVICE_ID_INTEL_BYT) {
struct gpio_desc *gpio;
+ int ret;
ret = devm_acpi_dev_add_driver_gpios(&pdev->dev,
acpi_dwc3_byt_gpios);
@@ -152,21 +146,6 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
}
}
- if (pdev->vendor
[GIT PULL] USB-serial updates for v4.19-rc1
The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.19-rc1 for you to fetch changes up to c8acfe0aadbeb78f65826959891be15cc0a709a3: USB: serial: cp210x: implement GPIO support for CP2102N (2018-07-20 18:22:52 +0200) USB-serial updates for v4.19-rc1 Here are the USB-serial updates for 4.19-rc1, including: - gpio support for CP2102N devices - improved line-speed handling for cp210x - conversion to spin_lock_irqsave() in completion handlers - dropped kl5kusb105 support from the kl5kusb105 driver (sic!) Included are also various lower-priority fixes and clean ups. All but the final commit have been in linux-next, and with no reported issues. Signed-off-by: Johan Hovold Chengguang Xu (1): USB: serial: cast sizeof() to int when comparing with error code Colin Ian King (1): USB: serial: mos7720: remove redundant variables iflag, mask and serial Johan Hovold (11): USB: serial: digi_acceleport: rename tty flag variable USB: serial: kobil_sct: fix modem-status error handling USB: serial: kobil_sct: add missing version error handling USB: serial: kl5kusb105: remove KLSI device id USB: serial: clean up kl5kusb105 documentation USB: serial: iuu_phoenix: drop unused driver-data baud rate USB: serial: iuu_phoenix: drop redundant input-speed re-encoding USB: serial: cp210x: make line-speed quantisation data driven USB: serial: cp210x: honour device-type maximum line speed USB: serial: cp210x: generalise CP2102N line-speed handling USB: serial: cp210x: improve line-speed handling for CP2104 and CP2105 John Ogness (12): USB: serial: cyberjack: use irqsave() in USB's complete callback USB: serial: digi_acceleport: use irqsave() in USB's complete callback USB: serial: io_edgeport: use irqsave() in USB's complete callback USB: serial: io_ti: use irqsave() in USB's complete callback USB: serial: mos7720: use irqsave() in USB's complete callback USB: serial: mos7840: use irqsave() in USB's complete callback USB: serial: quatech2: use irqsave() in USB's complete callback USB: serial: sierra: fix potential deadlock at close USB: serial: sierra: use irqsave() in USB's complete callback USB: serial: symbolserial: use irqsave() in USB's complete callback USB: serial: ti_usb_3410_5052: use irqsave() in USB's complete callback USB: serial: usb_wwan: use irqsave() in USB's complete callback Karoly Pados (2): USB: serial: cp210x: improve baudrate support for CP2102N USB: serial: cp210x: implement GPIO support for CP2102N Documentation/usb/usb-serial.txt | 9 - drivers/usb/serial/cp210x.c | 421 +++--- drivers/usb/serial/cyberjack.c| 17 +- drivers/usb/serial/digi_acceleport.c | 35 +-- drivers/usb/serial/io_edgeport.c | 17 +- drivers/usb/serial/io_ti.c| 5 +- drivers/usb/serial/ir-usb.c | 2 +- drivers/usb/serial/iuu_phoenix.c | 5 - drivers/usb/serial/kl5kusb105.c | 1 - drivers/usb/serial/kl5kusb105.h | 3 - drivers/usb/serial/kobil_sct.c| 24 +- drivers/usb/serial/mos7720.c | 14 +- drivers/usb/serial/mos7840.c | 5 +- drivers/usb/serial/quatech2.c | 7 +- drivers/usb/serial/sierra.c | 13 +- drivers/usb/serial/ssu100.c | 2 +- drivers/usb/serial/symbolserial.c | 5 +- drivers/usb/serial/ti_usb_3410_5052.c | 9 +- drivers/usb/serial/usb_wwan.c | 5 +- 19 files changed, 431 insertions(+), 168 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB-serial updates for v4.19-rc1
On Fri, Jul 20, 2018 at 06:56:11PM +0200, Johan Hovold wrote: > The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: > > Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.19-rc1 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
we provide editing
Hi, We provide image editing services like - photo cut out; photo clipping path; photo masking; photo shadow creation; photo color correction; photo retouching; beauty model retouching on skin, face, body; glamour retouching; products retouching and other image editing. We are also offering to deliver testing for you, so that you get to know our quality first hand. If you want to explore further, please reply back. Thanks and Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usbip: Fix misuse of strncpy()
gcc 8 reports: usbip_device_driver.c: In function ‘read_usb_vudc_device’: usbip_device_driver.c:106:2: error: ‘strncpy’ specified bound 256 equals destination size [-Werror=stringop-truncation] strncpy(dev->path, path, SYSFS_PATH_MAX); ^~~~ usbip_device_driver.c:125:2: error: ‘strncpy’ specified bound 32 equals destination size [-Werror=stringop-truncation] strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE); ^~~~ I'm not convinced it makes sense to truncate the copied strings here, but since we're already doing so let's ensure they're still null- terminated. We can't easily use strlcpy() here, so use snprintf(). usbip_common.c has the same problem. Signed-off-by: Ben Hutchings Cc: sta...@vger.kernel.org --- tools/usb/usbip/libsrc/usbip_common.c|4 ++-- tools/usb/usbip/libsrc/usbip_device_driver.c |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) --- a/tools/usb/usbip/libsrc/usbip_common.c +++ b/tools/usb/usbip/libsrc/usbip_common.c @@ -226,8 +226,8 @@ int read_usb_device(struct udev_device * path = udev_device_get_syspath(sdev); name = udev_device_get_sysname(sdev); - strncpy(udev->path, path, SYSFS_PATH_MAX); - strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE); + snprintf(udev->path, SYSFS_PATH_MAX, "%s", path); + snprintf(udev->busid, SYSFS_BUS_ID_SIZE, "%s", name); sscanf(name, "%u-%u", &busnum, &devnum); udev->busnum = busnum; --- a/tools/usb/usbip/libsrc/usbip_device_driver.c +++ b/tools/usb/usbip/libsrc/usbip_device_driver.c @@ -103,7 +103,7 @@ int read_usb_vudc_device(struct udev_dev copy_descr_attr16(dev, &descr, idProduct); copy_descr_attr16(dev, &descr, bcdDevice); - strncpy(dev->path, path, SYSFS_PATH_MAX); + snprintf(dev->path, SYSFS_PATH_MAX, "%s", path); dev->speed = USB_SPEED_UNKNOWN; speed = udev_device_get_sysattr_value(sdev, "current_speed"); @@ -122,7 +122,7 @@ int read_usb_vudc_device(struct udev_dev dev->busnum = 0; name = udev_device_get_sysname(plat); - strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE); + snprintf(dev->busid, SYSFS_BUS_ID_SIZE, "%s", name); return 0; err: fclose(fd); signature.asc Description: Digital signature
RFC on OTi-2108 USB Data Link cable driver implementation
Hi, This device presents itself as an USB CD Drive, and extends that "metaphor" (kinda) to how it transfers data (= ethernet frames in our case) between hosts. That is one SCSI vendor command (0xD8) over bulk-only mass-storage is used to poll whether data is available and another one (0xD9) is used to transfer the data. Yes, this is not good but the hardware is what it is. The question is, if i were to implement a driver for this, which is the better option: 1) Make a driver that (ab)uses the kernel SCSI and usb mass storage drivers to do the transfers. or 2) Make a driver that contains a minimal set of usb mass storage bulk transfer code to do what is needed for this device. If you answer 1, I'd like to know the appropriate API layer to hook into, and how to probe for the device and such... Second case is in many ways much simpler (though I'm not sure if i need to detach the mass storage driver from the device in some way), but duplicates some amount of code. Please CC me in any replies to this thread. Extra context information: I bought this device for cheap expecting it to work as an usb network cable in linux. It doesn't, but if i have the spare cycles i might just make it happen. I found a driver online for windows 7 that makes it present the cable as a "virtual" network card, and I was able to capture usb traces from that already. The usb ID is 0ea0:2108, though the windows driver also supports some other OTi host-to-host chips (like the apparently newer 2208) so maybe one day a linux driver might too... (This message was already sent to the LKML, but i got a suggestion to try here, so sorry if you got it twice.) -- Urja Rannikko -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/29] usb: usbtmc: Support Read Status Byte with SRQ per file
On Wed, Jul 18, 2018 at 10:45:34AM +0200, Guido Kiener wrote: > } > - dev_warn(dev, "invalid notification: %x\n", > data->iin_buffer[0]); > + dev_warn(dev, "invalid notification: %x\n", > + data->iin_buffer[0]); > break; > case -EOVERFLOW: > dev_err(dev, "overflow with length %d, actual length is %d\n", > @@ -1295,6 +1369,7 @@ static void usbtmc_interrupt(struct urb *urb) > case -ESHUTDOWN: > case -EILSEQ: > case -ETIME: > + case -EPIPE: > /* urb terminated, clean up */ > dev_dbg(dev, "urb terminated, status: %d\n", status); > return; Minor nit, these two changes didn't have anything to do with the larger patch. I'll let them slide for now, but please be more careful in the future. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/29] usb: usbtmc: Add ioctls to set/get usb timeout
On Wed, Jul 18, 2018 at 10:45:36AM +0200, Guido Kiener wrote:
> +/*
> + * Set the usb timeout value
> + */
> +static int usbtmc_ioctl_set_timeout(struct usbtmc_file_data *file_data,
> + void __user *arg)
> +{
> + u32 timeout;
> +
> + if (get_user(timeout, (__u32 __user *)arg))
> + return -EFAULT;
> +
> + /* Note that timeout = 0 means
> + * MAX_SCHEDULE_TIMEOUT in usb_control_msg
> + */
> + if (timeout < USBTMC_MIN_TIMEOUT)
> + return -EINVAL;
No max timeout limit? That feels odd, but ok, it's your api, you might
be waiting a long time :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/29] usb: usbtmc: Add ioctl for generic requests on control
On Wed, Jul 18, 2018 at 10:45:41AM +0200, Guido Kiener wrote:
> 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
> ---
> drivers/usb/class/usbtmc.c | 151 +++
> include/uapi/linux/usb/tmc.h | 15
> 2 files changed, 166 insertions(+)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index d685db78b80b..846599dd0c84 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2007 Stefan Kopp, Gechingen, Germany
> * Copyright (C) 2008 Novell, Inc.
> * Copyright (C) 2008 Greg Kroah-Hartman
> + * Copyright (C) 2018 IVI Foundation, Inc.
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -36,6 +37,9 @@
> /* Default USB timeout (in milliseconds) */
> #define USBTMC_TIMEOUT 5000
>
> +/* I/O buffer size used in generic read/write functions */
> +#define USBTMC_BUFSIZE (4096)
> +
> /*
> * Maximum number of read cycles to empty bulk in endpoint during CLEAR and
> * ABORT_BULK_IN requests. Ends the loop if (for whatever reason) a short
> @@ -126,6 +130,17 @@ struct usbtmc_file_data {
> bool term_char_enabled;
> };
>
> +#ifdef CONFIG_COMPAT
> +
> +struct compat_usbtmc_ctrlrequest {
> + struct usbtmc_request req;
> + compat_uptr_t data;
> +} __packed;
Wait, why? You are creating a new api here, why do you need a 32bit
compat layer? Just create it in a way that works for both layouts.
Just make your pointer a 64bit value and cast it to the pointer when
using it. Other ioctls do this in lots of places, making things simpler
overall. That way you don't need an ioctl compat call at all.
Please rework the code that way, don't create new apis that have to add
"old" 32bit compatibility support to them. That's just extra work you
don't need to do here.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 09/29] usb: usbtmc: Add ioctl for vendor specific write
On Wed, Jul 18, 2018 at 10:45:42AM +0200, Guido Kiener wrote:
> 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 flag USBTMC_FLAG_APPEND additional urbs are queued and
> out_status/out_transfer_size is not reset. EPOLLOUT | EPOLLWRNORM
> is signaled when all submitted urbs are completed.
>
> Flush flying urbs when file handle is closed or device is
> suspended or reset.
>
> Signed-off-by: Guido Kiener
> Reviewed-by: Steve Bayless
> ---
> drivers/usb/class/usbtmc.c | 416 ++-
> include/uapi/linux/usb/tmc.h | 14 ++
> 2 files changed, 428 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> index 846599dd0c84..c46280f53f39 100644
> --- a/drivers/usb/class/usbtmc.c
> +++ b/drivers/usb/class/usbtmc.c
> @@ -37,6 +37,8 @@
> /* Default USB timeout (in milliseconds) */
> #define USBTMC_TIMEOUT 5000
>
> +/* Max number of urbs used in write transfers */
> +#define MAX_URBS_IN_FLIGHT 16
> /* I/O buffer size used in generic read/write functions */
> #define USBTMC_BUFSIZE (4096)
>
> @@ -125,9 +127,19 @@ struct usbtmc_file_data {
> u32timeout;
> u8 srq_byte;
> atomic_t srq_asserted;
> +
> u8 eom_val;
> u8 term_char;
> bool term_char_enabled;
> +
> + spinlock_t err_lock; /* lock for errors */
> +
> + struct usb_anchor submitted;
> +
> + /* data for generic_write */
> + struct semaphore limit_write_sem;
> + u32 out_transfer_size;
> + int out_status;
> };
>
> #ifdef CONFIG_COMPAT
> @@ -137,12 +149,21 @@ struct compat_usbtmc_ctrlrequest {
> compat_uptr_t data;
> } __packed;
>
> +struct compat_usbtmc_message {
> + __u32 transfer_size;
> + __u32 transferred;
> + __u32 flags;
> + compat_uptr_t message;
> +} __packed;
Same here, no need for this at all.
I've stopped reviewing in the series here. I've applied the first 6
patches in the series, please rework the remaining ones to not have any
compatibility ioctls needed and resend. Or you can restructure what you
already have and resend everything without the new ioctls so I can
review/take them if you need more time to redo the ioctls stuff.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
