[PATCH v4 4/5] usb: dwc3: Add quirk for Synopsis device disconnection errata
Synopsis Designware USB3 IP earlier than v3.00a which is configured in silicon
with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to prevent
xhci host controller from dying when device is disconnected.
Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
cannot be checked from software in runtime, it has to be enabled via platform
data or device tree.
Signed-off-by: Sneeker Yeh
---
Documentation/devicetree/bindings/usb/dwc3.txt | 17 +
drivers/usb/dwc3/core.c|6 ++
drivers/usb/dwc3/core.h|4
drivers/usb/dwc3/host.c|4
drivers/usb/dwc3/platform_data.h |8
5 files changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..1b78b29 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,23 @@ Optional properties:
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
+ - snps,has_suspend_on_disconnect: true when IP is configured in silicon with
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
+ specific quirk to prevent xhci host controller from
+ dying when usb device is disconnected from root hub.
+ Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
+ configuration whose state cannot be checked from
+ software in runtime, it has to be enabled via platform
+ data or device tree.
+
+ xhci host dying symptom here is caused by that
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
+ configuration makes IP auto-suspended after PORTCSC is
+ cleared when usb device detached, then an asynchronous
+ disconnection procedure might fail using endpoint
+ command that suspened IP won't have any response to.
+
+ this issue is fixed when IP version >= 3.00a.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9f0e209..705980c 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
"snps,tx_de_emphasis_quirk");
of_property_read_u8(node, "snps,tx_de_emphasis",
&tx_de_emphasis);
+
+ dwc->suspend_on_disconnect_quirk = of_property_read_bool(node,
+ "snps,has_suspend_on_disconnect");
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->tx_de_emphasis_quirk = pdata->tx_de_emphasis_quirk;
if (pdata->tx_de_emphasis)
tx_de_emphasis = pdata->tx_de_emphasis;
+
+ dwc->suspend_on_disconnect_quirk =
+ pdata->has_suspend_on_disconnect;
}
/* default to superspeed if no maximum_speed passed */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0b3bb0f..dfc7d63 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -688,6 +688,9 @@ struct dwc3_scratchpad_array {
* @resize_fifos: tells us it's ok to reconfigure our TxFIFO sizes.
* @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
* @start_config_issued: true when StartConfig command has been issued
+ * @suspend_on_disconnect_quirk: set if core was configured with
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. Note that there's
+ * now way for software to detect this in runtime.
* @three_stage_setup: set if we perform a three phase setup
* @disable_scramble_quirk: set if we enable the disable scramble quirk
* @u2exit_lfps_quirk: set if we enable u2exit lfps quirk
@@ -813,6 +816,7 @@ struct dwc3 {
unsignedresize_fifos:1;
unsignedsetup_packet_pending:1;
unsignedstart_config_issued:1;
+ unsignedsuspend_on_disconnect_quirk:1;
unsignedthree_stage_setup:1;
unsigneddisable_scramble_quirk:1;
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 12bfd3c..9c42074 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,10 @@ int dwc3_host_init(struct dwc3 *dwc)
pdata.usb3_lpm_capable =
[PATCH v4 0/5] Add support for Fujitsu USB host controller
These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions < 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 4 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions < 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Successfully tested on Fujitsu mb86s7x board. Changes since v3 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Mathias's comment, fix bug and using xhci_port_state_to_neutral() helper function to mask out some RW1C bits, prevent writing back all the bits read from the PORTSC register. Changes since v2 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Felipe's comment, re-order patches to avoid breaking bisectability, - based on Felipe's comment, add comment to structure's member, and sort it alphabetically, - based on Felipe's comment, add another v2.90 revision number in dwc3 IP. Changes since v1 (RFC): [https://lkml.org/lkml/2014/12/15/929] - based on Arnd's comment, remove entire unnecessary Fujitsu EHCI/OHCI glue, - based on Felipe's comment, fix mis-using of runtime-pm API and setting dma mask, remove unnecessary comment, and refactor suspend/resume handler in Fujitsu Specific Glue layer in dwc3, - based on Felipe's comment, add more commit log and comments in Synopsis quirk implementation, and separate it into four patches. Sneeker Yeh (5): xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core xhci: Platform: Set Synopsis device disconnection quirk based on platform data usb: dwc3: add revision number DWC3_REVISION_290A and DWC3_REVISION_300A usb: dwc3: Add quirk for Synopsis device disconnection errata usb: dwc3: add Fujitsu Specific Glue layer Documentation/devicetree/bindings/usb/dwc3.txt | 17 ++ .../devicetree/bindings/usb/fujitsu-dwc3.txt | 33 drivers/usb/dwc3/Kconfig | 11 ++ drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/core.c|6 + drivers/usb/dwc3/core.h|6 + drivers/usb/dwc3/dwc3-mb86s70.c| 206 drivers/usb/dwc3/host.c|4 + drivers/usb/dwc3/platform_data.h |8 + drivers/usb/host/xhci-hub.c|4 + drivers/usb/host/xhci-plat.c |3 + drivers/usb/host/xhci.c| 31 +++ drivers/usb/host/xhci.h| 24 +++ include/linux/usb/xhci_pdriver.h |4 + 14 files changed, 358 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c -- 1.7.9.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 v4 3/5] usb: dwc3: add revision number DWC3_REVISION_290A and DWC3_REVISION_300A
Add the contstant for v2.90a and v3.00a dwc3 IP detection
Signed-off-by: Sneeker Yeh
---
drivers/usb/dwc3/core.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index d201910..0b3bb0f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -772,6 +772,8 @@ struct dwc3 {
#define DWC3_REVISION_260A 0x5533260a
#define DWC3_REVISION_270A 0x5533270a
#define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_290A 0x5533290a
+#define DWC3_REVISION_300A 0x5533300a
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
--
1.7.9.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 v4 2/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data
If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.
Signed-off-by: Sneeker Yeh
---
drivers/usb/host/xhci-plat.c |3 +++
include/linux/usb/xhci_pdriver.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
+
+ if (pdata && pdata->delay_portcsc_clear)
+ xhci->quirks |= XHCI_DISCONNECT_QUIRK;
/*
* Set the xHCI pointer before xhci_plat_setup() (aka hcd_driver.reset)
* is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
*
* @usb3_lpm_capable: determines if this xhci platform supports USB3
* LPM capability
+ * @delay_portcsc_clear: determines if Synopsis USB3 core has errata in
+ * "DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1" hardware
+ * configuration.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ unsigneddelay_portcsc_clear:1;
};
#endif /* __USB_CORE_XHCI_PDRIVER_H */
--
1.7.9.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 v4 5/5] usb: dwc3: add Fujitsu Specific Glue layer
This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh
---
.../devicetree/bindings/usb/fujitsu-dwc3.txt | 33
drivers/usb/dwc3/Kconfig | 11 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-mb86s70.c| 206
4 files changed, 251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c
diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..be091eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,33 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+- compatible: Should be "fujitsu,mb86s70-dwc3"
+- clocks: from common clock binding, handle to usb clock.
+- clock-names: Should contain the following:
+ "core" Master/Core clock needs to run at a minimum of 125 MHz to
+ support a 4 Gbps IN or 4 Gbps OUT
+ transfer at a given time.
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+Example device nodes:
+
+ usb3host: mb86s70_usb3host {
+ compatible = "fujitsu,mb86s70-dwc3";
+ clocks = <&clk_alw_1_1>;
+ clock-names = "core";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+
+ dwc3@3220 {
+ compatible = "synopsys,dwc3";
+ reg = <0 0x3230 0x10>;
+ interrupts = <0 412 0x4>,
+ <0 414 0x4>;
+ };
+ };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index edbf9c8..8ab0f2c 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
say 'Y' or 'M' if you have one such device.
+config USB_DWC3_MB86S70
+ tristate "MB86S70 Designware USB3 Platform code"
+ default USB_DWC3
+ help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
config USB_DWC3_PCI
tristate "PCIe-based Platforms"
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 46172f4..76634b7 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -37,3 +37,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..301be76
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,206 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Authors: Alice Chan
+ * Sneeker Yeh
+ * based on dwc3-exynos.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_mb86s70 {
+ struct device *dev;
+ struct clk *clks[5];
+ u8 clk_cnt;
+};
+
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+ struct dwc3_mb86s70 *priv = dev_get_drvdata(dev);
+ int ret, i = priv->clk_cnt;
+
+ if (!on)
+ goto clock_off;
+
+ for (i = 0; i < priv->clk_cnt; i++) {
+ ret = clk_prepare_enable(priv->clks[i]);
+ if (ret) {
+ dev_err(dev, "failed to enable clock[%d]\n", i);
+ on = ret;
+ goto clock_off;
+ }
+ }
+
+ return 0;
+
+clock_off:
+ for (; i > 0;)
+ clk_disable_unprepare(priv->clks[--i]);
+
+ return on;
+}
+
+static int dwc3_mb86s70_remove_child(struct device *dev, void *unused)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static int dwc3_mb86s70_pro
[PATCH v4 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
This issue is defined by a three-way race at disconnect, between
1) Class driver interrupt endpoint resheduling attempts if the ISR gave an ep
error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
- DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
- Synopsys IP version is < 3.00a
The IP will auto-suspend itself on device detach with some phy-specific interval
after CSC is cleared by 2)
If 2) and 3) complete before 1), the interrupts it expects will not be generated
by the autosuspended IP, leading to a deadlock. Even later disconnection
procedure would detect that corresponding urb is still in-progress and issue a
ep stop command, auto-suspended IP still won't respond to that command.
this defect would result in this when device detached:
---
[ 99.603544] usb 4-1: USB disconnect, device number 2
[ 104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[ 104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting host.
[ 104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[ 104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[ 104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[ 104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--
As a result, when device detached, we desired to postpone "PORTCSC clear" behind
"disable slot". it's found that all executed ep command related to disconnetion,
are executed before "disable slot".
Signed-off-by: Sneeker Yeh
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci.c | 31 +++
drivers/usb/host/xhci.h | 24
3 files changed, 59 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = "warm(BH) reset";
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci->quirks & XHCI_DISCONNECT_QUIRK) &&
+ !(readl(addr) & PORT_CONNECT))
+ return;
+
status = PORT_CSC;
port_change_bit = "connect";
break;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ec8ac16..1fb8c1c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3580,6 +3580,35 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd->speed == HCD_USB3) {
+ max_ports = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ } else {
+ max_ports = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ }
+
+ if (dev_port_num > max_ports) {
+ xhci_err(xhci, "%s() port number invalid", __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status & PORT_CONNECT) && (status & PORT_CSC)) {
+ status = xhci_port_state_to_neutral(status);
+ writel(status | PORT_CSC, port_array[dev_port_num - 1]);
+ }
+}
+
/*
* At this point, the struct usb_device is about to go away, the device has
* disconnected, and all traffic has been stopped and the endpoints have been
@@ -3645,6 +3674,8 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device
*udev)
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(&xhci->lock, flags);
+ if (xhci->quirks & XHCI_DISCONNECT_QUIRK)
+ xhci_try_to_clear_csc(hcd, udev->portnum);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9745147..cb74706 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1560,6 +1560,30 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_WAKEUP (1 << 18)
/* For controllers with a broken beyond repair streams implementation */
#define XHCI_BROKEN_STREAMS(1 << 19)
+/*
+ * This issue is defined by a three-way race at disconnect in Synopsis USB3 IP,
+ * between
+ * 1) Class driver interrupt endpoint resheduling attempts if the ISR gave an
ep
+ *error event due to device detach (it would try 3 times)
+ * 2) Disconnect interrupt on PORTSC_CSC, which is cleared b
Re: [PATCH v2] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
On Mon, Feb 16, 2015 at 07:32:46PM -0700, Joseph Kogut wrote: > Removed FIXME from usb/dwc3/dwc3-pci.c by moving definition of > PCI_VENDOR_ID_SYNOPSYS shared with usb/dwc2 to linux/pci_ids.h. > > Signed-off-by: Joseph Kogut > --- > drivers/usb/dwc2/pci.c | 1 - > drivers/usb/dwc3/dwc3-pci.c | 2 -- > include/linux/pci_ids.h | 2 ++ > 3 files changed, 2 insertions(+), 3 deletions(-) Felipe will take this through his tree when it opens back up again in a few weeks. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function
Hi Geert-san,
Thank you for the reply again!
> Hi Shimoda-san,
>
> On Mon, Feb 16, 2015 at 2:52 AM, Yoshihiro Shimoda
> wrote:
> > According to the gadget.h, a "complete" function will always be called
> > with interrupts disabled. However, sometimes usbhsg_queue_pop() function
> > is called with interrupts enabled. So, this function should calls
> > local_irq_save() before this calls the usb_gadget_giveback_request().
> > Otherwise, there is possible to cause a spinlock suspected in a gadget
> > complete function.
>
> I still feel uneasy about adding the call to local_irq_save(), as the need for
> this is usually an indicator of another locking problem.
I also think that I would like to avoid using local_irq_save().
But, I have no idea to resolve this issue for now.
> Unfortunately I know next to nothing about the USB gadget subsystem, so some
> help from the USB gadget experts would be appreciated.
>
> I had a look at other drivers, and it seems most drivers actually release
> and reacquire a spinlock around the call to usb_gadget_giveback_request(),
> i.e. they do:
>
> spin_unlock(...);
> usb_gadget_giveback_request(...);
> spin_lock();
>
> This means they had already acquired the spinlock (and disabled interrupts!)
> before, which looks much healthier to me.
>
> There's only one driver that uses local_irq_save() (pxa27x_udc).
I had a look at the musb driver. It uses a dmaengine driver.
And, in the callback routine of the musb driver, it calls spin_lock_irqsave()
at first.
cppi41_dma_callback
--> spin_lock_irqsave(&musb->lock, flags);
--> cppi41_trans_done
--> musb_dma_completion
--> musb_g_tx or musb_g_rx
--> musb_g_giveback
--> spin_unlock(&musb->lock); # This means unlocked the spin, but
disabled interrupts.
--> usb_gadget_giveback_request
--> spin_lock(&musb->lock);
< snip >
--> spin_unlock_irqrestore(&musb->lock, flags);
So, about disabled interrupts before usb_gadget_giveback_request(),
it is similar with this patch.
Best regards,
Yoshihiro Shimoda
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
[PATCH v2] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
Removed FIXME from usb/dwc3/dwc3-pci.c by moving definition of PCI_VENDOR_ID_SYNOPSYS shared with usb/dwc2 to linux/pci_ids.h. Signed-off-by: Joseph Kogut --- drivers/usb/dwc2/pci.c | 1 - drivers/usb/dwc3/dwc3-pci.c | 2 -- include/linux/pci_ids.h | 2 ++ 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c index a4e724b..6646adb 100644 --- a/drivers/usb/dwc2/pci.c +++ b/drivers/usb/dwc2/pci.c @@ -54,7 +54,6 @@ #include "core.h" #include "hcd.h" -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_PRODUCT_ID_HAPS_HSOTG 0xabc0 static const char dwc2_driver_name[] = "dwc2"; diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 8d95056..b773fb5 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -24,8 +24,6 @@ #include "platform_data.h" -/* FIXME define these in */ -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd #define PCI_DEVICE_ID_INTEL_BYT0x0f37 #define PCI_DEVICE_ID_INTEL_MRFLD 0x119e diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index e63c02a..38cff8f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2315,6 +2315,8 @@ #define PCI_VENDOR_ID_CENATEK 0x16CA #define PCI_DEVICE_ID_CENATEK_IDE 0x0001 +#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 + #define PCI_VENDOR_ID_VITESSE 0x1725 #define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174 -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
On Mon, Feb 16, 2015 at 07:16:36PM -0700, Joseph Kogut wrote: > On Mon, 2015-02-16 at 17:57 -0800, Greg KH wrote: > > On Mon, Feb 16, 2015 at 06:45:53PM -0700, Joseph Kogut wrote: > > > Signed-off-by: Joseph Kogut > > > > You need a changelog description here please. > > > > Should I reply inline, or is resending the patch okay? Do a 'v2' version of the patch, we can't apply inline changes :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
On Mon, 2015-02-16 at 17:57 -0800, Greg KH wrote: > On Mon, Feb 16, 2015 at 06:45:53PM -0700, Joseph Kogut wrote: > > Signed-off-by: Joseph Kogut > > You need a changelog description here please. > Should I reply inline, or is resending the patch okay? -- 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: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
On Mon, Feb 16, 2015 at 06:45:53PM -0700, Joseph Kogut wrote: > Signed-off-by: Joseph Kogut You need a changelog description here please. -- 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: move definition of PCI_VENDOR_ID_SYNOPSYS to linux/pci_ids.h
Signed-off-by: Joseph Kogut --- drivers/usb/dwc2/pci.c | 1 - drivers/usb/dwc3/dwc3-pci.c | 2 -- include/linux/pci_ids.h | 2 ++ 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/dwc2/pci.c b/drivers/usb/dwc2/pci.c index a4e724b..6646adb 100644 --- a/drivers/usb/dwc2/pci.c +++ b/drivers/usb/dwc2/pci.c @@ -54,7 +54,6 @@ #include "core.h" #include "hcd.h" -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_PRODUCT_ID_HAPS_HSOTG 0xabc0 static const char dwc2_driver_name[] = "dwc2"; diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 8d95056..b773fb5 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -24,8 +24,6 @@ #include "platform_data.h" -/* FIXME define these in */ -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 #define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd #define PCI_DEVICE_ID_INTEL_BYT0x0f37 #define PCI_DEVICE_ID_INTEL_MRFLD 0x119e diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index e63c02a..38cff8f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2315,6 +2315,8 @@ #define PCI_VENDOR_ID_CENATEK 0x16CA #define PCI_DEVICE_ID_CENATEK_IDE 0x0001 +#define PCI_VENDOR_ID_SYNOPSYS 0x16c3 + #define PCI_VENDOR_ID_VITESSE 0x1725 #define PCI_DEVICE_ID_VITESSE_VSC7174 0x7174 -- 2.3.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep
Hello,
Greg KH 於 2015/2/17 上午 03:41 寫道:
+ if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
Never use unlikely() unless you can prove that it actually matters if
you use it. Hint, it's almost impossible to prove, so don't use it, the
compiler and processor look-ahead is almost smarter than we are.
Thanks for your hint. I'll remove it with next patch.
--
With Best Regards,
Peter Hung
--
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 01/13] usb: define a generic USB_RESUME_TIMEOUT macro
Hi, On Sun, Feb 15, 2015 at 09:06:15AM +0800, Peter Chen wrote: > On Fri, Feb 13, 2015 at 07:42:22PM -0600, Felipe Balbi wrote: > > On Sat, Feb 14, 2015 at 08:13:36AM +0800, Greg KH wrote: > > > On Fri, Feb 13, 2015 at 03:07:43PM -0600, Felipe Balbi wrote: > > > > Every USB Host controller should use this new > > > > macro to define for how long resume signalling > > > > should be driven on the bus. > > > > > > > > Currently, almost every single USB controller > > > > is using a 20ms timeout for resume signalling. > > > > > > > > That's problematic for two reasons: > > > > > > > > a) sometimes that 20ms timer expires a little > > > > before 20ms, which makes us fail certification > > > > > > > > b) some (many) devices actually need more than > > > > 20ms resume signalling. > > > > > > > > Sure, in case of (b) we can state that the device > > > > is against the USB spec, but the fact is that > > > > we have no control over which device the certification > > > > lab will use. We also have no control over which host > > > > they will use. Most likely they'll be using a Windows > > > > PC which, again, we have no control over how that > > > > USB stack is written and how long resume signalling > > > > they are using. > > > > > > > > At the end of the day, we must make sure Linux passes > > > > electrical compliance when working as Host or as Device > > > > and currently we don't pass compliance as host because > > > > we're driving resume signallig for exactly 20ms and > > > > that confuses certification test setup resulting in > > > > Certification failure. > > > > > > > > Signed-off-by: Felipe Balbi > > > > --- > > > > include/linux/usb.h | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/include/linux/usb.h b/include/linux/usb.h > > > > index f89c24a03bd9..1dd89f0db344 100644 > > > > --- a/include/linux/usb.h > > > > +++ b/include/linux/usb.h > > > > @@ -210,6 +210,9 @@ void usb_put_intf(struct usb_interface *intf); > > > > #define USB_MAXINTERFACES 32 > > > > #define USB_MAXIADS(USB_MAXINTERFACES/2) > > > > > > > > +/* USB Resume Timer */ > > > > +#define USB_RESUME_TIMEOUT 40 /* ms */ > > > > + > > > > > > If you add the comment as Alan suggested, feel free to add: > > > > > > Acked-by: Greg Kroah-Hartman > > > > Is this good enough ? > > > > commit 3154122f81c8411b432d5f44a196302243d5af3d > > Author: Felipe Balbi > > Date: Fri Feb 13 14:34:25 2015 -0600 > > > > usb: define a generic USB_RESUME_TIMEOUT macro > > > > Every USB Host controller should use this new > > macro to define for how long resume signalling > > should be driven on the bus. > > > > Currently, almost every single USB controller > > is using a 20ms timeout for resume signalling. > > > > That's problematic for two reasons: > > > > a) sometimes that 20ms timer expires a little > > before 20ms, which makes us fail certification > > > > b) some (many) devices actually need more than > > 20ms resume signalling. > > > > Sure, in case of (b) we can state that the device > > is against the USB spec, but the fact is that > > we have no control over which device the certification > > lab will use. We also have no control over which host > > they will use. Most likely they'll be using a Windows > > PC which, again, we have no control over how that > > USB stack is written and how long resume signalling > > they are using. > > > > At the end of the day, we must make sure Linux passes > > electrical compliance when working as Host or as Device > > and currently we don't pass compliance as host because > > we're driving resume signallig for exactly 20ms and > > that confuses certification test setup resulting in > > Certification failure. > > > > Signed-off-by: Felipe Balbi > > > > diff --git a/include/linux/usb.h b/include/linux/usb.h > > index 7ee1b5c3b4cb..447fe29b55b4 100644 > > --- a/include/linux/usb.h > > +++ b/include/linux/usb.h > > @@ -205,6 +205,32 @@ void usb_put_intf(struct usb_interface *intf); > > #define USB_MAXINTERFACES 32 > > #define USB_MAXIADS(USB_MAXINTERFACES/2) > > > > +/* > > + * USB Resume Timer: Every Host controller driver should drive the resume > > + * signalling on the bus for the amount of time defined by this macro. > > + * > > + * That way we will have a 'stable' behavior among all HCDs supported by > > Linux. > > + * > > + * Note that the USB Specification states we should drive resume for *at > > least* > > + * 20 ms, but it doesn't give an upper bound. This creates two possible > > + * situations which we want to avoid: > > + * > > + * (a) sometimes an msleep(20) might expire slightly before 20 ms, which > > causes > > + * us to fail USB Electrical Tests, thus failing Certification > > + * > > + * (b) Some (many) devices actually need more than 20 ms of resume > > signalling,
Re: dwc3/xHCI max connection limit
On Mon, Feb 16, 2015 at 08:52:35AM -0600, Bin Liu wrote: > Felipe, > > On Mon, Feb 16, 2015 at 7:17 AM, Felipe Balbi wrote: > > On Wed, Feb 11, 2015 at 04:14:49PM -0600, Bin Liu wrote: > >> Alan, > >> > >> On Wed, Feb 11, 2015 at 3:56 PM, Alan Stern > >> wrote: > >> > On Wed, 11 Feb 2015, Bin Liu wrote: > >> > > >> >> > The problem probably isn't the number of endpoints, but rather the > >> >> > scheduling entries for interrupt and isochronous endpoints. > >> >> > >> >> -12 return code in the log is due to COMP_ENOMEM (7, in Table 135 in > >> >> xHCI Specs) returned by the completion of configure endpoint command. > >> >> All in xhci_configure_endpoint() in xhci.c. > >> >> > >> >> Then in xHCI Specs Section 4.6.6 Configure Endpoint, and Section > >> >> 4.14.1.1 System Bus Bandwidth Scheduling, I got a feeling it is indeed > >> >> due to periodic scheduling, after certain amount of interrupt > >> >> (applicable to ISO as while) endpoints have been scheduled, there does > >> >> not have enough bus bandwidth left for new interrupt scheduling any > >> >> more. > >> >> > >> >> I am new to xhci, any comments for my suspicion? > >> > > >> > It could be that there is not enough bus bandwidth. Or it could be > >> > some other resource that the xHCI controller uses internally for the > >> > periodic scheduling. Either way, that's the reason you reach the > >> > limit. > >> > >> Yeah. My question is answered, I just wanted to understand if there > >> was a hw or sw bug which causes the limit. I believe this is just a > >> nature of periodic transfers - within the period between the minimum > >> interrupt intervals, it can only have a limited slots for new > >> interrupt transfers. > > > > The limitation is imposed by the USB spec. I can't remember which > > section but it does state that for isochronous and interrupt EPs, we > > need to guarantee bandwidth; a consequence of that is we can't allow new > > interrupt/isoc endpoints to be used if we can't fulfill bandwidth > > requirements. > > My response above meant the same - bandwidth limitation. > > But I now believe Alan is correct, the limitation is very likely due > to xhci internal resource, not about bus bandwidth. > > bInterval of EP in mouse or keyboard is 10ms, xhci polls the EP in > about 7~8ms, each interrupt transfer takes about 500ns roughly. > > So in 7ms interval, roughly the bus can do 7000us / 0.5 = 14K > interrupt transfers, considering other factors in reality, for example > packet turn around time, the 14K number will be much smaller, but it > cannot be lower to 28. So in this particular case, I don't think it > reaches bus bandwidth limit for periodic transfers. Makes sense. I wonder if that's configurable for the IP or is it something XHCI just mandates and that's it. -- balbi signature.asc Description: Digital signature
[PATCH] usb: plusb: Add support for National Instruments host-to-host cable
The National Instruments USB Host-to-Host Cable is based on the Prolific
PL-25A1 chipset. Add its VID/PID so the plusb driver will recognize it.
Signed-off-by: Ben Shelton
---
drivers/net/usb/plusb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 3d18bb0..1bfe0fc 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -134,6 +134,11 @@ static const struct usb_device_id products [] = {
}, {
USB_DEVICE(0x050d, 0x258a), /* Belkin F5U258/F5U279 (PL-25A1) */
.driver_info = (unsigned long) &prolific_info,
+}, {
+ USB_DEVICE(0x3923, 0x7825), /* National Instruments USB
+* Host-to-Host Cable
+*/
+ .driver_info = (unsigned long) &prolific_info,
},
{ },// END
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please can you add my device ?
On Sun, Feb 15, 2015 at 11:10:05AM +0100, faivre.laur...@laposte.net wrote: > Thanks for your reply. > > If I use directly the ftdi_sio driver, I can't read anything. > some details : > $ dmesg > usb 1-1.3: new full-speed USB device number 4 using dwc_otg > usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001 > usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 1-1.3: Product: FT232R USB UART > usb 1-1.3: Manufacturer: FTDI > usb 1-1.3: SerialNumber: AD02DY77 > usbcore: registered new interface driver usbserial > usbcore: registered new interface driver usbserial_generic > usbserial: USB Serial support registered for generic > usbcore: registered new interface driver ftdi_sio > usbserial: USB Serial support registered for FTDI USB Serial Device > ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected > usb 1-1.3: Detected FT232RL > usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0 > > > $stty -F /dev/ttyUSB0 ispeed 1200 ospeed 1200 cs7 -cstopb clocal cread > parenb -parodd inpck istrip -crtscts -icanon -echo -echoe -isig -ixon -ixoff > -ixany -icrnl -opost > > $stty -F /dev/ttyUSB0 -a > speed 1200 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = > ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; > werase = ^W; lnext = ^V; flush = ^O; > min = 1; time = 0; > parenb -parodd cs7 hupcl -cstopb cread clocal -crtscts > -ignbrk -brkint -ignpar -parmrk inpck istrip -inlcr -igncr -icrnl -ixon > -ixoff -iuclc -ixany -imaxbel -iutf8 > -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 > ff0 > -isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop > -echoprt echoctl echoke > > >Settings are OK > > $ cat /dev/ttyUSB0 > Nothing appears ! Don't use 'cat' for a serial device, use something like minicom that knows how to directly talk to a serial port properly. 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 V6 03/10] USB: f81232: implement RX bulk-in ep
On Mon, Feb 16, 2015 at 03:57:55PM +0800, Peter Hung wrote:
> The F81232 bulk-in is RX data + LSR channel, data format is
> [LSR+Data][LSR+Data]. , We had reimplemented in this patch.
>
> Signed-off-by: Peter Hung
> ---
> drivers/usb/serial/f81232.c | 68
> +++--
> 1 file changed, 35 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index ec4609d..9ea498a 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -185,44 +185,46 @@ exit:
> static void f81232_process_read_urb(struct urb *urb)
> {
> struct usb_serial_port *port = urb->context;
> - struct f81232_private *priv = usb_get_serial_port_data(port);
> unsigned char *data = urb->transfer_buffer;
> - char tty_flag = TTY_NORMAL;
> - unsigned long flags;
> - u8 line_status;
> + char tty_flag;
> int i;
>
> - /* update line status */
> - spin_lock_irqsave(&priv->lock, flags);
> - line_status = priv->modem_status;
> - priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
> - spin_unlock_irqrestore(&priv->lock, flags);
> -
> - if (!urb->actual_length)
> + if (urb->actual_length < 2)
> return;
>
> - /* break takes precedence over parity, */
> - /* which takes precedence over framing errors */
> - if (line_status & UART_BREAK_ERROR)
> - tty_flag = TTY_BREAK;
> - else if (line_status & UART_PARITY_ERROR)
> - tty_flag = TTY_PARITY;
> - else if (line_status & UART_FRAME_ERROR)
> - tty_flag = TTY_FRAME;
> - dev_dbg(&port->dev, "%s - tty_flag = %d\n", __func__, tty_flag);
> -
> - /* overrun is special, not associated with a char */
> - if (line_status & UART_OVERRUN_ERROR)
> - tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
> -
> - if (port->port.console && port->sysrq) {
> - for (i = 0; i < urb->actual_length; ++i)
> - if (!usb_serial_handle_sysrq_char(port, data[i]))
> - tty_insert_flip_char(&port->port, data[i],
> - tty_flag);
> - } else {
> - tty_insert_flip_string_fixed_flag(&port->port, data, tty_flag,
> - urb->actual_length);
> + /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
> +
> + for (i = 0 ; i < urb->actual_length ; i += 2) {
> + tty_flag = TTY_NORMAL;
> +
> + if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
Never use unlikely() unless you can prove that it actually matters if
you use it. Hint, it's almost impossible to prove, so don't use it, the
compiler and processor look-ahead is almost smarter than we are.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: Moved PCI IDS to linux/pci_ids.h
On Mon, Feb 16, 2015 at 09:27:09AM -0700, Joseph Kogut wrote: > It seems that the Synopsys vendor ID is used in usb/dwc2 as well, and > the rest of the definitions aren't referenced outside of usb/dwc3. > Would the proper approach be to move the Synopsys vendor ID to > linux/pci_ids.h, remove the redefinition in usb/dwc2, and remove the > fixme? That sounds like the "correct" fix for this. -- 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: please can you add my device ?
Hi, just a remark, in the dmesg result, there is no lines likes : usb 1-1.3: Endpoint 1 MaxPacketSize 64 usb 1-1.3: Endpoint 2 MaxPacketSize 64 usb 1-1.3: Setting MaxPacketSize 64 Is this normal ? Thanks Le 15/02/2015 11:10, faivre.laur...@laposte.net a écrit : Thanks for your reply. If I use directly the ftdi_sio driver, I can't read anything. some details : $ dmesg usb 1-1.3: new full-speed USB device number 4 using dwc_otg usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.3: Product: FT232R USB UART usb 1-1.3: Manufacturer: FTDI usb 1-1.3: SerialNumber: AD02DY77 usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbcore: registered new interface driver ftdi_sio usbserial: USB Serial support registered for FTDI USB Serial Device ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected usb 1-1.3: Detected FT232RL usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0 $stty -F /dev/ttyUSB0 ispeed 1200 ospeed 1200 cs7 -cstopb clocal cread parenb -parodd inpck istrip -crtscts -icanon -echo -echoe -isig -ixon -ixoff -ixany -icrnl -opost $stty -F /dev/ttyUSB0 -a speed 1200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; parenb -parodd cs7 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk inpck istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke >Settings are OK $ cat /dev/ttyUSB0 Nothing appears ! If I add this device id "by hand", I can't set the parameters, but I can read something (not usable unfortunately) some details : $ dmesg : result in previous mail $ stty -F /dev/ttyUSB0 ispeed 1200 ospeed 1200 cs7 -cstopb clocal cread parenb -parodd inpck istrip -crtscts -icanon -echo -echoe -isig -ixon -ixoff -ixany -icrnl -opost stty: /dev/ttyUSB0 : impossible d'effectuer toutes les opérations demandées >(unable to perform all requested operations) $ stty -F /dev/ttyUSB0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk inpck istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke BUT : $ cat /dev/ttyUSB0 bbb@bp``pp```ppp```@pp`p```pp```p@`ppp`p``p`p`pp``pppp`p```p``p```pp``` >continually. It's the data that I want but read at 9600 cs8 -parenb instead of 1200 cs7 parenb Since this device is already supported by the driver, I will resume my tests using the ftdi_sio driver directly. If you have any solutions, I would be interested Thanks Le 14/02/2015 20:03, Greg KH a écrit : On Sat, Feb 14, 2015 at 07:26:20PM +0100, faivre.laur...@laposte.net wrote: Hi ! I try to use a usb-serial converter and i can't set the baud rate (and other stuff) on the ttyUSB0. The converter can be see on this page (Version USB : 20.00 €) : http://www.domotibox.com/solarbox/?section=Boutique There is some data from my system (raspberry pi b+, raspbian) : $ uname -a Linux domo-1 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux $ /opt/vc/bin/vcgencmd version Feb 12 2015 17:23:49 Copyright (c) 2012 Broadcom version 571f5d2143489e4300d7e2ed5b1a73f33f3b13e5 (clean) (release) $ cat /etc/*-release PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)" NAME="Raspbian GNU/Linux" VERSION_ID="7" VERSION="7 (wheezy)" ID=raspbian ID_LIKE=debian ANSI_COLOR="1;31" HOME_URL="http://www.raspbian.org/"; SUPPORT_URL="http://www.raspbian.org/RaspbianForums"; BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"; $ dmesg usb 1-1.3: new full-speed USB device number 4 using dwc_otg usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001 usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.3: Product: FT232R USB UART usb 1-1.3: Manufacturer: FTDI usb 1-1.3: SerialNumber: AD02DY77 usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbserial_generic 1-1.3:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes. u
Re: [PATCH] usb: dwc3: Moved PCI IDS to linux/pci_ids.h
It seems that the Synopsys vendor ID is used in usb/dwc2 as well, and the rest of the definitions aren't referenced outside of usb/dwc3. Would the proper approach be to move the Synopsys vendor ID to linux/pci_ids.h, remove the redefinition in usb/dwc2, and remove the fixme? -- 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 02/13] usb: host: xhci: use new USB_RESUME_TIMEOUT
On 13.02.2015 23:07, Felipe Balbi wrote:
> Make sure we're using the new macro, so our
> resume signaling will always pass certification.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/usb/host/xhci-ring.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index e692e769c50c..775bb54ef277 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1574,7 +1574,7 @@ static void handle_port_status(struct xhci_hcd *xhci,
> } else {
> xhci_dbg(xhci, "resume HS port %d\n", port_id);
> bus_state->resume_done[faked_port_index] = jiffies +
> - msecs_to_jiffies(20);
> + msecs_to_jiffies(USB_RESUME_TIMEOUT);
> set_bit(faked_port_index, &bus_state->resuming_ports);
> mod_timer(&hcd->rh_timer,
> bus_state->resume_done[faked_port_index]);
>
Acked-by: Mathias Nyman
--
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: dwc3: Moved PCI IDS to linux/pci_ids.h
On Sun, Feb 15, 2015 at 6:17 PM, Joseph Kogut wrote:
> Moved DWC3 PCI IDS to linux/pci_ids.h per the FIXME.
>
> Signed-off-by: Joseph Kogut
> ---
> drivers/usb/dwc3/dwc3-pci.c | 10 +-
> include/linux/pci_ids.h | 8
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index 8d95056..19ca7f6 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -20,19 +20,11 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "platform_data.h"
>
> -/* FIXME define these in */
> -#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
> -#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
> -#define PCI_DEVICE_ID_INTEL_BYT0x0f37
> -#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
> -#define PCI_DEVICE_ID_INTEL_BSW0x22B7
> -#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
> -#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
It looks like these constants are used only in this file. If that's
the case, the comment at the top of pci_ids.h applies, the definitions
can stay here, and you can just remove the "FIXME" comment.
> static int dwc3_pci_quirks(struct pci_dev *pdev)
> {
> if (pdev->vendor == PCI_VENDOR_ID_AMD &&
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index e63c02a..6fc5cdd 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2312,6 +2312,9 @@
> #define PCI_VENDOR_ID_NETCELL 0x169c
> #define PCI_DEVICE_ID_REVOLUTION 0x0044
>
> +#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
> +#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
> +
> #define PCI_VENDOR_ID_CENATEK 0x16CA
> #define PCI_DEVICE_ID_CENATEK_IDE 0x0001
>
> @@ -2566,12 +2569,14 @@
> #define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB0x095E
> #define PCI_DEVICE_ID_INTEL_I960 0x0960
> #define PCI_DEVICE_ID_INTEL_I960RM 0x0962
> +#define PCI_DEVICE_ID_INTEL_BYT0x0f37
> #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60
> #define PCI_DEVICE_ID_INTEL_8257X_SOL 0x1062
> #define PCI_DEVICE_ID_INTEL_82573E_SOL 0x1085
> #define PCI_DEVICE_ID_INTEL_82573L_SOL 0x108F
> #define PCI_DEVICE_ID_INTEL_82815_MC 0x1130
> #define PCI_DEVICE_ID_INTEL_82815_CGC 0x1132
> +#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
> #define PCI_DEVICE_ID_INTEL_82092AA_0 0x1221
> #define PCI_DEVICE_ID_INTEL_7505_0 0x2550
> #define PCI_DEVICE_ID_INTEL_7205_0 0x255d
> @@ -2593,6 +2598,7 @@
> #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI 0x1e31
> #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN 0x1e40
> #define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX 0x1e5f
> +#define PCI_DEVICE_ID_INTEL_BSW0x22B7
> #define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MIN 0x2310
> #define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MAX 0x231f
> #define PCI_DEVICE_ID_INTEL_82801AA_0 0x2410
> @@ -2891,6 +2897,8 @@
> #define PCI_DEVICE_ID_INTEL_84460GX0x84ea
> #define PCI_DEVICE_ID_INTEL_IXP4XX 0x8500
> #define PCI_DEVICE_ID_INTEL_IXP28000x9004
> +#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
> +#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
> #define PCI_DEVICE_ID_INTEL_S21152BB 0xb152
>
> #define PCI_VENDOR_ID_SCALEMP 0x8686
> --
> 2.3.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dwc3/xHCI max connection limit
Felipe, On Mon, Feb 16, 2015 at 7:17 AM, Felipe Balbi wrote: > On Wed, Feb 11, 2015 at 04:14:49PM -0600, Bin Liu wrote: >> Alan, >> >> On Wed, Feb 11, 2015 at 3:56 PM, Alan Stern >> wrote: >> > On Wed, 11 Feb 2015, Bin Liu wrote: >> > >> >> > The problem probably isn't the number of endpoints, but rather the >> >> > scheduling entries for interrupt and isochronous endpoints. >> >> >> >> -12 return code in the log is due to COMP_ENOMEM (7, in Table 135 in >> >> xHCI Specs) returned by the completion of configure endpoint command. >> >> All in xhci_configure_endpoint() in xhci.c. >> >> >> >> Then in xHCI Specs Section 4.6.6 Configure Endpoint, and Section >> >> 4.14.1.1 System Bus Bandwidth Scheduling, I got a feeling it is indeed >> >> due to periodic scheduling, after certain amount of interrupt >> >> (applicable to ISO as while) endpoints have been scheduled, there does >> >> not have enough bus bandwidth left for new interrupt scheduling any >> >> more. >> >> >> >> I am new to xhci, any comments for my suspicion? >> > >> > It could be that there is not enough bus bandwidth. Or it could be >> > some other resource that the xHCI controller uses internally for the >> > periodic scheduling. Either way, that's the reason you reach the >> > limit. >> >> Yeah. My question is answered, I just wanted to understand if there >> was a hw or sw bug which causes the limit. I believe this is just a >> nature of periodic transfers - within the period between the minimum >> interrupt intervals, it can only have a limited slots for new >> interrupt transfers. > > The limitation is imposed by the USB spec. I can't remember which > section but it does state that for isochronous and interrupt EPs, we > need to guarantee bandwidth; a consequence of that is we can't allow new > interrupt/isoc endpoints to be used if we can't fulfill bandwidth > requirements. My response above meant the same - bandwidth limitation. But I now believe Alan is correct, the limitation is very likely due to xhci internal resource, not about bus bandwidth. bInterval of EP in mouse or keyboard is 10ms, xhci polls the EP in about 7~8ms, each interrupt transfer takes about 500ns roughly. So in 7ms interval, roughly the bus can do 7000us / 0.5 = 14K interrupt transfers, considering other factors in reality, for example packet turn around time, the 14K number will be much smaller, but it cannot be lower to 28. So in this particular case, I don't think it reaches bus bandwidth limit for periodic transfers. Regards, -Bin. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
On 09.02.2015 10:31, Greg Kroah-Hartman wrote:
> On Mon, Feb 09, 2015 at 09:22:50AM +0100, Maxime Ripard wrote:
>> On Wed, Feb 04, 2015 at 05:04:18AM -0800, Greg Kroah-Hartman wrote:
>>> On Wed, Feb 04, 2015 at 10:35:22AM +0100, Maxime Ripard wrote:
Hi Mathias, Greg,
On Mon, Jan 19, 2015 at 02:01:12PM +0100, Maxime Ripard wrote:
> The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
> 375/38x XHCI controllers") extended the xhci-plat driver to support the
> Armada
> 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
>
> However, that quirk was run before the clock the controllers needs has
> been
> enabled. This usually worked because the clock was first enabled by the
> bootloader, and left as such until the driver is probe, where it tries to
> access the MBUS configuration registers before enabling the clock.
>
> Things get messy when EPROBE_DEFER is involved during the probe, since as
> part
> of its error path, the driver will rightfully disable the clock. When the
> driver will be reprobed, it will retry to access the MBUS registers, but
> this
> time with the clock disabled, which hangs forever.
>
> Fix this by running the quirks after the clock has been enabled by the
> driver.
>
> Signed-off-by: Maxime Ripard
> Cc: # v3.16+
Any chance for this to go in 3.19?
>>>
>>> For 3.19? It's too late, I'm not sending anything else to Linus as 3.19
>>> will be out in a few days.
>>
>> Ok. I'll resend it when 3.20-rc1 is out then.
>
> Why resend? Mathias should be queueing this up properly. Mathias?
>
Yep, I'll send it forward to Greg once 3.20-rc1 is tagged
-Mathias
--
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: dwc3/xHCI max connection limit
On Wed, Feb 11, 2015 at 04:14:49PM -0600, Bin Liu wrote: > Alan, > > On Wed, Feb 11, 2015 at 3:56 PM, Alan Stern wrote: > > On Wed, 11 Feb 2015, Bin Liu wrote: > > > >> > The problem probably isn't the number of endpoints, but rather the > >> > scheduling entries for interrupt and isochronous endpoints. > >> > >> -12 return code in the log is due to COMP_ENOMEM (7, in Table 135 in > >> xHCI Specs) returned by the completion of configure endpoint command. > >> All in xhci_configure_endpoint() in xhci.c. > >> > >> Then in xHCI Specs Section 4.6.6 Configure Endpoint, and Section > >> 4.14.1.1 System Bus Bandwidth Scheduling, I got a feeling it is indeed > >> due to periodic scheduling, after certain amount of interrupt > >> (applicable to ISO as while) endpoints have been scheduled, there does > >> not have enough bus bandwidth left for new interrupt scheduling any > >> more. > >> > >> I am new to xhci, any comments for my suspicion? > > > > It could be that there is not enough bus bandwidth. Or it could be > > some other resource that the xHCI controller uses internally for the > > periodic scheduling. Either way, that's the reason you reach the > > limit. > > Yeah. My question is answered, I just wanted to understand if there > was a hw or sw bug which causes the limit. I believe this is just a > nature of periodic transfers - within the period between the minimum > interrupt intervals, it can only have a limited slots for new > interrupt transfers. The limitation is imposed by the USB spec. I can't remember which section but it does state that for isochronous and interrupt EPs, we need to guarantee bandwidth; a consequence of that is we can't allow new interrupt/isoc endpoints to be used if we can't fulfill bandwidth requirements. -- balbi signature.asc Description: Digital signature
Re: [PATCH V5 3/8] USB: f81232: implement RX bulk-in ep
On Mon, Feb 16, 2015 at 07:59:45PM +0700, Johan Hovold wrote: > On Fri, Feb 06, 2015 at 05:46:49PM +0800, Peter Hung wrote: > I'll try to look at the rest of the series soon. Managed to comment on v5 rather than v6, but looks like comments on this patch still apply. 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 V5 3/8] USB: f81232: implement RX bulk-in ep
On Fri, Feb 06, 2015 at 05:46:49PM +0800, Peter Hung wrote:
> The F81232 bulk-in is RX data + LSR channel, data format is
> [LSR+Data][LSR+Data]. , We had reimplemented in this patch.
>
> Signed-off-by: Peter Hung
> ---
> drivers/usb/serial/f81232.c | 68
> +++--
> 1 file changed, 35 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index ec4609d..9ea498a 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -185,44 +185,46 @@ exit:
> static void f81232_process_read_urb(struct urb *urb)
> {
> struct usb_serial_port *port = urb->context;
> - struct f81232_private *priv = usb_get_serial_port_data(port);
> unsigned char *data = urb->transfer_buffer;
> - char tty_flag = TTY_NORMAL;
> - unsigned long flags;
> - u8 line_status;
> + char tty_flag;
> int i;
>
> - /* update line status */
> - spin_lock_irqsave(&priv->lock, flags);
> - line_status = priv->modem_status;
> - priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
> - spin_unlock_irqrestore(&priv->lock, flags);
> -
> - if (!urb->actual_length)
> + if (urb->actual_length < 2)
> return;
>
> - /* break takes precedence over parity, */
> - /* which takes precedence over framing errors */
> - if (line_status & UART_BREAK_ERROR)
> - tty_flag = TTY_BREAK;
> - else if (line_status & UART_PARITY_ERROR)
> - tty_flag = TTY_PARITY;
> - else if (line_status & UART_FRAME_ERROR)
> - tty_flag = TTY_FRAME;
> - dev_dbg(&port->dev, "%s - tty_flag = %d\n", __func__, tty_flag);
> -
> - /* overrun is special, not associated with a char */
> - if (line_status & UART_OVERRUN_ERROR)
> - tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
> -
> - if (port->port.console && port->sysrq) {
> - for (i = 0; i < urb->actual_length; ++i)
> - if (!usb_serial_handle_sysrq_char(port, data[i]))
> - tty_insert_flip_char(&port->port, data[i],
> - tty_flag);
> - } else {
> - tty_insert_flip_string_fixed_flag(&port->port, data, tty_flag,
> - urb->actual_length);
> + /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
> +
> + for (i = 0 ; i < urb->actual_length ; i += 2) {
No space after ;.
> + tty_flag = TTY_NORMAL;
> +
> + if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
Always use spaces around binary operators such as +, but in this case
I think it would be preferable to introduce a temporary variable u8 lsr,
which you update at the beginning of the loop construct.
> + if (data[i+0] & UART_LSR_BI) {
> + tty_flag = TTY_BREAK;
> + port->icount.brk++;
> + usb_serial_handle_break(port);
> + } else if (data[i+0] & UART_LSR_PE) {
> + tty_flag = TTY_PARITY;
> + port->icount.parity++;
> + } else if (data[i+0] & UART_LSR_FE) {
> + tty_flag = TTY_FRAME;
> + port->icount.frame++;
> + }
> +
> + if (data[0] & UART_LSR_OE) {
You probably want data[i] (lsr) here as well.
> + port->icount.overrun++;
> + tty_insert_flip_char(&port->port, 0,
> + TTY_OVERRUN);
> + }
> + }
> +
> + if (port->port.console && port->sysrq) {
> + if (!usb_serial_handle_sysrq_char(port, data[i+1]))
Spaces around + again.
> + tty_insert_flip_char(&port->port, data[i+1],
> + tty_flag);
> + } else {
> + tty_insert_flip_string_fixed_flag(&port->port,
> + &data[i+1], tty_flag, 1);
> + }
Use tty_insert_flip_char in both branches. In fact, you could rewrite
this as:
if (port->port.console && port->sysrq) {
if (usb_serial_handle_sysrq_char(port, data[i + 1]))
continue;
}
tty_insert_flip_char(&port->port, data[i + 1], tty_flag);
> }
>
> tty_flip_buffer_push(&port->port);
I'll try to look at the rest of the series soon.
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
need an additional option to access first check-in of a file
Hi All, Not sure where I should post this as this is a Git infra related suggestion. I think we should have an additional option "first/oldest" along with "Newer/Older" in Git. This will be helpful in browsing the first check-in of a file. Thanks.
Re: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function
Hi Shimoda-san,
On Mon, Feb 16, 2015 at 2:52 AM, Yoshihiro Shimoda
wrote:
> According to the gadget.h, a "complete" function will always be called
> with interrupts disabled. However, sometimes usbhsg_queue_pop() function
> is called with interrupts enabled. So, this function should calls
> local_irq_save() before this calls the usb_gadget_giveback_request().
> Otherwise, there is possible to cause a spinlock suspected in a gadget
> complete function.
I still feel uneasy about adding the call to local_irq_save(), as the need for
this is usually an indicator of another locking problem.
Unfortunately I know next to nothing about the USB gadget subsystem, so some
help from the USB gadget experts would be appreciated.
I had a look at other drivers, and it seems most drivers actually release
and reacquire a spinlock around the call to usb_gadget_giveback_request(),
i.e. they do:
spin_unlock(...);
usb_gadget_giveback_request(...);
spin_lock();
This means they had already acquired the spinlock (and disabled interrupts!)
before, which looks much healthier to me.
There's only one driver that uses local_irq_save() (pxa27x_udc).
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/usb/renesas_usbhs/mod_gadget.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c
> b/drivers/usb/renesas_usbhs/mod_gadget.c
> index e0384af..104bddf 100644
> --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> @@ -126,11 +126,22 @@ static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> struct usbhsg_gpriv *gpriv = usbhsg_uep_to_gpriv(uep);
> struct usbhs_pipe *pipe = usbhsg_uep_to_pipe(uep);
> struct device *dev = usbhsg_gpriv_to_dev(gpriv);
> + unsigned long flags;
>
> dev_dbg(dev, "pipe %d : queue pop\n", usbhs_pipe_number(pipe));
>
> ureq->req.status = status;
> + /*
> +* According to the gadget.h, a "complete" function will always be
> +* called with interrupts disabled. However, sometimes this function
> +* is called with interrupts enabled. (e.g. complete a DMAC transfer
> or
> +* write data and done is set immediately when PIO.) So, this function
> +* should calls local_irq_save() before this calls the
> +* usb_gadget_giveback_request().
> +*/
> + local_irq_save(flags);
> usb_gadget_giveback_request(&uep->ep, &ureq->req);
> + local_irq_restore(flags);
> }
>
> static void usbhsg_queue_done(struct usbhs_priv *priv, struct usbhs_pkt *pkt)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On 15.02.2015 16:29, Sneeker Yeh wrote:
> hi Mathias:
>
> thanks for reviewing these patch,
> and sorry for replying lately~
>
>>> + status = readl(port_array[dev_port_num - 1]);
>>> +
>>> + /* write 1 to clear */
>>> + if (!(status & PORT_CONNECT) && (status & PORT_CSC))
>>> + writel(status & PORT_CSC, port_array[0]);
>>
>> Shouldn't this be writel(...,port_array[dev_port_num - 1]) ?
>
> yes, thanks for correcting this,
> and I also would like to add xhci_port_state_to_neutral() you mentioned.
> what would you think if I modify it like this?
>
> + /* write 1 to clear */
> + if (!(status & PORT_CONNECT) && (status & PORT_CSC)) {
> + status = xhci_port_state_to_neutral(status);
> + writel(status | PORT_CSC, port_array[dev_port_num - 1]);
> + }
>
Looks good to me
-Mathias
--
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] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
W dniu 15.02.2015 o 23:43, Ruslan Bilovol pisze: In my opinion all things which you have described are working out-of-box when you use configfs interface. It's mostly ready so you may create equivalent of most legacy gadgets (apart from printer and tcm) and just bind from one udc to another whenever you want. It's because legacy gadgets are easy to use and usually don't need any userspace-side configuration. Are there any plans to remove legacy drivers in the future? I'm not going to express strong opinions here, but their name implies that this can happen, some time in the future. And I also think it will not happen before the userspace part (libusbg, gt, gadgetd etc) is mature enough. My personal opinion in that matter is that it will take at least a couple of years to remove legacy gadgets entirely. AP -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 03/10] USB: f81232: implement RX bulk-in ep
The F81232 bulk-in is RX data + LSR channel, data format is
[LSR+Data][LSR+Data]. , We had reimplemented in this patch.
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 68 +++--
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index ec4609d..9ea498a 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -185,44 +185,46 @@ exit:
static void f81232_process_read_urb(struct urb *urb)
{
struct usb_serial_port *port = urb->context;
- struct f81232_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb->transfer_buffer;
- char tty_flag = TTY_NORMAL;
- unsigned long flags;
- u8 line_status;
+ char tty_flag;
int i;
- /* update line status */
- spin_lock_irqsave(&priv->lock, flags);
- line_status = priv->modem_status;
- priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
- spin_unlock_irqrestore(&priv->lock, flags);
-
- if (!urb->actual_length)
+ if (urb->actual_length < 2)
return;
- /* break takes precedence over parity, */
- /* which takes precedence over framing errors */
- if (line_status & UART_BREAK_ERROR)
- tty_flag = TTY_BREAK;
- else if (line_status & UART_PARITY_ERROR)
- tty_flag = TTY_PARITY;
- else if (line_status & UART_FRAME_ERROR)
- tty_flag = TTY_FRAME;
- dev_dbg(&port->dev, "%s - tty_flag = %d\n", __func__, tty_flag);
-
- /* overrun is special, not associated with a char */
- if (line_status & UART_OVERRUN_ERROR)
- tty_insert_flip_char(&port->port, 0, TTY_OVERRUN);
-
- if (port->port.console && port->sysrq) {
- for (i = 0; i < urb->actual_length; ++i)
- if (!usb_serial_handle_sysrq_char(port, data[i]))
- tty_insert_flip_char(&port->port, data[i],
- tty_flag);
- } else {
- tty_insert_flip_string_fixed_flag(&port->port, data, tty_flag,
- urb->actual_length);
+ /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
+
+ for (i = 0 ; i < urb->actual_length ; i += 2) {
+ tty_flag = TTY_NORMAL;
+
+ if (unlikely(data[i+0] & UART_LSR_BRK_ERROR_BITS)) {
+ if (data[i+0] & UART_LSR_BI) {
+ tty_flag = TTY_BREAK;
+ port->icount.brk++;
+ usb_serial_handle_break(port);
+ } else if (data[i+0] & UART_LSR_PE) {
+ tty_flag = TTY_PARITY;
+ port->icount.parity++;
+ } else if (data[i+0] & UART_LSR_FE) {
+ tty_flag = TTY_FRAME;
+ port->icount.frame++;
+ }
+
+ if (data[0] & UART_LSR_OE) {
+ port->icount.overrun++;
+ tty_insert_flip_char(&port->port, 0,
+ TTY_OVERRUN);
+ }
+ }
+
+ if (port->port.console && port->sysrq) {
+ if (!usb_serial_handle_sysrq_char(port, data[i+1]))
+ tty_insert_flip_char(&port->port, data[i+1],
+ tty_flag);
+ } else {
+ tty_insert_flip_string_fixed_flag(&port->port,
+ &data[i+1], tty_flag, 1);
+ }
}
tty_flip_buffer_push(&port->port);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 01/10] USB: f81232: rename private struct member name
Change private struct member name from line_status to modem_status.
It will store MSR for some functions used
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c5dc233..669a2f2 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,7 +47,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
struct f81232_private {
spinlock_t lock;
u8 line_control;
- u8 line_status;
+ u8 modem_status;
};
static void f81232_update_line_status(struct usb_serial_port *port,
@@ -113,8 +113,8 @@ static void f81232_process_read_urb(struct urb *urb)
/* update line status */
spin_lock_irqsave(&priv->lock, flags);
- line_status = priv->line_status;
- priv->line_status &= ~UART_STATE_TRANSIENT_MASK;
+ line_status = priv->modem_status;
+ priv->modem_status &= ~UART_STATE_TRANSIENT_MASK;
spin_unlock_irqrestore(&priv->lock, flags);
if (!urb->actual_length)
@@ -241,7 +241,7 @@ static void f81232_dtr_rts(struct usb_serial_port *port,
int on)
static int f81232_carrier_raised(struct usb_serial_port *port)
{
struct f81232_private *priv = usb_get_serial_port_data(port);
- if (priv->line_status & UART_DCD)
+ if (priv->modem_status & UART_DCD)
return 1;
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 00/10] USB: f81232: V6 patches
This series patch V6 is improvement from V5&V4 as following: 1. transform all function not to use private data as parameter, using usb_serial_port instead. 2. process_read_urb() add process of Break/FrameError/ParityError/OE. (patch: 03/10) 3. fix calc_baud_divisor() will cause divide by zero with B0. (patch: 04/10) 4. Some init step we extract it from set_termios() to f81232_port_init() and run it when open port only. (patch: 04/10) 5. We'll force re-read msr in tiocmget() because the IIR with MSR change maybe delay received. (patch: 05/10) 6. fix MSR status bits changed but delta bits is 0 will cause read serial port malfunctional with update port status. (patch: 08/10) 7. Add MSR change statistic when MSR has been read. (patch: 09/10) 8. clarify a lot of code about Johan suggested. Logs: 1. We had add dev_err() in set/get register function. Also add dev_err() in some function is to help us easily point out error position, so we still decide to remain it. Thanks for reading. Peter Hung (10): USB: f81232: rename private struct member name USB: f81232: implement read IIR/MSR with endpoint USB: f81232: implement RX bulk-in ep USB: f81232: implement set_termios USB: f81232: implement MCR/MSR function USB: f81232: clarify f81232_ioctl and fix USB: f81232: fix error in f81232_carrier_raised() USB: f81232: fix read MSR strange value USB: f81232: implement delta change for MSR count USB: f81232: modify/add author drivers/usb/serial/f81232.c | 495 +++- 1 file changed, 399 insertions(+), 96 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 02/10] USB: f81232: implement read IIR/MSR with endpoint
The interrupt Endpoint will report current IIR. If we got IIR with MSR Changed
, We will do read MSR with interrupt_work worker to do f81232_read_msr() func.
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 109
1 file changed, 100 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 669a2f2..ec4609d 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1934, 0x0706) },
@@ -30,6 +31,13 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
+/* USB Control EP parameter */
+#define F81232_REGISTER_REQUEST 0xA0
+#define F81232_GET_REGISTER 0xc0
+
+#define SERIAL_BASE_ADDRESS 0x0120
+#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
+
#define CONTROL_DTR0x01
#define CONTROL_RTS0x02
@@ -48,19 +56,92 @@ struct f81232_private {
spinlock_t lock;
u8 line_control;
u8 modem_status;
+
+ struct work_struct interrupt_work;
+ struct usb_serial_port *port;
};
-static void f81232_update_line_status(struct usb_serial_port *port,
+static int f81232_get_register(struct usb_serial_port *port,
+ u16 reg, u8 *data)
+{
+ int status;
+ struct usb_device *dev = port->serial->dev;
+
+ status = usb_control_msg(dev,
+usb_rcvctrlpipe(dev, 0),
+F81232_REGISTER_REQUEST,
+F81232_GET_REGISTER,
+reg,
+0,
+data,
+sizeof(*data),
+USB_CTRL_GET_TIMEOUT);
+ if (status < 0)
+ dev_err(&port->dev, "%s status: %d\n", __func__, status);
+
+ return status;
+}
+
+static void f81232_read_msr(struct usb_serial_port *port)
+{
+ int status;
+ unsigned long flags;
+ u8 current_msr;
+ struct tty_struct *tty;
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+
+ status = f81232_get_register(port, MODEM_STATUS_REGISTER,
+ ¤t_msr);
+ if (status < 0) {
+ /* Retain the error even reported in f81232_get_register()
+to make debug easily :D */
+ dev_err(&port->dev, "%s fail, status: %d\n", __func__, status);
+ return;
+ }
+
+ if (!(current_msr & UART_MSR_ANY_DELTA))
+ return;
+
+ tty = tty_port_tty_get(&port->port);
+ if (tty) {
+ if (current_msr & UART_MSR_DDCD) {
+ usb_serial_handle_dcd_change(port, tty,
+ current_msr & UART_MSR_DCD);
+ }
+
+ tty_kref_put(tty);
+ }
+
+ spin_lock_irqsave(&priv->lock, flags);
+ priv->modem_status = current_msr;
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ wake_up_interruptible(&port->port.delta_msr_wait);
+}
+
+static void f81232_update_modem_status(struct usb_serial_port *port,
unsigned char *data,
unsigned int actual_length)
{
- /*
-* FIXME: Update port->icount, and call
-*
-* wake_up_interruptible(&port->port.delta_msr_wait);
-*
-*on MSR changes.
-*/
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+
+ if (!actual_length)
+ return;
+
+ switch (data[0] & 0x07) {
+ case 0x00: /* msr change */
+ dev_dbg(&port->dev, "IIR: MSR Change: %x\n", data[0]);
+ schedule_work(&priv->interrupt_work);
+ break;
+ case 0x02: /* tx-empty */
+ break;
+ case 0x04: /* rx data available */
+ break;
+ case 0x06: /* lsr change */
+ /* we can forget it. the LSR will read from bulk-in */
+ dev_dbg(&port->dev, "IIR: LSR Change: %x\n", data[0]);
+ break;
+ }
}
static void f81232_read_int_callback(struct urb *urb)
@@ -91,7 +172,7 @@ static void f81232_read_int_callback(struct urb *urb)
usb_serial_debug_data(&port->dev, __func__,
urb->actual_length, urb->transfer_buffer);
- f81232_update_line_status(port, data, actual_length);
+ f81232_update_modem_status(port, data, actual_length);
exit:
retval = usb_submit_urb(urb, GFP_ATOMIC);
@@ -270,6 +351,14 @@ static int f81232_ioctl(struct tty_struct *tty,
return -ENOIOCTLCMD;
}
+static void f81232_interrupt_work(struct work_struct *work)
+{
+ struct f81232_private *priv =
+ container_of(work,
[PATCH V6 10/10] USB: f81232: modify/add author
Add me to co-author and fix no '>' in greg kh's email
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 5134a19..5e35859 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -632,5 +632,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
module_usb_serial_driver(serial_drivers, id_table);
MODULE_DESCRIPTION("Fintek F81232 USB to serial adaptor driver");
-MODULE_AUTHOR("Greg Kroah-Hartman ");
+MODULE_AUTHOR("Peter Hong ");
MODULE_LICENSE("GPL v2");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 04/10] USB: f81232: implement set_termios
The original driver had do not any h/w change in driver.
This patch implements with configure H/W for
baud/parity/word length/stop bits functional.
Some init step extract to f81232_port_init(), called once with open().
And refine baudrate setting to f81232_set_baudrate()
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 145 +---
1 file changed, 138 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 9ea498a..06d1eb0 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -31,11 +31,19 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
+/* Maximum baudrate for F81232 */
+#define F81232_MAX_BAUDRATE 115200L
+
/* USB Control EP parameter */
#define F81232_REGISTER_REQUEST 0xA0
#define F81232_GET_REGISTER 0xc0
+#define F81232_SET_REGISTER 0x40
#define SERIAL_BASE_ADDRESS 0x0120
+#define RECEIVE_BUFFER_REGISTER(0x00 + SERIAL_BASE_ADDRESS)
+#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
#define CONTROL_DTR0x01
@@ -61,6 +69,14 @@ struct f81232_private {
struct usb_serial_port *port;
};
+static int calc_baud_divisor(u32 baudrate)
+{
+ if (!baudrate)
+ return 0;
+ else
+ return DIV_ROUND_CLOSEST(F81232_MAX_BAUDRATE, baudrate);
+}
+
static int f81232_get_register(struct usb_serial_port *port,
u16 reg, u8 *data)
{
@@ -82,6 +98,27 @@ static int f81232_get_register(struct usb_serial_port *port,
return status;
}
+static int f81232_set_register(struct usb_serial_port *port,
+ u16 reg, u8 data)
+{
+ int status;
+ struct usb_device *dev = port->serial->dev;
+
+ status = usb_control_msg(dev,
+ usb_sndctrlpipe(dev, 0),
+ F81232_REGISTER_REQUEST,
+ F81232_SET_REGISTER,
+ reg,
+ 0,
+ &data,
+ sizeof(data),
+ USB_CTRL_SET_TIMEOUT);
+ if (status < 0)
+ dev_err(&port->dev, "%s status: %d\n", __func__, status);
+
+ return status;
+}
+
static void f81232_read_msr(struct usb_serial_port *port)
{
int status;
@@ -247,18 +284,106 @@ static void f81232_break_ctl(struct tty_struct *tty, int
break_state)
*/
}
+static void f81232_set_baudrate(struct usb_serial_port *port, int baudrate)
+{
+ u8 divisor;
+ int status = 0;
+
+ divisor = calc_baud_divisor(baudrate);
+
+ status = f81232_set_register(port, LINE_CONTROL_REGISTER,
+UART_LCR_DLAB); /* DLAB */
+ if (status < 0) {
+ dev_err(&port->dev, "%s status: %d line:%d\n",
+ __func__, status, __LINE__);
+ }
+
+ status = f81232_set_register(port, RECEIVE_BUFFER_REGISTER,
+divisor & 0x00ff); /* low */
+ if (status < 0) {
+ dev_err(&port->dev, "%s status: %d line:%d\n",
+ __func__, status, __LINE__);
+ }
+
+ status = f81232_set_register(port, INTERRUPT_ENABLE_REGISTER,
+(divisor & 0xff00) >> 8); /* high */
+ if (status < 0) {
+ dev_err(&port->dev, "%s status: %d line:%d\n", __func__,
+ status, __LINE__);
+ }
+
+ status = f81232_set_register(port, LINE_CONTROL_REGISTER, 0x00);
+ if (status < 0) {
+ dev_err(&port->dev, "%s status: %d line:%d\n", __func__,
+ status, __LINE__);
+ }
+}
+
+static int f81232_port_init(struct usb_serial_port *port)
+{
+ u8 data;
+ int status = 0;
+
+ /* fifo on, trigger8, clear TX/RX*/
+ data = UART_FCR_TRIGGER_8 | UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR
+ | UART_FCR_CLEAR_XMIT;
+
+ status |= f81232_set_register(port, FIFO_CONTROL_REGISTER, data);
+
+ /* MSR Interrupt only, LSR will read from Bulk-in odd byte */
+ data = UART_IER_MSI;
+
+ /* IER */
+ status |= f81232_set_register(port, INTERRUPT_ENABLE_REGISTER, data);
+ if (status < 0) {
+ dev_err(&port->dev, "%s set error: %d\n", __func__, status);
+ return status;
+ }
+
+ return 0;
+}
+
static void f81232_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
- /* FIXME - Stubbed out for now */
+ u8 new_lcr = 0;
+ int status = 0;
- /* Don't change anything if nothing has changed
[PATCH V6 09/10] USB: f81232: implement delta change for MSR count
We implement delta change for MSR counting. This patch is referenced
from ftdi_sio.c
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 94c05d7..5134a19 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -112,6 +112,7 @@ static void f81232_read_msr(struct usb_serial_port *port)
unsigned long flags;
u8 current_msr, prev_msr;
u8 msr_mask = ~UART_MSR_ANY_DELTA;
+ u8 msr_changed_bit;
struct tty_struct *tty;
struct f81232_private *priv = usb_get_serial_port_data(port);
@@ -141,14 +142,30 @@ static void f81232_read_msr(struct usb_serial_port *port)
!((prev_msr ^ current_msr) & msr_mask))
return;
- tty = tty_port_tty_get(&port->port);
- if (tty) {
- if (current_msr & UART_MSR_DDCD) {
+ /* find checked delta bits set */
+ msr_changed_bit =
+ (current_msr & UART_MSR_ANY_DELTA) << 4;
+
+ /* append with not delta but changed bits */
+ msr_changed_bit |= (prev_msr ^ current_msr) & msr_mask;
+
+ if (msr_changed_bit & UART_MSR_CTS)
+ port->icount.cts++;
+ if (msr_changed_bit & UART_MSR_DSR)
+ port->icount.dsr++;
+ if (msr_changed_bit & UART_MSR_RI)
+ port->icount.rng++;
+ if (msr_changed_bit & UART_MSR_DCD) {
+
+ port->icount.dcd++;
+ tty = tty_port_tty_get(&port->port);
+ if (tty) {
+
usb_serial_handle_dcd_change(port, tty,
current_msr & UART_MSR_DCD);
- }
- tty_kref_put(tty);
+ tty_kref_put(tty);
+ }
}
wake_up_interruptible(&port->port.delta_msr_wait);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 05/10] USB: f81232: implement MCR/MSR function
This patch implement relative MCR/MSR function, such like
tiocmget()/tiocmset()/dtr_rts().
The f81232_set_mctrl() replace set_control_lines() to do MCR control
so we clean-up the set_control_lines() function.
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 98 +++--
1 file changed, 77 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 06d1eb0..e1cdf42 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -44,6 +44,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define INTERRUPT_ENABLE_REGISTER (0x01 + SERIAL_BASE_ADDRESS)
#define FIFO_CONTROL_REGISTER (0x02 + SERIAL_BASE_ADDRESS)
#define LINE_CONTROL_REGISTER (0x03 + SERIAL_BASE_ADDRESS)
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
#define CONTROL_DTR0x01
@@ -156,6 +157,50 @@ static void f81232_read_msr(struct usb_serial_port *port)
wake_up_interruptible(&port->port.delta_msr_wait);
}
+static int f81232_set_mctrl(struct usb_serial_port *port,
+ unsigned int set, unsigned int clear)
+{
+ u8 urb_value;
+ int status;
+ unsigned long flags;
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+
+ if (((set | clear) & (TIOCM_DTR | TIOCM_RTS)) == 0)
+ return 0; /* no change */
+
+ /* 'set' takes precedence over 'clear' */
+ clear &= ~set;
+
+ /* force enable interrupt with OUT2 */
+ urb_value = UART_MCR_OUT2 | priv->line_control;
+
+ if (clear & TIOCM_DTR)
+ urb_value &= ~UART_MCR_DTR;
+
+ if (clear & TIOCM_RTS)
+ urb_value &= ~UART_MCR_RTS;
+
+ if (set & TIOCM_DTR)
+ urb_value |= UART_MCR_DTR;
+
+ if (set & TIOCM_RTS)
+ urb_value |= UART_MCR_RTS;
+
+ dev_dbg(&port->dev, "%s new:%02x old:%02x\n", __func__,
+ urb_value, priv->line_control);
+
+ status = f81232_set_register(port, MODEM_CONTROL_REGISTER, urb_value);
+ if (status < 0) {
+ dev_err(&port->dev, "%s set MCR status < 0\n", __func__);
+ } else {
+ spin_lock_irqsave(&priv->lock, flags);
+ priv->line_control = urb_value;
+ spin_unlock_irqrestore(&priv->lock, flags);
+ }
+
+ return status;
+}
+
static void f81232_update_modem_status(struct usb_serial_port *port,
unsigned char *data,
unsigned int actual_length)
@@ -267,12 +312,6 @@ static void f81232_process_read_urb(struct urb *urb)
tty_flip_buffer_push(&port->port);
}
-static int set_control_lines(struct usb_device *dev, u8 value)
-{
- /* FIXME - Stubbed out for now */
- return 0;
-}
-
static void f81232_break_ctl(struct tty_struct *tty, int break_state)
{
/* FIXME - Stubbed out for now */
@@ -388,15 +427,41 @@ static void f81232_set_termios(struct tty_struct *tty,
static int f81232_tiocmget(struct tty_struct *tty)
{
- /* FIXME - Stubbed out for now */
- return 0;
+ int r;
+ struct usb_serial_port *port = tty->driver_data;
+ struct f81232_private *port_priv = usb_get_serial_port_data(port);
+ unsigned long flags;
+ u8 mcr, msr;
+
+ /* force get current MSR changed state */
+ f81232_read_msr(port);
+
+ spin_lock_irqsave(&port_priv->lock, flags);
+ mcr = port_priv->line_control;
+ msr = port_priv->modem_status;
+ spin_unlock_irqrestore(&port_priv->lock, flags);
+
+ r = (mcr & UART_MCR_DTR ? TIOCM_DTR : 0) |
+ (mcr & UART_MCR_RTS ? TIOCM_RTS : 0) |
+ (msr & UART_MSR_CTS ? TIOCM_CTS : 0) |
+ (msr & UART_MSR_DCD ? TIOCM_CAR : 0) |
+ (msr & UART_MSR_RI ? TIOCM_RI : 0) |
+ (msr & UART_MSR_DSR ? TIOCM_DSR : 0);
+
+ return r;
}
static int f81232_tiocmset(struct tty_struct *tty,
unsigned int set, unsigned int clear)
{
- /* FIXME - Stubbed out for now */
- return 0;
+ int status;
+ struct usb_serial_port *port = tty->driver_data;
+
+ status = f81232_set_mctrl(port, set, clear);
+ if (status < 0)
+ return usb_translate_errors(status);
+ else
+ return 0;
}
static int f81232_open(struct tty_struct *tty, struct usb_serial_port *port)
@@ -437,19 +502,10 @@ static void f81232_close(struct usb_serial_port *port)
static void f81232_dtr_rts(struct usb_serial_port *port, int on)
{
- struct f81232_private *priv = usb_get_serial_port_data(port);
- unsigned long flags;
- u8 control;
-
- spin_lock_irqsave(&priv->lock, flags);
- /* Change DTR and RTS */
if (on)
- priv->line_control |=
[PATCH V6 06/10] USB: f81232: clarify f81232_ioctl and fix
We extract TIOCGSERIAL section in f81232_ioctl() to f81232_get_serial_info()
to make it clarify.
Also we fix device type from 16654 to 16550A, and set it's baud_base
to 115200 (1.8432MHz/16)
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index e1cdf42..e70ec62 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -516,24 +516,32 @@ static int f81232_carrier_raised(struct usb_serial_port
*port)
return 0;
}
+static int f81232_get_serial_info(struct usb_serial_port *port,
+ unsigned long arg)
+{
+ struct serial_struct ser;
+
+ memset(&ser, 0, sizeof(ser));
+
+ ser.type = PORT_16550A;
+ ser.line = port->minor;
+ ser.port = port->port_number;
+ ser.baud_base = 115200;
+
+ if (copy_to_user((void __user *)arg, &ser, sizeof(ser)))
+ return -EFAULT;
+
+ return 0;
+}
+
static int f81232_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg)
{
- struct serial_struct ser;
struct usb_serial_port *port = tty->driver_data;
switch (cmd) {
case TIOCGSERIAL:
- memset(&ser, 0, sizeof ser);
- ser.type = PORT_16654;
- ser.line = port->minor;
- ser.port = port->port_number;
- ser.baud_base = 460800;
-
- if (copy_to_user((void __user *)arg, &ser, sizeof ser))
- return -EFAULT;
-
- return 0;
+ return f81232_get_serial_info(port, arg);
default:
break;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 07/10] USB: f81232: fix error in f81232_carrier_raised()
It's should compared with UART_MSR_DCD, not UART_DCD.
also we clean-up some non-used define to avoid impropriety use.
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index e70ec62..c87a3eb 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,20 +47,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
-#define CONTROL_DTR0x01
-#define CONTROL_RTS0x02
-
-#define UART_STATE 0x08
-#define UART_STATE_TRANSIENT_MASK 0x74
-#define UART_DCD 0x01
-#define UART_DSR 0x02
-#define UART_BREAK_ERROR 0x04
-#define UART_RING 0x08
-#define UART_FRAME_ERROR 0x10
-#define UART_PARITY_ERROR 0x20
-#define UART_OVERRUN_ERROR 0x40
-#define UART_CTS 0x80
-
struct f81232_private {
spinlock_t lock;
u8 line_control;
@@ -511,7 +497,7 @@ static void f81232_dtr_rts(struct usb_serial_port *port,
int on)
static int f81232_carrier_raised(struct usb_serial_port *port)
{
struct f81232_private *priv = usb_get_serial_port_data(port);
- if (priv->modem_status & UART_DCD)
+ if (priv->modem_status & UART_MSR_DCD)
return 1;
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 08/10] USB: f81232: fix read MSR strange value
When we use RS232 loopback, assume doing RTS change will cause
CTS change, DTR change will cause DCD/DSR change too.
Sometimes we got 7~4 bits of MSR changed but the 3~0 bits of
MSR(delta) maybe not changed when set & get MCR fasterly.
So we add more check not only UART_MSR_ANY_DELTA but also with
comparing DCD/RI/DSR/CTS change with old value. Due to the state
bit is always correct, we direct save msr when read.
The following step to reproduce this problem with while loop step 1~4:
1. ioctl(fd, TIOCMSET, &data) to set RTS or DTR
2. ioctl(fd, TIOCMGET, &data) to read CTS or DCD/DSR state
3. ioctl(fd, TIOCMSET, &data) to unset RTS or DTR
4. ioctl(fd, TIOCMGET, &data) to read CTS or DCD/DSR state
Signed-off-by: Peter Hung
---
drivers/usb/serial/f81232.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c87a3eb..94c05d7 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -110,7 +110,8 @@ static void f81232_read_msr(struct usb_serial_port *port)
{
int status;
unsigned long flags;
- u8 current_msr;
+ u8 current_msr, prev_msr;
+ u8 msr_mask = ~UART_MSR_ANY_DELTA;
struct tty_struct *tty;
struct f81232_private *priv = usb_get_serial_port_data(port);
@@ -123,7 +124,21 @@ static void f81232_read_msr(struct usb_serial_port *port)
return;
}
- if (!(current_msr & UART_MSR_ANY_DELTA))
+ /*
+ * The 7~4 bits of MSR will change but the 3~0 bits of MSR(delta)
+ * maybe not change when set & get MCR fasterly.
+ *
+ * So we add more check with comparing DCD/RI/DSR/CTS
+ * change. and direct save msr when read.
+ */
+
+ spin_lock_irqsave(&priv->lock, flags);
+ prev_msr = priv->modem_status;
+ priv->modem_status = current_msr;
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ if (!(current_msr & UART_MSR_ANY_DELTA) &&
+ !((prev_msr ^ current_msr) & msr_mask))
return;
tty = tty_port_tty_get(&port->port);
@@ -136,10 +151,6 @@ static void f81232_read_msr(struct usb_serial_port *port)
tty_kref_put(tty);
}
- spin_lock_irqsave(&priv->lock, flags);
- priv->modem_status = current_msr;
- spin_unlock_irqrestore(&priv->lock, flags);
-
wake_up_interruptible(&port->port.delta_msr_wait);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
