Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On 9/30/2014 5:03 AM, Mark Knibbs wrote: Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Hi Mark, I tried to reproduce this issue. I connected a USB key under a full-speed hub. sg_rbuf returns error which I am not familiar with. allen@allen-ivb:~$ lsusb -t [...snip...] /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 4: Dev 11, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 12, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 12, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 15, If 0, Class=Mass Storage, Driver=usb-storage, 12M allen@allen-ivb:~$ sudo dd if=/dev/zero of=/dev/sdb bs=4k count=1k 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.32676 s, 969 kB/s allen@allen-ivb:~$ sudo sg_rbuf --buffer=524288 -q -t -v /dev/sg2 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER descriptor error: SCSI status: Check Condition Fixed format, current; Sense key: Illegal Request Additional sense: Invalid command operation code Thanks, -baolu -- 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: Urb completion handler returns -32
Hi Alan, The device replied with a STALL. The device runs at low speed or full speed and is connected through a USB-2 hub Yes, my device is full speed (12Mbps) device and connected to 2.0 root hub. So how to avoid getting the STALL? I attached the usbmon log and Ellisys USB analyser log. I connected the eight similar devices(USB Bluetooth Dongles) to host and captured the logs. My device numbers are here : Bus 001 Device Numbers (063\066\067\068\069\070\071\072) Usbmon log shows STALL packets for INT in URB completion handler $ tail -f /tmp/1.mon.out | grep C Ii 8800aaedb780 3159611663 C Ii:1:072:1 -32:1 0 880131449cc0 3360277718 C Ii:1:068:1 -32:1 0 8800aaedb9c0 3360278570 C Ii:1:069:1 -32:1 0 880131f52000 3360291656 C Ii:1:067:1 -32:1 0 8800aae88600 3360299542 C Ii:1:068:1 -32:1 0 On receiving the STALL response, work queue got scheduled in INT in URB completion handler for clearing halt condition(used usb_clear_halt() API in that work queue) I enabled “Drop Start of Frames and Keep Alives” “Drop NAK transactions” recording options before taking the Ellisys USB analyser log. I don’t see STALL packet in Ellisys USB analyser log, but only observed in usbmon log. Does it mean, device is not sending the STALL, but only Host controller driver is sending it to my USB device driver? On Mon, Sep 29, 2014 at 7:01 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Sep 2014, Naveen Kumar Parna wrote: Hi All, I want to know the reason for getting INT urb completion status as -EPIPE ? The most common reasons are: The device replied with a STALL. The device runs at low speed or full speed and is connected through a USB-2 hub. Under those conditions, URBs complete with -EPIPE status when the device is disconnected. 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 net] r8152: fix setting RTL8152_UNPLUG
The flag of RTL8152_UNPLUG should only be set when the device is
unplugged, not each time the rtl8152_disconnect() is called.
Otherwise, the device wouldn't be stopped normally.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e039442..f68a4e6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,7 +3576,11 @@ static void rtl8152_disconnect(struct usb_interface
*intf)
usb_set_intfdata(intf, NULL);
if (tp) {
- set_bit(RTL8152_UNPLUG, tp-flags);
+ struct usb_device *udev = tp-udev;
+
+ if (udev-state == USB_STATE_NOTATTACHED)
+ set_bit(RTL8152_UNPLUG, tp-flags);
+
tasklet_kill(tp-tl);
unregister_netdev(tp-netdev);
tp-rtl_ops.unload(tp);
--
1.9.3
--
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: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Tue, 30 Sep 2014 14:10:28 +0800 Lu, Baolu baolu...@linux.intel.com wrote: I tried to reproduce this issue. I connected a USB key under a full-speed hub. sg_rbuf returns error which I am not familiar with. allen@allen-ivb:~$ lsusb -t [...snip...] /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 4: Dev 11, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 12, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 12, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 15, If 0, Class=Mass Storage, Driver=usb-storage, 12M allen@allen-ivb:~$ sudo dd if=/dev/zero of=/dev/sdb bs=4k count=1k 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.32676 s, 969 kB/s allen@allen-ivb:~$ sudo sg_rbuf --buffer=524288 -q -t -v /dev/sg2 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER descriptor error: SCSI status: Check Condition Fixed format, current; Sense key: Illegal Request Additional sense: Invalid command operation code You won't be able to use sg_rbuf. sg_rbuf issues READ BUFFER commands, which most/all USB sticks won't support. Using dd instead should be fine to show the problem. In the USB tree you posted, the hub is connected to a USB 2.0 port and the 969KB/sec dd result looks reasonable. Now try with the USB 1.1 hub connected to a USB 3.0 port. For my testing, I increased the maximum USB transfer size using a command like echo 1024 /sys/block/sdb/device/max_sectors [By default the kernel limits transfers to 120KB (240 512-byte sectors), presumably because some devices break with larger ones. Changing that shouldn't be necessary to show the problem though.] If you want to bypass the block layer, you could use ddpt instead of dd; see http://sg.danny.cz/sg/ddpt.html ddpt can issue SCSI commands directly, so you could do something like ddpt if=/dev/sdb of=/dev/null bs=512 bpt=240 count=65536 verbose=2 iflag=pt to time reading the first 32MB. Mark -- 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 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller
On Thu, Sep 25, 2014 at 11:20:12AM +0530, Muthu Mani wrote:
Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu Mani m...@cypress.com
Signed-off-by: Rajaram Regupathy r...@cypress.com
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/cyusbs23x.c | 190
++
include/linux/mfd/cyusbs23x.h | 57 +
4 files changed, 260 insertions(+)
create mode 100644 drivers/mfd/cyusbs23x.c
create mode 100644 include/linux/mfd/cyusbs23x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..a31e9e3 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -116,6 +116,18 @@ config MFD_ASIC3
This driver supports the ASIC3 multifunction chip found on many
PDAs (mainly iPAQ and HTC based ones)
+config MFD_CYUSBS23X
+tristate Cypress CYUSBS23x USB Serial Bridge controller
+ select MFD_CORE
+ depends on USB
+ default n
+ help
+ Say yes here if you want support for Cypress Semiconductor
+ CYUSBS23x USB-Serial Bridge controller.
+
+ This driver can also be built as a module. If so, the module will be
+ called cyusbs23x.
+
config PMIC_DA903X
bool Dialog Semiconductor DA9030/DA9034 PMIC Support
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..fc5bcd1 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -151,6 +151,7 @@ si476x-core-y := si476x-cmd.o si476x-prop.o si476x-i2c.o
obj-$(CONFIG_MFD_SI476X_CORE)+= si476x-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
+obj-$(CONFIG_MFD_CYUSBS23X) += cyusbs23x.o
obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE)+= pm8921-core.o ssbi.o
obj-$(CONFIG_TPS65911_COMPARATOR)+= tps65911-comparator.o
diff --git a/drivers/mfd/cyusbs23x.c b/drivers/mfd/cyusbs23x.c
new file mode 100644
index 000..cf2d53b
--- /dev/null
+++ b/drivers/mfd/cyusbs23x.c
@@ -0,0 +1,190 @@
+/*
+ * Cypress USB-Serial Bridge Controller USB adapter driver
+ *
+ * Copyright (c) 2014 Cypress Semiconductor Corporation.
+ *
+ * Author:
+ * Muthu Mani m...@cypress.com
+ *
+ * Additional contributors include:
+ * Rajaram Regupathy r...@cypress.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ */
+
+/*
+ * This is core MFD driver for Cypress Semiconductor CYUSBS234 USB-Serial
+ * Bridge controller. CYUSBS234 offers a single channel serial interface
+ * (I2C/SPI/UART). It can be configured to enable either of I2C, SPI, UART
+ * interfaces. The GPIOs are also available to access.
+ * Details about the device can be found at:
+ *http://www.cypress.com/?rID=84126
+ *
+ * Separate cell drivers are available for I2C and GPIO. SPI and UART are not
+ * supported yet. All GPIOs are exposed for get operation. However, only
+ * unused GPIOs can be set.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+
+#include linux/mfd/core.h
+#include linux/mfd/cyusbs23x.h
+
+#include linux/usb.h
+
+static const struct usb_device_id cyusbs23x_usb_table[] = {
+ { USB_DEVICE(0x04b4, 0x0004) }, /* Cypress Semiconductor */
+ { } /* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, cyusbs23x_usb_table);
+
+static const struct mfd_cell cyusbs23x_i2c_devs[] = {
+ {
+ .name = cyusbs23x-i2c,
+ },
+ {
+ .name = cyusbs23x-gpio,
+ },
+};
+
+static int update_ep_details(struct usb_interface *interface,
+ struct cyusbs23x *cyusbs)
+{
+ struct usb_host_interface *iface_desc;
+ struct usb_endpoint_descriptor *ep;
+ int i;
+
+ dev_dbg(interface-dev, %s\n, __func__);
Drop this.
+
+ iface_desc = interface-cur_altsetting;
+
+ for (i = 0; i iface_desc-desc.bNumEndpoints; ++i) {
+
+ dev_dbg(interface-dev, %s %d/%d\n,
+ __func__, i, iface_desc-desc.bNumEndpoints);
Drop this one as well. lsusb can always be used to give the endpoint
configuration (count).
+
+ ep = iface_desc-endpoint[i].desc;
+
+ if (!cyusbs-bulk_in_ep_num
+ usb_endpoint_is_bulk_in(ep)) {
Indent continuation lines at least two tabs (throughout).
But why are you even breaking this one? Merge the lines and remove the
braces.
+ cyusbs-bulk_in_ep_num = ep-bEndpointAddress;
+ }
+
Re: Urb completion handler returns -32
The device tree is here: root@naveen-OptiPlex-745:/home/naveen# lsusb -t 1-1.5.2:1.2: No such file or directory 1-1.5.3:1.2: No such file or directory 1-1.5.4:1.2: No such file or directory 1-1.5.5:1.2: No such file or directory 1-1.5.6:1.2: No such file or directory 1-1.5.7.1:1.2: No such file or directory 1-1.5.7.2:1.2: No such file or directory 1-1.5.7.3:1.2: No such file or directory /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/6p, 480M |__ Port 3: Dev 3, If 0, Class=HID, Driver=usbhid, 480M |__ Port 3: Dev 3, If 1, Class=HID, Driver=usbhid, 480M |__ Port 3: Dev 3, If 2, Class=stor., Driver=usb-storage, 480M |__ Port 3: Dev 3, If 3, Class=stor., Driver=usb-storage, 480M |__ Port 5: Dev 4, If 0, Class=hub, Driver=hub/7p, 12M |__ Port 1: Dev 5, If 0, Class=hub, Driver=hub/7p, 12M |__ Port 1: Dev 12, If 0, Class=vend., Driver=babel, 12M |__ Port 2: Dev 13, If 0, Class=vend., Driver=babel, 12M |__ Port 3: Dev 14, If 0, Class=vend., Driver=babel, 12M |__ Port 4: Dev 15, If 0, Class=vend., Driver=babel, 12M |__ Port 5: Dev 16, If 0, Class=vend., Driver=babel, 12M |__ Port 6: Dev 17, If 0, Class=vend., Driver=babel, 12M |__ Port 7: Dev 18, If 0, Class=hub, Driver=hub/2p, 12M |__ Port 1: Dev 22, If 0, Class=vend., Driver=babel, 12M |__ Port 2: Dev 23, If 0, Class=vend., Driver=babel, 12M |__ Port 2: Dev 66, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 2: Dev 66, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 2: Dev 66, If 2, Class=app., Driver=, 12M |__ Port 4: Dev 63, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 4: Dev 63, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 4: Dev 63, If 2, Class=app., Driver=, 12M |__ Port 3: Dev 67, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 3: Dev 67, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 3: Dev 67, If 2, Class=app., Driver=, 12M |__ Port 5: Dev 68, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 5: Dev 68, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 5: Dev 68, If 2, Class=app., Driver=, 12M |__ Port 6: Dev 69, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 6: Dev 69, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 6: Dev 69, If 2, Class=app., Driver=, 12M |__ Port 7: Dev 11, If 0, Class=hub, Driver=hub/3p, 12M |__ Port 1: Dev 70, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 1: Dev 70, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 1: Dev 70, If 2, Class=app., Driver=, 12M |__ Port 2: Dev 71, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 2: Dev 71, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 2: Dev 71, If 2, Class=app., Driver=, 12M |__ Port 3: Dev 72, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 3: Dev 72, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=mybtusb, 12M |__ Port 3: Dev 72, If 2, Class=app., Driver=, 12M On Tue, Sep 30, 2014 at 12:05 PM, Naveen Kumar Parna pnaveen...@gmail.com wrote: Hi Alan, The device replied with a STALL. The device runs at low speed or full speed and is connected through a USB-2 hub Yes, my device is full speed (12Mbps) device and connected to 2.0 root hub. So how to avoid getting the STALL? I attached the usbmon log and Ellisys USB analyser log. I connected the eight similar devices(USB Bluetooth Dongles) to host and captured the logs. My device numbers are here : Bus 001 Device Numbers (063\066\067\068\069\070\071\072) Usbmon log shows STALL packets for INT in URB completion handler $ tail -f /tmp/1.mon.out | grep C Ii 8800aaedb780 3159611663 C Ii:1:072:1 -32:1 0 880131449cc0 3360277718 C Ii:1:068:1 -32:1 0 8800aaedb9c0 3360278570 C Ii:1:069:1 -32:1 0
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Tue, 30 Sep 2014 14:10:28 +0800 Lu, Baolu baolu...@linux.intel.com wrote: On 9/30/2014 5:03 AM, Mark Knibbs wrote: Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Hi Mark, I tried to reproduce this issue. I connected a USB key under a full-speed hub. Just to confirm, I do see the slowdown with a USB 2.0 drive connected to USB 1.1 hub connected to USB 3.0 port. My results (kernel 3.17-rc6): Connected to USB 3.0 port via USB 1.1 hub: # ddpt if=/dev/sg6 bs=512 bpt=240 count=65536 verbose=2 Input file type: pass-through [pt] device open /dev/sg6 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg6: Freecom DataBar USB2.02.00 [pdt=0] Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg6 [readcap]: num_blocks=127908 [0x1f3a4], block_size=512, 65 MB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 58.147836 secs at 577.1 KB/sec Connected to USB 2.0 port via USB 1.1 hub: # ddpt if=/dev/sg6 bs=512 bpt=240 count=65536 verbose=2 Input file type: pass-through [pt] device open /dev/sg6 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg6: Freecom DataBar USB2.02.00 [pdt=0] Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg6 [readcap]: num_blocks=127908 [0x1f3a4], block_size=512, 65 MB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 39.146843 secs at 857.1 KB/sec Mark -- 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 v3 2/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
Hello.
(2014/09/30 1:35), Sergei Shtylyov wrote:
Hello.
On 09/03/2014 09:25 AM, Yoshihiro Shimoda wrote:
This driver supports other SoCs, but they need boards/Soc depend code.
So, this patch adds device tree support for R-Car H2 and M2 initially.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/usb/renesas_usbhs/common.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1b9bf8d..b3b6813 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -18,6 +18,8 @@
#include linux/gpio.h
#include linux/io.h
#include linux/module.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include linux/pm_runtime.h
#include linux/slab.h
#include linux/sysfs.h
@@ -438,6 +440,43 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
platform_device *pdev)
[...]
+static struct renesas_usbhs_platform_info *usbhs_parse_dt(struct device
*dev)
+{
+struct renesas_usbhs_platform_info *info;
+struct renesas_usbhs_driver_param *dparam;
+const struct of_device_id *of_id = of_match_device(usbhs_of_match, dev);
+u32 tmp;
+int gpio;
+
+info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+if (!info)
+return NULL;
+
+dparam = info-driver_param;
+dparam-type = of_id ? (u32)of_id-data : 0;
+if (!of_property_read_u32(dev-of_node, renesas,buswait, tmp))
+dparam-buswait_bwait = tmp;
+gpio = of_get_named_gpio_flags(dev-of_node, renesas,enable-gpio, 0,
+ NULL);
+if (gpio 0)
+dparam-enable_gpio = gpio;
+
+return info;
I don't see where you parse the optional phy property. It should exist
for the Lager and Koelsch boards you target.
Since I wrote 'phy-names: must be usb' in the document,
I intend to use a fixed property for phy driver like the following:
phy = phy_get(pdev-dev, usb);
Is this a bad code?
About using the phy driver in renesas_usbhs driver, I intend to modify
the drivers/usb/renesas_usbhs/rcar.c.
Best regards,
Yoshihiro Shimoda
WBR, Sergei
--
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 v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tuesday 30 September 2014 08:12:07 Peter Chen wrote:
+
+ if (dev-of_node) {
+ ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
+ if (ret)
+ goto clk_err;
+ } else {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto clk_err;
+ }
My suggestion:
- call dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32)) for both
dt and non-dt
No, as I explained before, hardcoding the dma mask is always wrong, don't
do that. Call dma_set_mask_and_coherent and check the return value.
It's not wrong to do that for both DT and ATAGS.
Arnd
--
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 v4] ARM: shmobile: r8a7790: link PCI USB devices to USB PHY
On Monday 29 September 2014 22:21:59 Sergei Shtylyov wrote:
+
+ usb@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ phys = usb0 0;
+ phy-names = usb;
+ };
+
+ usb@0,2 {
Nice to see this actually works!
The patch looks good to me, but I wasn't sure if the ARM PCI code handled
of_nodes correctly.
We frequently get people asking for the same functionality on USB device,
which should really work the same way, so I guess I can point them at
this now.
Arnd
--
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 2/3] i2c: add support for Cypress CYUSBS234 USB-I2C adapter
On Thu, Sep 25, 2014 at 05:46:16AM +, Muthu Mani wrote:
+static int cy_i2c_xfer(struct i2c_adapter *adapter,
+struct i2c_msg *msgs, int num) {
+ int ret = 0;
+ struct cyusbs_i2c *cy_i2c;
+ struct cyusbs23x *cyusbs = (struct cyusbs23x
+*)adapter-algo_data;
+
+ dev_dbg(adapter-dev, %s\n, __func__);
+
+ if (num 1) {
+ dev_err(adapter-dev, i2c_msg number is 1\n);
+ return -EIO;
+ }
Why not handle multiple messages?
This iteration of the driver is designed to handle only a single
message at a time.
It can be expanded to handle multiple messages in future.
No, please do that now. It's just a matter of adding a for loop.
Thanks,
Johan
--
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 2/3] i2c: add support for Cypress CYUSBS234 USB-I2C adapter
On Thu, Sep 25, 2014 at 11:21:15AM +0530, Muthu Mani wrote:
Adds support for USB-I2C interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The read/write operation is setup using vendor command through control
endpoint
and actual data transfer happens through bulk in/out endpoints.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu Mani m...@cypress.com
Signed-off-by: Rajaram Regupathy r...@cypress.com
---
drivers/i2c/busses/Kconfig | 12 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-cyusbs23x.c | 514
+
3 files changed, 527 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-cyusbs23x.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..1fdc6ec 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -848,6 +848,18 @@ config I2C_RCAR
comment External I2C/SMBus adapter drivers
+config I2C_CYUSBS23X
+tristate CYUSBS23x I2C adapter
+depends on MFD_CYUSBS23X USB
+help
+ Say yes if you would like to access Cypress CYUSBS23x I2C device.
+
+ This driver enables the I2C interface of CYUSBS23x USB Serial Bridge
+ controller.
+
+ This driver can also be built as a module. If so, the module will be
+ called i2c-cyusbs23x.
+
config I2C_DIOLAN_U2C
tristate Diolan U2C-12 USB adapter
depends on USB
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..cbf28cb 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
# External I2C/SMBus adapter drivers
+obj-$(CONFIG_I2C_CYUSBS23X) += i2c-cyusbs23x.o
obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o
obj-$(CONFIG_I2C_PARPORT)+= i2c-parport.o
obj-$(CONFIG_I2C_PARPORT_LIGHT) += i2c-parport-light.o
diff --git a/drivers/i2c/busses/i2c-cyusbs23x.c
b/drivers/i2c/busses/i2c-cyusbs23x.c
new file mode 100644
index 000..5cf60f0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cyusbs23x.c
@@ -0,0 +1,514 @@
+/*
+ * I2C subdriver for Cypress CYUSBS234 USB-Serial Bridge controller.
+ * Details about the device can be found at:
+ *http://www.cypress.com/?rID=84126
+ *
+ * Copyright (c) 2014 Cypress Semiconductor Corporation.
+ *
+ * Author:
+ * Rajaram Regupathy r...@cypress.com
+ *
+ * Additional contributors include:
+ * Muthu Mani m...@cypress.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ */
+
+/*
+ * It exposes sysfs entries under the i2c adapter for getting the i2c
transfer
+ * status, reset i2c read/write module, get/set nak and stop bits.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+#include linux/platform_device.h
+
+#include linux/usb.h
+#include linux/i2c.h
+
+#include linux/mfd/cyusbs23x.h
+
+#define CY_I2C_MODE_WRITE 1
+#define CY_I2C_MODE_READ 0
Make this an enum that you pass to get_status and reset.
+
+#define CY_I2C_XFER_STATUS_LEN 3
+
+struct cyusbs_i2c_config {
+ u32 frequency;/* Frequency of operation. Only valid values are
+ 100KHz and 400KHz */
Multi-line comments should be on the form
/*
* ...
*/
+ u8 slave_addr;/* Slave address to be used when in slave mode */
+ u8 is_msb_first; /* Whether to transmit MSB first */
+ u8 is_master; /* Whether block is to be configured as a master:
+ 1 - The block functions as I2C master;
+ 0 - The block functions as I2C slave */
+ u8 s_ignore; /* Ignore general call in slave mode */
+ u8 clock_stretch; /* Whether to stretch clock in case of no FIFO
+ availability */
+ u8 is_loopback; /* Whether to loop back TX data to RX. Valid
+ only for debug purposes */
+ u8 reserved[6]; /* Reserved for future use */
+} __packed;
+
+struct cyusbs_i2c {
+ struct i2c_adapter i2c_adapter;
+ struct cyusbs_i2c_config *i2c_config;
+
+ bool is_stop_bit;
+ bool is_nak_bit;
What are these for? Document along with attributes (see below).
Seems like use_ rather than is_ would be more appropriate.
+};
+
+#define to_cyusbs_i2c(a) container_of(a, struct cyusbs_i2c, i2c_adapter)
+
+static int cy_i2c_get_status(struct device *d, char *buf, u16 mode);
+static int cy_i2c_reset(struct device *d, u16 mode);
+
+static
Re: [PATCH v2 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Thu, Sep 25, 2014 at 11:21:58AM +0530, Muthu Mani wrote:
Adds support for USB-GPIO interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The GPIO get/set can be done through vendor command on control endpoint.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu Mani m...@cypress.com
Signed-off-by: Rajaram Regupathy r...@cypress.com
---
drivers/gpio/Kconfig | 13 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-cyusbs23x.c | 182
++
3 files changed, 196 insertions(+)
create mode 100644 drivers/gpio/gpio-cyusbs23x.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..932e07c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -886,6 +886,19 @@ config GPIO_BCM_KONA
comment USB GPIO expanders:
+config GPIO_CYUSBS23X
+ tristate CYUSBS23x GPIO support
+ depends on MFD_CYUSBS23X USB
+ help
+ Say yes here to access the GPIO signals of Cypress
+ Semiconductor CYUSBS23x USB Serial Bridge Controller.
+
+ This driver enables the GPIO interface of CYUSBS23x USB Serial
+ Bridge controller.
+
+ This driver can also be built as a module. If so, the module will be
+ called gpio-cyusbs23x.
+
config GPIO_VIPERBOARD
tristate Viperboard GPIO a b support
depends on MFD_VIPERBOARD USB
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..3ad89f1 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_GPIO_BT8XX)+= gpio-bt8xx.o
obj-$(CONFIG_GPIO_CLPS711X) += gpio-clps711x.o
obj-$(CONFIG_GPIO_CS5535)+= gpio-cs5535.o
obj-$(CONFIG_GPIO_CRYSTAL_COVE) += gpio-crystalcove.o
+obj-$(CONFIG_GPIO_CYUSBS23X) += gpio-cyusbs23x.o
obj-$(CONFIG_GPIO_DA9052)+= gpio-da9052.o
obj-$(CONFIG_GPIO_DA9055)+= gpio-da9055.o
obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
diff --git a/drivers/gpio/gpio-cyusbs23x.c b/drivers/gpio/gpio-cyusbs23x.c
new file mode 100644
index 000..ad83b00
--- /dev/null
+++ b/drivers/gpio/gpio-cyusbs23x.c
@@ -0,0 +1,182 @@
+/*
+ * GPIO subdriver for Cypress CYUSBS234 USB-Serial Bridge controller.
+ * Details about the device can be found at:
+ *http://www.cypress.com/?rID=84126
+ * All GPIOs are exposed for get operation and only unused GPIOs can be set.
+ *
+ * Copyright (c) 2014 Cypress Semiconductor Corporation.
+ *
+ * Author:
+ * Muthu Mani m...@cypress.com
+ *
+ * Additional contributors include:
+ * Rajaram Regupathy r...@cypress.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/mutex.h
+#include linux/platform_device.h
+
+#include linux/usb.h
+#include linux/gpio.h
+
+#include linux/mfd/cyusbs23x.h
+
+#define CY_GPIO_GET_LEN (2)
No parentheses.
+
+struct cyusbs_gpio {
+ struct gpio_chip gpio;
+ struct cyusbs23x *cyusbs;
+};
+
+static int cy_gpio_get(struct gpio_chip *chip,
+ unsigned offset)
+{
+ int ret;
+ char *buf;
+ u16 wIndex, wValue;
+ struct cyusbs_gpio *gpio =
+ container_of(chip, struct cyusbs_gpio, gpio);
Add helper macro?
+ struct cyusbs23x *cyusbs = gpio-cyusbs;
+
+ dev_dbg(cyusbs-usb_intf-dev, %s: %d\n, __func__,
+ offset);
Drop this.
+ wValue = offset;
+ wIndex = 0;
+ buf = kmalloc(CY_GPIO_GET_LEN, GFP_KERNEL);
Error handling missing.
+
+ mutex_lock(cyusbs-lock);
Locking not needed.
+ ret = usb_control_msg(cyusbs-usb_dev,
+ usb_rcvctrlpipe(cyusbs-usb_dev, 0),
+ CY_GPIO_GET_VALUE_CMD,
+ USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_IN,
+ wValue, wIndex, buf, CY_GPIO_GET_LEN, 2000);
timeout define.
+ mutex_unlock(cyusbs-lock);
+
+ dev_dbg(cyusbs-usb_intf-dev, %s: %d %02x %02x\n, __func__,
+ ret, buf[0], buf[1]);
Use the gpio_chip device rather than usb-interface device in gpio
callbacks for debug and error messages.
+
+ if (ret == CY_GPIO_GET_LEN) {
+ if (buf[0] == 0)
+ ret = buf[1];
+ else
+ ret = -EINVAL;
+ } else {
+ ret = -EREMOTEIO;
+ }
Just use -EIO for both error cases.
+
+ kfree(buf);
+ return ret;
+}
+
+static void cy_gpio_set(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ int ret;
+ u16 wIndex, wValue;
+ struct cyusbs_gpio *gpio =
+
Re: [PATCH v2 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Tue, Sep 30, 2014 at 01:08:29PM +0200, Johan Hovold wrote:
On Thu, Sep 25, 2014 at 11:21:58AM +0530, Muthu Mani wrote:
+static int cy_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset)
+{
+ return 0;
+}
+
+static int cy_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ return 0;
+}
This is not a correct implementation of these. You're are supposed to
return what direction the gpio is configured for. You should also add a
call back to set the direction.
That was backwards; these are supposed to set the direction, and then
you should also implement the get_direction callback.
Johan
--
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 3/3] gpio: add support for Cypress CYUSBS234 USB-GPIO adapter
On Thu, Sep 25, 2014 at 05:47:11AM +, Muthu Mani wrote:
-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
+static int cy_gpio_direction_input(struct gpio_chip *chip,
+ unsigned offset) {
+ return 0;
Aren't the GPIOs output-only?
No.
Then you should implement this callback to configure the pin as an
input.
Or can the configuration only be made through your configuration tools
and stored in eeprom?
Then you need to retrieve the actual config and implement these
callbacks (e.g. fail if not matching the eeprom config) along with
get_direction().
+}
+
+static int cy_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value) {
+ return 0;
+}
+
+static int cyusbs23x_gpio_probe(struct platform_device *pdev) {
+ struct cyusbs23x *cyusbs;
+ struct cyusbs_gpio *cy_gpio;
+ int ret = 0;
+
+ dev_dbg(pdev-dev, %s\n, __func__);
+
+ cyusbs = dev_get_drvdata(pdev-dev.parent);
+
+ cy_gpio = devm_kzalloc(pdev-dev, sizeof(*cy_gpio), GFP_KERNEL);
+ if (cy_gpio == NULL)
+ return -ENOMEM;
+
+ cy_gpio-cyusbs = cyusbs;
+ /* registering gpio */
+ cy_gpio-gpio.label = cyusbs23x gpio;
+ cy_gpio-gpio.dev = pdev-dev;
+ cy_gpio-gpio.owner = THIS_MODULE;
+ cy_gpio-gpio.base = -1;
+ cy_gpio-gpio.ngpio = 12; /* total GPIOs */
I think you need to read out the gpio config from the device eeprom and
implement a request() callback where you verify that a requested gpio is
actually available (mode dependent, and there are never more than 10 gpios
availble).
In this initial driver, all GPIOs are made available to user space.
Additional functionalities will be added in the next version of the driver.
I think this needs to be implemented now. It's needed for direction
handling as well as mentioned above.
+ cy_gpio-gpio.can_sleep = true;
+ cy_gpio-gpio.set = cy_gpio_set;
+ cy_gpio-gpio.get = cy_gpio_get;
+ cy_gpio-gpio.direction_input = cy_gpio_direction_input;
+ cy_gpio-gpio.direction_output = cy_gpio_direction_output;
+ ret = gpiochip_add(cy_gpio-gpio);
+ if (ret 0) {
+ dev_err(cy_gpio-gpio.dev, could not add gpio);
+ goto error;
+ }
Thanks,
Johan
--
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: host: st: fix ehci/ohci driver selection
On Mon, 2014-09-29 at 14:54 +0200, Arnd Bergmann wrote: The newly added sti ehci and ohci drivers come with a single Kconfig entry that does not depend on either of the base drivers, which leads to a link error when they are disabled: drivers/built-in.o: In function `ohci_platform_init': :(.init.text+0x14788): undefined reference to `ohci_init_driver' To fix that, this patch introduces two separate Kconfig options with proper dependencies, which avoids the problem and is also more consistent with the other glue drivers. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: d115837259ada (usb: host: ohci-st: Add OHCI driver support for ST STB devices) Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Peter Griffin peter.grif...@linaro.org Cc: Alan Stern st...@rowland.harvard.edu Cc: linux-usb@vger.kernel.org This became commit 905e300e1043 (USB: host: st: fix ehci/ohci driver selection) in next-20140930. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index b943545f862c..002ba1d5bcf5 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -174,6 +174,15 @@ config USB_EHCI_HCD_SPEAR Enables support for the on-chip EHCI controller on ST SPEAr chips. +config USB_EHCI_HCD_STI + tristate Support for ST STiHxxx on-chip EHCI USB controller + depends on ARCH_STI OF + select GENERIC_PHY + select USB_EHCI_HCD_PLATFORM + help + Enable support for the on-chip EHCI controller found on + STMicroelectronics consumer electronics SoC's. + config USB_EHCI_HCD_AT91 tristate Support for Atmel on-chip EHCI USB controller depends on USB_EHCI_HCD ARCH_AT91 @@ -402,6 +411,15 @@ config USB_OHCI_HCD_SPEAR Enables support for the on-chip OHCI controller on ST SPEAr chips. +config USB_OHCI_HCD_STI + tristate Support for ST STiHxxx on-chip OHCI USB controller + depends on ARCH_STI OF + select GENERIC_PHY + select USB_OHCI_HCD_PLATFORM + help + Enable support for the on-chip OHCI controller found on + STMicroelectronics consumer electronics SoC's. + config USB_OHCI_HCD_S3C2410 tristate OHCI support for Samsung S3C24xx/S3C64xx SoC series depends on USB_OHCI_HCD (ARCH_S3C24XX || ARCH_S3C64XX) @@ -761,14 +779,6 @@ config USB_HCD_SSB If unsure, say N. -config USB_HCD_ST - tristate ST USB driver for ST SoC Series - depends on ARCH_STI OF - select GENERIC_PHY - help - Enable support for the on-chip OHCI EHCI controller found on - STMicroelectronics consumer electronics SoC's. - config USB_HCD_TEST_MODE bool HCD test mode support ---help--- diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index ae2db0b87993..0336bb2c0e6f 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -38,6 +38,7 @@ obj-$(CONFIG_USB_EHCI_MXC) += ehci-mxc.o obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o obj-$(CONFIG_USB_EHCI_HCD_ORION) += ehci-orion.o obj-$(CONFIG_USB_EHCI_HCD_SPEAR) += ehci-spear.o +obj-$(CONFIG_USB_EHCI_HCD_ST)+= ehci-st.o This should have been CONFIG_USB_EHCI_HCD_STI (A rather subtle typo, easy to make given the rest of the patch.) obj-$(CONFIG_USB_EHCI_EXYNOS)+= ehci-exynos.o obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o obj-$(CONFIG_USB_EHCI_MSM) += ehci-msm.o @@ -55,6 +56,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o +obj-$(CONFIG_USB_OHCI_HCD_STI) += ohci-st.o obj-$(CONFIG_USB_OHCI_HCD_AT91) += ohci-at91.o obj-$(CONFIG_USB_OHCI_HCD_S3C2410) += ohci-s3c2410.o obj-$(CONFIG_USB_OHCI_HCD_LPC32XX) += ohci-nxp.o @@ -77,4 +79,3 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o obj-$(CONFIG_USB_FOTG210_HCD)+= fotg210-hcd.o obj-$(CONFIG_USB_MAX3421_HCD)+= max3421-hcd.o -obj-$(CONFIG_USB_HCD_ST) += ehci-st.o ohci-st.o Paul Bolle -- 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 v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tue, Sep 30, 2014 at 12:03:42PM +0200, Arnd Bergmann wrote:
On Tuesday 30 September 2014 08:12:07 Peter Chen wrote:
+
+ if (dev-of_node) {
+ ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
+ if (ret)
+ goto clk_err;
+ } else {
+ ret = dma_set_mask_and_coherent(pdev-dev,
DMA_BIT_MASK(32));
+ if (ret)
+ goto clk_err;
+ }
My suggestion:
- call dma_coerce_mask_and_coherent(dev-dev, DMA_BIT_MASK(32)) for both
dt and non-dt
No, as I explained before, hardcoding the dma mask is always wrong, don't
do that. Call dma_set_mask_and_coherent and check the return value.
It's not wrong to do that for both DT and ATAGS.
Thanks, Arnd. I had not thought setting dma mask is so complicated, yes, it
should check the return value, two things to confirm:
- dma_coerce_mask_and_coherent or dma_set_mask_and_coherent, the only difference
of these two API is the first one do dev-dma_mask = dev-coherent_dma_mask;
The reason you suggest choosing dma_set_mask_and_coherent is you do not want
assign dev-dma_mask?
- The second parameter for dma_set_mask_and_coherent is DMA_BIT_MASK(32), is it
ok?
I just a little confused of what's the operation is hardcoding the dma mask?
--
Best Regards,
Peter Chen
--
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 v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tuesday 30 September 2014 20:39:34 Peter Chen wrote: Thanks, Arnd. I had not thought setting dma mask is so complicated, yes, it should check the return value, two things to confirm: - dma_coerce_mask_and_coherent or dma_set_mask_and_coherent, the only difference of these two API is the first one do dev-dma_mask = dev-coherent_dma_mask; The reason you suggest choosing dma_set_mask_and_coherent is you do not want assign dev-dma_mask? No, that is just the current definition on ARM32 with CONFIG_ARCH_MULTIPLATFORM, and that is going to change soon to be DT aware. dma_set_mask_and_coherent() is supposed to check whether the platform can support the respective mask and return an error if it cannot. - The second parameter for dma_set_mask_and_coherent is DMA_BIT_MASK(32), is it ok? I just a little confused of what's the operation is hardcoding the dma mask? dma_coerce_mask_and_coherent() will hardcode the dma mask and override whatever the platform says is necessary. Arnd -- 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: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
On Mon, Sep 29, 2014 at 11:48:41PM -0500, Felipe Balbi wrote:
Hi,
On Tue, Sep 30, 2014 at 11:12:55AM +0800, Huang Rui wrote:
On Thu, Sep 25, 2014 at 03:21:46PM +0800, Huang Rui wrote:
diff --git a/drivers/usb/dwc3/core.c
b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct
dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface
for NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK |
DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX |
DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE |
DWC3_GUSB3PIPECTL_RX_DETOPOLL;
UX_EXITINPX is supposed to be used with a faulty PHY, I need
to see an
erratum before I can accept it. You have also duplicated the
bit in this
initialization.
U1U2EXITFAIL - also a workaround bit and I need to see an
erratum.
RX_DETOPOLL - it seems like it's safe to leave this one out
as it can
only be proven to work with this bit after going through full
USB
certification.
What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.
Look at the description of each of those bits and you'll see it
mentions
they're supposed to be used for workarounds. Here's
UX_EXIT_IN_PX, as an
example:
This bit is added for SS PHY workaround where SS PHY ...
Got it, so faulty PHY you meant that some special PHYs didn't not
meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.
Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.
I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of fpga. I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).
while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no generic way implemented by Synopsys into the RTL, then
we better not add anything.
Because the RTL is frozen.
I checked the spec again of GUID:
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version
info.
the problem is that we won't have something that will work for
everybody. Note that the register can be used as scratch register as
well and there's really no way we will be able to get every RTL designer
in every company out there who's licensing this core to agree on using
this register the exact same way.
Unless it ships already built into the RTL Synopsys delivers, there's
no way we can use it in the core dwc3 driver ;-)
Also, I'd have to ask you to provide full boot logs of your
platform
booting with my testing/next (where all the latest patches are)
plus
your patches.
I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under
3.14
before.
v3.14 is rather old, if you're sending patches upstream. I'd rather
see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.
Yes, I am doing these testing.
An issue meet your msc.c.
ray@hr-slim:~/felipe/usb-tools$ gcc -Wall -O2 -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -o msc msc.c
/tmp/ccUBcDC4.o: In function `do_write':
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to
Re: Urb completion handler returns -32
On Tue, 30 Sep 2014, Naveen Kumar Parna wrote: Hi Alan, The device replied with a STALL. The device runs at low speed or full speed and is connected through a USB-2 hub Yes, my device is full speed (12Mbps) device and connected to 2.0 root hub. So how to avoid getting the STALL? I don't know. I attached the usbmon log and Ellisys USB analyser log. The Ellisys viewer program runs under Windows, but I'm using Linux so I'm unable to view the analyzer log. I connected the eight similar devices(USB Bluetooth Dongles) to host and captured the logs. My device numbers are here : Bus 001 Device Numbers (063\066\067\068\069\070\071\072) Usbmon log shows STALL packets for INT in URB completion handler $ tail -f /tmp/1.mon.out | grep C Ii 8800aaedb780 3159611663 C Ii:1:072:1 -32:1 0 880131449cc0 3360277718 C Ii:1:068:1 -32:1 0 8800aaedb9c0 3360278570 C Ii:1:069:1 -32:1 0 880131f52000 3360291656 C Ii:1:067:1 -32:1 0 8800aae88600 3360299542 C Ii:1:068:1 -32:1 0 On receiving the STALL response, work queue got scheduled in INT in URB completion handler for clearing halt condition(used usb_clear_halt() API in that work queue) I enabled “Drop Start of Frames and Keep Alives” “Drop NAK transactions” recording options before taking the Ellisys USB analyser log. I don’t see STALL packet in Ellisys USB analyser log, but only observed in usbmon log. Does it mean, device is not sending the STALL, but only Host controller driver is sending it to my USB device driver? It probably means that the device is not sending the STALL, but the hub it is plugged into is sending the STALL. 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
[SOLVED] Re: No USB3 / Asus P5B-VM, U3S6 and Transcend RDF-8 card reader
Am Tue, 23 Sep 2014 23:09:25 +0200 schrieb Daniel van Gerpen dan...@vangerpen.de: my RDF-8 card reader does not establish a super-speed connection when connected to an U3S6 USB3.0 port. It only manages high-speed: [..] Problem was not kernel related. Fixed by changing the BIOS Option for PCI Express Frequency from Auto to 100 MHz: [1.90] usb 9-2: new SuperSpeed USB device number 2 using xhci_hcd [1.962091] usb 9-2: Parent hub missing LPM exit latency info. Power management will be impacted. [1.965223] usb 9-2: New USB device found, idVendor=8564, idProduct=4000 [1.965226] usb 9-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5 [1.965228] usb 9-2: Product: Transcend [1.965230] usb 9-2: Manufacturer: TS-RDF8 [1.965232] usb 9-2: SerialNumber: 00080 Not sure why lsusb doesn't identify the smart card reader by name, though: Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 009 Device 002: ID 8564:4000 Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Regards, Daniel -- 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 net] r8152: fix setting RTL8152_UNPLUG
From: Hayes Wang hayesw...@realtek.com Date: Tue, 30 Sep 2014 16:48:01 +0800 The flag of RTL8152_UNPLUG should only be set when the device is unplugged, not each time the rtl8152_disconnect() is called. Otherwise, the device wouldn't be stopped normally. Signed-off-by: Hayes Wang hayesw...@realtek.com Applied, thanks. -- 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 v3 2/2] usb: renesas_usbhs: Add device tree support for R-Car H2 and M2
Hello.
On 09/30/2014 01:51 PM, Yoshihiro Shimoda wrote:
This driver supports other SoCs, but they need boards/Soc depend code.
So, this patch adds device tree support for R-Car H2 and M2 initially.
Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
---
drivers/usb/renesas_usbhs/common.c | 44
1 file changed, 44 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1b9bf8d..b3b6813 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
[...]
@@ -438,6 +440,43 @@ static int usbhsc_drvcllbck_notify_hotplug(struct
platform_device *pdev)
[...]
+static struct renesas_usbhs_platform_info *usbhs_parse_dt(struct device *dev)
+{
+ struct renesas_usbhs_platform_info *info;
+ struct renesas_usbhs_driver_param *dparam;
+ const struct of_device_id *of_id = of_match_device(usbhs_of_match, dev);
+ u32 tmp;
+ int gpio;
+
+ info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return NULL;
+
+ dparam = info-driver_param;
+ dparam-type = of_id ? (u32)of_id-data : 0;
+ if (!of_property_read_u32(dev-of_node, renesas,buswait, tmp))
+ dparam-buswait_bwait = tmp;
+ gpio = of_get_named_gpio_flags(dev-of_node, renesas,enable-gpio, 0,
+ NULL);
+ if (gpio 0)
+ dparam-enable_gpio = gpio;
+
+ return info;
I don't see where you parse the optional phy property. It should exist
for the Lager and Koelsch boards you target.
Since I wrote 'phy-names: must be usb' in the document,
I intend to use a fixed property for phy driver like the following:
phy = phy_get(pdev-dev, usb);
Is this a bad code?
Seems OK.
About using the phy driver in renesas_usbhs driver, I intend to modify
the drivers/usb/renesas_usbhs/rcar.c.
Hm, it slready supports 'struct usb_phy'. Also PHYs are not limited to
R-Car Gen2 SoCs...
Best regards,
Yoshihiro Shimoda
WBR, Sergei
--
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 net 0/2] r8152: patches about firmware
The patches fix the issues when the firmware exists. For the multiple OS, the firmware may be loaded by the driver of the other OS. And the Linux driver has influences on it. Hayes Wang (2): r8152: remove clearing bp r8152: disable power cut for RTL8153 drivers/net/usb/r8152.c | 30 ++ 1 file changed, 2 insertions(+), 28 deletions(-) -- 1.9.3 -- 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 net 1/2] r8152: remove clearing bp
The xxx_clear_bp() is used to halt the firmware. It only necessary
for updating the new firmware. Besides, depend on the version of
the current firmware, it may have problem to halt the firmware
directly. Finally, halt the firmware would let the firmware code
useless, and the bugs which are fixed by the firmware would occur.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 28 +---
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f68a4e6..18b9e0d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
#include net/ip6_checksum.h
/* Version Information */
-#define DRIVER_VERSION v1.06.0 (2014/03/03)
+#define DRIVER_VERSION v1.06.1 (2014/10/01)
#define DRIVER_AUTHOR Realtek linux nic maintainers nic_s...@realtek.com
#define DRIVER_DESC Realtek RTL8152/RTL8153 Based USB Ethernet Adapters
#define MODULENAME r8152
@@ -2201,28 +2201,6 @@ static void rtl_phy_reset(struct r8152 *tp)
}
}
-static void rtl_clear_bp(struct r8152 *tp)
-{
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_PLA, PLA_BP_6, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_0, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_2, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_4, 0);
- ocp_write_dword(tp, MCU_TYPE_USB, USB_BP_6, 0);
- mdelay(3);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_BP_BA, 0);
- ocp_write_word(tp, MCU_TYPE_USB, USB_BP_BA, 0);
-}
-
-static void r8153_clear_bp(struct r8152 *tp)
-{
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_BP_EN, 0);
- ocp_write_byte(tp, MCU_TYPE_USB, USB_BP_EN, 0);
- rtl_clear_bp(tp);
-}
-
static void r8153_teredo_off(struct r8152 *tp)
{
u32 ocp_data;
@@ -2265,8 +2243,6 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
- rtl_clear_bp(tp);
-
set_bit(PHY_RESET, tp-flags);
}
@@ -2417,8 +2393,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
r8152_mdio_write(tp, MII_BMCR, data);
}
- r8153_clear_bp(tp);
-
if (tp-version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data = ~CTAP_SHORT_EN;
--
1.9.3
--
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 net 2/2] r8152: disable power cut for RTL8153
The firmware would be clear when the power cut is enabled for RTL8153. Signed-off-by: Hayes Wang hayesw...@realtek.com --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 18b9e0d..604ef21 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -3397,7 +3397,7 @@ static void rtl8153_unload(struct r8152 *tp) if (test_bit(RTL8152_UNPLUG, tp-flags)) return; - r8153_power_cut_en(tp, true); + r8153_power_cut_en(tp, false); } static int rtl_ops_init(struct r8152 *tp, const struct usb_device_id *id) -- 1.9.3 -- 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
