[PATCH v2 1/1] usb: hcd: move controller wakeup setting initialization to individual driver
Individual controller driver has different requirement for wakeup setting, so move it from core to itself. In order to align with current etting the default wakeup setting is enabled (except for chipidea host). Pass compile test with below commands: make O=outout/all allmodconfig make -j$CPU_NUM O=outout/all drivers/usb Signed-off-by: Peter Chen peter.c...@freescale.com --- Changes for v2: - Add changes for drivers/staging - Revert the change for dummy-hcd drivers/staging/dwc2/hcd.c |2 ++ drivers/staging/octeon-usb/octeon-hcd.c |1 + drivers/staging/ozwpan/ozhcd.c |1 + drivers/staging/usbip/vhci_hcd.c|1 + drivers/usb/c67x00/c67x00-hcd.c |1 + drivers/usb/core/hcd-pci.c |2 ++ drivers/usb/core/hcd.c |6 -- drivers/usb/host/ehci-atmel.c |1 + drivers/usb/host/ehci-exynos.c |1 + drivers/usb/host/ehci-fsl.c |1 + drivers/usb/host/ehci-grlib.c |1 + drivers/usb/host/ehci-mv.c |1 + drivers/usb/host/ehci-mxc.c |1 + drivers/usb/host/ehci-octeon.c |1 + drivers/usb/host/ehci-omap.c|1 + drivers/usb/host/ehci-orion.c |1 + drivers/usb/host/ehci-platform.c|1 + drivers/usb/host/ehci-pmcmsp.c |4 +++- drivers/usb/host/ehci-ppc-of.c |1 + drivers/usb/host/ehci-ps3.c |1 + drivers/usb/host/ehci-sead3.c |1 + drivers/usb/host/ehci-sh.c |1 + drivers/usb/host/ehci-spear.c |1 + drivers/usb/host/ehci-tegra.c |1 + drivers/usb/host/ehci-tilegx.c |1 + drivers/usb/host/ehci-w90x900.c |1 + drivers/usb/host/ehci-xilinx-of.c |4 +++- drivers/usb/host/fhci-hcd.c |1 + drivers/usb/host/fotg210-hcd.c |1 + drivers/usb/host/fusbh200-hcd.c |1 + drivers/usb/host/hwa-hc.c |1 + drivers/usb/host/imx21-hcd.c|1 + drivers/usb/host/isp116x-hcd.c |1 + drivers/usb/host/isp1362-hcd.c |1 + drivers/usb/host/isp1760-hcd.c |1 + drivers/usb/host/ohci-at91.c|4 +++- drivers/usb/host/ohci-da8xx.c |2 ++ drivers/usb/host/ohci-exynos.c |1 + drivers/usb/host/ohci-jz4740.c |1 + drivers/usb/host/ohci-nxp.c |4 +++- drivers/usb/host/ohci-octeon.c |1 + drivers/usb/host/ohci-omap.c|1 + drivers/usb/host/ohci-omap3.c |1 + drivers/usb/host/ohci-platform.c|1 + drivers/usb/host/ohci-ppc-of.c |4 +++- drivers/usb/host/ohci-ps3.c |1 + drivers/usb/host/ohci-pxa27x.c |4 +++- drivers/usb/host/ohci-s3c2410.c |1 + drivers/usb/host/ohci-sa.c |4 +++- drivers/usb/host/ohci-sm501.c |1 + drivers/usb/host/ohci-spear.c |4 +++- drivers/usb/host/ohci-tilegx.c |1 + drivers/usb/host/ohci-tmio.c|1 + drivers/usb/host/oxu210hp-hcd.c |1 + drivers/usb/host/r8a66597-hcd.c |1 + drivers/usb/host/sl811-hcd.c|1 + drivers/usb/host/u132-hcd.c |1 + drivers/usb/host/uhci-grlib.c |1 + drivers/usb/host/uhci-platform.c|1 + drivers/usb/host/whci/hcd.c |1 + drivers/usb/host/xhci-pci.c |1 + drivers/usb/host/xhci-plat.c|2 ++ drivers/usb/musb/musb_host.c|1 + drivers/usb/phy/phy-msm-usb.c |1 + drivers/usb/phy/phy-mv-usb.c|6 -- drivers/usb/renesas_usbhs/mod_host.c|1 + 66 files changed, 88 insertions(+), 16 deletions(-) diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c index da0d35c..e58c4e9 100644 --- a/drivers/staging/dwc2/hcd.c +++ b/drivers/staging/dwc2/hcd.c @@ -2893,6 +2893,8 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq, if (retval 0) goto error3; + device_wakeup_enable(hcd-self.controller); + dwc2_hcd_dump_state(hsotg); dwc2_enable_global_interrupts(hsotg); diff --git a/drivers/staging/octeon-usb/octeon-hcd.c b/drivers/staging/octeon-usb/octeon-hcd.c index 5dbbd14..8129c13 100644 --- a/drivers/staging/octeon-usb/octeon-hcd.c +++ b/drivers/staging/octeon-usb/octeon-hcd.c @@ -725,6 +725,7 @@ static int octeon_usb_driver_probe(struct device *dev) kfree(hcd); return -1; } + device_wakeup_enable(hcd-self.controller); dev_dbg(dev, Registered HCD for port %d on irq %d\n, usb_num, irq); diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c index d9c43c3..82f958a 100644 --- a/drivers/staging/ozwpan/ozhcd.c +++ b/drivers/staging/ozwpan/ozhcd.c @@ -2270,6 +2270,7 @@
Re: khubd timed out on ep0in len=0/64 with 3.4 kernel
Hi Here are dmesg's with old_scheme_first=1 and where it took about 20s for usb-storage to start using this device. Is there a way I can enable debugs from usb-storage to see what it is doing in that 20s gap. The device in question is at usb1-3 (sdb), manufactured by SMART. Thank you. [1.628068] usb 1-3: new high speed USB device using ehci_hcd and address 2 [1.628073] usb 1-3: usenewscheme 0 retry_counter 0 i 0 [1.628103] EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is recommended [1.628671] EXT4-fs (sda1): recovery complete [1.628680] EXT4-fs (sda1): mounted filesystem with ordered data mode [1.649360] usb 1-3: default language 0x0409 [1.650118] usb 1-3: udev 2, busnum 1, minor = 1 [1.650123] usb 1-3: New USB device found, idVendor=0e39, idProduct=2b00 [1.650127] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1.650131] usb 1-3: Product: eUSB [1.650133] usb 1-3: Manufacturer: SMART [1.650136] usb 1-3: SerialNumber: 29879006164049261011 [1.650311] usb 1-3: usb_probe_device [1.650316] usb 1-3: configuration #1 chosen from 1 choice [1.650465] usb 1-3: adding 1-3:1.0 (config #1, interface 0) [1.650708] usb-storage 1-3:1.0: usb_probe_interface [1.650716] usb-storage 1-3:1.0: usb_probe_interface - got id [1.650927] scsi4 : SCSI emulation for USB Mass Storage devices [1.651428] /bld/Kernel/Artools-rpmbuild/linux/drivers/usb/core/inode.c: creating file '002' [1.651453] hub 2-0:1.0: state 7 ports 5 chg 0020 evt [1.651464] hub 2-0:1.0: port 5, status 0501, change , 480 Mb/s [1.651477] usb-storage: device found at 2 [1.651770] usb-storage: device scan complete [1.704076] ehci_hcd :00:13.2: port 5 high speed [1.704083] ehci_hcd :00:13.2: GetStatus port 5 status 001005 POWER sig=se0 PE CONNECT [1.760060] usb 2-5: new high speed USB device using ehci_hcd and address 2 [1.760065] usb 2-5: usenewscheme 0 retry_counter 0 i 0 [1.781500] usb 2-5: default language 0x0409 [1.781880] usb 2-5: udev 2, busnum 2, minor = 129 [1.781885] usb 2-5: New USB device found, idVendor=0781, idProduct=5571 [1.781888] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1.781892] usb 2-5: Product: Cruzer Fit [1.781895] usb 2-5: Manufacturer: SanDisk [1.781897] usb 2-5: SerialNumber: 4C532008870615120374 [1.782072] usb 2-5: usb_probe_device [1.782077] usb 2-5: configuration #1 chosen from 1 choice [1.782228] usb 2-5: adding 2-5:1.0 (config #1, interface 0) [1.782463] usb-storage 2-5:1.0: usb_probe_interface [1.782471] usb-storage 2-5:1.0: usb_probe_interface - got id [1.782678] scsi5 : SCSI emulation for USB Mass Storage devices [1.783176] /bld/Kernel/Artools-rpmbuild/linux/drivers/usb/core/inode.c: creating file '002' [1.783202] hub 5-0:1.0: state 7 ports 5 chg evt [1.783207] hub 6-0:1.0: state 7 ports 4 chg evt [1.783212] usb-storage: device found at 2 [1.783532] usb-storage: device scan complete [1.784053] scsi 5:0:0:0: Direct-Access SanDisk Cruzer Fit 1.26 PQ: 0 ANSI: 5 [ 22.872067] ehci_hcd :00:12.2: port 3 high speed [ 22.872075] ehci_hcd :00:12.2: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT [ 22.928057] usb 1-3: reset high speed USB device using ehci_hcd and address 2 [ 22.928062] usb 1-3: usenewscheme 0 retry_counter 0 i 0 [ 22.952867] scsi 4:0:0:0: Direct-Access SMARTeUSB 883C PQ: 0 ANSI: 0 CCS [ 22.955195] sd 4:0:0:0: [sdb] 4014080 512-byte logical blocks: (2.05 GB/1.91 GiB) [ 22.955724] sd 4:0:0:0: [sdb] Write Protect is off [ 22.955730] sd 4:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 22.955733] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 23.031197] sd 5:0:0:0: [sdc] 7821312 512-byte logical blocks: (4.00 GB/3.72 GiB) [ 23.032940] sd 5:0:0:0: [sdc] Write Protect is off [ 23.032946] sd 5:0:0:0: [sdc] Mode Sense: 43 00 00 00 [ 23.032949] sd 5:0:0:0: [sdc] Assuming drive cache: write through [ 23.118414] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 23.191151] sdb: sdb1 sdb2 [ 23.194175] sd 5:0:0:0: [sdc] Assuming drive cache: write through [ 23.266918] sdc: [ 23.268744] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 23.344071] sdc1 [ 23.344766] sd 4:0:0:0: [sdb] Attached SCSI disk [ 23.346889] sd 5:0:0:0: [sdc] Assuming drive cache: write through [ 23.419967] sd 5:0:0:0: [sdc] Attached SCSI removable disk On Wed, Oct 30, 2013 at 3:21 PM, Prasad Koya prasad.k...@gmail.com wrote: Hi Thanks for suggesting the alternatives. With CONFIG_USB_DEBUG and CONFIG_USB_MON enabled I see below messages related to the USB device in question. This is not reproducible easily. I'll try the old_scheme_first. We are seeing this issue with flash that is internal to our box and not accessible outside and we ship them with this brand of flash. Will see if I
Re: CSW endpoint status returned STALL after BOT MSC Reset
Thanks for the quick patch..I will test it.
On Wed, Oct 30, 2013 at 10:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 30 Oct 2013, Alan Stern wrote:
I think you have found a bug in the dwc3 driver.
At this point, because the IGNORE_BULK_OUT bit is set, g_mass_storage
issues a usb_ep_clear_halt() call for the bulk-in (CSW) endpoint.
This tells the dwc3 driver to change the endpoint's status back to 0:
if (test_and_clear_bit(IGNORE_BULK_OUT,
common-fsg-atomic_bitflags))
usb_ep_clear_halt(common-fsg-bulk_in);
INFORetrieving status on CBW endpoint
INFOCBW endpoint status = 0x0
INFORetrieving status on CSW endpoint
INFOCSW endpoint status = 0x1
But the status is still set to 1. Clearly this is a bug in dwc3.
And indeed it is. The dwc3 driver does not implement the wedge method
correctly. This patch should fix it. Let me know how it works.
Alan Stern
Index: usb-3.12/drivers/usb/dwc3/ep0.c
===
--- usb-3.12.orig/drivers/usb/dwc3/ep0.c
+++ usb-3.12/drivers/usb/dwc3/ep0.c
@@ -459,6 +459,8 @@ static int dwc3_ep0_handle_feature(struc
dep = dwc3_wIndex_to_dep(dwc, wIndex);
if (!dep)
return -EINVAL;
+ if (set == 0 (dep-flags DWC3_EP_WEDGE))
+ break;
This is fine.
But I do not see any way to unwedge ep0. dwc3_gadget_ep0_set_halt
ignores *value*
argument and will not handle a gadget driver's clear halt status request.
However, I do no see any gadget driver wedging ep0, so may be it will not hurt.
ret = __dwc3_gadget_ep_set_halt(dep, set);
if (ret)
return -EINVAL;
Index: usb-3.12/drivers/usb/dwc3/gadget.c
===
--- usb-3.12.orig/drivers/usb/dwc3/gadget.c
+++ usb-3.12/drivers/usb/dwc3/gadget.c
@@ -1200,9 +1200,6 @@ int __dwc3_gadget_ep_set_halt(struct dwc
else
dep-flags |= DWC3_EP_STALL;
} else {
- if (dep-flags DWC3_EP_WEDGE)
- return 0;
-
ret = dwc3_send_gadget_ep_cmd(dwc, dep-number,
DWC3_DEPCMD_CLEARSTALL, params);
if (ret)
@@ -1210,7 +1207,7 @@ int __dwc3_gadget_ep_set_halt(struct dwc
value ? set : clear,
dep-name);
else
- dep-flags = ~DWC3_EP_STALL;
+ dep-flags = ~(DWC3_EP_STALL | DWC3_EP_WEDGE);
}
return ret;
--
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
Thanks for your kind help.
Regards
Pratyush
--
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] dt: exynos5250: Enable support for generic USB 3.0 phy
Update device tree bindings for DWC3 controller and
USB 3.0 phy present on Exynos 5250 SoC, to start using
the phy driver based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++---
1 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index bbac42a..31a6595 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -472,22 +472,17 @@
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
- usb-phy = usb2_phy usb3_phy;
+ phys = usb3_phy;
+ phy-names = usb3-phy;
};
};
usb3_phy: usbphy@1210 {
compatible = samsung,exynos5250-usb3phy;
- reg = 0x1210 0x100;
- clocks = clock 1, clock 286;
- clock-names = ext_xtal, usbdrd30;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- usbphy-sys {
- reg = 0x10040704 0x8;
- };
+ reg = 0x1210 0x100 0x10040704 0x4;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3drd;
+ #phy-cells = 0;
};
usb@1211 {
--
1.7.6.5
--
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] dt: exynos5420: Enable support for DWC3 controller
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 38 +++-
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 5df3308..4f676c1 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -236,7 +236,24 @@
status = disabled;
};
- usbphy@1210 {
+ usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 366;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ phys = usb3_phy0;
+ phy-names = usb3-phy;
+ };
+ };
+
+ usb3_phy0: usbphy@1210 {
compatible = samsung,exynos5420-usb3phy;
reg = 0x1210 0x100 0x10040704 0x4;
clocks = clock 366, clock 1, clock 152;
@@ -244,7 +261,24 @@
#phy-cells = 0;
};
- usbphy@1250 {
+ usb@1240 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 367;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1240 0x1;
+ interrupts = 0 73 0;
+ phys = usb3_phy1;
+ phy-names = usb3-phy;
+ };
+ };
+
+ usb3_phy1: usbphy@1250 {
compatible = samsung,exynos5420-usb3phy;
reg = 0x1250 0x100 0x10040708 0x4;
clocks = clock 367, clock 1, clock 153;
--
1.7.6.5
--
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] dt: exynos5420: Enable support for USB 3.0 PHY controller
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index d537cd7..5df3308 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -235,4 +235,20 @@
io-channel-ranges;
status = disabled;
};
+
+ usbphy@1210 {
+ compatible = samsung,exynos5420-usb3phy;
+ reg = 0x1210 0x100 0x10040704 0x4;
+ clocks = clock 366, clock 1, clock 152;
+ clock-names = phy, usb3drd, sclk_usbphy30;
+ #phy-cells = 0;
+ };
+
+ usbphy@1250 {
+ compatible = samsung,exynos5420-usb3phy;
+ reg = 0x1250 0x100 0x10040708 0x4;
+ clocks = clock 367, clock 1, clock 153;
+ clock-names = phy, usb3drd, sclk_usbphy30;
+ #phy-cells = 0;
+ };
};
--
1.7.6.5
--
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 RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/phy/samsung-phy.txt| 20 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 4 files changed, 590 insertions(+), 0 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..9b5c111 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,23 @@ Required properties: - compatible : should be samsung,exynos5250-dp-video-phy; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung Exynos5 SoC seiries USB 3.0 PHY controller +-- + +Required properties: +- compatible : + should be samsung,exynos5250-usb3phy for exynos5250 SoC + should be samsung,exynos5420-usb3phy for exynos5420 SoC +- reg : Register offset and length array + - first field corresponds to USB 3.0 PHY register set; + - second field corresponds to PHY power isolation register + present in PMU; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - first clock is main PHY clock (same as USB 3.0 controller IP clock) + - second clock is reference clock (usually crystal clock) + optional clock: + - third clock is special clock used by PHY for operation +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index a344f3d..9a100c6 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -51,4 +51,11 @@ config PHY_EXYNOS_DP_VIDEO help Support for Display Port PHY found on Samsung EXYNOS SoCs. +config PHY_EXYNOS5_USB3 + tristate Exynos5 SoC series USB 3.0 PHY driver + depends on ARCH_EXYNOS5 + select GENERIC_PHY + help + Enable USB 3.0 PHY support for Exynos 5 SoC series + endmenu diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index d0caae9..9c06a61 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o +obj-$(CONFIG_PHY_EXYNOS5_USB3) += phy-exynos5-usb3.o diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..b9a2674 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,562 @@ +/* + * Samsung EXYNOS5 SoC series USB 3.0 PHY driver + * + * Copyright (C) 2013 Samsung Electronics Co., Ltd. + * Author: Vivek Gautam gautam.vi...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/of.h +#include linux/of_address.h +#include linux/phy/phy.h +#include linux/platform_device.h +#include linux/mutex.h + +/* Exynos USB PHY registers */ +#define EXYNOS5_FSEL_9MHZ6 0x0 +#define EXYNOS5_FSEL_10MHZ 0x1 +#define EXYNOS5_FSEL_12MHZ 0x2 +#define EXYNOS5_FSEL_19MHZ20x3 +#define EXYNOS5_FSEL_20MHZ 0x4 +#define EXYNOS5_FSEL_24MHZ 0x5 +#define EXYNOS5_FSEL_50MHZ 0x7 + +/* EXYNOS5: USB 3.0 DRD PHY registers */ +#define EXYNOS5_DRD_LINKSYSTEM (0x04) + +#define LINKSYSTEM_FLADJ_MASK (0x3f 1) +#define LINKSYSTEM_FLADJ(_x) ((_x) 1) +#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 27) + +#define EXYNOS5_DRD_PHYUTMI(0x08) + +#define PHYUTMI_OTGDISABLE (0x1 6) +#define PHYUTMI_FORCESUSPEND (0x1 1) +#define PHYUTMI_FORCESLEEP (0x1 0) + +#define EXYNOS5_DRD_PHYPIPE(0x0c) + +#define EXYNOS5_DRD_PHYCLKRST (0x10) + +#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23) +#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23) + +#define PHYCLKRST_SSC_RANGE_MASK (0x03 21) +#define PHYCLKRST_SSC_RANGE(_x)
[PATCH RFC 0/4] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
Adding a phy driver for USB 3.0 PHY controller present on Exynos5 series of SoCs alongwith DWC3 controller for USB 3.0 operations. This driver is inline with Kamil's USB 2.0 phy driver. [1] Few functions used to translate ref clock rate are common to Kamil's changes. So we can figure out how to re-use them across these drivers. Theses patches are based on usb-next branch and tested with Kishon's patches for adapting DWC3 to generic phy framework, [2] on smdk5250 as well as smdk5420 board. [1] [PATCH 0/5] phy: Add new Exynos USB PHY driver https://lkml.org/lkml/2013/10/25/230 [2] [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's (http://www.spinics.net/lists/linux-usb/msg95733.html) [PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework (http://www.spinics.net/lists/linux-usb/msg95734.html) Vivek Gautam (4): phy: Add new Exynos5 USB 3.0 PHY driver dt: exynos5250: Enable support for generic USB 3.0 phy dt: exynos5420: Enable support for USB 3.0 PHY controller dt: exynos5420: Enable support for DWC3 controller .../devicetree/bindings/phy/samsung-phy.txt| 20 + arch/arm/boot/dts/exynos5250.dtsi | 17 +- arch/arm/boot/dts/exynos5420.dtsi | 50 ++ drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 6 files changed, 646 insertions(+), 11 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c -- 1.7.6.5 -- 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: LTE vodafone K5150 12d1 1f16 ; 12d1 1575 mbim IPV6/ipv4
Thomas Schäfer tschae...@t-online.de writes: Bjørn Mork bj...@mork.no writes: That was probably a bit too brief. What I meant was: Try changing the last argument to ipv6_stub-ndisc_send_na() from false to true and see if that makes any difference. It made a difference. It works. For checking en detail: http://www.cis.uni-muenchen.de/~thomas/mbim-5150-20131030-any.pcapng Great! Then I think I'll try to integrate something based on that solution. I'll remove the part where handled NS requests are dropped, so that they still show up in packet dumps. And I guess all this must depend on IPv6 being enabled. But other than that, I'll try to keep the final version as close as possible to the one you now have tested. Thanks for your very good reports and testing. I really didn't expect this problem to be solvable without being able to test it myself, but that's not an issue with testers like you. Bjørn -- 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 02/15] usbcore: introduce usb_domain for tracking port-connector relationships
On Thu, Oct 24, 2013 at 12:35:35AM -0700, Dan Williams wrote:
Platform firmware identifies ports that share a connector. This
information is relevant for port power control since we do not want a
device to reconnect on its peer port in a connector when pm has decided
to power-off its currently connected port.
I think I know what you mean by the above paragraph, but I'm not quite
sure. Do you mean that if you power off a SuperSpeed port, the USB 3.0
device will attempt to reconnect to its shared USB 2.0 port? Or do you
mean something different?
Sarah Sharp
In the case of xhci, peer ports are attached through separate root hubs
(and zero or more integrated hubs). 'struct usb_domain' is introduced
so that each root hub 'hcd' can register its ports to a unified
'platform' domain where connector relationships can be evaluated. A
connector is formed when two ports are registered with identical 'match
data'. ACPI defines connectors by specifying a common 'group token' and
'group position' property for the port [1]. Outside of this match data
there is nothing firmware specific about this implementation, hence the
creation of the common rountines in usb-platform.c.
[1] ACPI 5.0 Section 6.1.8 _PLD (Physical Device Location)
Signed-off-by: Dan Williams dan.j.willi...@intel.com
---
drivers/usb/core/Kconfig|4 +
drivers/usb/core/Makefile |1
drivers/usb/core/hcd-pci.c | 17 +++-
drivers/usb/core/hcd.c |2
drivers/usb/core/hub.h |8 ++
drivers/usb/core/usb-acpi.c | 69 +++--
drivers/usb/core/usb-platform.c | 162
+++
drivers/usb/core/usb-platform.h | 44 +++
drivers/usb/host/xhci-pci.c | 16 +++-
include/linux/usb/hcd.h |9 ++
10 files changed, 320 insertions(+), 12 deletions(-)
create mode 100644 drivers/usb/core/usb-platform.c
create mode 100644 drivers/usb/core/usb-platform.h
diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index db535b0aa172..e439a14b0210 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -89,3 +89,7 @@ config USB_OTG_BLACKLIST_HUB
and software costs by not supporting external hubs. So
are Embedded Hosts that don't offer OTG support.
+config USB_PLATFORM
+ bool
+ default y if ACPI
+
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 5e847ad2f58a..b534b9b28c69 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -11,5 +11,6 @@ usbcore-y += port.o
usbcore-$(CONFIG_PCI)+= hcd-pci.o
usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_USB_PLATFORM) += usb-platform.o
obj-$(CONFIG_USB)+= usbcore.o
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index dfe9d0f22978..542dc0f6ef74 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -161,20 +161,23 @@ static void ehci_wait_for_companions(struct pci_dev
*pdev, struct usb_hcd *hcd,
/* always called with process context; sleeping is OK */
/**
- * usb_hcd_pci_probe - initialize PCI-based HCDs
+ * usb_hcd_pci_probe_domain - initialize PCI-based HCDs
* @dev: USB Host Controller being probed
* @id: pci hotplug id connecting controller to HCD framework
+ * @domain: if this hcd coordinates port activity with another hcd from pdev
* Context: !in_interrupt()
*
* Allocates basic PCI resources for this USB host controller, and
* then invokes the start() method for the HCD associated with it
* through the hotplug entry's driver_data.
*
- * Store this function in the HCD's struct pci_driver as probe().
+ * Note the usb_domain is not to be confused with companion controllers which
+ * multiplex the same phy with multiple controllers.
*
* Return: 0 if successful.
*/
-int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+int usb_hcd_pci_probe_domain(struct pci_dev *dev, struct usb_domain *udom,
+ const struct pci_device_id *id)
{
struct hc_driver*driver;
struct usb_hcd *hcd;
@@ -215,6 +218,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
goto disable_pci;
}
+ hcd-domain = usb_get_domain(udom);
hcd-amd_resume_bug = (usb_hcd_amd_remote_wakeup_quirk(dev)
driver-flags (HCD_USB11 | HCD_USB3)) ? 1 : 0;
@@ -301,6 +305,13 @@ disable_pci:
dev_err(dev-dev, init %s fail, %d\n, pci_name(dev), retval);
return retval;
}
+EXPORT_SYMBOL_GPL(usb_hcd_pci_probe_domain);
+
+
+int usb_hcd_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+ return usb_hcd_pci_probe_domain(dev, NULL, id);
+}
EXPORT_SYMBOL_GPL(usb_hcd_pci_probe);
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index
Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
Du, ChangbinX changbinx...@intel.com writes:
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Tuesday, October 29, 2013 4:41 PM
To: Du, ChangbinX
Cc: oli...@neukum.org; linux-usb@vger.kernel.org; net...@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] net/cdc_ncm: fix null pointer panic at
usbnet_link_change
Du, ChangbinX changbinx...@intel.com writes:
From: Du, Changbin changbinx...@intel.com
In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
be called which calls free_netdev(net).
I am sure you are right, but I really don't see how that can happen.
AFAICS, we ensure that the intfdata is set to NULL before calling
usb_driver_release_interface() in the error cleanup in
cdc_ncm_bind_common():
error2:
usb_set_intfdata(ctx-control, NULL);
usb_set_intfdata(ctx-data, NULL);
if (ctx-data != ctx-control)
usb_driver_release_interface(driver, ctx-data);
error:
cdc_ncm_free((struct cdc_ncm_ctx *)dev-data[0]);
dev-data[0] = 0;
dev_info(dev-udev-dev, bind() failure\n);
return -ENODEV;
Thus we hit the test in disconnect, and usbnet_disconnect() is never
called:
static void cdc_ncm_disconnect(struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
if (dev == NULL)
return; /* already disconnected */
usbnet_disconnect(intf);
}
So we should really be OK, but we are not I would appreciate it if
anyone took the time to feed me why, with a very small spoon...
Yes, you are right. It should not happen if cdc_ncm_disconnect is not
called. But this really happened. It produced on kernel 3.10.
Yes, I do not doubt it. I just don't understand it. There is no
contradiction there. I believe lots of stuff I don't understand :-)
The version this happened is very useful, although I don't think there
are any relevant changes after v3.10.
Here is the full panic message for you to refer. I will get a method try to
reproduce it.
That would be great if you were able to. Otherwise it will be difficult
to verify that the proposed fix works.
In any case, as I said: I believe a fix which avoids the call to
usbnet_link_change() in case of bind failure is correct and
appropriate. But I suggest that you do it by removing the call and
comment from cdc_ncm_bind() and instead set the FLAG_LINK_INTR in the
driver_info. That's how this should have been implemented from the
beginning.
[ 15.635727] BUG: Bad page state in process khubd pfn:31994
[ 15.641989] page:f3ad9280 count:0 mapcount:0 mapping:0020 index:0x0
[ 15.649384] page flags: 0x4000()
[ 15.670096] BUG: unable to handle kernel NULL pointer dereference at
0078
[ 15.678078] IP: [c24b7f5e] usbnet_link_change+0x1e/0x80
[ 15.684120] *pde =
[ 15.687339] Oops: [#1] SMP
[ 15.690953] Modules linked in: atmel_mxt_ts vxd392 videobuf_vmalloc
videobuf_core bcm_bt_lpm bcm432)
[ 15.702658] CPU: 0 PID: 573 Comm: khubd Tainted: GB W O 3.10.1+ #1
[ 15.710241] task: f27e8f30 ti: f2084000 task.ti: f2084000
[ 15.716270] EIP: 0060:[c24b7f5e] EFLAGS: 00010246 CPU: 0
[ 15.722396] EIP is at usbnet_link_change+0x1e/0x80
[ 15.727747] EAX: f18524c0 EBX: ECX: f18524c0 EDX:
[ 15.734746] ESI: f18524c0 EDI: EBP: f2085b7c ESP: f2085b70
[ 15.741746] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
[ 15.747775] CR0: 8005003b CR2: 0078 CR3: 02c3b000 CR4: 001007d0
[ 15.754774] DR0: DR1: DR2: DR3:
[ 15.761774] DR6: 0ff0 DR7: 0400
[ 15.766054] Stack:
[ 15.768295] f18524c0 c2a03818 f2085b8c c24bc69a f1852000
f1f52e00 f2085be0
[ 15.776991] c24b8d32 0001 c2167f2c f2085bb4
c2821253 f2085bec
[ 15.785687] 0246 0246 f18d8088 f1f52e1c f1fce464 f1fce400
f18524c0 c28a06e0
[ 15.794376] Call Trace:
[ 15.797109] [c24bc69a] cdc_ncm_bind+0x3a/0x50
[ 15.802267] [c24b8d32] usbnet_probe+0x282/0x7d0
[ 15.807621] [c2167f2c] ? sysfs_new_dirent+0x6c/0x100
[ 15.813460] [c2821253] ? mutex_lock+0x13/0x40
[ 15.818618] [c24bb278] cdc_ncm_probe+0x8/0x10
[ 15.823777] [c24e0ef7] usb_probe_interface+0x187/0x2c0
I still do not understand how this happens, but usbnet_link_change will
schedule some delayed work which absolutely is not appropriate if
usbnet_probe fails. There are no cancel_work calls in the usbnet_probe
exit path
So the call should definitely be avoided if bind fails.
Bjørn
--
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: Maintainers change for usb serial drivers
On Wed, Oct 30, 2013 at 11:07:31AM -0700, Greg KH wrote: Johan has been conned^Wgracious in accepting the maintainership of the USB serial drivers, especially as he's been doing all of the real work for the past few years. At the same time, remove a bunch of old entries for USB serial drivers that don't make sense anymore, given that the developers are no longer around, and individual driver maintainerships for tiny things like this is pretty pointless. Cc: Johan Hovold jhov...@gmail.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Acked-by: Johan Hovold jhov...@gmail.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: [PATCH 1/1] usb: hcd: move controller wakeup setting initialization to individual driver
On Wed, Oct 30, 2013 at 11:19:12AM -0400, Alan Stern wrote: On Wed, 30 Oct 2013, Peter Chen wrote: Individual controller driver has different requirement for wakeup setting, so move it from core to itself. In order to align with current etting the default wakeup setting is enabled (except for chipidea host). Pass compile test with below commands: make O=outout/all allmodconfig make -j$CPU_NUM O=outout/all drivers/usb Signed-off-by: Peter Chen peter.c...@freescale.com --- drivers/usb/c67x00/c67x00-hcd.c |1 + drivers/usb/core/hcd-pci.c |2 ++ drivers/usb/core/hcd.c |6 -- drivers/usb/gadget/dummy_hcd.c |2 ++ drivers/usb/host/ehci-atmel.c|1 + drivers/usb/host/ehci-exynos.c |1 + drivers/usb/host/ehci-fsl.c |1 + drivers/usb/host/ehci-grlib.c|1 + drivers/usb/host/ehci-mv.c |1 + drivers/usb/host/ehci-mxc.c |1 + drivers/usb/host/ehci-octeon.c |1 + drivers/usb/host/ehci-omap.c |1 + drivers/usb/host/ehci-orion.c|1 + drivers/usb/host/ehci-platform.c |1 + drivers/usb/host/ehci-pmcmsp.c |4 +++- drivers/usb/host/ehci-ppc-of.c |1 + drivers/usb/host/ehci-ps3.c |1 + drivers/usb/host/ehci-sead3.c|1 + drivers/usb/host/ehci-sh.c |1 + drivers/usb/host/ehci-spear.c|1 + drivers/usb/host/ehci-tegra.c|1 + drivers/usb/host/ehci-tilegx.c |1 + drivers/usb/host/ehci-w90x900.c |1 + drivers/usb/host/ehci-xilinx-of.c|4 +++- drivers/usb/host/fhci-hcd.c |1 + drivers/usb/host/fotg210-hcd.c |1 + drivers/usb/host/fusbh200-hcd.c |1 + drivers/usb/host/hwa-hc.c|1 + drivers/usb/host/imx21-hcd.c |1 + drivers/usb/host/isp116x-hcd.c |1 + drivers/usb/host/isp1362-hcd.c |1 + drivers/usb/host/isp1760-hcd.c |1 + drivers/usb/host/ohci-at91.c |4 +++- drivers/usb/host/ohci-da8xx.c|2 ++ drivers/usb/host/ohci-exynos.c |1 + drivers/usb/host/ohci-jz4740.c |1 + drivers/usb/host/ohci-nxp.c |4 +++- drivers/usb/host/ohci-octeon.c |1 + drivers/usb/host/ohci-omap.c |1 + drivers/usb/host/ohci-omap3.c|1 + drivers/usb/host/ohci-platform.c |1 + drivers/usb/host/ohci-ppc-of.c |4 +++- drivers/usb/host/ohci-ps3.c |1 + drivers/usb/host/ohci-pxa27x.c |4 +++- drivers/usb/host/ohci-s3c2410.c |1 + drivers/usb/host/ohci-sa.c |4 +++- drivers/usb/host/ohci-sm501.c|1 + drivers/usb/host/ohci-spear.c|4 +++- drivers/usb/host/ohci-tilegx.c |1 + drivers/usb/host/ohci-tmio.c |1 + drivers/usb/host/oxu210hp-hcd.c |1 + drivers/usb/host/r8a66597-hcd.c |1 + drivers/usb/host/sl811-hcd.c |1 + drivers/usb/host/u132-hcd.c |1 + drivers/usb/host/uhci-grlib.c|1 + drivers/usb/host/uhci-platform.c |1 + drivers/usb/host/whci/hcd.c |1 + drivers/usb/host/xhci-pci.c |1 + drivers/usb/host/xhci-plat.c |2 ++ drivers/usb/musb/musb_host.c |1 + drivers/usb/phy/phy-msm-usb.c|1 + drivers/usb/phy/phy-mv-usb.c |6 -- drivers/usb/renesas_usbhs/mod_host.c |1 + 63 files changed, 85 insertions(+), 16 deletions(-) You missed a few under drivers/staging and drivers/usb/wusbcore. Also, it isn't necessary to add the call to dummy-hcd.c. The controller in dummy-hcd is merely an emulated device, so it's not capable of generating wakeup events. Alan Stern drivers/usb/wusbcore driver has not called usb_add_hcd Will change others, and send v2. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: choice =y selection becomes lost after having multiple entries =m with depends on
* Dirk Gouders | 2013-10-30 15:26:30 [+0100]: Hi Sebastian, Yann, all, Hi Dirk, below is a patch that prevents choice_values to appear in the list if they depend on 'm' symbols and the choice symbol is set to 'y'. I would be glad if you could have a look at it. I applied this patch (and ignored the other one in this thread) and the problem Tomi Valkeinen noticed and I reported here seems to be gone. Thank you very much. Dirk Sebastian -- 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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote: Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11. If it makes no difference, it's not a pl2303 issue. I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't). Can you tell me why do we even want to use this divisor based calculation if we can do the same with direct method? I mean why the driver can't do this: 1) Try direct method for *all* chips. 2) If it succeeds, use that value. Then we don't get any difference between actual and set baud rate. 3) If it fails, then and only then use divisor based method. I would expect that the above cures my problem and possibly others who might have affected by this regression. -- 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 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Hans Verkuil hans.verk...@cisco.com Somehow, I lost your original post (I got unsubscribed on a few days from all vger mailing lists at the end of september). I suspect that you want to sent this via your tree, right? If so: Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Regards, Hans --- drivers/staging/media/dt3155v4l/dt3155v4l.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c index 90d6ac4..081407b 100644 --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id) int err; struct dt3155_priv *pd; - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; pd = kzalloc(sizeof(*pd), GFP_KERNEL); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- 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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Thu, Oct 31, 2013 at 01:09:55PM +0200, Mika Westerberg wrote:
On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
If it makes no difference, it's not a pl2303 issue.
I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't).
Can you tell me why do we even want to use this divisor based calculation
if we can do the same with direct method?
I mean why the driver can't do this:
1) Try direct method for *all* chips.
2) If it succeeds, use that value. Then we don't get any difference
between actual and set baud rate.
3) If it fails, then and only then use divisor based method.
I would expect that the above cures my problem and possibly others who
might have affected by this regression.
Something like the patch below.
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index bedf8e47713b..85f3fa4afc81 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -461,11 +461,11 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
enum pl2303_type type,
u8 buf[4])
{
- int baud;
+ int baud_req, baud;
- baud = tty_get_baud_rate(tty);
- dev_dbg(port-dev, baud requested = %d\n, baud);
- if (!baud)
+ baud_req = tty_get_baud_rate(tty);
+ dev_dbg(port-dev, baud requested = %d\n, baud_req);
+ if (!baud_req)
return;
/*
* There are two methods for setting/encoding the baud rate
@@ -480,10 +480,10 @@ static void pl2303_encode_baudrate(struct tty_struct *tty,
* the device likely uses the same baud rate generator for both methods
* so that there is likley no difference.
*/
- if (type == type_0 || type == type_1 || type == HX_CLONE)
- baud = pl2303_baudrate_encode_direct(baud, type, buf);
- else
- baud = pl2303_baudrate_encode_divisor(baud, type, buf);
+ baud = pl2303_baudrate_encode_direct(baud_req, type, buf);
+ if (baud != baud_req)
+ baud = pl2303_baudrate_encode_divisor(baud_req, type, buf);
+
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
dev_dbg(port-dev, baud set = %d\n, baud);
--
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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Am 31.10.2013 12:09, schrieb Mika Westerberg: On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote: Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11. If it makes no difference, it's not a pl2303 issue. I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't). Ok, here a two more things to test (on top of 3.12-rc + patch): 1) move the line port-port.drain_delay = 256; from pl2303_port_probe() back to the end pl2303_open(). 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); 3) Verify that the chip is detected as HXD_EA_RA_SA (in debug mode, there should be a corresponding dmesg line). These are the only remaining differences between 3.11 and 3.12. Can you tell me why do we even want to use this divisor based calculation if we can do the same with direct method? It seems that some of the newer chips don't work with the direct method at baud rates 115200. See commit 8d48fdf689fe USB: PL2303: correctly handle baudrates above 115200). As a said, the commit description is awful and the author doesn't reply to emails. But Prolific states that newer chips need a different baud rate handling, too, which indicates that this commit makes sense. So if we revert this old commit, we likely cause a regression with other pl2303 chips. Apart from that, the divisor based baud rate encoding has been working well since kernel 3.1. The divisor based baud rate method also allows (nearly) continious baud rate adjustment, while the direct method only supports a fixed set of standrad baud rates. Regards, Frank I mean why the driver can't do this: 1) Try direct method for *all* chips. 2) If it succeeds, use that value. Then we don't get any difference between actual and set baud rate. 3) If it fails, then and only then use divisor based method. I would expect that the above cures my problem and possibly others who might have affected by this regression. -- 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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Am 31.10.2013 13:03, schrieb Mika Westerberg:
On Thu, Oct 31, 2013 at 01:09:55PM +0200, Mika Westerberg wrote:
On Wed, Oct 30, 2013 at 11:14:34PM +0100, Frank Schäfer wrote:
Hmm... try to replace the whole pl2303.c from 3.12 with the one from 3.11.
If it makes no difference, it's not a pl2303 issue.
I did that and the 3.11 pl2303.c works (whereas 3.12 doesn't).
Can you tell me why do we even want to use this divisor based calculation
if we can do the same with direct method?
I mean why the driver can't do this:
1) Try direct method for *all* chips.
2) If it succeeds, use that value. Then we don't get any difference
between actual and set baud rate.
3) If it fails, then and only then use divisor based method.
I would expect that the above cures my problem and possibly others who
might have affected by this regression.
Something like the patch below.
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index bedf8e47713b..85f3fa4afc81 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -461,11 +461,11 @@ static void pl2303_encode_baudrate(struct tty_struct
*tty,
enum pl2303_type type,
u8 buf[4])
{
- int baud;
+ int baud_req, baud;
- baud = tty_get_baud_rate(tty);
- dev_dbg(port-dev, baud requested = %d\n, baud);
- if (!baud)
+ baud_req = tty_get_baud_rate(tty);
+ dev_dbg(port-dev, baud requested = %d\n, baud_req);
+ if (!baud_req)
return;
/*
* There are two methods for setting/encoding the baud rate
@@ -480,10 +480,10 @@ static void pl2303_encode_baudrate(struct tty_struct
*tty,
* the device likely uses the same baud rate generator for both methods
* so that there is likley no difference.
*/
- if (type == type_0 || type == type_1 || type == HX_CLONE)
- baud = pl2303_baudrate_encode_direct(baud, type, buf);
- else
- baud = pl2303_baudrate_encode_divisor(baud, type, buf);
+ baud = pl2303_baudrate_encode_direct(baud_req, type, buf);
+ if (baud != baud_req)
+ baud = pl2303_baudrate_encode_divisor(baud_req, type, buf);
+
That doesn't work.
The direct encoding always succeeds.
But if an unsupported baud rate is set, original chips silently run at
9600 baud and the Chinese clones produce data corruption. :/
Frank
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
dev_dbg(port-dev, baud set = %d\n, baud);
--
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: phy: Move R-Car Gen2 driver registration to postcore_inictall
On 10/31/2013 03:36 AM, Valentine wrote: On 10/30/2013 06:12 PM, Greg KH wrote: On Wed, Oct 30, 2013 at 01:56:25PM +0400, Valentine wrote: On 10/30/2013 03:57 AM, Greg KH wrote: On Tue, Oct 29, 2013 at 09:19:09PM +0400, Valentine wrote: On 10/29/2013 09:00 PM, Laurent Pinchart wrote: Hi Valentine, Thank you for the patch. On Tuesday 29 October 2013 20:21:06 Valentine Barshak wrote: USB phy controls USB channels 0 and 2 which are shared between PCI USB host controllers and USBHS/USBSS respectively. This Initializes USB phy driver earlier because we need it before PCI USB host controllers are initialized. Can't you use deferred probing ? No, unfortunately this doesn't work with PCI. We need the USB PHY set up before the PCI driver starts. PCI controllers should be initialized via subsys_initcall and can't be built as a module. Deferred probing is done at late_initcall and that's far too late in this case. The MXS USB phy uses the similar approach, initializing the driver via postcore_initcall. I _HATE_ this make this driver later than the others mess. I'll not This is actually make this driver before the others mess. take patches that move drivers to different initcalls, sorry. Please fix up the link order, or use deferred probing, as that is why it was created. This is needed for the PCI EHCI/OHCI drivers to operate correctly on R-Car Gen platform since it has built-in PCI host controllers that share USB I/O with USBHS/USBSS devices. The phy has to be configured before the PCI EHCI/OHCI devices are probed. I'd really appreciate if you could give me a hint on how to fix the PCI EHCI/OHCI driver to use deferred probing, or fix the link order without creating a bigger mess. Just change the PCI driver to use deferred probing, it isn't that hard to do so. Do you mean to change usb_hcd_pci_probe() to return -EPROBE_DEFER if the phy is not ready? Or should I defer the whole PCI subsystem initialization (pci_common_int)? Greg, the reason I ask is that it doesn't seem that simple to me. Here's some details: The h/w is an ARM SoC that has 3 internal PCI controllers with a single EHCI/OHCI on each one. This gives us 3 USB channels as this is called in the h/w manual. Channel 0 is shared with USBHS (USB function) device. Channel 2 is shared with USBSS (USB3.0 host). Both channels are configured by a single USB phy. USB PHY is a platform device, while EHCI/OCHI are located on the PCI busses. If PCI USB host is probed before USB phy, the EHCI/OHCI device is detected, but nothing works. We could change the USB HDC PCI driver and make usb_hcd_pci_probe() return -EPROBE_DEFER, but I'm not sure how the condition for that should be phrased. We could check the PCI vendor/device id, but there's no guarantee the same PCI device is not used on other Renesas h/w which do not require any PHY setup. More over we only need to setup the phy for the USB hosts connected to PCI controller 0/2. We could try to defer the PCI driver and call pci_common_init() after the USB phy is initialized. However, it seems that it's gonna be a bigger mess. 1. We need to add custom PCI bus scan callback to the hw_pci structure. We can't use default (pci_scan_root_bus) because it will try to probe/enable pci devices before their resources are fixed up when called late (after the PCI USB host drivers are registered). 2. All of the internal PCI controllers are initialized using a single call to the pci_common_init_dev(). So we can't easily defer just PCI controller 0/2. Even if we try to defer the whole PCI subsystem initialization, we probably need some sort of a dummy device that will defer pci_common_init_dev call untill USB phy is initialized. 3. The data structures and functions that are used to setup PCI are called at subsys_init() and marked __initdata/__init, so that we can easily get rid of them once the PCI is registered. Using deferred probe we'd need to keep them forever. Using late_initcall() instead of subsys_initcall() for the PCI registration might work if we implement custom PCI bus scan callback, But that's just doing the same thing that I've tried to do with USB phy here with additional PCI bus scan quirk. On the other hand, postcore_initcall is used in drivers/usb/phy/phy-mxs-usb.c which is in your tree. I agree that it's not that pretty, but it doesn't seem that bad considering other options we have. good luck, Thanks, Val. Please, let me know if you see better options. Thanks, Val. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote: 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); This seems to fix the problem :) Once the line is commented out, the serial console works fine with the speeds I've been testing (115200, 230400 and 460800). -- 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] usb: xhci: Less verbose tracing of short receives
Only receive TD can have a transfer length less than the transfer size,
so rename COMP_SHORT_TX to COMP_SHORT_RX, XHCI_TRUST_TX_LENGTH to
XHCI_TRUST_RX_LENGTH.
handle_tx_event() is called for both receive and transmit completions
so rename to handle_data_event().
In process_bulk_intr_td():
- Only trace unexpected short completions if XHCI_TRUST_RX_LENGTH isn't set,
ratelimit the trace (as is done elsewhere).
- Only debug trace short receives if URB_SHORT_NOT_OK isn't set.
---
I hope this isn't mangled!
---
drivers/usb/host/xhci-pci.c | 4 +--
drivers/usb/host/xhci-ring.c | 62 +---
drivers/usb/host/xhci.h | 4 +--
3 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index b8dffd5..97b3edc 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -89,7 +89,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
QUIRK: Fresco Logic revision %u
has broken MSI implementation,
pdev-revision);
- xhci-quirks |= XHCI_TRUST_TX_LENGTH;
+ xhci-quirks |= XHCI_TRUST_RX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_NEC)
@@ -135,7 +135,7 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
xhci-quirks |= XHCI_RESET_ON_RESUME;
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
QUIRK: Resetting on resume);
- xhci-quirks |= XHCI_TRUST_TX_LENGTH;
+ xhci-quirks |= XHCI_TRUST_RX_LENGTH;
}
if (pdev-vendor == PCI_VENDOR_ID_VIA)
xhci-quirks |= XHCI_RESET_ON_RESUME;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 6bfbd80..e38abc2 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2071,7 +2071,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
*status = 0;
}
break;
- case COMP_SHORT_TX:
+ case COMP_SHORT_RX:
if (td-urb-transfer_flags URB_SHORT_NOT_OK)
*status = -EREMOTEIO;
else
@@ -2166,9 +2166,9 @@ static int process_isoc_td(struct xhci_hcd *xhci, struct
xhci_td *td,
frame-status = 0;
break;
}
- if ((xhci-quirks XHCI_TRUST_TX_LENGTH))
- trb_comp_code = COMP_SHORT_TX;
- case COMP_SHORT_TX:
+ if ((xhci-quirks XHCI_TRUST_RX_LENGTH))
+ trb_comp_code = COMP_SHORT_RX;
+ case COMP_SHORT_RX:
frame-status = td-urb-transfer_flags URB_SHORT_NOT_OK ?
-EREMOTEIO : 0;
break;
@@ -2264,36 +2264,34 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci,
struct xhci_td *td,
switch (trb_comp_code) {
case COMP_SUCCESS:
/* Double check that the HW transferred everything. */
- if (event_trb != td-last_trb ||
- EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) != 0) {
- xhci_warn(xhci, WARN Successful completion
- on short TX\n);
- if (td-urb-transfer_flags URB_SHORT_NOT_OK)
- *status = -EREMOTEIO;
- else
- *status = 0;
- if ((xhci-quirks XHCI_TRUST_TX_LENGTH))
- trb_comp_code = COMP_SHORT_TX;
- } else {
+ if (event_trb == td-last_trb
+ EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)) == 0) {
*status = 0;
+ break;
}
- break;
- case COMP_SHORT_TX:
- if (td-urb-transfer_flags URB_SHORT_NOT_OK)
- *status = -EREMOTEIO;
+ if (xhci-quirks XHCI_TRUST_RX_LENGTH)
+ trb_comp_code = COMP_SHORT_RX;
else
+ xhci_warn_ratelimited(xhci,
+ WARN Successful completion on short
RX: needs XHCI_TRUST_RX_LENGTH quirk?\n);
+ /* FALLTHROUGH */
+ case COMP_SHORT_RX:
+ if (td-urb-transfer_flags URB_SHORT_NOT_OK) {
+ xhci_dbg(xhci, ep %#x - asked for %d bytes,
+ %d bytes untransferred\n,
+ td-urb-ep-desc.bEndpointAddress,
+ td-urb-transfer_buffer_length,
+
EVENT_TRB_LEN(le32_to_cpu(event-transfer_len)));
+ *status = -EREMOTEIO;
+
Re: [PATCH] usb: xhci: Less verbose tracing of short receives
On Thu, 31 Oct 2013, David Laight wrote: Only receive TD can have a transfer length less than the transfer size, Without commenting on the patch itself, let me point out that this statement is wrong. An OUT transfer can terminate early for several reasons. They are all error conditions, however, whereas an IN transfer can terminate early without any error. 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: CSW endpoint status returned STALL after BOT MSC Reset
On Thu, 31 Oct 2013, Pratyush Anand wrote: This is fine. But I do not see any way to unwedge ep0. dwc3_gadget_ep0_set_halt ignores *value* argument and will not handle a gadget driver's clear halt status request. However, I do no see any gadget driver wedging ep0, so may be it will not hurt. That's right. The only driver that needs to wedge an endpoint is usb-storage, and it never wedges ep0. 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 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote: Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Hans Verkuil hans.verk...@cisco.com Somehow, I lost your original post (I got unsubscribed on a few days from all vger mailing lists at the end of september). I suspect that you want to sent this via your tree, right? Yes please. If so: Acked-by: Mauro Carvalho Chehab m.che...@samsung.com Added, thanks. - err = dma_set_mask(pdev-dev, DMA_BIT_MASK(32)); - if (err) - return -ENODEV; - err = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32)); + err = dma_set_mask_and_coherent(pdev-dev, DMA_BIT_MASK(32)); if (err) return -ENODEV; One thing I've just noticed is that return should be return err not return -ENODEV - are you okay for me to change that in this patch? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gadget: should usb_ep_enable() clear EP STALL?
On Wed, Oct 30, 2013 at 10:44:30PM +0100, Johannes Stezenbach wrote: On Wed, Oct 30, 2013 at 12:54:15PM -0500, Felipe Balbi wrote: On Wed, Oct 30, 2013 at 03:17:46PM +0100, Johannes Stezenbach wrote: I'm testing dwc3 with g_zero and noticed that errors seem to stick even after SET_CONFIGURATION/SET_INTERFACE. In f_sourcesink.c, check_read_data() calls usb_ep_set_halt() if the data does not match the expected values, and sourcesink_set_alt() indirectly calls usb_ep_disable() and usb_ep_enable(). Now, include/linux/usb/gadget.h comments for usb_ep_enable() are not 100% clear wrt STALL, except making it usable sounds like it should clear it. However, usb_ep_set_halt() comments states: * Note that while an endpoint CLEAR_FEATURE will be invisible to the * gadget driver, a SET_INTERFACE will not be. To reset endpoints for the * current altsetting, see usb_ep_clear_halt(). When switching altsettings, * it's simplest to use usb_ep_enable() or usb_ep_disable() for the endpoints. That suggests to me that sourcesink_set_alt() is correct to simply call usb_ep_enable(), i.e. no explicit usb_ep_clear_halt() is needed? If so it would mean dwc3 ep_enable() is buggy. we clear those flags on usb_ep_disable(). You can't enable an endpoint which is already enabled. And you can see that when you're going to switch alt settings, f_sourcesink calls disable_source_sink() which will call disable_endpoints() which will disable each and every endpoint, thus clearing the such flags. Do you have any patches on f_sourcesink which might have caused this bug ? No patches, but maybe out of date code. However, I'm looking at current git master, I see you clear dep-flags but I don't see any dwc3_send_gadget_ep_cmd(DWC3_DEPCMD_CLEARSTALL)? I just tried to add __dwc3_gadget_ep_set_halt(dep, false); right before the call to __dwc3_gadget_ep_disable() in dwc3_gadget_ep_disable(), it seems to fix the issue. It is easily reproducible using the attached Python script, it should print: $ ./dwc3test.py [Errno 32] Pipe error (expected) OK but instead prints: $ ./dwc3test.py [Errno 32] Pipe error (expected) [Errno 32] Pipe error Thanks, Johannes #!/usr/bin/env python2 # g_zero speed test # needs pyusb-1.0.0b1 from http://sourceforge.net/projects/pyusb/ import sys sys.path.insert(0, ./pyusb-1.0.0b1) import usb.core import usb.util # find Linux gadget zero dev = usb.core.find(idVendor=0x0525, idProduct=0xa4a0) if dev is None: print 'Device not found' sys.exit(1) # choose data sink + source configuration dev.set_configuration(3) cfg = dev.get_active_configuration() # use first interface + alternate setting intf = cfg[(0,0)] out_ep = usb.util.find_descriptor( intf, custom_match = lambda e: \ usb.util.endpoint_direction(e.bEndpointAddress) == \ usb.util.ENDPOINT_OUT) try: out_ep.write(test) out_ep.write(test) except usb.core.USBError, e: print e, (expected) else: print error: didn't get the expected EPIPE # SET_INTERFACE should clear STALL intf.set_altsetting() try: out_ep.write(\0 * 4) except usb.core.USBError, e: print e else: print OK
[PATCH] Fix ring expansion on BE hosts.
Convert TRB_CYCLE to LE when initialising the ring entries.
---
drivers/usb/host/xhci-mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83bcd13..79cdcc2 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -57,7 +57,7 @@ static struct xhci_segment *xhci_segment_alloc(struct
xhci_hcd *xhci,
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
if (cycle_state == 0) {
for (i = 0; i TRBS_PER_SEGMENT; i++)
- seg-trbs[i].link.control |= TRB_CYCLE;
+ seg-trbs[i].link.control = cpu_to_le32(TRB_CYCLE);
}
seg-dma = dma;
seg-next = NULL;
--
1.8.1.2
--
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: gadget: should usb_ep_enable() clear EP STALL?
Hi, On Thu, Oct 31, 2013 at 04:02:20PM +0100, Johannes Stezenbach wrote: On Wed, Oct 30, 2013 at 10:44:30PM +0100, Johannes Stezenbach wrote: On Wed, Oct 30, 2013 at 12:54:15PM -0500, Felipe Balbi wrote: On Wed, Oct 30, 2013 at 03:17:46PM +0100, Johannes Stezenbach wrote: I'm testing dwc3 with g_zero and noticed that errors seem to stick even after SET_CONFIGURATION/SET_INTERFACE. In f_sourcesink.c, check_read_data() calls usb_ep_set_halt() if the data does not match the expected values, and sourcesink_set_alt() indirectly calls usb_ep_disable() and usb_ep_enable(). Now, include/linux/usb/gadget.h comments for usb_ep_enable() are not 100% clear wrt STALL, except making it usable sounds like it should clear it. However, usb_ep_set_halt() comments states: * Note that while an endpoint CLEAR_FEATURE will be invisible to the * gadget driver, a SET_INTERFACE will not be. To reset endpoints for the * current altsetting, see usb_ep_clear_halt(). When switching altsettings, * it's simplest to use usb_ep_enable() or usb_ep_disable() for the endpoints. That suggests to me that sourcesink_set_alt() is correct to simply call usb_ep_enable(), i.e. no explicit usb_ep_clear_halt() is needed? If so it would mean dwc3 ep_enable() is buggy. we clear those flags on usb_ep_disable(). You can't enable an endpoint which is already enabled. And you can see that when you're going to switch alt settings, f_sourcesink calls disable_source_sink() which will call disable_endpoints() which will disable each and every endpoint, thus clearing the such flags. Do you have any patches on f_sourcesink which might have caused this bug ? No patches, but maybe out of date code. However, I'm looking at current git master, I see you clear dep-flags but I don't see any dwc3_send_gadget_ep_cmd(DWC3_DEPCMD_CLEARSTALL)? I just tried to add __dwc3_gadget_ep_set_halt(dep, false); right before the call to __dwc3_gadget_ep_disable() in dwc3_gadget_ep_disable(), it seems to fix the issue. It is easily reproducible using the attached Python script, it should print: $ ./dwc3test.py [Errno 32] Pipe error (expected) OK but instead prints: $ ./dwc3test.py [Errno 32] Pipe error (expected) [Errno 32] Pipe error Thanks, Johannes #!/usr/bin/env python2 # g_zero speed test # needs pyusb-1.0.0b1 from http://sourceforge.net/projects/pyusb/ import sys sys.path.insert(0, ./pyusb-1.0.0b1) import usb.core import usb.util # find Linux gadget zero dev = usb.core.find(idVendor=0x0525, idProduct=0xa4a0) if dev is None: print 'Device not found' sys.exit(1) # choose data sink + source configuration dev.set_configuration(3) cfg = dev.get_active_configuration() # use first interface + alternate setting intf = cfg[(0,0)] out_ep = usb.util.find_descriptor( intf, custom_match = lambda e: \ usb.util.endpoint_direction(e.bEndpointAddress) == \ usb.util.ENDPOINT_OUT) try: out_ep.write(test) out_ep.write(test) except usb.core.USBError, e: print e, (expected) else: print error: didn't get the expected EPIPE # SET_INTERFACE should clear STALL intf.set_altsetting() try: out_ep.write(\0 * 4) except usb.core.USBError, e: print e else: print OK can you send a patch to dwc3 so we can review and possibly apply ? -- balbi signature.asc Description: Digital signature
Re: Gadget tool proposition
Hi, On Thu, Oct 31, 2013 at 01:35:45PM +0100, Krzysztof Opasiak wrote: Dear List, After introduction of ConfigFS composite gadget, there appeared an gap in the user space. I mean that without this file system, creation of gadget is as simple as: $ modprobe g_gadget_module [params] But when we are trying to use ConfigFS we have to write a lot of commands. The minimal set is: $ mkdir gadget name $ mkdir configs/config name.config number $ mkdir functions/fucion type.instance name $ ln -s functions/fucion configs/configuration $ echo udc name UDC + setting vendorID, productID and others not entirely true. not at all!!! We have provided stubs for the gadget drivers which were already in tree and you can still use modprobe g_mass_storage, etc. Ok, fine, but it's done only for backward compatibility. The main method of gadget creation should be configFS. yes, this is what I said on line below For new gadgets, then sure, they need to be done via configfs. See [1] for some examples of ConfigFS usage. With all ConfigFS benefits, flexibility and other advantages, it's 5 or maybe 10 times more writing than in the old solution to fulfill the most common use cases. Users are lazy, they will still use the old, bad solution, unless we will develop some user-space tool for convenient gadget management. there's already libgadget [1] which Matt Porter has been working on, how about you help him out ? I'd really like to see libgadget bindings for ruby, for example. As well as some default examples for current, in-tree gadget drivers. As I wrote in previous message. I would like to use libgadget. There are some issues, but I will prepare some patches which implements the missing things, I that Matt will accept them. More over I'm not sure if there is a need to have two projects - gt and libgadget. Maybe create only one and only in distributions provide separate packages for tool and library. What do you think Matt? sounds good to me. I was recently thinking about this issue, so I would like to introduce you my design proposition of gt - flexible gadget tool. First of all, the name should be short so I have chosen just simply gt [2]. [Proof of Concept] I have divided my tool into two parts: === Custom gadget manipulation === First part is a wrapper for file system manipulations and it allow user to use the flexibility of ConfigFS and compose their own fully custom gadget. Some example commands: Gadget, Function or Configuration creation: $ gt create gadget name [attr=val] $ gt func create gadget name [attr=val] $ gt config create gadget name [attr=val] Removal is also as simple as creation just use rm instead of create. When gadget is created you can set it's attributes using: $ gt set gadget_name attr=val For function or Config simply add config or func to your call. Gadget/function/Confiuration may contain additional folders, so the attribute can have / signs. For example to create a folder you should use: $ gt set gadget1 strings/0x415/=1 Above command will create subdir 0x415 in strings directory of gadget1. After that you can simply set all values below, for example: gt set gadget1 strings/0x415/manofacturer=Polski producent Simple, isn't it? this all sounds like it should be a tool using Matt's libgadget. === Gadget templates === The second part of a gadget tool are gadget templates. It's my idea to full fill the most standard use case with really simple and convenient commands. What is gadget template? It's a file where in some format (XML looks suitable here) all the setting of gadget or function etc are stored. How it will work? User sets up some custom gadget using commands from first part. The next step is to store this gadget it gadget template using: $ gt save gadget1 my_first_gadget_template Then users can distribute those templates as standard text files. When a gadget is needed user simply executes: $ gt load my_first_gadget_template And the gt will parse the file and create gadget1 in ConfigFS. All the values of attributes will be restored, and we will get the fully configured and enabled gadget. It's even simpler than the old method which used modeprobe, isn't it? right, this is a nice feature which I'd actually expect from such a tool. Great, I hope you will enjoy using the new tool when it will be ready. sure, for testing purposes it's awesome, but when building a real device, I'd expect application framework to use libgadget directly and use your tool as a reference implementation. -- balbi signature.asc Description: Digital signature
Large USB HID transfers
Hello, We are using a linux device as a iPad MFI peripheral. In the current scenario, the iPad is the USB device, and linux system is the host. With Apple MFI in this configuration, the only protocol available to transfer data is HID. We're noticing that when we transfer a lot of data over HID, the kernel is locked (seems that interrupts are disabled) for up to 40ms at a time. We noticed a big improvement when upgrading from the 3.0 to the 3.12 kernel, but the problem is still there. The CPU is the TI DM3730 (same as beaglebone-xm). Is this expected? Any suggestions on where to start looking to improve this. Thanks, Cliff -- = http://bec-systems.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: khubd timed out on ep0in len=0/64 with 3.4 kernel
On Wed, 30 Oct 2013, Prasad Koya wrote: Hi Here are dmesg's with old_scheme_first=1 and where it took about 20s for usb-storage to start using this device. Is there a way I can enable debugs from usb-storage to see what it is doing in that 20s gap. The device in question is at usb1-3 (sdb), manufactured by SMART. The easiest way to find out is by using usbmon, not by enabling debug in usb-storage. 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: Large USB HID transfers
On Thu, Oct 31, 2013 at 11:24:05AM -0400, Cliff Brake wrote: Hello, We are using a linux device as a iPad MFI peripheral. In the current scenario, the iPad is the USB device, and linux system is the host. With Apple MFI in this configuration, the only protocol available to transfer data is HID. We're noticing that when we transfer a lot of data over HID, the kernel is locked (seems that interrupts are disabled) for up to 40ms at a time. We noticed a big improvement when upgrading from the 3.0 to the 3.12 kernel, but the problem is still there. The CPU is the TI DM3730 (same as beaglebone-xm). Is this expected? Any suggestions on where to start looking to improve this. I'd focus on the host controller driver, it would be the one that is probably the issue (you can test this with a PC running Linux and a different host controller.) USB transfers cause irqs to be disabled during the callbacks, that's the way the stack is written (people are slowly working on resolving this.) Does holding interrupts off for that long cause problems for you? If so, perhaps you should change hardware platforms? (not to a rpi, those are _way_ worse for USB...) sorry, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large USB HID transfers
On Thu, Oct 31, 2013 at 11:56 AM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Oct 31, 2013 at 11:24:05AM -0400, Cliff Brake wrote: I'd focus on the host controller driver, it would be the one that is probably the issue (you can test this with a PC running Linux and a different host controller.) Thanks for the suggestion. USB transfers cause irqs to be disabled during the callbacks, that's the way the stack is written (people are slowly working on resolving this.) Does holding interrupts off for that long cause problems for you? Yes, its an embedded application where a serial port is receiving data at 1.5Mbit. So when the kernel gets locked, it appears the 64-byte serial fifo's are overflowing. If so, perhaps you should change hardware platforms? (not to a rpi, those are _way_ worse for USB...) :-) With 1000's of units in the field, I guess we'll work on a fix ... Thanks, Cliff -- 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: phy: Move R-Car Gen2 driver registration to postcore_inictall
On Thu, Oct 31, 2013 at 12:43 PM, Valentine valentine.bars...@cogentembedded.com wrote: Please, let me know if you see better options. How about disregarding the whole PCI aspect? I mean, yes, those are PCI busses, but they are internal, with a fixed set of devices attached, and as far as I can tell there are no other PCI busses in the system. So how about treating the USB host controllers as platform devices the way it's done in the vendor kernel, saving us the trouble of pulling in the entire PCI subsystem without any tangible benefit? CU Uli -- 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
xhci ring expansion
Code was recently added to the xhci driver to dynamically add extra ring segments if there is insufficient space for all the fragments of the URB being sent. ISTM that it would be better to just queue the URB (on the ring) and process it when space becomes available. This wouldn't solve the problem of pathologically badly fragmented, or very long URB, but there are simpler solutions to that. I believe that very long bulk transfers can be split into separate TD on USB block boundaries - so they can be safely added to the ring in several pieces. I don't know if any other data type is allowed to exceed the block length? Badly fragmented URB are probably best copied into a linear buffer. This would make the code a lot simpler, especially since the tx setup could be started if there were a 'reasonable' number of free entries in the TRB ring without having to calculate the actual number needed (and Additionally it would make it possible to ensure that LINK TRB only happen on the appropriate boundary. This might require some fragments be copied to a linear buffer. If this is a reasonable idea I'll volunteer to do the changes. We are seeing some issues with the xhci driver, and parts of it are just to contorted! 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] usb: phy: Move R-Car Gen2 driver registration to postcore_inictall
On 10/31/2013 08:12 PM, Ulrich Hecht wrote: On Thu, Oct 31, 2013 at 12:43 PM, Valentine valentine.bars...@cogentembedded.com wrote: Please, let me know if you see better options. How about disregarding the whole PCI aspect? I mean, yes, those are PCI busses, but they are internal, with a fixed set of devices attached, and as far as I can tell there are no other PCI busses in the system. So how about treating the USB host controllers as platform devices the way it's done in the vendor kernel, saving us the trouble of pulling in the entire PCI subsystem without any tangible benefit? There's also a PCIe bus available on the SoC. It is not yet supported, but we'll eventually need the entire PCI subsystem, which is not that huge as it may seem, btw. Besides, the internal PCI driver has already been submitted to the PCI mailing list and applied to Bjorn's tree. I don't see how treating the PCI devices as platform devices is better than adjusting the initialization order of the USB phy. CU Uli Thanks, Val. -- 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: phy: Move R-Car Gen2 driver registration to postcore_inictall
On Thu, 31 Oct 2013, Valentine wrote: Do you mean to change usb_hcd_pci_probe() to return -EPROBE_DEFER if the phy is not ready? Or should I defer the whole PCI subsystem initialization (pci_common_int)? Greg, the reason I ask is that it doesn't seem that simple to me. Here's some details: The h/w is an ARM SoC that has 3 internal PCI controllers with a single EHCI/OHCI on each one. This gives us 3 USB channels as this is called in the h/w manual. Channel 0 is shared with USBHS (USB function) device. Channel 2 is shared with USBSS (USB3.0 host). Both channels are configured by a single USB phy. USB PHY is a platform device, while EHCI/OCHI are located on the PCI busses. If PCI USB host is probed before USB phy, the EHCI/OHCI device is detected, but nothing works. We could change the USB HDC PCI driver and make usb_hcd_pci_probe() return -EPROBE_DEFER, but I'm not sure how the condition for that should be phrased. You need to tell usb_hcd_pci_probe() to wait for the PHY. That seems to be the proper solution to your problem. The difficulty is that you have a discoverable device (the PCI EHCI controller) which needs to wait for a platform device (the PHY). The kernel doesn't have a good way to describe such a constraint between two different kinds of device like that, as far as I know. This is similar to the problems facing Runtime Interpreted Power Sequences, although not quite the same. 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: khubd timed out on ep0in len=0/64 with 3.4 kernel
I tried usbmon before forcing crash:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 5
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 2.06
S: Manufacturer=Linux 2.6.32.28 ehci_hcd
S: Product=EHCI Host Controller
S: SerialNumber=:00:12.2
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0e39 ProdID=2b00 Rev=88.3c
S: Manufacturer=SMART
S: Product=eUSB
S: SerialNumber=29879006164049261011
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=31875us
bash-4.1#
As this USB is on bus 1, I tried below:
cat /sys/kernel/debug/usb/usbmon/1u
I didn't see anything till I copied a file or did some activity on it.
While cat'ing above, I copied a file to that flash with dd in another
terminal and I got this:
-bash-4.1# cat /sys/kernel/debug/usb/usbmon/1u
88013e81acc0 1352058978 S Bo:1:002:2 -115 31 = 55534243 301d
00e00100 0a2a 1a8f 97f0 00
88013e81acc0 1352059090 C Bo:1:002:2 0 31
8800a9a306c0 1352059112 S Bo:1:002:2 -115 4096 =
8800a9a30600 1352059115 S Bo:1:002:2 -115 8192 =
8800a9a30480 1352059117 S Bo:1:002:2 -115 8192 =
8800b2981d40 1352059119 S Bo:1:002:2 -115 8192 =
8800b2981c80 1352059120 S Bo:1:002:2 -115 8192 =
8800b2981b00 1352059122 S Bo:1:002:2 -115 8192 =
8800b2981bc0 1352059123 S Bo:1:002:2 -115 8192 =
8800b2981a40 1352059125 S Bo:1:002:2 -115 8192 =
88013e8a3140 1352059126 S Bo:1:002:2 -115 8192 =
88013e8a3500 1352059127 S Bo:1:002:2 -115 8192 =
88013e8a3440 1352059129 S Bo:1:002:2 -115 8192 =
88013e8a3740 1352059130 S Bo:1:002:2 -115 8192 =
88013e8a3380 1352059131 S Bo:1:002:2 -115 8192 =
88013e8a3080 1352059133 S Bo:1:002:2 -115 8192 =
88013e8532c0 1352059134 S Bo:1:002:2 -115 8192 =
88013e9cd900 1352059135 S Bo:1:002:2 -115 4096 =
8800a9a306c0 1352068401 C Bo:1:002:2 0 4096
8800a9a30600 1352068410 C Bo:1:002:2 0 8192
8800a9a30480 1352068411 C Bo:1:002:2 0 8192
8800b2981d40 1352068413 C Bo:1:002:2 0 8192
8800b2981c80 1352068414 C Bo:1:002:2 0 8192
8800b2981b00 1352068416 C Bo:1:002:2 0 8192
8800b2981bc0 1352068424 C Bo:1:002:2 0 8192
8800b2981a40 1352068425 C Bo:1:002:2 0 8192
88013e8a3140 1352068427 C Bo:1:002:2 0 8192
88013e8a3500 1352068428 C Bo:1:002:2 0 8192
88013e8a3440 1352068430 C Bo:1:002:2 0 8192
88013e8a3740 1352068431 C Bo:1:002:2 0 8192
88013e8a3380 1352068432 C Bo:1:002:2 0 8192
88013e8a3080 1352068434 C Bo:1:002:2 0 8192
88013e8532c0 1352069318 C Bo:1:002:2 0 8192
88013e9cd900 1352069328 C Bo:1:002:2 0 4096
88013e81acc0 1352069359 S Bi:1:002:1 -115 13
88013e81acc0 1352069818 C Bi:1:002:1 0 13 = 55534253 301d 00
88013e81acc0 1352069918 S Bo:1:002:2 -115 31 = 55534243 311d
00e00100 0a2a 1a90 87f0 00
88013e81acc0 1352070055 C Bo:1:002:2 0 31
But I'm seeing the issue in early boot. So is there any other way to
get the usbmon traces out?
Thank you.
On Thu, Oct 31, 2013 at 8:52 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 30 Oct 2013, Prasad Koya wrote:
Hi
Here are dmesg's with old_scheme_first=1 and where it took about 20s
for usb-storage to start using this device. Is there a way I can
enable debugs from usb-storage to see what it is doing in that 20s
gap. The device in question is at usb1-3 (sdb),
Re: Large USB HID transfers
On Thu, Oct 31, 2013 at 12:09:54PM -0400, Cliff Brake wrote: On Thu, Oct 31, 2013 at 11:56 AM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Oct 31, 2013 at 11:24:05AM -0400, Cliff Brake wrote: I'd focus on the host controller driver, it would be the one that is probably the issue (you can test this with a PC running Linux and a different host controller.) Thanks for the suggestion. USB transfers cause irqs to be disabled during the callbacks, that's the way the stack is written (people are slowly working on resolving this.) Does holding interrupts off for that long cause problems for you? Yes, its an embedded application where a serial port is receiving data at 1.5Mbit. So when the kernel gets locked, it appears the 64-byte serial fifo's are overflowing. Ick, that's not good. This sounds like a driver issue, if you can find out where interrupts are being held for so long, hopefully a fix can be found and resolved. It's good that 3.11 is better, but ideally a real fix can be created. What host controller driver are you using? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Large USB HID transfers
On Thu, Oct 31, 2013 at 1:54 PM, Greg KH gre...@linuxfoundation.org wrote: Ick, that's not good. This sounds like a driver issue, if you can find out where interrupts are being held for so long, hopefully a fix can be found and resolved. It's good that 3.11 is better, but ideally a real fix can be created. What host controller driver are you using? Its the USB EHCI host in the TI DM3730, so it uses the drivers/usb/host/ehci-omap.c driver. Thanks, Cliff -- = http://bec-systems.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: khubd timed out on ep0in len=0/64 with 3.4 kernel
On Thu, 31 Oct 2013, Prasad Koya wrote: I tried usbmon before forcing crash: As this USB is on bus 1, I tried below: cat /sys/kernel/debug/usb/usbmon/1u I didn't see anything till I copied a file or did some activity on it. While cat'ing above, I copied a file to that flash with dd in another terminal and I got this: ... But I'm seeing the issue in early boot. So is there any other way to get the usbmon traces out? That makes it more difficult. You can't use usbmon during early boot, so your only option is to enable CONFIG_USB_STORAGE_DEBUG. The output is more verbose, but we should be able to see what's going on. 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: Large USB HID transfers
On Thu, 31 Oct 2013, Cliff Brake wrote: On Thu, Oct 31, 2013 at 1:54 PM, Greg KH gre...@linuxfoundation.org wrote: Ick, that's not good. This sounds like a driver issue, if you can find out where interrupts are being held for so long, hopefully a fix can be found and resolved. It's good that 3.11 is better, but ideally a real fix can be created. What host controller driver are you using? Its the USB EHCI host in the TI DM3730, so it uses the drivers/usb/host/ehci-omap.c driver. You can find out exactly what part of the kernel is responsible for interrupt delays by using the irqsoff tracer. See Documentation/trace/ftrace.txt for details about how to use it. 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: Large USB HID transfers
On Thu, Oct 31, 2013 at 2:25 PM, Alan Stern st...@rowland.harvard.edu wrote: On Thu, 31 Oct 2013, Cliff Brake wrote: On Thu, Oct 31, 2013 at 1:54 PM, Greg KH gre...@linuxfoundation.org wrote: Ick, that's not good. This sounds like a driver issue, if you can find out where interrupts are being held for so long, hopefully a fix can be found and resolved. It's good that 3.11 is better, but ideally a real fix can be created. What host controller driver are you using? Its the USB EHCI host in the TI DM3730, so it uses the drivers/usb/host/ehci-omap.c driver. You can find out exactly what part of the kernel is responsible for interrupt delays by using the irqsoff tracer. See Documentation/trace/ftrace.txt for details about how to use it. Thanks, I'll try to get some data on that. Its interesting that we've not observed problems with any other USB devices (network, mass storage, etc). Cliff -- = http://bec-systems.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: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Am 31.10.2013 13:30, schrieb Mika Westerberg: On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote: 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); This seems to fix the problem :) Once the line is commented out, the serial console works fine with the speeds I've been testing (115200, 230400 and 460800). Urgh... so it seems getty gets confused if the actually set baud rate is reported back. The kernel still reports the standard baud rate (e.g. B230400), it only sets the exact value in the c_ispeed and c_ospeed fields of the termios struct. So even if getty doesn't support non-standard baud rates, everything should be fine. I'll have to take a closer look at this issue later. Ok, so now let's see if the fixed/improved divisor based method also works for the HXD chip if we don't report the actually set baud rate. Try commenting out the line baud = 1200 * 32 / ((1 A) * B); at the end of pl2303_baudrate_encode_divisor() of a clean 3.12-rc kernel. It's unlikely that this makes baud rates 115200 working, but testing both cases doesn't harm. ;) Regards, Frank -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget driver
On 10/30/2013 10:35 AM, Felipe Balbi wrote: On Wed, Oct 30, 2013 at 10:06:18AM -0700, David Cohen wrote: DWC3 requires epout to have buffer size aligned to MaxPacketSize value. This patch adds necessary quirk for it. Signed-off-by: David Cohen david.a.co...@linux.intel.com --- drivers/usb/dwc3/gadget.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 5452c0f..528c7d7 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2600,6 +2600,12 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc-gadget.name= dwc3-gadget; /* + * Per databook, DWC3 needs buffer size to be aligned to MaxPacketSize + * on ep out. + */ +dwc-gadget.quirk_ep_out_aligned_size = 1; just to make it look cooler and neater, could you set to 'true' instead :-) 'bool' is an alien in C :) But I can change to true in next patch set. Br, David Cohen -- 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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote: On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote: Am 31.10.2013 13:30, schrieb Mika Westerberg: On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote: 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); This seems to fix the problem :) Once the line is commented out, the serial console works fine with the speeds I've been testing (115200, 230400 and 460800). Urgh... so it seems getty gets confused if the actually set baud rate is reported back. The kernel still reports the standard baud rate (e.g. B230400), it only sets the exact value in the c_ispeed and c_ospeed fields of the termios struct. So even if getty doesn't support non-standard baud rates, everything should be fine. I'll have to take a closer look at this issue later. I think I know what's going on. The pl2303 is known to loose bytes when changing the termios settings (see commit bf5e5834b (pl2303: Fix mode switching regression)). Your commit 57ce61aad (usb: pl2303: fix+improve the divisor based baud rate encoding method) introduced a regression when it started reporting back the baudrates determined by the divisor algorithm. Since that commit, tty_termios_hw_change(tty-termios, old_termios) will always return true -- even when userspace isn't requesting a different baudrate. Ok, so now let's see if the fixed/improved divisor based method also works for the HXD chip if we don't report the actually set baud rate. Try commenting out the line baud = 1200 * 32 / ((1 A) * B); at the end of pl2303_baudrate_encode_divisor() of a clean 3.12-rc kernel. It's unlikely that this makes baud rates 115200 working, but testing both cases doesn't harm. ;) I can trigger the problem here with my HXD/EA/RA/SA-device as well, and I've verified that not returning the calculated baudrate makes this particular issue *seem* to go away. This obviously has to be fixed or reverted quickly. Greg, what do you say about this? Is reverting for 3.12 the correct way to deal with this, and make sure these fairly invasive patches get some more testing before being reapplied? Reverting would mean reverting a whole bunch of commits though, as they appear to depend quite heavily on each other: 7d26a78 USB: pl2303: distinguish between original and cloned HX chips 034d152 pl2303: improve the chip type detection/distinction a77a8c2 pl2303: improve the chip type information output on startup 73b583a pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() c23bda3 usb: pl2303: add two comments concerning the supported baud rates with HX chips 61fa8d6 usb: pl2303: also use the divisor based baud rate encoding method for baud rates 115200 with HX chips b5c16c6 usb: pl2303: increase the allowed baud rate range for the divisor based encoding method e917ba0 usb: pl2303: move the two baud rate encoding methods to separate functions b9208c7 usb: pl2303: remove 50 baud from the list of standard baud rates 75417d9 usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method 57ce61a usb: pl2303: fix+improve the divsor based baud rate encoding method b8bdad6 USB: pl2303: restrict the divisor based baud rate encoding method to the HX chip type Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Thu, Oct 31, 2013 at 09:56:25PM +0100, Johan Hovold wrote: On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote: On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote: Am 31.10.2013 13:30, schrieb Mika Westerberg: On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote: 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); This seems to fix the problem :) Once the line is commented out, the serial console works fine with the speeds I've been testing (115200, 230400 and 460800). Urgh... so it seems getty gets confused if the actually set baud rate is reported back. The kernel still reports the standard baud rate (e.g. B230400), it only sets the exact value in the c_ispeed and c_ospeed fields of the termios struct. So even if getty doesn't support non-standard baud rates, everything should be fine. I'll have to take a closer look at this issue later. I think I know what's going on. The pl2303 is known to loose bytes when changing the termios settings (see commit bf5e5834b (pl2303: Fix mode switching regression)). Your commit 57ce61aad (usb: pl2303: fix+improve the divisor based baud rate encoding method) introduced a regression when it started reporting back the baudrates determined by the divisor algorithm. Since that commit, tty_termios_hw_change(tty-termios, old_termios) will always return true -- even when userspace isn't requesting a different baudrate. Ok, so now let's see if the fixed/improved divisor based method also works for the HXD chip if we don't report the actually set baud rate. Try commenting out the line baud = 1200 * 32 / ((1 A) * B); at the end of pl2303_baudrate_encode_divisor() of a clean 3.12-rc kernel. It's unlikely that this makes baud rates 115200 working, but testing both cases doesn't harm. ;) I can trigger the problem here with my HXD/EA/RA/SA-device as well, and I've verified that not returning the calculated baudrate makes this particular issue *seem* to go away. This obviously has to be fixed or reverted quickly. Greg, what do you say about this? Is reverting for 3.12 the correct way to deal with this, and make sure these fairly invasive patches get some more testing before being reapplied? Reverting would mean reverting a whole bunch of commits though, as they appear to depend quite heavily on each other: Ick :( Would fixing the return the baudrate issue solve this in an easier way than to revert all of these? That might be an easier, and smaller, patch that can get added to 3.12-stable, right? 7d26a78 USB: pl2303: distinguish between original and cloned HX chips 034d152 pl2303: improve the chip type detection/distinction a77a8c2 pl2303: improve the chip type information output on startup 73b583a pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() c23bda3 usb: pl2303: add two comments concerning the supported baud rates with HX chips 61fa8d6 usb: pl2303: also use the divisor based baud rate encoding method for baud rates 115200 with HX chips b5c16c6 usb: pl2303: increase the allowed baud rate range for the divisor based encoding method e917ba0 usb: pl2303: move the two baud rate encoding methods to separate functions b9208c7 usb: pl2303: remove 50 baud from the list of standard baud rates 75417d9 usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method 57ce61a usb: pl2303: fix+improve the divsor based baud rate encoding method b8bdad6 USB: pl2303: restrict the divisor based baud rate encoding method to the HX chip type Or I can just revert all of them for 3.12-stable as well, let me know which one you want me to do. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget driver
On Thu, Oct 31, 2013 at 12:58:51PM -0700, David Cohen wrote: On 10/30/2013 10:35 AM, Felipe Balbi wrote: On Wed, Oct 30, 2013 at 10:06:18AM -0700, David Cohen wrote: DWC3 requires epout to have buffer size aligned to MaxPacketSize value. This patch adds necessary quirk for it. Signed-off-by: David Cohen david.a.co...@linux.intel.com --- drivers/usb/dwc3/gadget.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 5452c0f..528c7d7 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2600,6 +2600,12 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc-gadget.name= dwc3-gadget; /* + * Per databook, DWC3 needs buffer size to be aligned to MaxPacketSize + * on ep out. + */ + dwc-gadget.quirk_ep_out_aligned_size = 1; just to make it look cooler and neater, could you set to 'true' instead :-) 'bool' is an alien in C :) But I can change to true in next patch set. don't change the type, just assign true instead of 1. true is defined as !0, so it'll be a 1 anywa. Still the rest of the driver uses true/false for one-bit fields. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] lib/scatterlist: export sg_miter_skip()
On Wed, 30 Oct 2013 00:07:22 +0800 Ming Lei ming@canonical.com wrote:
sg_copy_buffer() can't meet demand for some drrivers(such usb
mass storage), so we have to use the sg_miter_* APIs to access
sg buffer, then need export sg_miter_skip() for these drivers.
The API is needed for converting to sg_miter_* APIs in USB storage
driver for accessing sg buffer.
...
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -345,6 +345,7 @@ struct sg_mapping_iter {
void sg_miter_start(struct sg_mapping_iter *miter, struct scatterlist *sgl,
unsigned int nents, unsigned int flags);
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset);
bool sg_miter_next(struct sg_mapping_iter *miter);
void sg_miter_stop(struct sg_mapping_iter *miter);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d16fa29..3a8e8e8 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -495,7 +495,7 @@ static bool sg_miter_get_next_page(struct sg_mapping_iter
*miter)
* true if @miter contains the valid mapping. false if end of sg
* list is reached.
*/
-static bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
{
sg_miter_stop(miter);
@@ -513,6 +513,7 @@ static bool sg_miter_skip(struct sg_mapping_iter *miter,
off_t offset)
return true;
}
+EXPORT_SYMBOL(sg_miter_skip);
/**
* sg_miter_next - proceed mapping iterator to the next mapping
Looks OK to me. Please include this in whatever tree is used to merge
[PATCH 2/2] USB: storage: use sg_miter_* APIs to access scsi buffer.
--
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: choice =y selection becomes lost after having multiple entries =m with depends on
Dirk, All, On 2013-10-30 15:26 +0100, Dirk Gouders spake thusly: Dirk Gouders d...@gouders.net writes: [--SNIP--] below is a patch that prevents choice_values to appear in the list if they depend on 'm' symbols and the choice symbol is set to 'y'. I would be glad if you could have a look at it. Next time, could you use 'git send-email' to send your patches, it makes reviewing and commenting much simpler. Also, it does not mangle the patch commit, and thus makes it easier to apply with 'git am'. Yann, in this patch I wrote if (choice_sym != NULL... -- I guess that is one point that you will probably remark in the previous patch. When we check that a pointer is valid, there's no reason to check it against NULL, just: if (choice_sym choice_sym-...) Another point is that all the conditionals in both patches could be I am not sure I understand what issue this patch(es) are supposed to fix. What bothers me is that they touch two different places in the code, yet have the same subject, so it seems both are tryiong to fix the same issue. Do you intend that both patches should be applied, or that this second one supersedes the previous one? limited to only those choice_values that are of type tristate but I think that makes the code even harder to read... Yes, and it does not matter since non-trisates are necessarily booleans, and those are covered since they will never be '== mod', so their visibility was, and still is, properly handled. From 677f5830588749cbb0bdb0568cbdaba271937c8d Mon Sep 17 00:00:00 2001 From: Dirk Gouders d...@gouders.net Date: Wed, 30 Oct 2013 15:06:05 +0100 Subject: [PATCH 2/2] kconfig/symbol.c: handle visibility of choice_values that depend on 'm' symbols If choice_values depend on symbols that are set to 'm' then these choice_values should not be visible in choice lists if the choice symbol is set to 'y'. See USB Gadget Drivers, for example. I liked your previous commit message better, because it had a test-case that did exhibit the problem. Can you please: - confirm which patch/es is/are needed - update the commit log/s back with the test-case/s - resend needed patch/es Thank you! Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `.---: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy. | '--^---^--^' -- 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] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Thu, Oct 31, 2013 at 02:03:22PM -0700, Greg KH wrote: On Thu, Oct 31, 2013 at 09:56:25PM +0100, Johan Hovold wrote: On Thu, Oct 31, 2013 at 09:26:06PM +0100, Johan Hovold wrote: On Thu, Oct 31, 2013 at 7:45 PM, Frank Schäfer wrote: Am 31.10.2013 13:30, schrieb Mika Westerberg: On Thu, Oct 31, 2013 at 01:02:56PM +0100, Frank Schäfer wrote: 2) comment out the following line at the end of pl2303_baudrate_encode_divisor_HXD(): baud = 1200 * 32 / ((1 buf[1]) * buf[0]); This seems to fix the problem :) Once the line is commented out, the serial console works fine with the speeds I've been testing (115200, 230400 and 460800). Urgh... so it seems getty gets confused if the actually set baud rate is reported back. The kernel still reports the standard baud rate (e.g. B230400), it only sets the exact value in the c_ispeed and c_ospeed fields of the termios struct. So even if getty doesn't support non-standard baud rates, everything should be fine. I'll have to take a closer look at this issue later. I think I know what's going on. The pl2303 is known to loose bytes when changing the termios settings (see commit bf5e5834b (pl2303: Fix mode switching regression)). Your commit 57ce61aad (usb: pl2303: fix+improve the divisor based baud rate encoding method) introduced a regression when it started reporting back the baudrates determined by the divisor algorithm. Since that commit, tty_termios_hw_change(tty-termios, old_termios) will always return true -- even when userspace isn't requesting a different baudrate. Ok, so now let's see if the fixed/improved divisor based method also works for the HXD chip if we don't report the actually set baud rate. Try commenting out the line baud = 1200 * 32 / ((1 A) * B); at the end of pl2303_baudrate_encode_divisor() of a clean 3.12-rc kernel. It's unlikely that this makes baud rates 115200 working, but testing both cases doesn't harm. ;) I can trigger the problem here with my HXD/EA/RA/SA-device as well, and I've verified that not returning the calculated baudrate makes this particular issue *seem* to go away. This obviously has to be fixed or reverted quickly. Greg, what do you say about this? Is reverting for 3.12 the correct way to deal with this, and make sure these fairly invasive patches get some more testing before being reapplied? Reverting would mean reverting a whole bunch of commits though, as they appear to depend quite heavily on each other: Ick :( Would fixing the return the baudrate issue solve this in an easier way than to revert all of these? That might be an easier, and smaller, patch that can get added to 3.12-stable, right? It would possibly be sufficient, but I don't have much time the next couple of days to do much further digging and verification of this. There could be other ways to trigger the problem and I'd like to get a chance to look into that as well. 7d26a78 USB: pl2303: distinguish between original and cloned HX chips 034d152 pl2303: improve the chip type detection/distinction a77a8c2 pl2303: improve the chip type information output on startup 73b583a pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() c23bda3 usb: pl2303: add two comments concerning the supported baud rates with HX chips 61fa8d6 usb: pl2303: also use the divisor based baud rate encoding method for baud rates 115200 with HX chips b5c16c6 usb: pl2303: increase the allowed baud rate range for the divisor based encoding method e917ba0 usb: pl2303: move the two baud rate encoding methods to separate functions b9208c7 usb: pl2303: remove 50 baud from the list of standard baud rates 75417d9 usb: pl2303: do not round to the next nearest standard baud rate for the divisor based baud rate encoding method 57ce61a usb: pl2303: fix+improve the divsor based baud rate encoding method b8bdad6 USB: pl2303: restrict the divisor based baud rate encoding method to the HX chip type Or I can just revert all of them for 3.12-stable as well, let me know which one you want me to do. Yes, I think we should revert (if possible before 3.12 is out), clean up the above series and do some more verification before reapplying as a single, clean series (there appears to already be a regression with fix within the patches listed above). Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] lib/scatterlist: export sg_miter_skip()
Hi Andrew, Thank you for the comment. On Fri, Nov 1, 2013 at 5:47 AM, Andrew Morton a...@linux-foundation.org wrote: Looks OK to me. Please include this in whatever tree is used to merge [PATCH 2/2] USB: storage: use sg_miter_* APIs to access scsi buffer. Greg and Alan, would you mind reviewing commenting on 2/2 and merge the two finally to usb-next tree if you are OK with it? Thanks, -- Ming Lei -- 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
