Re: UAS crash with Apricorn USB3 SATA bridge
On Wed, Dec 10, 2014 at 05:41:54PM -0800, Darrick J. Wong wrote: On Wed, Dec 10, 2014 at 02:29:29AM -0800, Darrick J. Wong wrote: On Wed, Dec 10, 2014 at 02:15:14AM -0800, Darrick J. Wong wrote: On Wed, Dec 10, 2014 at 01:04:58AM -0800, Darrick J. Wong wrote: On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote: Hi, On 09-12-14 20:31, Darrick J. Wong wrote: Hi, I have an Apricorn USB 3 disk dongle thing that claims to support UAS. However, the kernel crashes when I plug it in[1]. Yes there are some known issues with uas error handling which are fixed in 3.18, can you try with a 3.18 kernel please ? The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a fuller dmesg output. Looking at the code, it looks like we end up in queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we fall off the end. Well, there are (at least) two issues going on here. The first is that the SCSI layer passes us zero-length READ10 commands, which is causing this crash. Zero length means the sglist is empty, so the usb host has nothing to map, and hence urb-num_mapped_sgs == 0 and the loop goes boom. I don't know what it means to send a bulk URB with no buffers, so... ...then I took a tour of how SCSI LLDDs deal with zero-length read/write commands. mpt2sas attaches a junk sg and pushes the command out. libata detects zero-length READ/WRITE SCSI commands and completes the scsi command without ever touching hardware. I wasn't able to get any of my parallel SCSI disks to boot, so I could not try that. The other problem is when I plug in a different disk (same mfg/model), READ CAPACITY 16 intermittently returns the string USBSUSBSUSBS, which of course is garbage. The kernel then tries to use these values; fortunately, it rejects a sector size of 1431519827 (USBS) and sets the size to zero. It turns out that this dongle will return USBSUSBSUSB to just about *any* command, such as READ10. In fact, that's the root cause of the crash. The partition code issues a 4k read to the disk (looking for partition tables). The dongle returns USBSUSBSUSB (13 bytes) which causes the bio to be advanced by 13 bytes because the URB's actual_length is stuffed into the SCSI resid(ual length) field. The block layer code now wants to read 4083 bytes starting at byte 13, which, results in 3584 bytes being read ... to somewhere. This leaves 499 bytes in the bio, which is rounded down to 0 sectors, and thus we crash on a zero-length READ10 when we try to read the remaining piece and there's no sg to land the data. Worse yet, if you somehow patch all *that* up, now the reader sees USBSUSBSUSB when the bio completes. Let's disable UAS on this thing entirely. (Well, you /could/ hack it to detect USBSUSBSUSB and fail the SCSI command entirely, but... meh.) Though we should shortcut a zero-length read to avoid crashing the kernel, since sg_raw can issue such commands. Patches soon, --D So, I can code up a couple of patches -- one to teach UAS how to deal with zero length read and writes; and a second patch to set US_FL_IGNORE_UAS on Apricorn bridges. I tried setting US_FL_NO_READ_CAPACITY_16, but for whatever reason sd.c was still trying RC16. --D (Alas it's now 1am here, so I'm going to bed. :/ ) Eh, nuts to sleeping. dmesg produces this: [ 231.128074] usbcore: registered new interface driver usb-storage [ 231.133822] usbcore: registered new interface driver uas [ 252.121353] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd [ 252.136927] scsi host6: uas [ 252.141679] scsi 6:0:0:0: Direct-Access Apricorn 0128 PQ: 0 ANSI: 6 [ 252.145433] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 252.145525] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB) [ 252.145527] sd 6:0:0:0: [sdc] 4096-byte physical blocks [ 252.145891] sd 6:0:0:0: [sdc] Write Protect is off [ 252.145973] sd 6:0:0:0: [sdc] No Caching mode page found [ 252.145975] sd 6:0:0:0: [sdc] Assuming drive cache: write through Huh. 4096-byte physical blocks?? That drive is /not/ a 4k sector drive. Here's what the kernel said when I plugged in the other (Plugable brand) UAS bridge[1]: [ 32.466870] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd [ 32.498996] usbcore: registered new interface driver usb-storage [ 37.660963] scsi host6: uas [ 37.661193] usbcore: registered new interface driver uas [ 37.661292] queue_bulk_sg_tx: num=1 sg=880447764500 addr=45af41000 len=0 pagelink=ea00116bd042 [ 37.661550] queue_bulk_sg_tx: num=1 sg=8804483fb600 addr=45af41000 len=0 pagelink=ea00116bd042 [ 37.661744] scsi 6:0:0:0: Direct-Access Plugable USB3-SATA-UASP1 0 PQ: 0 ANSI: 6 [ 37.661865] queue_bulk_sg_tx: num=1
Re: [PATCH] extcon: add MAX3355 driver
On Thu, Dec 11, 2014 at 2:46 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
Could you send the datasheet of MAX3355E to me?
First Google hit:
http://datasheets.maximintegrated.com/en/ds/MAX3355E.pdf
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: Re: [PATCH] USB: serial: add nt124 usb to serial driver
Johan Hovold jo...@kernel.org wrote: On Mon, Dec 08, 2014 at 05:24:17PM -0600, George McCollister wrote: + newline.bParityType = termios-c_cflag PARENB ? + (termios-c_cflag PARODD ? 1 : 2) + + (termios-c_cflag CMSPAR ? 2 : 0) : 0; This hardly readable. Don't use ?: There's also C_PARENB(tty), C_PARODD(tty), and C_CMSPAR(tty) macros available, in addition to the others that Johan pointed out. Sincerely, Karl P
[PATCH v6 0/5] Patches to add support for Rockchip usb PHYs.
Patches to add support for Rockchip usb phys.Add a new Rockchip usb phy driver and modify dwc2 controller driver to make dwc2 platform devices support a generic PHY framework driver. This patch set has been tested on my rk3288-evb and power off the usb phys would reduce about 60mW power budget in total during sustem suspend. Changes in v6: - Rename SIDDQ_MSK to SIDDQ_WRITE_ENA. - Use phandle args to find a phy struct directly. Changes in v5: - Adjust entry order of example devicetree node in document. - reorder the phy dt node to a correct position. Changes in v4: - Get number of PHYs from device tree. - Model each PHY as subnode of the phy provider node. - Updata description for phy device tree subnode. - Add phy subnodes. Changes in v3: - Use BIT macro instead of bit shift ops. - Rename the config entry to PHY_ROCKCHIP_USB. - Fix coding style: both branches of the if() which only one branch of the conditional statement is a single statement should have braces. - No need to test dwc2-phy for NULL before calling generic phy APIs. Yunzhi Li (5): phy: add a driver for the Rockchip SoC internal USB2.0 PHY Documentation: bindings: add dt documentation for Rockchip usb PHY usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver. ARM: dts: rockchip: add rk3288 usb PHY ARM: dts: rockchip: Enable usb PHY on rk3288-evb board .../devicetree/bindings/phy/rockchip-usb-phy.txt | 32 arch/arm/boot/dts/rk3288-evb.dtsi | 4 + arch/arm/boot/dts/rk3288.dtsi | 27 +++ drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-rockchip-usb.c | 198 + drivers/usb/dwc2/gadget.c | 33 ++-- drivers/usb/dwc2/platform.c| 36 +++- 8 files changed, 315 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt create mode 100644 drivers/phy/phy-rockchip-usb.c -- 2.0.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 v6 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.
Get PHY parameters from devicetree and power off usb PHY during
system suspend.
Signed-off-by: Yunzhi Li l...@rock-chips.com
Acked-by: Paul Zimmerman pa...@synopsys.com
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Fix coding style: both branches of the if() which only one
branch of the conditional statement is a single statement
should have braces.
- No need to test dwc2-phy for NULL before calling generic phy
APIs.
drivers/usb/dwc2/gadget.c | 33 -
drivers/usb/dwc2/platform.c | 36 ++--
2 files changed, 46 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..2601c61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
{
struct device *dev = hsotg-dev;
struct s3c_hsotg_plat *plat = dev-platform_data;
- struct phy *phy;
- struct usb_phy *uphy;
struct s3c_hsotg_ep *eps;
int epnum;
int ret;
@@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg-phyif = GUSBCFG_PHYIF16;
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
*/
- phy = devm_phy_get(dev, usb2-phy);
- if (IS_ERR(phy)) {
- uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- if (IS_ERR(uphy)) {
- /* Fallback for pdata */
- plat = dev_get_platdata(dev);
- if (!plat) {
- dev_err(dev,
- no platform data or transceiver defined\n);
- return -EPROBE_DEFER;
- }
- hsotg-plat = plat;
- } else
- hsotg-uphy = uphy;
- } else {
- hsotg-phy = phy;
+ if (IS_ERR_OR_NULL(hsotg-phy) IS_ERR_OR_NULL(hsotg-uphy)) {
+ plat = dev_get_platdata(dev);
+ if (!plat) {
+ dev_err(dev,
+ no platform data or transceiver defined\n);
+ return -EPROBE_DEFER;
+ }
+ hsotg-plat = plat;
+ } else if (hsotg-phy) {
/*
* If using the generic PHY framework, check if the PHY bus
* width is 8-bit and set the phyif appropriately.
*/
- if (phy_get_bus_width(phy) == 8)
+ if (phy_get_bus_width(hsotg-phy) == 8)
hsotg-phyif = GUSBCFG_PHYIF8;
}
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..ae095f0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
+ struct phy *phy;
+ struct usb_phy *uphy;
int retval;
int irq;
@@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+ /*
+* Attempt to find a generic PHY, then look for an old style
+* USB PHY
+*/
+ phy = devm_phy_get(dev-dev, usb2-phy);
+ if (IS_ERR(phy)) {
+ hsotg-phy = NULL;
+ uphy = devm_usb_get_phy(dev-dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(uphy))
+ hsotg-uphy = NULL;
+ else
+ hsotg-uphy = uphy;
+ } else {
+ hsotg-phy = phy;
+ phy_power_on(hsotg-phy);
+ phy_init(hsotg-phy);
+ }
+
spin_lock_init(hsotg-lock);
mutex_init(hsotg-init_mutex);
retval = dwc2_gadget_init(hsotg, irq);
@@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
- if (dwc2_is_device_mode(dwc2))
+ if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
+ } else {
+ if (dwc2-lx_state == DWC2_L0)
+ return 0;
+ phy_exit(dwc2-phy);
+ phy_power_off(dwc2-phy);
+
+ }
return ret;
}
@@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
- if (dwc2_is_device_mode(dwc2))
+ if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_resume(dwc2);
+ } else {
+
RE: Learning USB Programming on Linux
-Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of Peter Chen Sent: Thursday, December 11, 2014 4:25 AM To: Greg KH; ivo welch Cc: linux-usb; sgowdy+usb...@gmail.com Subject: RE: Learning USB Programming on Linux On Thu, Dec 11, 2014 at 10:54:13AM +0800, ivo welch wrote: thank you, greg. if linux-usb is the wrong starter, can you recommend some pointers to good starter documentation and books about writing user-space USB programs? (is it really read the linux kernel source??) I don't know of any, sorry. Look at libusb, there are lots of programs in your distro that use it, so start with that. The libusb web site might have example programs as well, that will get you started on the userspace side for the host. Not the gadget, that's a different story, but you already have a start with that by looking at the PTP gadget userspace code you have access to. For host: http://libusb.info/ For device: https://github.com/libusbg/libusbg Please let me clarify. Libusbg is *not* the library for USB programming in a similar meaning as libusb. Libusb is the library for writing userspace programs on host side which communicate directly with USB device using pure USB protocol (usb requests). On the other hand libusbg is a library for gadget side but it is *not* desired for any communication. It's only a library for USB gadget *composition*. Using this library you can build a USB gadget from existing blocks called functions for example mass storage, serial, Ethernet or your custom one based on FunctionFS implemented in userspace. If you would like to communicate with host from USB device you should use mentioned before *FunctionFS*[1]. It's a file system which allows you to implement the second side of communication for libusb for example PTP function. The best place to start are some examples which are present in kernel tree[2]. First of all please look at ffs-test.c which is a simple device side program which use synchronous functionfs API. When you will get through this you should look into [3] where you will find examples how to use asynchronous functionfs API. Moreover you can find there also host side programs which use libusb. Footnotes: (All paths in kernel repository) [1] - Documentation/usb/functionfs.txt [2] - tools/usb [3] - tools/usb/ffs-aio-example/ -- Best regards, Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics k.opas...@samsung.com -- 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: Learning USB Programming on Linux
-Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of Greg KH Sent: Thursday, December 11, 2014 4:18 AM To: ivo welch Cc: linux-usb; sgowdy+usb...@gmail.com Subject: Re: Learning USB Programming on Linux On Thu, Dec 11, 2014 at 10:54:13AM +0800, ivo welch wrote: thank you, greg. if linux-usb is the wrong starter, can you recommend some pointers to good starter documentation and books about writing user-space USB programs? (is it really read the linux kernel source??) I don't know of any, sorry. In addition to my last email I have couple of links which may be a good place to start to learn about USB gadget: Andrzej presentation[1] about basics of USB and base usb configuration using configfs. It's a wiki page[2] which describes how to Create your own usb gadget using configfs interface. My presentation[3] which shows configfs configuration and how to usb libusbg API and it's feature gadget schemes. To begin I recommend slides 1-39, rest may be too complicated for beginning. More over if you would like to create your first gadget I recommend gadget schemes usage[4]. You will need to create simple configuration file and then use gadget-import example to set it up on your BBB. If you will find some missing functionality or bugs in libusbg, some of them may be already implemented/fixed in my repository[5] on devel_* branch or in pull requests for the official one[6]. Footnotes: 1 - http://events.linuxfoundation.org/sites/events/files/slides/LinuxConNA-M ake-your-own-USB-gadget-Andrzej.Pietrasiewicz.pdf 2 - https://wiki.tizen.org/wiki/USB/Linux_USB_Layers/Configfs_Composite_Gadg et 3 - http://events.linuxfoundation.org/sites/events/files/slides/Tame_the_USB _gadgets_takative_beast_Opasiak_Krzysztof_0.pdf 4 - https://github.com/kopasiak/libusbg/blob/master/doc/gadget_schemes.txt 5 - https://github.com/kopasiak/libusbg 6 - https://github.com/libusbg/libusbg -- Best regards, Krzysztof Opasiak Samsung RD Institute Poland Samsung Electronics k.opas...@samsung.com -- 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
Query regarding USB gadget driver
Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just ping to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is kevent 12 may have been dropped. I guess this is connected to the TCP Previous Segment not captured and TCP Dup ACK messages. My script for the gadget configuration is as below: /bin/mount none /mnt -t configfs /bin/mkdir /mnt/usb_gadget/g1 cd /mnt/usb_gadget/g1 /bin/mkdir configs/c.1 /bin/mkdir functions/ecm.0 /bin/mkdir strings/0x409 /bin/mkdir configs/c.1/strings/0x409 echo 0xa4a2 idProduct echo 0x0525 idVendor echo Freescale123 strings/0x409/serialnumber echo Freescale strings/0x409/manufacturer echo USB Serial Gadget strings/0x409/product echo Conf 1 configs/c.1/strings/0x409/configuration echo 200 configs/c.1/MaxPower ln -s functions/ecm.0 configs/c.1 echo ci_hdrc.0 UDC /sbin/ifconfig usb0 up /sbin/ifconfig usb0 192.168.1.10 I have debug prints in the udc.c and u_ether.c using pr_debug and enable them when required using dynamic debug. Without running iperf, using ping gives me a sequence of prints as below: [ 277.434409] In eth_start_xmit [ 277.434517] In UDC irq [ 277.434553] In usb_gadget_giveback_request [ 277.434567] In tx_complete [ 277.435443] In UDC irq [ 277.435477] In usb_gadget_giveback_request [ 277.435491] In rx_complete [ 277.435517] In rx_submit [ 277.435601] In eth_start_xmit [ 277.436441] In UDC irq [ 277.436465] In usb_gadget_giveback_request [ 277.436478] In rx_complete [ 277.436493] In rx_submit [ 277.436520] In usb_gadget_giveback_request [ 277.436533] In tx_complete [ 278.434865] In eth_start_xmit [ 278.434959] In UDC irq [ 278.434993] In usb_gadget_giveback_request [ 278.435006] In tx_complete [ 278.435881] In UDC irq [ 278.435910] In usb_gadget_giveback_request [ 278.435923] In rx_complete [ 278.435946] In rx_submit After running iperf without debug prints and then enabling before using ping gives me a sequence of prints as below [ 81.989827] In UDC irq [ 81.989871] In usb_gadget_giveback_request [ 81.989886] In rx_complete [ 81.989905] In rx_submit [ 82.989892] In UDC irq [ 82.989951] In usb_gadget_giveback_request [ 82.989967] In rx_complete [ 82.989992] In rx_submit [ 83.990064] In UDC irq [ 83.990126] In usb_gadget_giveback_request [ 83.990142] In rx_complete [ 83.990167] In rx_submit [ 84.990007] In UDC irq [ 84.990049] In usb_gadget_giveback_request [ 84.990064] In rx_complete [ 84.990083] In rx_submit [ 85.990085] In UDC irq [ 85.990147] In usb_gadget_giveback_request [ 85.990163] In rx_complete [ 85.990188] In rx_submit If I force a full speed configuration for this USB client port, I get a slightly more reliable operation where iperf can run for may be half an hour or so or almost an hour before it falls through. Putting in a delay of 100-150 microseconds in eth_start_xmit also improves it like full speed, but, still not reliable. If I run iperf with debug prints enable, this gives similar results to full speed config. After the failure of iperf test, even ping doesn't work. Bringing down this usb0 interface and then up again makes ping work again. I do realize that putting debug prints or delays like this is not the right thing to do, especially in ISR, but, just trying to debug. This is my first time digging in the USB stack. Based on the above, it seems there might a subtle bug or race condition somewhere in the execution call chain which I have not been able to trace yet. Can someone give me some pointers on how I can dig and debug further?. Regards, Sanchayan. -- 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] phy: phy-samsung-usb2: Don't use same name for driver name and global structure
Hi,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Thursday, December 11, 2014 7:30 AM
To: Kishon Vijay Abraham I; Kamil Debski
Cc: linux-ker...@vger.kernel.org; Linux USB Mailing List; Vivek Gautam
Subject: Re: [PATCH] phy: phy-samsung-usb2: Don't use same name for
driver name and global structure
On Wed, Nov 12, 2014 at 3:54 PM, Vivek Gautam gautam.vi...@samsung.com
wrote:
Using the same driver name for platform driver and a globally defined,
structure used throughout the file, looks a bit unpleasing.
So changing the driver name from samsung_usb2_phy_driver to
samsung_usb2_phy
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Although just a trivial change, does it look valid ?
I can agree that the naming of this variable is a bit unfortunate.
Changing name of samsung_usb2_phy_driver to samsung_usb2_phy is, as
you said, a minor change and does not change how the driver works.
Acked-by: Kamil Debski k.deb...@samsung.com
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
drivers/phy/phy-samsung-usb2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
samsung-usb2.c
index 908949d..2934fb7 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -226,7 +226,7 @@ static int samsung_usb2_phy_probe(struct
platform_device *pdev)
return 0;
}
-static struct platform_driver samsung_usb2_phy_driver = {
+static struct platform_driver samsung_usb2_phy = {
.probe = samsung_usb2_phy_probe,
.driver = {
.of_match_table = samsung_usb2_phy_of_match,
@@ -234,7 +234,7 @@ static struct platform_driver
samsung_usb2_phy_driver = {
}
};
-module_platform_driver(samsung_usb2_phy_driver);
+module_platform_driver(samsung_usb2_phy);
MODULE_DESCRIPTION(Samsung S5P/EXYNOS SoC USB PHY driver);
MODULE_AUTHOR(Kamil Debski k.deb...@samsung.com);
MODULE_LICENSE(GPL v2);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-
kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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] phy: phy-samsung-usb2: Don't use same name for driver name and global structure
On Thu, Dec 11, 2014 at 4:13 PM, Kamil Debski k.deb...@samsung.com wrote:
Hi,
From: Vivek Gautam [mailto:gautamvivek1...@gmail.com]
Sent: Thursday, December 11, 2014 7:30 AM
To: Kishon Vijay Abraham I; Kamil Debski
Cc: linux-ker...@vger.kernel.org; Linux USB Mailing List; Vivek Gautam
Subject: Re: [PATCH] phy: phy-samsung-usb2: Don't use same name for
driver name and global structure
On Wed, Nov 12, 2014 at 3:54 PM, Vivek Gautam gautam.vi...@samsung.com
wrote:
Using the same driver name for platform driver and a globally defined,
structure used throughout the file, looks a bit unpleasing.
So changing the driver name from samsung_usb2_phy_driver to
samsung_usb2_phy
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
---
Although just a trivial change, does it look valid ?
I can agree that the naming of this variable is a bit unfortunate.
Changing name of samsung_usb2_phy_driver to samsung_usb2_phy is, as
you said, a minor change and does not change how the driver works.
true.
Acked-by: Kamil Debski k.deb...@samsung.com
Thanks
Best wishes,
--
Kamil Debski
Samsung RD Institute Poland
drivers/phy/phy-samsung-usb2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
samsung-usb2.c
index 908949d..2934fb7 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -226,7 +226,7 @@ static int samsung_usb2_phy_probe(struct
platform_device *pdev)
return 0;
}
-static struct platform_driver samsung_usb2_phy_driver = {
+static struct platform_driver samsung_usb2_phy = {
.probe = samsung_usb2_phy_probe,
.driver = {
.of_match_table = samsung_usb2_phy_of_match,
@@ -234,7 +234,7 @@ static struct platform_driver
samsung_usb2_phy_driver = {
}
};
-module_platform_driver(samsung_usb2_phy_driver);
+module_platform_driver(samsung_usb2_phy);
MODULE_DESCRIPTION(Samsung S5P/EXYNOS SoC USB PHY driver);
MODULE_AUTHOR(Kamil Debski k.deb...@samsung.com);
MODULE_LICENSE(GPL v2);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-
kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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: Query regarding USB gadget driver
Hello, W dniu 11.12.2014 o 11:38, Sanchayan Maity pisze: Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just ping to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is kevent 12 may have been dropped. I guess this is connected to the TCP Previous Segment not captured and TCP Dup ACK messages. My script for the gadget configuration is as below: Two pointers which might/might not be helpful: 1) Can you reproduce the same behaviour using a legacy gadget, that is, when your gadget is not composed with configfs but rather loaded as a module (g_ether for example)? 2) Once upon a time I had a very strange error: http://www.spinics.net/lists/linux-usb/msg99135.html The communication over ethernet gadget used to break randomly. It turned out it was a toolchain error. AP -- 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: [PATCHv2 18/18] Documentation: usb: UAC2 function testing
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com --- Documentation/usb/gadget-testing.txt | 27 +++ 1 file changed, 27 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 40d22d8..b946f79 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -17,6 +17,7 @@ provided by gadgets. 14. SERIAL function 15. SOURCESINK function 16. UAC1 function +17. UAC2 function 1. ACM function @@ -614,3 +615,29 @@ Testing the UAC1 function device: run the gadget host: aplay -l # should list our USB Audio Gadget + +17. UAC2 function += + +The function is provided by usb_f_uac2.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is uac2. +The uac2 function provides these attributes in its function directory: + + chmask - capture channel mask + c_srate - capture sampling rate + c_ssize - capture sample size (bytes) + p_chmask - playback channel mask + p_srate - playback sampling rate + p_ssize - playback sample size (bytes) + +The attributes have sane default values. + +Testing the UAC2 function +- + +device: run the gadget UAC2 may a little complicated, you may need to run below command at device side: root@imx6sxsabresd:~# arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 arecord uses uac2_gadget to record, aplay uses real codec to play +host: aplay -l # should list our USB Audio Gadget -- 1.9.1 -- 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 -- 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/4] phy: samsung-usb2: Add support for Vbus regulator
This has been on my to-do list for sometime. Until now the host controller (specifically ehci-exynos) is responsible for enabling VBUS supply. This opens up one more issue which is, when only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was never enabled (since ohci did not have the code to enabled the VBUS supply). Rather it should be wise to move the VBUS related stuff to phy driver and let phy take care of enabling it. This patch series adds that VBUS regulator to phy-samsung-usb2 driver, adds necessary binding information as well as vbus-supply properties to phy nodes on exynos5250 systems. Also we have removed the samsung,vbus-gpio property from usb2 (ehci) node on exynos5250 systems. **[The older code in ehci-exynos for vbus setting is left intact to keep supporting older dt bindings]. Vivek Gautam (4): Doc/devicetree: bindings: Update bindings information for USB3.0 DRD PHY phy: samsung-usb2: Add facility for VBUS supply arm: dts: exynos5250: Use regulator for USB 2.0 VBUS supply arm: dts: exynos5250: Remove vbus gpio property from usb 2.0 host .../devicetree/bindings/phy/samsung-phy.txt| 12 arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 -- arch/arm/boot/dts/exynos5250-snow.dts | 22 -- drivers/phy/phy-samsung-usb2.c | 30 drivers/phy/phy-samsung-usb2.h |1 + 5 files changed, 83 insertions(+), 4 deletions(-) -- 1.7.10.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 1/4] Doc/devicetree: bindings: Update bindings information for USB3.0 DRD PHY
Add missing VBUS-supply information and consumer usage information for
USB 3.0 DRD PHY.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/devicetree/bindings/phy/samsung-phy.txt |9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index d5bad92..0090ad1 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -148,6 +148,9 @@ Required properties:
control pmu registers for power isolation.
- #phy-cells : from the generic PHY bindings, must be 1;
+Optional properties:
+- vbus-supply : Reference to regulator node which supplies VBUS on the PHY.
+
For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
compatible PHYs, the second cell in the PHY specifier identifies the
PHY id, which is interpreted as follows:
@@ -164,6 +167,12 @@ Example:
#phy-cells = 1;
};
+Then the PHY can be used in other nodes such as:
+ phy-consumer@1234 {
+ phys = usbdrd_phy 0, usbdrd_phy 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+
- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY
controllers,
'usbdrd_phy' nodes should have numbered alias in the aliases node,
in the form of usbdrdphyN, N = 0, 1... (depending on number of
--
1.7.10.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 2/4] phy: samsung-usb2: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a regulator
on USB 2.0 port.
This is a part of moving vbus setting out of ehci-exynos.
Since vbus can be handled by USB 2.0 phy itself, so the host
need not care about it.
Moreover, setting VBUS in USB 2.0 phy helps both ehci as well
as ohci. This issue was not taken care of until now; when
ehci is not enabled and only ohci is enabled the VBUS was never
set.
Keeping the vbus setting code in ehci-exynos intact for now
to keep supporting older dt bindings.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt|3 ++
drivers/phy/phy-samsung-usb2.c | 30
drivers/phy/phy-samsung-usb2.h |1 +
3 files changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 0090ad1..44d82ba 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -44,6 +44,9 @@ Required properties:
- the ref clock is used to get the rate of the clock provided to the
PHY module
+Optional properties:
+- vbus-supply : Reference to regulator node which supplies VBUS on the PHY.
+
The first phandle argument in the PHY specifier identifies the PHY, its
meaning is compatible dependent. For the currently supported SoCs (Exynos 4210
and Exynos 4212) it is as follows:
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index 4a12f66..7fe7c84 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -16,6 +16,7 @@
#include linux/of_address.h
#include linux/phy/phy.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
#include linux/spinlock.h
#include phy-samsung-usb2.h
@@ -33,6 +34,16 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
ret = clk_prepare_enable(drv-ref_clk);
if (ret)
goto err_instance_clk;
+
+ /* Enable VBUS supply */
+ if (drv-vbus) {
+ ret = regulator_enable(drv-vbus);
+ if (ret) {
+ dev_err(drv-dev, Failed to enable VBUS supply\n);
+ goto err_fail_vbus;
+ }
+ }
+
if (inst-cfg-power_on) {
spin_lock(drv-lock);
ret = inst-cfg-power_on(inst);
@@ -41,6 +52,8 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
return 0;
+err_fail_vbus:
+ clk_disable_unprepare(drv-ref_clk);
err_instance_clk:
clk_disable_unprepare(drv-clk);
err_main_clk:
@@ -60,8 +73,14 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
ret = inst-cfg-power_off(inst);
spin_unlock(drv-lock);
}
+
+ /* Disable VBUS supply */
+ if (drv-vbus)
+ regulator_disable(drv-vbus);
+
clk_disable_unprepare(drv-ref_clk);
clk_disable_unprepare(drv-clk);
+
return ret;
}
@@ -197,6 +216,17 @@ static int samsung_usb2_phy_probe(struct platform_device
*pdev)
return ret;
}
+ /* Get Vbus regulators */
+ drv-vbus = devm_regulator_get(dev, vbus);
+ if (IS_ERR(drv-vbus)) {
+ ret = PTR_ERR(drv-vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, Failed to get VBUS supply regulator\n);
+ drv-vbus = NULL;
+ }
+
for (i = 0; i drv-cfg-num_phys; i++) {
char *label = drv-cfg-phys[i].label;
struct samsung_usb2_phy_instance *p = drv-instances[i];
diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
index 44bead9..cb92e3e 100644
--- a/drivers/phy/phy-samsung-usb2.h
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -43,6 +43,7 @@ struct samsung_usb2_phy_driver {
void __iomem *reg_phy;
struct regmap *reg_pmu;
struct regmap *reg_sys;
+ struct regulator *vbus;
spinlock_t lock;
struct samsung_usb2_phy_instance instances[0];
};
--
1.7.10.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 3/4] arm: dts: exynos5250: Use regulator for USB 2.0 VBUS supply
Start using VBUS regulator for USB 2.0 phy, so that we can
remove the gpio property from host's node later.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 ++
arch/arm/boot/dts/exynos5250-snow.dts | 22 ++
2 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a759100..85e74df 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -361,6 +361,17 @@
samsung,audio-codec = wm8994;
};
+ usb2_vbus_reg: regulator-usb2 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB2;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpx2 6 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb2_vbus_en;
+ enable-active-high;
+ };
+
usb@1211 {
samsung,vbus-gpio = gpx2 6 0;
};
@@ -418,4 +429,15 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ usb2_vbus_en: usb2-vbus-en {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+};
+
+usb2_phy_gen {
+ vbus-supply = usb2_vbus_reg;
};
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 60429ad..8085750 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -285,6 +285,17 @@
vbus-supply = usb3_vbus_reg;
};
+ usb2_vbus_reg: regulator-usb2 {
+ compatible = regulator-fixed;
+ regulator-name = P5.0V_USB2;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpx1 1 0;
+ pinctrl-names = default;
+ pinctrl-0 = usb2_vbus_en;
+ enable-active-high;
+ };
+
usb@1211 {
samsung,vbus-gpio = gpx1 1 0;
};
@@ -616,6 +627,13 @@
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
+
+ usb2_vbus_en: usb2-vbus-en {
+ samsung,pins = gpx1-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
};
spi_1 {
@@ -628,4 +646,8 @@
dr_mode = host;
};
+usb2_phy_gen {
+ vbus-supply = usb2_vbus_reg;
+};
+
#include cros-ec-keyboard.dtsi
--
1.7.10.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 4/4] arm: dts: exynos5250: Remove vbus gpio property from usb 2.0 host
Now that we can use the VBUS regulator for USB 2.0 phy, we can
remove the vbus-gpio property from usb 2.0 host to avoid
duplicate gpio settings.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250-smdk5250.dts |4
arch/arm/boot/dts/exynos5250-snow.dts |4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 85e74df..281b962 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -372,10 +372,6 @@
enable-active-high;
};
- usb@1211 {
- samsung,vbus-gpio = gpx2 6 0;
- };
-
dp-controller@145B {
samsung,color-space = 0;
samsung,dynamic-range = 0;
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 8085750..ee966c3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -296,10 +296,6 @@
enable-active-high;
};
- usb@1211 {
- samsung,vbus-gpio = gpx1 1 0;
- };
-
fixed-rate-clocks {
xxti {
compatible = samsung,clock-xxti;
--
1.7.10.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
Re: Query regarding USB gadget driver
Hello Andrzej, Thanks for the input. On 12/11/2014 04:34 PM, Andrzej Pietrasiewicz wrote: Hello, W dniu 11.12.2014 o 11:38, Sanchayan Maity pisze: Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just ping to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is kevent 12 may have been dropped. I guess this is connected to the TCP Previous Segment not captured and TCP Dup ACK messages. My script for the gadget configuration is as below: Two pointers which might/might not be helpful: 1) Can you reproduce the same behaviour using a legacy gadget, that is, when your gadget is not composed with configfs but rather loaded as a module (g_ether for example)? I was not using configfs at the start actually. g_ether was compiled as a module and it gives the same results. I switched to using configfs later when I came to know about it, as I also wanted to test serial and mass storage gadget. Did not stress test these functionalities, but, they seem to work. Tested serial bulk in/out, CDC ACM and gadget mass storage. 2) Once upon a time I had a very strange error: http://www.spinics.net/lists/linux-usb/msg99135.html The communication over ethernet gadget used to break randomly. It turned out it was a toolchain error. I have already tried this with two toolchains. One is Linaro GCC 4.7.2 pre-built and the other Linaro GCC 4.7.8 created by Open Embedded. AP --Sanchayan -- 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 0/4] phy: samsung-usb2: Add support for Vbus regulator
From: Vivek Gautam This has been on my to-do list for sometime. Until now the host controller (specifically ehci-exynos) is responsible for enabling VBUS supply. This opens up one more issue which is, when only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was never enabled (since ohci did not have the code to enabled the VBUS supply). Rather it should be wise to move the VBUS related stuff to phy driver and let phy take care of enabling it. This patch series adds that VBUS regulator to phy-samsung-usb2 driver, adds necessary binding information as well as vbus-supply properties to phy nodes on exynos5250 systems. ... Does this go anyway to allowing devices to be powered from a micro-usb connector while acting as a USB host (USB OTG). ie when you want VBUS disabled even though it would normally need to be enabled. David -- 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] extcon: add MAX3355 driver
Hello. On 12/11/2014 4:46 AM, Chanwoo Choi wrote: I reviewed this patch quickly. This driver has just two gpio without any registers for IP. Because there are no registers. I wonder whether MAX3355E is separate chip to detect external connector Yes. I thought my description has made that clear... or just use gpio of AP. What do you mean by AP? MAX3355 is indeed partly connected to GPIOs and partly to the USB pins. Could you send the datasheet of MAX3355E to me? Looks like Geert has beaten me to it. :-) Thanks, Chanwoo Choi 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] extcon: add MAX3355 driver
On 12/11/2014 09:47 PM, Sergei Shtylyov wrote: Hello. On 12/11/2014 4:46 AM, Chanwoo Choi wrote: I reviewed this patch quickly. This driver has just two gpio without any registers for IP. Because there are no registers. I wonder whether MAX3355E is separate chip to detect external connector Yes. I thought my description has made that clear... or just use gpio of AP. What do you mean by AP? MAX3355 is indeed partly connected to GPIOs and partly to the USB pins. Could you send the datasheet of MAX3355E to me? Looks like Geert has beaten me to it. :-) Thanks, Chanwoo Choi OK, I'll review it. Thanks, Chanwoo Choi -- 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 0/4] phy: samsung-usb2: Add support for Vbus regulator
On Thu, Dec 11, 2014 at 5:52 PM, David Laight david.lai...@aculab.com wrote: From: Vivek Gautam This has been on my to-do list for sometime. Until now the host controller (specifically ehci-exynos) is responsible for enabling VBUS supply. This opens up one more issue which is, when only ohci-exynos is enabled and ehci-exynosis disabled then VBUS was never enabled (since ohci did not have the code to enabled the VBUS supply). Rather it should be wise to move the VBUS related stuff to phy driver and let phy take care of enabling it. This patch series adds that VBUS regulator to phy-samsung-usb2 driver, adds necessary binding information as well as vbus-supply properties to phy nodes on exynos5250 systems. ... Does this go anyway to allowing devices to be powered from a micro-usb connector while acting as a USB host (USB OTG). ie when you want VBUS disabled even though it would normally need to be enabled. Sorry i didn't get your second line. This change allows HOST and HSIC phys to enable VBUS for the devices connected to it. Although now i think there can be a flaw in this approach when only in OTG mode, when DEVICE phy is being used, even then the regulator will be turned on causing power unnecessary consumption. -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 2/3] gpio: dln2: use bus_sync_unlock instead of scheduling work
Use the irq_chip bus_sync_unlock method to update hardware registers
instead of scheduling work from the mask/unmask methods. This simplifies
a bit the driver and make it more uniform with the other GPIO IRQ
drivers.
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/gpio/gpio-dln2.c | 92 +++-
1 file changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 28a62c4..2fdb138 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -47,13 +47,6 @@
#define DLN2_GPIO_MAX_PINS 32
-struct dln2_irq_work {
- struct work_struct work;
- struct dln2_gpio *dln2;
- int pin;
- int type;
-};
-
struct dln2_gpio {
struct platform_device *pdev;
struct gpio_chip gpio;
@@ -66,7 +59,10 @@ struct dln2_gpio {
/* active IRQs - not synced to hardware */
DECLARE_BITMAP(unmasked_irqs, DLN2_GPIO_MAX_PINS);
- struct dln2_irq_work *irq_work;
+ /* active IRQS - synced to hardware */
+ DECLARE_BITMAP(enabled_irqs, DLN2_GPIO_MAX_PINS);
+ int irq_type[DLN2_GPIO_MAX_PINS];
+ struct mutex irq_lock;
};
struct dln2_gpio_pin {
@@ -296,18 +292,6 @@ static int dln2_gpio_set_event_cfg(struct dln2_gpio *dln2,
unsigned pin,
req, sizeof(req));
}
-static void dln2_irq_work(struct work_struct *w)
-{
- struct dln2_irq_work *iw = container_of(w, struct dln2_irq_work, work);
- struct dln2_gpio *dln2 = iw-dln2;
- u8 type = iw-type DLN2_GPIO_EVENT_MASK;
-
- if (test_bit(iw-pin, dln2-unmasked_irqs))
- dln2_gpio_set_event_cfg(dln2, iw-pin, type, 0);
- else
- dln2_gpio_set_event_cfg(dln2, iw-pin, DLN2_GPIO_EVENT_NONE, 0);
-}
-
static void dln2_irq_unmask(struct irq_data *irqd)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
@@ -315,7 +299,6 @@ static void dln2_irq_unmask(struct irq_data *irqd)
int pin = irqd_to_hwirq(irqd);
set_bit(pin, dln2-unmasked_irqs);
- schedule_work(dln2-irq_work[pin].work);
}
static void dln2_irq_mask(struct irq_data *irqd)
@@ -325,7 +308,6 @@ static void dln2_irq_mask(struct irq_data *irqd)
int pin = irqd_to_hwirq(irqd);
clear_bit(pin, dln2-unmasked_irqs);
- schedule_work(dln2-irq_work[pin].work);
}
static int dln2_irq_set_type(struct irq_data *irqd, unsigned type)
@@ -336,19 +318,19 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
switch (type) {
case IRQ_TYPE_LEVEL_HIGH:
- dln2-irq_work[pin].type = DLN2_GPIO_EVENT_LVL_HIGH;
+ dln2-irq_type[pin] = DLN2_GPIO_EVENT_LVL_HIGH;
break;
case IRQ_TYPE_LEVEL_LOW:
- dln2-irq_work[pin].type = DLN2_GPIO_EVENT_LVL_LOW;
+ dln2-irq_type[pin] = DLN2_GPIO_EVENT_LVL_LOW;
break;
case IRQ_TYPE_EDGE_BOTH:
- dln2-irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE;
+ dln2-irq_type[pin] = DLN2_GPIO_EVENT_CHANGE;
break;
case IRQ_TYPE_EDGE_RISING:
- dln2-irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE_RISING;
+ dln2-irq_type[pin] = DLN2_GPIO_EVENT_CHANGE_RISING;
break;
case IRQ_TYPE_EDGE_FALLING:
- dln2-irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE_FALLING;
+ dln2-irq_type[pin] = DLN2_GPIO_EVENT_CHANGE_FALLING;
break;
default:
return -EINVAL;
@@ -357,11 +339,50 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
return 0;
}
+static void dln2_irq_bus_lock(struct irq_data *irqd)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
+ struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
+
+ mutex_lock(dln2-irq_lock);
+}
+
+static void dln2_irq_bus_unlock(struct irq_data *irqd)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
+ struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
+ int pin = irqd_to_hwirq(irqd);
+ int enabled, unmasked;
+ unsigned type;
+ int ret;
+
+ enabled = test_bit(pin, dln2-enabled_irqs);
+ unmasked = test_bit(pin, dln2-unmasked_irqs);
+
+ if (enabled != unmasked) {
+ if (unmasked) {
+ type = dln2-irq_type[pin] DLN2_GPIO_EVENT_MASK;
+ set_bit(pin, dln2-enabled_irqs);
+ } else {
+ type = DLN2_GPIO_EVENT_NONE;
+ clear_bit(pin, dln2-enabled_irqs);
+ }
+
+ ret = dln2_gpio_set_event_cfg(dln2, pin, type, 0);
+ if (ret)
+ dev_err(dln2-gpio.dev, failed to set event\n);
+ }
+
+ mutex_unlock(dln2-irq_lock);
+}
+
static struct irq_chip dln2_gpio_irqchip = {
[PATCH 3/3] mfd: dln2: add suspend/resume functionality
Without suspend/resume functionality in the USB driver the USB core
will disconnect and reconnect the DLN2 port and because the GPIO
framework does not yet support removal of an in-use controller a
suspend/resume operation will result in a crash.
This patch provides suspend and resume functions for the DLN2 driver
so that the above scenario is avoided.
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/mfd/dln2.c | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 6d49685..08c403c 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -587,7 +587,6 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
int i;
for (i = 0; i DLN2_MAX_URBS; i++) {
- usb_kill_urb(dln2-rx_urb[i]);
usb_free_urb(dln2-rx_urb[i]);
kfree(dln2-rx_buf[i]);
}
@@ -665,9 +664,8 @@ static const struct mfd_cell dln2_devs[] = {
},
};
-static void dln2_disconnect(struct usb_interface *interface)
+static void dln2_stop(struct dln2_dev *dln2)
{
- struct dln2_dev *dln2 = usb_get_intfdata(interface);
int i, j;
/* don't allow starting new transfers */
@@ -696,6 +694,16 @@ static void dln2_disconnect(struct usb_interface
*interface)
/* wait for transfers to end */
wait_event(dln2-disconnect_wq, !dln2-active_transfers);
+ for (i = 0; i DLN2_MAX_URBS; i++)
+ usb_kill_urb(dln2-rx_urb[i]);
+}
+
+static void dln2_disconnect(struct usb_interface *interface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(interface);
+
+ dln2_stop(dln2);
+
mfd_remove_devices(interface-dev);
dln2_free(dln2);
@@ -767,11 +775,38 @@ static const struct usb_device_id dln2_table[] = {
MODULE_DEVICE_TABLE(usb, dln2_table);
+static int dln2_suspend(struct usb_interface *iface, pm_message_t message)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(iface);
+
+ dln2_stop(dln2);
+ return 0;
+}
+
+static int dln2_resume(struct usb_interface *iface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(iface);
+ int i;
+ int ret = 0;
+
+ dln2-disconnect = false;
+
+ for (i = 0; i DLN2_MAX_URBS; i++) {
+ ret = usb_submit_urb(dln2-rx_urb[i], GFP_KERNEL);
+ if (ret)
+ break;
+ }
+
+ return ret;
+}
+
static struct usb_driver dln2_driver = {
.name = dln2,
.probe = dln2_probe,
.disconnect = dln2_disconnect,
.id_table = dln2_table,
+ .suspend = dln2_suspend,
+ .resume = dln2_resume,
};
module_usb_driver(dln2_driver);
--
1.9.1
--
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/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
As noticed during suspend/resume operations, the IRQ can be unmasked
then disabled in suspend and eventually enabled in resume, but without
being unmasked.
The current implementation does not take into account interactions
between mask/unmask and enable/disable interrupts, and thus in the
above scenarios the IRQs remain unactive.
To fix this we removed the enable/disable operations as they fallback
to mask/unmask anyway.
We also remove the pending bitmaks as it is already done in irq_data
(i.e. IRQS_PENDING).
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
drivers/gpio/gpio-dln2.c | 53 +++-
1 file changed, 7 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 978b51e..28a62c4 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -64,9 +64,8 @@ struct dln2_gpio {
*/
DECLARE_BITMAP(output_enabled, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ /* active IRQs - not synced to hardware */
+ DECLARE_BITMAP(unmasked_irqs, DLN2_GPIO_MAX_PINS);
struct dln2_irq_work *irq_work;
};
@@ -303,29 +302,19 @@ static void dln2_irq_work(struct work_struct *w)
struct dln2_gpio *dln2 = iw-dln2;
u8 type = iw-type DLN2_GPIO_EVENT_MASK;
- if (test_bit(iw-pin, dln2-irqs_enabled))
+ if (test_bit(iw-pin, dln2-unmasked_irqs))
dln2_gpio_set_event_cfg(dln2, iw-pin, type, 0);
else
dln2_gpio_set_event_cfg(dln2, iw-pin, DLN2_GPIO_EVENT_NONE, 0);
}
-static void dln2_irq_enable(struct irq_data *irqd)
-{
- struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
- struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
- int pin = irqd_to_hwirq(irqd);
-
- set_bit(pin, dln2-irqs_enabled);
- schedule_work(dln2-irq_work[pin].work);
-}
-
-static void dln2_irq_disable(struct irq_data *irqd)
+static void dln2_irq_unmask(struct irq_data *irqd)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
int pin = irqd_to_hwirq(irqd);
- clear_bit(pin, dln2-irqs_enabled);
+ set_bit(pin, dln2-unmasked_irqs);
schedule_work(dln2-irq_work[pin].work);
}
@@ -335,27 +324,8 @@ static void dln2_irq_mask(struct irq_data *irqd)
struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
int pin = irqd_to_hwirq(irqd);
- set_bit(pin, dln2-irqs_masked);
-}
-
-static void dln2_irq_unmask(struct irq_data *irqd)
-{
- struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
- struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
- struct device *dev = dln2-gpio.dev;
- int pin = irqd_to_hwirq(irqd);
-
- if (test_and_clear_bit(pin, dln2-irqs_pending)) {
- int irq;
-
- irq = irq_find_mapping(dln2-gpio.irqdomain, pin);
- if (!irq) {
- dev_err(dev, pin %d not mapped to IRQ\n, pin);
- return;
- }
-
- generic_handle_irq(irq);
- }
+ clear_bit(pin, dln2-unmasked_irqs);
+ schedule_work(dln2-irq_work[pin].work);
}
static int dln2_irq_set_type(struct irq_data *irqd, unsigned type)
@@ -389,8 +359,6 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
static struct irq_chip dln2_gpio_irqchip = {
.name = dln2-irq,
- .irq_enable = dln2_irq_enable,
- .irq_disable = dln2_irq_disable,
.irq_mask = dln2_irq_mask,
.irq_unmask = dln2_irq_unmask,
.irq_set_type = dln2_irq_set_type,
@@ -425,13 +393,6 @@ static void dln2_gpio_event(struct platform_device *pdev,
u16 echo,
return;
}
- if (!test_bit(pin, dln2-irqs_enabled))
- return;
- if (test_bit(pin, dln2-irqs_masked)) {
- set_bit(pin, dln2-irqs_pending);
- return;
- }
-
switch (dln2-irq_work[pin].type) {
case DLN2_GPIO_EVENT_CHANGE_RISING:
if (event-value)
--
1.9.1
--
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/3] DLN2 fixes related to suspend/resume
First patch in the series fixes a GPIO IRQ issues found during suspend/resume testing, the next simplifies a bit the IRQ code and the last adds support for suspend/resume to DLN2 to avoid a crash during suspend caused by the fact that we cant unplug a GPIO controller while it is in use. As suggested by Johan, I have tested the suspend/resume on barebone hardware, in addition to KVM USB pass-through and reset_resume routine is not neccessary on barebone hardware. It looks like with KVM USB pass-through the emulated port is reseted during suspend/resume regardless of the state of the physical port. Octavian Purdila (3): gpio: dln2: fix issue when an IRQ is unmasked then enabled gpio: dln2: use bus_sync_unlock instead of scheduling work mfd: dln2: add suspend/resume functionality drivers/gpio/gpio-dln2.c | 141 +++ drivers/mfd/dln2.c | 41 +- 2 files changed, 94 insertions(+), 88 deletions(-) -- 1.9.1 -- 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: Query regarding USB gadget driver
Hi, On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just ping to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is kevent 12 may have been dropped. I guess this is connected to the TCP Previous Segment not captured and TCP Dup ACK messages. My script for the gadget configuration is as below: /bin/mount none /mnt -t configfs /bin/mkdir /mnt/usb_gadget/g1 cd /mnt/usb_gadget/g1 /bin/mkdir configs/c.1 /bin/mkdir functions/ecm.0 /bin/mkdir strings/0x409 /bin/mkdir configs/c.1/strings/0x409 echo 0xa4a2 idProduct echo 0x0525 idVendor echo Freescale123 strings/0x409/serialnumber echo Freescale strings/0x409/manufacturer echo USB Serial Gadget strings/0x409/product echo Conf 1 configs/c.1/strings/0x409/configuration echo 200 configs/c.1/MaxPower ln -s functions/ecm.0 configs/c.1 echo ci_hdrc.0 UDC /sbin/ifconfig usb0 up /sbin/ifconfig usb0 192.168.1.10 I have debug prints in the udc.c and u_ether.c using pr_debug and just a little hint, use any of the dev_*() macros next time, they'll print the device name which helps figuring out which UDC you're using. Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen maintains that one, it really helps adding maintainers to Cc list. enable them when required using dynamic debug. Without running iperf, using ping gives me a sequence of prints as below: [ 277.434409] In eth_start_xmit [ 277.434517] In UDC irq [ 277.434553] In usb_gadget_giveback_request [ 277.434567] In tx_complete [ 277.435443] In UDC irq [ 277.435477] In usb_gadget_giveback_request [ 277.435491] In rx_complete [ 277.435517] In rx_submit [ 277.435601] In eth_start_xmit [ 277.436441] In UDC irq [ 277.436465] In usb_gadget_giveback_request [ 277.436478] In rx_complete [ 277.436493] In rx_submit [ 277.436520] In usb_gadget_giveback_request [ 277.436533] In tx_complete [ 278.434865] In eth_start_xmit [ 278.434959] In UDC irq [ 278.434993] In usb_gadget_giveback_request [ 278.435006] In tx_complete [ 278.435881] In UDC irq [ 278.435910] In usb_gadget_giveback_request [ 278.435923] In rx_complete [ 278.435946] In rx_submit After running iperf without debug prints and then enabling before using ping gives me a sequence of prints as below [ 81.989827] In UDC irq [ 81.989871] In usb_gadget_giveback_request [ 81.989886] In rx_complete [ 81.989905] In rx_submit [ 82.989892] In UDC irq [ 82.989951] In usb_gadget_giveback_request [ 82.989967] In rx_complete [ 82.989992] In rx_submit [ 83.990064] In UDC irq [ 83.990126] In usb_gadget_giveback_request [ 83.990142] In rx_complete [ 83.990167] In rx_submit [ 84.990007] In UDC irq [ 84.990049] In usb_gadget_giveback_request [ 84.990064] In rx_complete [ 84.990083] In rx_submit [ 85.990085] In UDC irq [ 85.990147] In usb_gadget_giveback_request [ 85.990163] In rx_complete [ 85.990188] In rx_submit If I force a full speed configuration for this USB client port, I get a slightly more reliable operation where iperf can run for may be half an hour or so or almost an hour before it falls through. Putting in a delay of 100-150 microseconds in eth_start_xmit also improves it like full speed, but, still not reliable. If I run iperf with debug prints enable, this gives similar results to full speed config. After the failure of iperf test, even ping doesn't work. Bringing down this usb0 interface and then up again makes ping work again. I do realize that putting debug prints or delays like this is not the right thing to do, especially in ISR, but, just trying to debug. This is my first time digging in the USB stack. Based on the above, it seems there might a subtle bug or race condition somewhere in the execution call chain which I have not been able to trace yet. Can someone give me some pointers on how I can dig and debug further?. yeah, I'd start pointing fingers at chipidea. But just to make sure, can you try the same thing with dummy_hcd ? dummy_hcd is a SW-only host and peripheral controller pair tied together. If that one works, you definitely have a bug with chipidea. If you want to debug chipidea like
[RFC PATCH] mfd: dln2: add support for ACPI
This patch adds support to load a custom ACPI table that describes
devices connected via the DLN2 USB to I2C/SPI/GPIO bridge.
The ACPI table is loaded at runtime as firmware with the name
dln2.aml, it looks for an ACPI device entry with _HID set to
DLN2 and makes it the ACPI companion for DLN2 USB sub-drivers.
It is sort of a hack due to the ../acpi/internal.h and
../usb/core/usb.h includes and perhaps something more generic would
be more appropriate. Any suggestions to the right direction are kindly
appreciated.
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
Documentation/acpi/dln2-acpi.txt | 48 ++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2-acpi.c | 103 +++
drivers/mfd/dln2.c | 6 +--
drivers/mfd/dln2.h | 9
6 files changed, 173 insertions(+), 5 deletions(-)
create mode 100644 Documentation/acpi/dln2-acpi.txt
create mode 100644 drivers/mfd/dln2-acpi.c
create mode 100644 drivers/mfd/dln2.h
diff --git a/Documentation/acpi/dln2-acpi.txt b/Documentation/acpi/dln2-acpi.txt
new file mode 100644
index 000..c099241
--- /dev/null
+++ b/Documentation/acpi/dln2-acpi.txt
@@ -0,0 +1,48 @@
+Diolan DLN2 custom APCI table
+
+The Diolan DLN2 is an USB to I2C/SPI/GPIO bridge and as such it can be used to
+connect to various I2C or SPI devices. Because these busses lack an enumeration
+protocol, the driver obtains various information about the device (such as I2C
+address and GPIO pins) from either ACPI or device tree.
+
+To allow using such devices connect to the DLN2 bridge to their full extend
+(e.g. interrupt mode), if CONFIG_MFD_DLN2_ACPI option has been compiled in the
+kernel, the user can define a custom ACPI table that will be dynamically loaded
+at boot time from firmware paths. The ACPI table filename must be dln2.aml and
+it must contain a root device with _HID set DLN2.
+
+Here is a example of how the ACPI table should look like:
+
+DefinitionBlock (ssdt.aml, SSDT, 1, INTEL , CpuDptf, 0x0003)
+{
+ Device (DLN0)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, DLN2000)
+
+ Device (STAC)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, BMC150A)
+ Name (_CID, INTACCL)
+ Name (_UID, One)
+
+ Method (_CRS, 0, Serialized)
+ {
+ Name (RBUF, ResourceTemplate ()
+ {
+ I2cSerialBus (0x0010,
ControllerInitiated, 0x00061A80,
+ AddressingMode7Bit,
\\DLN0,
+ 0x00, ResourceConsumer, ,)
+
+ GpioInt (Level, ActiveHigh, Exclusive,
PullDown, 0x,
+\\DLN0, 0x00,
ResourceConsumer, , )
+ { // Pin list
+ 0
+ }
+ })
+ Return (RBUF)
+ }
+ }
+ }
+}
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..b810195 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -205,6 +205,17 @@ config MFD_DLN2
etc. must be enabled in order to use the functionality of
the device.
+config MFD_DLN2_ACPI
+ bool Diolan DLN2 ACPI support
+ depends on MFD_DLN2 ACPI
+ default n
+ help
+ Say yes here to add ACPI support to DLN2 which allows loading a custom
+ ACPI table to describe devices between the DLN2 I2C or SPI bridge as
+ well as GPIO support for those devices. See
+ Documentation/acpi/dln2-acpi.txt for more information.
+
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..dbe1f3f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -176,6 +176,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO)+= ipaq-micro.o
obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
+obj-$(CONFIG_MFD_DLN2_ACPI)+= dln2-acpi.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2-acpi.c b/drivers/mfd/dln2-acpi.c
new file mode 100644
index 000..8c99769
--- /dev/null
+++ b/drivers/mfd/dln2-acpi.c
@@ -0,0 +1,103 @@
+#define pr_fmt(fmt) dln2-acpi: fmt
+
+#include linux/module.h
+#include linux/usb.h
+#include linux/device.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/acpi.h
[PATCH] usb: musb: stuff leak of struct usb_hcd
since the split of host+gadget mode in commit 74c2e9360058 (usb: musb: factor out hcd initalization) we leak the usb_hcd struct. We call now musb_host_cleanup() which does basically usb_remove_hcd() and also sets the hcd variable to NULL. Doing so makes the finall call to musb_host_free() basically a nop and the usb_hcd remains around for ever without anowner. This patch drops that NULL assignment for that reason. Fixes: 74c2e9360058 (usb: musb: factor out hcd initalization) Cc: sta...@vger.kernel.org Cc: Daniel Mack zon...@gmail.com Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_host.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index 855793d701bb..4500610356f2 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -2663,7 +2663,6 @@ void musb_host_cleanup(struct musb *musb) if (musb-port_mode == MUSB_PORT_MODE_GADGET) return; usb_remove_hcd(musb-hcd); - musb-hcd = NULL; } void musb_host_free(struct musb *musb) -- 2.1.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: [GIT PULL] USB driver fixes for 3.18-rc7
On Wed, Dec 03, 2014 at 06:02:08PM +0200, Mathias Nyman wrote: On 02.12.2014 20:18, Greg KH wrote: On Sun, Nov 30, 2014 at 11:47:20AM -0800, Linus Torvalds wrote: Hmm, Greg. I seem to get this problem possibly more commonly at boot these days: usb 1-6: new full-speed USB device number 2 using xhci_hcd usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 3 using xhci_hcd usb 1-6: device descriptor read/64, error -71 usb 1-6: hub failed to enable device, error -22 usb 1-6: new full-speed USB device number 4 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 4, error -71 usb 1-6: new full-speed USB device number 5 using xhci_hcd usb 1-6: Device not responding to setup address. usb 1-6: Device not responding to setup address. usb 1-6: device not accepting address 5, error -71 usb usb1-port6: unable to enumerate USB device and my keyboard doesn't work. I then unplug and re-plug it, and get usb 1-6: new full-speed USB device number 9 using xhci_hcd usb 1-6: New USB device found, idVendor=2516, idProduct=0020 usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6: Product: Quickfire Rapid i usb 1-6: Manufacturer: CM Storm Any ideas? Some setup delay that isn't long enough at boot time for a slightly finicky device? It has happened before, but now I've gotten it twice within a couple of days: Nov 02 12:18:56 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 28 16:54:06 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 Nov 30 11:26:35 i7.lan kernel: usb 1-6: device descriptor read/64, error -71 (I've had this keyboard since mid-September, and looking at the logs this machine has been rebooted 41 times since, with those three failures..) I've been seeing this occasionally recently as well, but was blaming a bad USB 3 hub I have here that I use, and the problem goes away with a replug. Mathias, any ideas what is going on here? Looks like when xhci changed to use new scheme device enumeration for non SuperSpeed devices, we broke the device descriptor read retry for xhci. Normally we try to read the descriptor again, and if it still fails then fall back to old scheme. In this failing xhci case the slot is left in a default state after first failed descriptor read, and we then try to enable the slot again in retry, which is an invalid xhci context state change, and prints the error message: xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1 I see this all the time on my MinnowboardMax. For slot 2 that is. And on this machine, it does not boot from USB properly, I have to, after the kernel comes up (which was read off of USB by UEFI just fine), unplug and plug the storage device back in so that the boot process continues. Works that way for 2 different USB 3.0 storage devices. After this It might be hard to get the device addressed. I don't know why it fail the first device descriptor read, but fixing the xhci part should allow more real reties. I'll work on it. The change to use xhci new scheme enumeration was done in 3.14 to support known legacy devices requiring it. commit 48fc7dbd52c0559647291f33a10ccdc6cdbe4c72 How can that break non-legacy devices? 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
[PATCH] uas: disable UAS on Apricorn SATA dongles
The Apricorn SATA dongle will occasionally return USBSUSBSUSB in response to SCSI commands when running in UAS mode. Therefore, disable UAS mode on this dongle. Signed-off-by: Darrick J. Wong darrick.w...@oracle.com --- drivers/usb/storage/unusual_uas.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h index 18a283d..3530cb0 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -40,6 +40,16 @@ * and don't forget to CC: the USB development list linux-usb@vger.kernel.org */ +/* + * Apricorn USB3 dongle sometimes returns USBSUSBSUSBS in response to SCSI + * commands in UAS mode. Observed with the 1.28 firmware; are there others? + */ +UNUSUAL_DEV(0x0984, 0x0301, 0x0128, 0x0128, + Apricorn, + , + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_UAS), + /* https://bugzilla.kernel.org/show_bug.cgi?id=79511 */ UNUSUAL_DEV(0x0bc2, 0x2312, 0x, 0x, Seagate, -- 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: PROBLEM: [ums-realtek] media change events incorrectly implemented?
On Tue, 9 Dec 2014, Rubén Herrero wrote: With systemd 217, systemd-udevd complains every ~10 seconds (see below). No error shows up on 216. The systemd people claim this is a drivers issue. (See: https://bugs.freedesktop.org/show_bug.cgi?id=86414#c5) Lennart Poettering: Seems to be your card reader. The ums-realtek kernel USB driver seems to implement media change events incorrectly. Please contact the kernel/driver folks about this, there's little we can do about this from the systemd side. What does a usbmon trace show? 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
Re: [sur40] Videobuf2 and/or DMA?
On Sun, 7 Dec 2014, Florian Echtler wrote: Hello everyone, I'm preparing to finally add support for the raw sensor video stream to my driver for the SUR40 touchscreen. However, after an extensive amount of Googling, I'm still not clear on the relationship between DMA transfers, the USB core and the videobuf2 framework. Specifically, I'd like to know: - Can I always use DMA on the USB side (for bulk transfers), or does this in any way require support from the USB device's hardware? (I'm guessing no, but a definite answer would be great.) DMA requires hardware support in the USB host controller, not in the USB device. Most current USB host controllers support DMA; only a few of the oldest ones don't. 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
RE: [PATCH] usb: dwc2: gadget: kill requests with 'force' in s3c_hsotg_udc_stop()
From: Robert Baldyga [mailto:r.bald...@samsung.com]
Sent: Tuesday, December 09, 2014 5:42 AM
This makes us sure that all requests are completed before we unbind
gadget. There are assumptions in gadget API that all requests have to
be completed and leak of complete can break some usb function drivers.
For example unbind of ECM function can cause NULL pointer dereference:
[ 26.396595] configfs-gadget gadget: unbind function
'cdc_ethernet'/e79c4c00
[ 26.414999] Unable to handle kernel NULL pointer dereference at
virtual address
(...)
[ 26.452223] PC is at ecm_unbind+0x6c/0x9c
[ 26.456209] LR is at ecm_unbind+0x68/0x9c
(...)
[ 26.603696] [c033fdb4] (ecm_unbind) from [c033661c]
(purge_configs_funcs+0x94/0xd8)
[ 26.611674] [c033661c] (purge_configs_funcs) from [c0336674]
(configfs_composite_unbind+0x14/0x34)
[ 26.620961] [c0336674] (configfs_composite_unbind) from
[c0337124] (usb_gadget_remove_driver+0x68/0x9c)
[ 26.630683] [c0337124] (usb_gadget_remove_driver) from [c03376c8]
(usb_gadget_unregister_driver+0x64/0x94)
[ 26.640664] [c03376c8] (usb_gadget_unregister_driver) from
[c0336be8] (unregister_gadget+0x20/0x3c)
[ 26.650038] [c0336be8] (unregister_gadget) from [c0336c84]
(gadget_dev_desc_UDC_store+0x80/0xb8)
[ 26.659152] [c0336c84] (gadget_dev_desc_UDC_store) from
[c0335120] (gadget_info_attr_store+0x1c/0x28)
[ 26.668703] [c0335120] (gadget_info_attr_store) from [c012135c]
(configfs_write_file+0xe8/0x148)
[ 26.677818] [c012135c] (configfs_write_file) from [c00c8dd4]
(vfs_write+0xb0/0x1a0)
[ 26.685801] [c00c8dd4] (vfs_write) from [c00c91b8]
(SyS_write+0x44/0x84)
[ 26.692834] [c00c91b8] (SyS_write) from [c000e560]
(ret_fast_syscall+0x0/0x30)
[ 26.700381] Code: e30409f8 e34c0069 eb07b88d e59430a8 (e593)
[ 26.706485] ---[ end trace f62a082b323838a2 ]---
It's because in some cases request is still running on endpoint during
unbind and kill_all_requests() called from s3c_hsotg_udc_stop() function
doesn't cause call of complete() of request. Missing complete() call
causes ecm-notify_req equals NULL in ecm_unbind() function, and this
is reason of this bug.
Similar breaks can be observed in another usb function drivers.
This patch fixes this bug forcing usb request completion in when
s3c_hsotg_ep_disable() is called from s3c_hsotg_udc_stop().
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/dwc2/gadget.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 8b5c079..cb4c925 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2590,7 +2590,7 @@ error:
* s3c_hsotg_ep_disable - disable given endpoint
* @ep: The endpoint to disable.
*/
-static int s3c_hsotg_ep_disable(struct usb_ep *ep)
+static int s3c_hsotg_ep_disable_force(struct usb_ep *ep, bool force)
{
struct s3c_hsotg_ep *hs_ep = our_ep(ep);
struct s3c_hsotg *hsotg = hs_ep-parent;
@@ -2611,7 +2611,7 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
spin_lock_irqsave(hsotg-lock, flags);
/* terminate all requests with shutdown */
- kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, false);
+ kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, force);
hsotg-fifo_map = ~(1hs_ep-fifo_index);
hs_ep-fifo_index = 0;
@@ -2632,6 +2632,10 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
return 0;
}
+static int s3c_hsotg_ep_disable(struct usb_ep *ep)
+{
+ return s3c_hsotg_ep_disable_force(ep, false);
+}
/**
* on_list - check request is on the given endpoint
* @ep: The endpoint to check.
@@ -2933,7 +2937,7 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
/* all endpoints should be shutdown */
for (ep = 1; ep hsotg-num_of_eps; ep++)
- s3c_hsotg_ep_disable(hsotg-eps[ep].ep);
+ s3c_hsotg_ep_disable_force(hsotg-eps[ep].ep, true);
spin_lock_irqsave(hsotg-lock, flags);
Acked-by: Paul Zimmerman pa...@synopsys.com
--
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] mfd: dln2: add support for ACPI
On Thursday, December 11, 2014 06:32:07 PM Octavian Purdila wrote:
This patch adds support to load a custom ACPI table that describes
devices connected via the DLN2 USB to I2C/SPI/GPIO bridge.
The ACPI table is loaded at runtime as firmware with the name
dln2.aml, it looks for an ACPI device entry with _HID set to
DLN2 and makes it the ACPI companion for DLN2 USB sub-drivers.
Why?
It is sort of a hack due to the ../acpi/internal.h and
../usb/core/usb.h includes and perhaps something more generic would
be more appropriate. Any suggestions to the right direction are kindly
appreciated.
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
---
Documentation/acpi/dln2-acpi.txt | 48 ++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 1 +
drivers/mfd/dln2-acpi.c | 103
+++
drivers/mfd/dln2.c | 6 +--
drivers/mfd/dln2.h | 9
6 files changed, 173 insertions(+), 5 deletions(-)
create mode 100644 Documentation/acpi/dln2-acpi.txt
create mode 100644 drivers/mfd/dln2-acpi.c
create mode 100644 drivers/mfd/dln2.h
diff --git a/Documentation/acpi/dln2-acpi.txt
b/Documentation/acpi/dln2-acpi.txt
new file mode 100644
index 000..c099241
--- /dev/null
+++ b/Documentation/acpi/dln2-acpi.txt
@@ -0,0 +1,48 @@
+Diolan DLN2 custom APCI table
+
+The Diolan DLN2 is an USB to I2C/SPI/GPIO bridge and as such it can be used
to
+connect to various I2C or SPI devices. Because these busses lack an
enumeration
+protocol, the driver obtains various information about the device (such as
I2C
+address and GPIO pins) from either ACPI or device tree.
+
+To allow using such devices connect to the DLN2 bridge to their full extend
+(e.g. interrupt mode), if CONFIG_MFD_DLN2_ACPI option has been compiled in
the
+kernel, the user can define a custom ACPI table that will be dynamically
loaded
+at boot time from firmware paths. The ACPI table filename must be dln2.aml
and
+it must contain a root device with _HID set DLN2.
+
+Here is a example of how the ACPI table should look like:
+
+DefinitionBlock (ssdt.aml, SSDT, 1, INTEL , CpuDptf, 0x0003)
+{
+ Device (DLN0)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, DLN2000)
+
+ Device (STAC)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, BMC150A)
+ Name (_CID, INTACCL)
+ Name (_UID, One)
+
+ Method (_CRS, 0, Serialized)
+ {
+ Name (RBUF, ResourceTemplate ()
+ {
+ I2cSerialBus (0x0010,
ControllerInitiated, 0x00061A80,
+ AddressingMode7Bit,
\\DLN0,
+ 0x00, ResourceConsumer, ,)
+
+ GpioInt (Level, ActiveHigh, Exclusive,
PullDown, 0x,
+ \\DLN0, 0x00,
ResourceConsumer, , )
+ { // Pin list
+ 0
+ }
+ })
+ Return (RBUF)
+}
+ }
+ }
+}
Well, can you please explain here what the resources in the _CRS mean for
this device? How they are supposed to be used etc.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b731..b810195 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -205,6 +205,17 @@ config MFD_DLN2
etc. must be enabled in order to use the functionality of
the device.
+config MFD_DLN2_ACPI
+ bool Diolan DLN2 ACPI support
+ depends on MFD_DLN2 ACPI
+ default n
+ help
+ Say yes here to add ACPI support to DLN2 which allows loading a custom
+ ACPI table to describe devices between the DLN2 I2C or SPI bridge as
+ well as GPIO support for those devices. See
+ Documentation/acpi/dln2-acpi.txt for more information.
+
+
config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..dbe1f3f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -176,6 +176,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC)+= hi6421-pmic-core.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
+obj-$(CONFIG_MFD_DLN2_ACPI) += dln2-acpi.o
First, why is this MFD at all?
intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2-acpi.c
[PATCHv2 0/2] Added Multiple Phy support for ehci and ohci drivers
From: Arun Ramamurthy arunr...@broadcom.com Broadcom has a chip where one ehci and ohci controller are connected to three separate phys. This patch allows each phy to be controlled separately. Changes in v2: - removed x character mistakenly introduced by manual edit of diff file Arun Ramamurthy (2): usb: ohci-platform: add support for multiple phys per controller usb: ehci-platform: add support for multiple phys per controller drivers/usb/host/ehci-platform.c | 70 drivers/usb/host/ohci-platform.c | 70 2 files changed, 98 insertions(+), 42 deletions(-) -- 2.2.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
[PATCHv2 1/2] usb: ohci-platform: add support for multiple phys per controller
From: Arun Ramamurthy arunr...@broadcom.com
Added support for cases where one controller is connected
to multiple phys
Signed-off-by: Arun Ramamurthy arunr...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/usb/host/ohci-platform.c | 70
1 file changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 4369299..eef82f1 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -38,7 +38,8 @@
struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
struct reset_control *rst;
- struct phy *phy;
+ struct phy *phys;
+ int num_phys;
};
static const char hcd_name[] = ohci-platform;
@@ -61,7 +62,7 @@ static int ohci_platform_power_on(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
- int clk, ret;
+ int clk, ret, phy_num;
for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++) {
ret = clk_prepare_enable(priv-clks[clk]);
@@ -69,20 +70,28 @@ static int ohci_platform_power_on(struct platform_device
*dev)
goto err_disable_clks;
}
- if (priv-phy) {
- ret = phy_init(priv-phy);
- if (ret)
- goto err_disable_clks;
-
- ret = phy_power_on(priv-phy);
- if (ret)
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ ret = phy_init(priv-phys[phy_num]);
+ if (ret) {
+ if (phy_num == 0)
+ goto err_disable_clks;
+ else
+ goto err_exit_phy;
+ }
+ ret = phy_power_on(priv-phys[phy_num]);
+ if (ret) {
+ phy_exit(priv-phys[phy_num]);
goto err_exit_phy;
+ }
}
return 0;
err_exit_phy:
- phy_exit(priv-phy);
+ while (--phy_num = 0) {
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
+ };
err_disable_clks:
while (--clk = 0)
clk_disable_unprepare(priv-clks[clk]);
@@ -94,11 +103,11 @@ static void ohci_platform_power_off(struct platform_device
*dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
- int clk;
+ int clk, phy_num;
- if (priv-phy) {
- phy_power_off(priv-phy);
- phy_exit(priv-phy);
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
@@ -127,7 +136,9 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
- int err, irq, clk = 0;
+ struct phy *temp_phy;
+ const char *phy_name;
+ int err, irq, phy_num, clk = 0;
if (usb_disabled())
return -ENODEV;
@@ -175,12 +186,29 @@ static int ohci_platform_probe(struct platform_device
*dev)
if (of_property_read_bool(dev-dev.of_node, big-endian))
ohci-flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
- priv-phy = devm_phy_get(dev-dev, usb);
- if (IS_ERR(priv-phy)) {
- err = PTR_ERR(priv-phy);
- if (err == -EPROBE_DEFER)
- goto err_put_hcd;
- priv-phy = NULL;
+ priv-num_phys = of_count_phandle_with_args
+ (dev-dev.of_node, phys, #phy-cells);
+ if (priv-num_phys 0) {
+ priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
+ sizeof(struct phy), GFP_KERNEL);
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ err = of_property_read_string_index(
+ dev-dev.of_node,
+ phy-names, phy_num,
+ phy_name);
+ if (err 0) {
+ dev_err(dev-dev, Phy-names not
provided);
+ goto err_put_hcd;
+ }
+
+ temp_phy = devm_of_phy_get(dev-dev,
+ dev-dev.of_node, phy_name);
+ if
[PATCHv2 2/2] usb: ehci-platform: add support for multiple phys per controller
From: Arun Ramamurthy arunr...@broadcom.com
Added support for cases where one controller is connected
to multiple phys.
Signed-off-by: Arun Ramamurthy arunr...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/usb/host/ehci-platform.c | 70
1 file changed, 49 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 2f5b9ce..a1a7d82 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -43,7 +43,8 @@
struct ehci_platform_priv {
struct clk *clks[EHCI_MAX_CLKS];
struct reset_control *rst;
- struct phy *phy;
+ struct phy *phys;
+ int num_phys;
};
static const char hcd_name[] = ehci-platform;
@@ -78,7 +79,7 @@ static int ehci_platform_power_on(struct platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
- int clk, ret;
+ int clk, ret, phy_num;
for (clk = 0; clk EHCI_MAX_CLKS priv-clks[clk]; clk++) {
ret = clk_prepare_enable(priv-clks[clk]);
@@ -86,20 +87,28 @@ static int ehci_platform_power_on(struct platform_device
*dev)
goto err_disable_clks;
}
- if (priv-phy) {
- ret = phy_init(priv-phy);
- if (ret)
- goto err_disable_clks;
-
- ret = phy_power_on(priv-phy);
- if (ret)
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ ret = phy_init(priv-phys[phy_num]);
+ if (ret) {
+ if (phy_num == 0)
+ goto err_disable_clks;
+ else
+ goto err_exit_phy;
+ }
+ ret = phy_power_on(priv-phys[phy_num]);
+ if (ret) {
+ phy_exit(priv-phys[phy_num]);
goto err_exit_phy;
+ }
}
return 0;
err_exit_phy:
- phy_exit(priv-phy);
+ while (--phy_num = 0) {
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
+ }
err_disable_clks:
while (--clk = 0)
clk_disable_unprepare(priv-clks[clk]);
@@ -111,11 +120,11 @@ static void ehci_platform_power_off(struct
platform_device *dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
- int clk;
+ int clk, phy_num;
- if (priv-phy) {
- phy_power_off(priv-phy);
- phy_exit(priv-phy);
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
for (clk = EHCI_MAX_CLKS - 1; clk = 0; clk--)
@@ -143,7 +152,9 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(dev-dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
- int err, irq, clk = 0;
+ struct phy *temp_phy;
+ const char *phy_name;
+ int err, irq, phy_num, clk = 0;
if (usb_disabled())
return -ENODEV;
@@ -190,12 +201,29 @@ static int ehci_platform_probe(struct platform_device
*dev)
if (of_property_read_bool(dev-dev.of_node, big-endian))
ehci-big_endian_mmio = ehci-big_endian_desc = 1;
- priv-phy = devm_phy_get(dev-dev, usb);
- if (IS_ERR(priv-phy)) {
- err = PTR_ERR(priv-phy);
- if (err == -EPROBE_DEFER)
- goto err_put_hcd;
- priv-phy = NULL;
+ priv-num_phys = of_count_phandle_with_args
+ (dev-dev.of_node, phys, #phy-cells);
+ if (priv-num_phys 0) {
+ priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
+ sizeof(struct phy), GFP_KERNEL);
+ for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
+ err = of_property_read_string_index(
+ dev-dev.of_node,
+ phy-names, phy_num,
+ phy_name);
+ if (err 0) {
+ dev_err(dev-dev, Phy-names not
provided);
+ goto err_put_hcd;
+ }
+
+ temp_phy = devm_of_phy_get(dev-dev,
+ dev-dev.of_node, phy_name);
+ if
[PATCH 2/2] usb: serial: handle -ENODEV quietly in generic_submit_read_urb
If a USB serial device (e.g. /dev/ttyUSB0) with an active program is
unplugged, an -ENODEV (19) error will be produced after it gives up
trying to resubmit a read.
usb_serial_generic_submit_read_urb - usb_submit_urb failed: -19
Add -ENODEV as one of the permanent errors along with -EPERM that
usb_serial_generic_submit_read_urb() handles quietly without an error.
Signed-off-by: Jeremiah Mahler jmmah...@gmail.com
---
drivers/usb/serial/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 98fe718..cca81c4 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -286,7 +286,7 @@ static int usb_serial_generic_submit_read_urb(struct
usb_serial_port *port,
res = usb_submit_urb(port-read_urbs[index], mem_flags);
if (res) {
- if (res != -EPERM) {
+ if (res != -EPERM res != -ENODEV) {
dev_err(port-dev,
%s - usb_submit_urb failed: %d\n,
__func__, res);
--
2.1.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 1/2] usb: serial: handle -EPROTO quietly in generic_read_bulk
If a USB serial device (e.g. /dev/ttyUSB0) with an active program is unplugged, a bunch of -EPROTO (71) error messages will be produced by usb_serial_generic_read_bulk_callback() as it tries to resubmit the request. usb_serial_generic_read_bulk_callback - nonzero urb status: -71 Keep the same functionality, resubmit after an -EPROTO error, but change message log level to debug instead of error so they are handled quietly by default. Signed-off-by: Jeremiah Mahler jmmah...@gmail.com --- drivers/usb/serial/generic.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c index 1bd1922..98fe718 100644 --- a/drivers/usb/serial/generic.c +++ b/drivers/usb/serial/generic.c @@ -372,6 +372,10 @@ void usb_serial_generic_read_bulk_callback(struct urb *urb) dev_err(port-dev, %s - urb stopped: %d\n, __func__, urb-status); return; + case -EPROTO: + dev_dbg(port-dev, %s - urb resubmit: %d\n, + __func__, urb-status); + goto resubmit; default: dev_err(port-dev, %s - nonzero urb status: %d\n, __func__, urb-status); -- 2.1.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 0/2] usb: serial: handle -ENODEV and -EPROTO quietly
If a USB serial device (e.g. /dev/ttyUSB0) with an active program is unplugged, a bunch of -ENODEV and -EPROTO errors will be produced in the logs. This patch set quiets these messages without changing the original behavior. This change is beneficial when using daemons such as slcand, which is similar to pppd or slip, that cannot determine whether they should exit until after the USB serial device is unplugged. Producing these error messages for a normal use case is not helpful. Jeremiah Mahler (2): usb: serial: handle -EPROTO quietly in generic_read_bulk usb: serial: handle -ENODEV quietly in generic_submit_read_urb drivers/usb/serial/generic.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 2.1.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: Query regarding USB gadget driver
On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: Hi, On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: Hello, I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core is clocked at 500MHz and the USB IP core for this is by Chip-idea. I am running a 3.18-rc5 kernel on it and trying to use the USB gadget functionality. To be more specific the CDC ECM class. Currently, I cannot use this properly. If I use just ping to check, it works fine, but, after running iperf, even one transaction doesn't complete or completes rarely. Checking the CDC Ether interface with Wireshark shows, TCP Dup Ack messages and checking the USB bus with Wireshark, shows packets with USB Protocol Error -71 at one point and after that packets with USB connection Reset -104 error. If it's of any significance, I have Arch Linux with the 3.18 kernel running on my laptop with which the Vybrid connects. On the host side, the only error dmesg shows is kevent 12 may have been dropped. I guess this is connected to the TCP Previous Segment not captured and TCP Dup ACK messages. My script for the gadget configuration is as below: /bin/mount none /mnt -t configfs /bin/mkdir /mnt/usb_gadget/g1 cd /mnt/usb_gadget/g1 /bin/mkdir configs/c.1 /bin/mkdir functions/ecm.0 /bin/mkdir strings/0x409 /bin/mkdir configs/c.1/strings/0x409 echo 0xa4a2 idProduct echo 0x0525 idVendor echo Freescale123 strings/0x409/serialnumber echo Freescale strings/0x409/manufacturer echo USB Serial Gadget strings/0x409/product echo Conf 1 configs/c.1/strings/0x409/configuration echo 200 configs/c.1/MaxPower ln -s functions/ecm.0 configs/c.1 echo ci_hdrc.0 UDC /sbin/ifconfig usb0 up /sbin/ifconfig usb0 192.168.1.10 I have debug prints in the udc.c and u_ether.c using pr_debug and just a little hint, use any of the dev_*() macros next time, they'll print the device name which helps figuring out which UDC you're using. Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen maintains that one, it really helps adding maintainers to Cc list. enable them when required using dynamic debug. Without running iperf, using ping gives me a sequence of prints as below: [ 277.434409] In eth_start_xmit [ 277.434517] In UDC irq [ 277.434553] In usb_gadget_giveback_request [ 277.434567] In tx_complete [ 277.435443] In UDC irq [ 277.435477] In usb_gadget_giveback_request [ 277.435491] In rx_complete [ 277.435517] In rx_submit [ 277.435601] In eth_start_xmit [ 277.436441] In UDC irq [ 277.436465] In usb_gadget_giveback_request [ 277.436478] In rx_complete [ 277.436493] In rx_submit [ 277.436520] In usb_gadget_giveback_request [ 277.436533] In tx_complete [ 278.434865] In eth_start_xmit [ 278.434959] In UDC irq [ 278.434993] In usb_gadget_giveback_request [ 278.435006] In tx_complete [ 278.435881] In UDC irq [ 278.435910] In usb_gadget_giveback_request [ 278.435923] In rx_complete [ 278.435946] In rx_submit After running iperf without debug prints and then enabling before using ping gives me a sequence of prints as below [ 81.989827] In UDC irq [ 81.989871] In usb_gadget_giveback_request [ 81.989886] In rx_complete [ 81.989905] In rx_submit [ 82.989892] In UDC irq [ 82.989951] In usb_gadget_giveback_request [ 82.989967] In rx_complete [ 82.989992] In rx_submit [ 83.990064] In UDC irq [ 83.990126] In usb_gadget_giveback_request [ 83.990142] In rx_complete [ 83.990167] In rx_submit [ 84.990007] In UDC irq [ 84.990049] In usb_gadget_giveback_request [ 84.990064] In rx_complete [ 84.990083] In rx_submit [ 85.990085] In UDC irq [ 85.990147] In usb_gadget_giveback_request [ 85.990163] In rx_complete [ 85.990188] In rx_submit If I force a full speed configuration for this USB client port, I get a slightly more reliable operation where iperf can run for may be half an hour or so or almost an hour before it falls through. Putting in a delay of 100-150 microseconds in eth_start_xmit also improves it like full speed, but, still not reliable. If I run iperf with debug prints enable, this gives similar results to full speed config. After the failure of iperf test, even ping doesn't work. Bringing down this usb0 interface and then up again makes ping work again. I do realize that putting debug prints or delays like this is not the right thing to do, especially in ISR, but, just trying to debug. This is my first time digging in the USB stack. Based on the above, it seems there might a subtle bug or race condition somewhere in the execution call chain which I have not been able to trace yet. Can someone give me some pointers on how I can dig and debug further?. I just tried latest usb-next with i.mx6 platform, it works ok with 10 mins iperf bi-direction test. I
RE: [PATCH v3 1/2] make xhci platform driver use 64 bit or 32 bit DMA
Hi Mark,
-Original Message-
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Mark Langsdorf
Sent: Wednesday, November 26, 2014 6:19 AM
To: linux-usb@vger.kernel.org; mathias.ny...@intel.com
Cc: mlang...@redhat.com
Subject: [PATCH v3 1/2] make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that either only
support 64-bit DMA or only support 32-bit DMA. Attempt to set a
coherent dma mask for 64-bit DMA, and attempt again with 32-bit
DMA if that fails.
I'm afraid but I have a comment about this patch.
Since my environment (It's R-Car Gen2. It has ARM/CA15 and LPAE) has a
restriction about DMA coherent, I intend to send some patches to avoid
the restriction. And then, I found this patch.
About my environment restriction is:
- R-Car Gen2 can use LAPE.
- So, dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64)); will not fail.
- AXI address bus width of R-Car Gen2 xHCI controller is 32 bit.
- However, The HCCPARAMS.AC64 is set to 1.
So, in this environment, I think the xHCI driver should call
dma_set_coherent(dev, DMA_BIT_MASK(32)) because AXI address bus width is 32 bit.
However, in this case, the xHCI driver will call dma_set_coherent_mask(dev,
DMA_BIT_MASK(64))
in line 4900 of drivers/usb/host/xhci.c:
/* Set dma_mask and coherent_dma_mask to 64-bits,
* if xHC supports 64-bit addressing */
if (HCC_64BIT_ADDR(xhci-hcc_params)
!dma_set_mask(dev, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, Enabling 64-bit DMA addresses.\n);
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
}
So, I intend to send some patches to add a quirk to this condition.
However, if this patch is applied, I also need more patch for xhci-plat.c.
Or, I misunderstand about the DMA-API?
Best regards,
Yoshihiro Shimoda
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Tested-by: Mark Salter msal...@redhat.com
---
Changes from v2:
None
Changes from v1:
Consolidated to use dma_set_mask_and_coherent
Got rid of the check against sizeof(dma_addr_t)
drivers/usb/host/xhci-plat.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..34cbf65 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -96,14 +96,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
return ret;
}
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- else
- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ /* Try setting the coherent_dma_mask to 64 bits, then try 32 bits */
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+ if (ret) {
+ ret = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd)
--
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
--
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
