[PATCH] [media] Prefer gspca_sonixb over sn9c102 for all devices
The sn9c102 driver is deprecated. It was moved to staging in
anticipation of its removal in a future kernel version. However, USB
devices 0C45:6024 and 0C45:6025 are still handled by sn9c102 when
both sn9c102 and gspca_sonixb are enabled.
We must migrate all the users of these devices to the gspca_sonixb
driver now, so that it gets sufficient testing before the sn9c102
driver is finally phased out.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Hans de Goede hdego...@redhat.com
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: Luca Risolia luca.riso...@studio.unibo.it
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
I consider this a bug fix, I believe it should go upstream ASAP.
drivers/media/usb/gspca/sonixb.c |2 --
drivers/staging/media/sn9c102/sn9c102_devtable.h |2 --
2 files changed, 4 deletions(-)
--- linux-3.15-rc0.orig/drivers/media/usb/gspca/sonixb.c2014-04-11
08:57:26.932408285 +0200
+++ linux-3.15-rc0/drivers/media/usb/gspca/sonixb.c 2014-04-11
09:02:32.151943578 +0200
@@ -1430,10 +1430,8 @@ static const struct usb_device_id device
{USB_DEVICE(0x0c45, 0x600d), SB(PAS106, 101)},
{USB_DEVICE(0x0c45, 0x6011), SB(OV6650, 101)},
{USB_DEVICE(0x0c45, 0x6019), SB(OV7630, 101)},
-#if !IS_ENABLED(CONFIG_USB_SN9C102)
{USB_DEVICE(0x0c45, 0x6024), SB(TAS5130CXX, 102)},
{USB_DEVICE(0x0c45, 0x6025), SB(TAS5130CXX, 102)},
-#endif
{USB_DEVICE(0x0c45, 0x6027), SB(OV7630, 101)}, /* Genius Eye 310 */
{USB_DEVICE(0x0c45, 0x6028), SB(PAS202, 102)},
{USB_DEVICE(0x0c45, 0x6029), SB(PAS106, 102)},
--- linux-3.15-rc0.orig/drivers/staging/media/sn9c102/sn9c102_devtable.h
2014-04-11 08:57:26.932408285 +0200
+++ linux-3.15-rc0/drivers/staging/media/sn9c102/sn9c102_devtable.h
2014-04-11 09:02:32.151943578 +0200
@@ -48,10 +48,8 @@ static const struct usb_device_id sn9c10
{ SN9C102_USB_DEVICE(0x0c45, 0x600d, BRIDGE_SN9C102), },
/* { SN9C102_USB_DEVICE(0x0c45, 0x6011, BRIDGE_SN9C102), }, OV6650 */
{ SN9C102_USB_DEVICE(0x0c45, 0x6019, BRIDGE_SN9C102), },
-#endif
{ SN9C102_USB_DEVICE(0x0c45, 0x6024, BRIDGE_SN9C102), },
{ SN9C102_USB_DEVICE(0x0c45, 0x6025, BRIDGE_SN9C102), },
-#if !defined CONFIG_USB_GSPCA_SONIXB !defined CONFIG_USB_GSPCA_SONIXB_MODULE
{ SN9C102_USB_DEVICE(0x0c45, 0x6028, BRIDGE_SN9C102), },
{ SN9C102_USB_DEVICE(0x0c45, 0x6029, BRIDGE_SN9C102), },
{ SN9C102_USB_DEVICE(0x0c45, 0x602a, BRIDGE_SN9C102), },
--
Jean Delvare
SUSE L3 Support
--
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] cdc-acm: some enhancement on acm delayed write
[ +CC: Jiri and Peter ] On Thu, Apr 10, 2014 at 10:02:03AM +0200, Oliver Neukum wrote: On Wed, 2014-04-09 at 22:57 +0800, Xiao Jin wrote: Thanks all for the review. We meet with the problems when developing product. I would like to explain my understanding. On 04/08/2014 11:05 AM, Xiao Jin wrote: We find two problems on acm tty write delayed mechanism. (1) When acm resume, the delayed wb will be started. But now only one write can be saved during acm suspend. More acm write may be abandoned. The scenario usually happened when user space write series AT after acm suspend. If acm accept the first AT, what's the reason for acm to refuse the second AT? If write return 0, user space will try repeatedly until resume. It looks simpler that acm accept all the data and sent out urb when resume. No. We cannot accept an arbitrary amount of data. It would let any user OOM the system. There will have to be an arbitrary limit. The simplest limit is 1 urb. And that is because we said that we are ready to accept data. That doesn't make much sense. Either tty can handle write returning 0 or it doesn't. Consider what happens when you get two consecutive writes (both preceded by write_room). Why should buffering the first write solve anything? In fact, it doesn't (at least not data being dropped). If buffering is indeed needed, we must buffer at least as much data as reported by write_room, which in this cause should amount to buffering all write_urbs as Jin suggests. And by the way, OOM is not an issue with Jin's patch as only ACM_NW (16) urbs are allocated and can be queued (the buffer should probably have been implemented using urb anchors, though). (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. We see tty write and close concurrently after acm suspend in this case. It looks no method to avoid it from tty layer. acm_tty_write and There is a delay user space can set. acm_resume call after acm_port_shutdown. It looks any action in acm_port_shutdown can't solve the problem. As acm has accepted the user space data, we can only find a way to send out urb. I feel anyway to discard the data looks like a lie to user space. It's not a lie. Consider what happens if you write a large buffer to a device using a 300 baud line? We have mechanisms (e.g. tcdrain() and closing_wait) to let the user decide whether to wait for that data to drain or not. Please also note that when using flow control, this could take literally forever. Jin, what is closing_wait set to in your application? The default is 30 seconds, which means there should have been plenty of the time for the device to resume (and submit any buffered data). In my understanding acm should accept data as much as possible, and send out urb as soon as possible. What do you think of? There's certainly no problem with sending out the data. Yet simply resuming the device in shutdown() should do the job. As soon as possible, yes, but again, we shouldn't be sending out urbs at shutdown (that is were we stop transmissions). (Resuming the device at close could be ok, but that would still be redundant as we have already done the async autopm_get in write.) If the data is precious, make sure to have a reasonable closing_wait, or it may be dropped. All that said, there are some serious bugs in the ACM driver: write is dropping data and leaking write urbs, _and_ buffered urbs are never reclaimed at shutdown. If it is ok to not buffer anything in write even though write_room returned 0, then I think we should simply rip out the buffering from the ACM driver and rely on the tty buffers. Otherwise, we must make sure that the buffer space matches what is returned by write_room and buffer all 16 write-urbs if needed (preferably, using urb anchors). When implementing the first option, I came across what appears to be a line-discipline bug which needs to be addressed first, though. Please have a look at the follow-up RFC. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/2] n_tty: fix dropped output characters
Fix characters being dropped by n_tty_write() due to a failure to check the return value of tty_put_char() in do_output_char(). Characters are currently being dropped by write if a tty driver claims to have write room available, but still fails to buffer any data (e.g. if a driver without internal buffer is run-time suspended between write_room and write). Note that process_output_block() handles such a failed buffer attempt, but that the consecutive process_output() of the first character will drop it. This could lead to the whole buffer being silently dropped as the remainder of the buffer is processed in a loop. Signed-off-by: Johan Hovold jhov...@gmail.com --- drivers/tty/n_tty.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index d15624c1b751..d22a2d8f1cb7 100644 --- a/drivers/tty/n_tty.c +++ b/drivers/tty/n_tty.c @@ -513,7 +513,9 @@ static int do_output_char(unsigned char c, struct tty_struct *tty, int space) break; } - tty_put_char(tty, c); + if (!tty_put_char(tty, c)) + return -1; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/2] USB: cdc-acm: fix broken runtime suspend
The current runtime suspend implementation is broken in several ways:
Firstly, it buffers only the first write request being made while
suspended -- any further writes are silently dropped.
Secondly, writes being dropped also leak write urbs which are never
reclaimed (until the device is unbound).
Thirdly, even the single buffered write is not cleared at shutdown
(which may happen before the device is resumed), something which can
lead to another urb leak.
Fix this by simple removing the broken and redundant buffer
implementation from the driver, and rely on the tty buffers instead.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/class/cdc-acm.c | 28 +++-
drivers/usb/class/cdc-acm.h | 1 -
2 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff805ee..c85bf3062bba 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -646,12 +646,10 @@ static int acm_tty_write(struct tty_struct *tty,
usb_autopm_get_interface_async(acm-control);
if (acm-susp_count) {
- if (!acm-delayed_wb)
- acm-delayed_wb = wb;
- else
- usb_autopm_put_interface_async(acm-control);
+ wb-use = 0;
+ usb_autopm_put_interface_async(acm-control);
spin_unlock_irqrestore(acm-write_lock, flags);
- return count; /* A white lie */
+ return 0;
}
usb_mark_last_busy(acm-dev);
@@ -1540,7 +1538,6 @@ static int acm_suspend(struct usb_interface *intf,
pm_message_t message)
static int acm_resume(struct usb_interface *intf)
{
struct acm *acm = usb_get_intfdata(intf);
- struct acm_wb *wb;
int rv = 0;
int cnt;
@@ -1554,25 +1551,14 @@ static int acm_resume(struct usb_interface *intf)
if (test_bit(ASYNCB_INITIALIZED, acm-port.flags)) {
rv = usb_submit_urb(acm-ctrlurb, GFP_NOIO);
-
- spin_lock_irq(acm-write_lock);
- if (acm-delayed_wb) {
- wb = acm-delayed_wb;
- acm-delayed_wb = NULL;
- spin_unlock_irq(acm-write_lock);
- acm_start_wb(acm, wb);
- } else {
- spin_unlock_irq(acm-write_lock);
- }
-
- /*
-* delayed error checking because we must
-* do the write path at all cost
-*/
if (rv 0)
goto err_out;
rv = acm_submit_read_urbs(acm, GFP_NOIO);
+ if (rv 0)
+ goto err_out;
+
+ schedule_work(acm-work);
}
err_out:
diff --git a/drivers/usb/class/cdc-acm.h b/drivers/usb/class/cdc-acm.h
index e38dc785808f..538bb1b3b0bc 100644
--- a/drivers/usb/class/cdc-acm.h
+++ b/drivers/usb/class/cdc-acm.h
@@ -120,7 +120,6 @@ struct acm {
unsigned int throttled:1; /* actually throttled */
unsigned int throttle_req:1;/* throttle requested */
u8 bInterval;
- struct acm_wb *delayed_wb; /* write queued for a
device about to be woken */
};
#define CDC_DATA_INTERFACE_TYPE0x0a
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cdc-acm: some enhancement on acm delayed write
On Tue, Apr 08, 2014 at 12:22:22PM +0200, Oliver Neukum wrote:
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
Then you should split this into two patches.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm write
may be abandoned.
Why not simply return 0 in write and use the tty buffering rather than
implement another buffer in cdc_acm?
Yes. We need a single buffer because the tty layer is not happy
when you accept no data. But we should be able to refuse subsequent
writes. Could you test this patch?
Regards
Oliver
From 1d44c1f2a10b5617824a37c8ec51f5547e482259 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Tue, 8 Apr 2014 12:17:39 +0200
Subject: [PATCH] cdc-acm: fix consecutive writes while device is suspended
CDC-ACM needs to handle one attempt to write to a suspended
device because we told the tty layer that there is room.
A second attempt may and must fail or we drop data.
Signed-off-by: Oliver Neukum oneu...@suse.de
CC: sta...@vger.kernel.org
---
drivers/usb/class/cdc-acm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff..7ad3105 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -646,10 +646,12 @@ static int acm_tty_write(struct tty_struct *tty,
usb_autopm_get_interface_async(acm-control);
if (acm-susp_count) {
- if (!acm-delayed_wb)
+ if (!acm-delayed_wb) {
acm-delayed_wb = wb;
- else
+ } else {
usb_autopm_put_interface_async(acm-control);
+ count = 0;
You would still leak write urbs here, unless you set wb.use = 0.
+ }
spin_unlock_irqrestore(acm-write_lock, flags);
return count; /* A white lie */
}
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] r8152: check RTL8152_UNPLUG
When the device is unplugged, the driver would try to disable the
device. Add checking the flag of RTL8152_UNPLUG to skip setting
the device when it is unplugged. This could shorten the time of
unloading the driver.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 48
1 file changed, 48 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 18e12a3..3fbfb08 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -929,6 +929,9 @@ static int read_mii_word(struct net_device *netdev, int
phy_id, int reg)
struct r8152 *tp = netdev_priv(netdev);
int ret;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return -ENODEV;
+
if (phy_id != R8152_PHY_ID)
return -EINVAL;
@@ -949,6 +952,9 @@ void write_mii_word(struct net_device *netdev, int phy_id,
int reg, int val)
{
struct r8152 *tp = netdev_priv(netdev);
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
if (phy_id != R8152_PHY_ID)
return;
@@ -1962,6 +1968,9 @@ static int rtl_enable(struct r8152 *tp)
static int rtl8152_enable(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return -ENODEV;
+
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
@@ -1994,6 +2003,9 @@ static void r8153_set_rx_agg(struct r8152 *tp)
static int rtl8153_enable(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return -ENODEV;
+
set_tx_qlen(tp);
rtl_set_eee_plus(tp);
r8153_set_rx_agg(tp);
@@ -2006,6 +2018,11 @@ static void rtl8152_disable(struct r8152 *tp)
u32 ocp_data;
int i;
+ if (test_bit(RTL8152_UNPLUG, tp-flags)) {
+ rtl_drop_queued_tx(tp);
+ return;
+ }
+
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data = ~RCR_ACPT_ALL;
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
@@ -2232,6 +2249,9 @@ static void r8152b_exit_oob(struct r8152 *tp)
u32 ocp_data;
int i;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data = ~RCR_ACPT_ALL;
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
@@ -2460,6 +2480,9 @@ static void r8153_first_init(struct r8152 *tp)
u32 ocp_data;
int i;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
rxdy_gated_en(tp, true);
r8153_teredo_off(tp);
@@ -2687,6 +2710,11 @@ out:
static void rtl8152_down(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags)) {
+ rtl_drop_queued_tx(tp);
+ return;
+ }
+
r8152_power_cut_en(tp, false);
r8152b_disable_aldps(tp);
r8152b_enter_oob(tp);
@@ -2695,6 +2723,11 @@ static void rtl8152_down(struct r8152 *tp)
static void rtl8153_down(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags)) {
+ rtl_drop_queued_tx(tp);
+ return;
+ }
+
r8153_u1u2en(tp, false);
r8153_power_cut_en(tp, false);
r8153_disable_aldps(tp);
@@ -2904,6 +2937,9 @@ static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
if (tp-version == RTL_VER_01) {
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_LED_FEATURE);
ocp_data = ~LED_MODE_MASK;
@@ -2939,6 +2975,9 @@ static void r8153_init(struct r8152 *tp)
u32 ocp_data;
int i;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
r8153_u1u2en(tp, false);
for (i = 0; i 500; i++) {
@@ -3213,6 +3252,9 @@ static int rtl8152_ioctl(struct net_device *netdev,
struct ifreq *rq, int cmd)
struct mii_ioctl_data *data = if_mii(rq);
int res;
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return -ENODEV;
+
res = usb_autopm_get_interface(tp-intf);
if (res 0)
goto out;
@@ -3293,12 +3335,18 @@ static void r8152b_get_version(struct r8152 *tp)
static void rtl8152_unload(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
if (tp-version != RTL_VER_01)
r8152_power_cut_en(tp, true);
}
static void rtl8153_unload(struct r8152 *tp)
{
+ if (test_bit(RTL8152_UNPLUG, tp-flags))
+ return;
+
r8153_power_cut_en(tp, true);
}
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: f_subset: replace PTR_RET with PTR_ERR_OR_ZERO
PTR_RET is deprecated. Do not recommend its usage anymore. Use PTR_ERR_OR_ZERO instead. Signed-off-by: Duan Jiong duanj.f...@cn.fujitsu.com --- drivers/usb/gadget/f_subset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c index df4a0dcb..1ea8baf 100644 --- a/drivers/usb/gadget/f_subset.c +++ b/drivers/usb/gadget/f_subset.c @@ -276,7 +276,7 @@ static int geth_set_alt(struct usb_function *f, unsigned intf, unsigned alt) } net = gether_connect(geth-port); - return PTR_RET(net); + return PTR_ERR_OR_ZERO(net); } static void geth_disable(struct usb_function *f) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cdc-acm: some enhancement on acm delayed write
On Fri, 2014-04-11 at 06:51 +0800, Xiao Jin wrote: Hi, Oliver, On 04/10/2014 04:02 PM, Oliver Neukum wrote: On Wed, 2014-04-09 at 22:57 +0800, Xiao Jin wrote: Thanks all for the review. We meet with the problems when developing product. I would like to explain my understanding. On 04/08/2014 11:05 AM, Xiao Jin wrote: We find two problems on acm tty write delayed mechanism. (1) When acm resume, the delayed wb will be started. But now only one write can be saved during acm suspend. More acm write may be abandoned. The scenario usually happened when user space write series AT after acm suspend. If acm accept the first AT, what's the reason for acm to refuse the second AT? If write return 0, user space will try repeatedly until resume. It looks simpler that acm accept all the data and sent out urb when resume. No. We cannot accept an arbitrary amount of data. It would let any user OOM the system. There will have to be an arbitrary limit. The simplest limit is 1 urb. And that is because we said that we are ready to accept data. We apply cdc-acm for modem AT data. I can find other usb modem driver usb_wwan_write use list to accept more data when suspend, maybe usbnet is the same. Do you have any more reason for me to understand why cdc-acm accept only one? User space must be ready to deal with a device that cannot accept any more data. There is simply no additional benefit in more caching. We see tty write and close concurrently, we have debug log to show that acm_tty_write and acm_resume is called after acm_port_shutdown, I don't understand resuming the device in shutdown() should do the job. There we have a problem. In fact it looks like a bug in the tty layer. Could you post the logs? Regards Oliver -- 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
Deadlock v3.10.35 with FTD_SIO usb-serial adapter
We are experiencing stuck processes (D state) which are talking to an FTD_SIO usb_serial adapter. The process sometimes has to close the serial device when it detects an error or a timeout. We rebuilt the kernel with the CONFIG_DEBUG_USB option and the stuck processes reporting enabled. The output was this: = [89400.258190] INFO: task XX:26743 blocked for more than 120 seconds. [89400.258263] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [89400.258329] XD c132e6a0 0 26743 2260 0x [89400.258397] de2e5e5c 00200082 de2e5dfc c132e6a0 68d4dbc8 511c db24c000 [89400.258506] de2e4000 db24c000 de002c80 dee34000 c1537ea0 de2e5e38 c1315cb0 def5ac00 [89400.258614] c104a7ae de2e5e30 c12a9b48 de2e5e38 c104a7ae de2e5e64 c13169a6 c14eee71 [89400.258722] Call Trace: [89400.258783] [c132e6a0] ? start_ed_unlink+0x19/0x4f [89400.258854] [c1315cb0] ? unlink1+0x29/0x13d [89400.258913] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.258997] [c12a9b48] ? put_device+0x14/0x16 [89400.259099] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.259160] [c13169a6] ? usb_hcd_unlink_urb+0xac/0xbe [89400.259228] [c14eee71] ? mutex_unlock+0x8/0x13 [89400.259283] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.259341] [c10421c3] ? prepare_to_wait+0x49/0x75 [89400.259405] [c14efdbb] schedule+0x22/0x4c [89400.259459] [c1317c2c] usb_kill_urb+0x62/0x92 [89400.259514] [c10423a9] ? finish_wait+0x71/0x71 [89400.259589] [dffd7fb1] usb_serial_generic_close+0x78/0x90 [usbserial] [89400.259660] [dffd601f] serial_port_shutdown+0x1f/0x21 [usbserial] [89400.259727] [c128ac5b] tty_port_shutdown+0x46/0x66 [89400.259787] [c128b59e] tty_port_close+0x20/0x3d [89400.259851] [dffd668c] serial_close+0x1d/0x20 [usbserial] [89400.259920] [c1283b1b] tty_release+0xce/0x525 [89400.260003] [c104a7ae] ? sub_preempt_count+0xb/0xa5 [89400.262022] [c10f341d] ? fsnotify+0xe/0x29f [89400.262280] [c10f8c33] ? timerfd_read+0x1bf/0x27c [89400.262346] [c10f37f1] ? __fsnotify_parent+0xe/0xd3 [89400.262410] [c10c0034] __fput+0x8b/0x205 [89400.262468] [c10c0252] fput+0xd/0xf [89400.262526] [c103f0a1] task_work_run+0x57/0x79 [89400.262584] [c10018c5] do_notify_resume+0x5b/0x5d [89400.262640] [c10be61a] ? SyS_close+0x1b/0x42 [89400.262697] [c14f0e8b] work_notifysig+0x24/0x29 [89400.262764] [c14f] ? wait_for_completion+0x8/0x19 = (also on http://pastebin.com/zTy0uhMN ) I couldn't find the cause, nor a way to trigger this, except waiting for around 24 hours. Is there anything we could look at to help? Thank you in advance, Matteo -- 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
[RFC 0/4] Enable U1/U2 initiation from dwc3 xhci host
These patches provides support of LPM capability to the dwc3 xhci hosts. LPM capability is disabled by default. Any dwc3 based platform can enable it through device tree. Patches have been tested on STih407 by Aymen BOUATTAY. Pratyush Anand (4): dwc3: dts: Binding information for an optional property lpm_capable dwc3: host: Set xhci quirk for LPM if a platform supports it xhci: A default implementation for Ux timeout calculation and tier policy check xhci: Platform: Add (en/dis)able_usb3_lpm_timeout Documentation/devicetree/bindings/usb/dwc3.txt | 2 + drivers/usb/dwc3/core.c| 1 + drivers/usb/dwc3/core.h| 1 + drivers/usb/dwc3/host.c| 2 + drivers/usb/host/xhci-plat.c | 3 ++ drivers/usb/host/xhci.c| 61 ++ 6 files changed, 70 insertions(+) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable
If a dwc3 host implementation is lpm capable then enable lpm_capable in
device tree.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..a7a48f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - lpm-capable: determines if xhci host is lpm capable
This is usually a subnode to DWC3 glue to which it is connected.
@@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
+ lpm-capable;
};
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 4/4] xhci: Platform: Add (en/dis)able_usb3_lpm_timeout
To use auto U0-U1/U2 transition by xhci platform device add
(en/dis)able_usb3_lpm_timeout function to the xhci_plat_xhci_driver struct.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/host/xhci-plat.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5413861..89c863d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -83,6 +83,9 @@ static const struct hc_driver xhci_plat_xhci_driver = {
.hub_status_data = xhci_hub_status_data,
.bus_suspend = xhci_bus_suspend,
.bus_resume = xhci_bus_resume,
+
+ .enable_usb3_lpm_timeout = xhci_enable_usb3_lpm_timeout,
+ .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
};
static int xhci_plat_probe(struct platform_device *pdev)
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] dwc3: host: Set xhci quirk for LPM if a platform supports it
If a platform supports LPM then enable quirk in XHCI for the same.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/core.c | 1 +
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/host.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 358375e..119dea3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -490,6 +490,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
+ dwc-lpm_capable = of_property_read_bool(node, lpm-capable);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 27dad99..f7bf6da 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -725,6 +725,7 @@ struct dwc3 {
unsignedsetup_packet_pending:1;
unsigneddelayed_status:1;
unsignedneeds_fifo_resize:1;
+ unsignedlpm_capable:1;
unsignedresize_fifos:1;
unsignedpullups_connected:1;
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index a362ed9..38b5c41 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -86,6 +86,8 @@ int dwc3_host_init(struct dwc3 *dwc)
hcd = platform_get_drvdata(xhci);
xhci_dev = hcd_to_xhci(hcd);
xhci_dev-shared_hcd-phy = dwc-usb3_phy;
+ if (dwc-lpm_capable)
+ xhci_dev-quirks |= XHCI_LPM_SUPPORT;
return 0;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/4] xhci: A default implementation for Ux timeout calculation and tier policy check
As best case, a host controller should support U0 to U1 switching for
the devices connected below any tier of hub level supported by usb
specification. Therefore xhci_check_default_tier_policy always returns
success.
A host should be able to issue LGO_Ux after the timeout calculated as
per definition of system exit latency defined in C.1.5.2. Therefore
xhci_calculate_default_ux_timeout returns ux_params.sel as the default
implementation.
Use default calculation in absence of any vendor specific limitations.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/host/xhci.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6cc58fe..930c01f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4140,6 +4140,53 @@ static u16 xhci_get_timeout_no_hub_lpm(struct usb_device
*udev,
return USB3_LPM_DISABLED;
}
+/* Returns the default hub-encoded U1 timeout value.
+ */
+static u16 xhci_calculate_default_u1_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u1_params.sel;
+
+ /* The U1 timeout is encoded in 1us intervals. */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
+ /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
+ if (timeout_ns == USB3_LPM_DISABLED)
+ timeout_ns++;
+
+ /* If the necessary timeout value is bigger than what we can set in the
+* USB 3.0 hub, we have to disable hub-initiated U1.
+*/
+ if (timeout_ns = USB3_LPM_U1_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U1 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
+}
+
+/* Returns the default hub-encoded U2 timeout value.
+ */
+static u16 xhci_calculate_default_u2_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u2_params.sel;
+
+ /* The U2 timeout is encoded in 256us intervals */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
+ /* If the necessary timeout value is bigger than what we can set in the
+* USB 3.0 hub, we have to disable hub-initiated U2.
+*/
+ if (timeout_ns = USB3_LPM_U2_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U2 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U2);
+}
+
+
/* Returns the hub-encoded U1 timeout value.
* The U1 timeout should be the maximum of the following values:
* - For control endpoints, U1 system exit latency (SEL) * 3
@@ -4241,9 +4288,13 @@ static u16
xhci_call_host_update_timeout_for_endpoint(struct xhci_hcd *xhci,
if (state == USB3_LPM_U1) {
if (xhci-quirks XHCI_INTEL_HOST)
return xhci_calculate_intel_u1_timeout(udev, desc);
+ else
+ return xhci_calculate_default_u1_timeout(udev, desc);
} else {
if (xhci-quirks XHCI_INTEL_HOST)
return xhci_calculate_intel_u2_timeout(udev, desc);
+ else
+ return xhci_calculate_default_u2_timeout(udev, desc);
}
return USB3_LPM_DISABLED;
@@ -4291,6 +4342,14 @@ static int xhci_update_timeout_for_interface(struct
xhci_hcd *xhci,
return 0;
}
+static int xhci_check_default_tier_policy(struct usb_device *udev,
+ enum usb3_link_state state)
+{
+ /* Keeep Ux enabled for all devices */
+
+ return 0;
+}
+
static int xhci_check_intel_tier_policy(struct usb_device *udev,
enum usb3_link_state state)
{
@@ -4321,6 +4380,8 @@ static int xhci_check_tier_policy(struct xhci_hcd *xhci,
{
if (xhci-quirks XHCI_INTEL_HOST)
return xhci_check_intel_tier_policy(udev, state);
+ else
+ return xhci_check_default_tier_policy(udev, state);
return -EINVAL;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/2] Support for Super Speed Link Layer Test
Lecroy's USB Compliance suites provide option to test Link Layer Tests for Super Speed device as well as host. As of now there is no standard way to test embedded host for these tests. These patches modifies Linux USB host stack to carry out these tests for embedded hosts. Modifications are still not complete. Patch 2 will have few more sysfs nodes to support some failing tests. I am sending these as RFC for mainly to have your comment on framework modifications. Please let me know, if there could be any better way to do it. Pratyush Anand (2): USB: Core: Quirk to prevent enumeration of LVS devices USB: Add LVS Test device driver Documentation/ABI/testing/sysfs-bus-usb| 10 ++ .../ABI/testing/sysfs-devices-platform-lvstestdev | 32 drivers/usb/core/hub.c | 105 - drivers/usb/core/hub.h | 2 + drivers/usb/core/sysfs.c | 34 drivers/usb/core/usb.c | 1 - drivers/usb/misc/Kconfig | 6 + drivers/usb/misc/Makefile | 1 + drivers/usb/misc/lvstestdev.c | 171 + include/linux/usb/quirks.h | 3 + 10 files changed, 361 insertions(+), 4 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-lvstestdev create mode 100644 drivers/usb/misc/lvstestdev.c -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/2] USB: Add LVS Test device driver
There are many Link Layer Tests which needs host to generate specific
traffic. This driver provides a way to do that.
For root hub n there would be different sysfs nodes corresponding to
each specific traffic generation case. For example:
1. To issue Get Device descriptor command for TD.7.06:
echo 1 /sys/devices/platform/lvstestdev.n.auto/get_dev_desc
2. To set U1 timeout to 127 for TD.7.18
echo 127 /sys/devices/platform/lvstestdev.n.auto/u1_timeout
3. To set U2 timeout to 0 for TD.7.18
echo 0 /sys/devices/platform/lvstestdev.n.auto/u2_timeout
4. To issue Hot Reset for TD.7.29
echo 1 /sys/devices/platform/lvstestdev.n.auto/hot_reset
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
.../ABI/testing/sysfs-devices-platform-lvstestdev | 32
drivers/usb/misc/Kconfig | 6 +
drivers/usb/misc/Makefile | 1 +
drivers/usb/misc/lvstestdev.c | 171 +
4 files changed, 210 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-lvstestdev
create mode 100644 drivers/usb/misc/lvstestdev.c
diff --git a/Documentation/ABI/testing/sysfs-devices-platform-lvstestdev
b/Documentation/ABI/testing/sysfs-devices-platform-lvstestdev
new file mode 100644
index 000..49f5871
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-platform-lvstestdev
@@ -0,0 +1,32 @@
+Link Layer Validation Device is a standard device for testing of Super
+Speed Link Layer tests.
+
+What: /sys/devices/platform/lvstestdev.n.auto/get_dev_desc
+Date: March 2014
+Contact: Pratyush Anand pratyush.an...@st.com
+Description:
+ Write 1 to this node to issue Get Device Descriptor
+ for Link Layer Validation device. It is needed for TD.7.06.
+
+What: /sys/devices/platform/lvstestdev.n.auto/u1_timeout
+Date: March 2014
+Contact: Pratyush Anand pratyush.an...@st.com
+Description:
+ Set U1 timeout for the downstream port where Link Layer
+ Validation device is connected. It is needed for TD.7.18,
+ TD.7.19, TD.7.20 and TD.7.21.
+
+What: /sys/devices/platform/lvstestdev.n.auto/u2_timeout
+Date: March 2014
+Contact: Pratyush Anand pratyush.an...@st.com
+Description:
+ Set U2 timeout for the downstream port where Link Layer
+ Validation device is connected. It is needed for TD.7.18,
+ TD.7.19, TD.7.20 and TD.7.21.
+
+What: /sys/devices/platform/lvstestdev.n.auto/hot_reset
+Date: March 2014
+Contact: Pratyush Anand pratyush.an...@st.com
+Description:
+ Write 1 to this node to issue Reset for Link Layer Validation
+ device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index a51e7d6..6ef1f81 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -235,3 +235,9 @@ config USB_HSIC_USB3503
depends on I2C
help
This option enables support for SMSC USB3503 HSIC to USB 2.0 Driver.
+
+config USB_LINK_LAYER_TEST
+ tristate USB Link Layer Test driver
+ help
+ This driver is for generating specific traffic for Super Speed Link
+ Layer Test Device.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 3e1bd70..6995c82 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_USB_YUREX) += yurex.o
obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstestdev.o
diff --git a/drivers/usb/misc/lvstestdev.c b/drivers/usb/misc/lvstestdev.c
new file mode 100644
index 000..58027a6
--- /dev/null
+++ b/drivers/usb/misc/lvstestdev.c
@@ -0,0 +1,171 @@
+/*
+ * drivers/usb/misc/lvstestdev.c
+ *
+ * Test pattern generation for Link Layer Validation System Tests
+ *
+ * Copyright (C) 2014 ST Microelectronics
+ * Pratyush Anand pratyush.an...@st.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/usb.h
+#include linux/usb/ch11.h
+
+static ssize_t issue_hot_reset(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct usb_device **pudev = dev_get_platdata(dev);
+ struct usb_device *udev = *pudev;
+ unsigned long val = simple_strtoul(buf, NULL, 10);
+ int ret;
+
+ if (val != 1)
+ return -EINVAL;
+
+ ret = usb_control_msg(udev-parent, usb_sndctrlpipe(udev-parent, 0),
+ USB_REQ_SET_FEATURE, USB_RT_PORT,
[RFC 1/2] USB: Core: Quirk to prevent enumeration of LVS devices
For an xhci host's downstream port, Link Validation System (LVS) is a
hardware which acts as device and used to run link layer tests. Most of
the link layer tests only expects link to be in U0. If a host sends a
setup packet, it is NAKed by LVS. However, there are some tests which
ask host to send some control command like Get Descriptor etc.
This patch adds a sysfs node to add a quirk flag to prevent enumeration
of a device, and then to call a driver for this device which can further
add options to generate test case specific traffic.
Without this patch many Lecroy Link Layer tests such as TD.7.02 fail.
Before a lecroy LVS device is connected to the root hub n, do following:
echo 1 /sys/bus/usb/devices/usbn/avoid_enum_quirk
Now connect LVS device and run Link Layer tests from Lecroy USB
Compliance Suite.
To get back into normal working situation (to connect a general usb device
to root hub n), do following:
echo 0 /sys/bus/usb/devices/usbn/avoid_enum_quirk
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/ABI/testing/sysfs-bus-usb | 10 +++
drivers/usb/core/hub.c | 105 +++-
drivers/usb/core/hub.h | 2 +
drivers/usb/core/sysfs.c| 34 +++
drivers/usb/core/usb.c | 1 -
include/linux/usb/quirks.h | 3 +
6 files changed, 151 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-usb
b/Documentation/ABI/testing/sysfs-bus-usb
index f093e59..d7f6bfd 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -236,3 +236,13 @@ Description:
This attribute is to expose these information to user space.
The file will read hotplug, wired and not used if the
information is available, and unknown otherwise.
+
+What: /sys/bus/usb/device/.../avoid_enum_quirk
+Date: March 2014
+Contact: Pratyush Anand pratyush.an...@st.com
+Description:
+ Only root hub allows to write. Writing to
+ other device will return error. Writing 1 to this file tells the
+ kernel that device connected to this root hub must not
+ be enumerated. Ports of this root hub will be used to
+ conncet Link Layer Validation System device.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5edcfb2..124b5c8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -27,6 +27,7 @@
#include linux/freezer.h
#include linux/random.h
#include linux/pm_qos.h
+#include linux/platform_device.h
#include asm/uaccess.h
#include asm/byteorder.h
@@ -4656,6 +4657,98 @@ static int hub_handle_remote_wakeup(struct usb_hub *hub,
unsigned int port,
return connect_change;
}
+static void usb_destroy_lvs_device(struct usb_hub *hub, int port1)
+{
+ struct usb_device *hdev = hub-hdev;
+ struct platform_device *lvstestdev = hub-ports[port1 -1]-lvstestdev;
+ struct usb_device *udev = hub-ports[port1 - 1]-child;
+
+ if (!lvstestdev) {
+ dev_err(hdev-dev, No Platform device at port %d\n, port1);
+ return;
+ }
+
+ platform_device_unregister(lvstestdev);
+
+ kfree(udev);
+
+ hub-ports[port1 -1]-child = NULL;
+ hub-ports[port1 -1]-lvstestdev = NULL;
+ dev_info(hdev-dev, LVS device destroyed\n);
+}
+
+static int usb_create_lvs_device(struct usb_hub *hub, int port1)
+{
+ struct usb_device *hdev = hub-hdev;
+ struct usb_device *udev;
+ struct platform_device *lvstestdev = hub-ports[port1 -1]-lvstestdev;
+ int ret;
+
+ if (lvstestdev) {
+ dev_err(hdev-dev,
+ Already a platform device at port %d\n, port1);
+ usb_destroy_lvs_device(hub, port1);
+ }
+
+ udev = usb_alloc_dev(hdev, hdev-bus, port1);
+ if (!udev) {
+ dev_err (hdev-dev, couldn't allocate port %d usb_device\n,
+ port1);
+ return -ENOMEM;
+ }
+
+ if (hub_is_superspeed(hdev)) {
+ udev-speed = USB_SPEED_SUPER;
+ udev-ep0.desc.wMaxPacketSize = cpu_to_le16(512);
+ usb_set_device_state(udev, USB_STATE_DEFAULT);
+ ret = hub_enable_device(udev);
+ if (ret 0) {
+ dev_err(hdev-dev, Failed to enable %d\n, ret);
+ goto free_udev;
+ }
+ } else {
+ dev_err(hdev-dev, Host not supported\n);
+ ret = -EINVAL;
+ goto free_udev;
+ }
+
+ lvstestdev = platform_device_alloc(lvstestdev, PLATFORM_DEVID_AUTO);
+ if (!lvstestdev) {
+ dev_err(hdev-dev, couldn't allocate lvstestdev device\n);
+ ret = -ENOMEM;
+ goto free_udev;
+ }
+
+ /*
+* udev will be
RE: i.MX51 ChipIdea USB device endpoints questions
Peter, Thanks for your response. I understand that currently for the i.MX51 in the ChipIdea drivers that the DEN value is 8 which results in defining endpoints ep[0-7]in and ep[0-7]out. I am looking to develop a piece of automated test equipment and drivers that emulates an existing device which has the following endpoints: ep0in - control ep0out - control ep3out - bulk ep3in - bulk ep4in - interrupt ep1out - bulk ep1in - bulk ep5out - bulk ep5in - bulk ep6in - interrupt ep9out - bulk ep9in - bulk ep10in - interrupt Thus the number of endpoints is not a problem, but I'm thinking that having ep9out, ep9in, and ep10in would not work (they are not defined). For instance if I want to write a user space gadget driver on top of gadgetfs, these endpoints will not even be present for use. Only endpoints ep[0-7]in and ep[0-7]out are accessible via gadgetfs. So are you saying that I could open up ep2in and ep2out which are not used to act as ep9in and ep9out for instance where ep2 is the physical endpoint, but I initialize it like ep9? Will that work? Can you explain this further? Do you mean at init I could set up the endpoint address to be 9, but use physical endpoint 2 and that should work? Thanks, Dave -Original Message- From: Peter Chen [mailto:peter.c...@freescale.com] Sent: Thursday, April 10, 2014 9:43 PM To: Ebright, Dave Cc: linux-usb@vger.kernel.org Subject: Re: i.MX51 ChipIdea USB device endpoints questions On Thu, Apr 10, 2014 at 07:08:22PM +, Ebright, Dave wrote: Hi Peter, I’m not sure what mailing list to post this to, but maybe you know… Linux usb mail list is the best place to ask linux usb questions. I am looking at the i.MX51 USB device functionality for a project I am working on and in the DCCPARAMS register (read only) there is the DEN field which defines the number of endpoints built into the device controller. For the i.MX51 when the register is read the DEN is set to 8. Valid values for this field are 0-16. My first question is do you know of any way of increasing this value? I don’t believe it can be based on the following from the i.MX51 reference manual: “The ARC USB-HS OTG High-Speed USB On-The-Go device controller hardware supports up to the USB 2.0 maximum of 32 endpoint specified numbers. Each additional endpoint beyond the required endpoint position adds additional hardware logic. The maximum number of endpoint numbers available to the DCD is configured at hardware synthesis timer. After synthesis, the DCD can enable, disable and configure endpoint type up to the maximum selected during synthesis.” Does synthesis mean when the processor chip is created or does it mean when the chip first starts up HW senses what the value should be? When the IC guys begin to integrate usb ip, the endpoint number can be changed, but once the chip has finished, this number can't be changed. Any idea if it would work to just over-ride the ci-hw_ep_map value set in hw_device_init()? Not sure what the synthesis does? The ChipIdea register set is still the same, but I assume the functionality is somehow limited in the core? Yes, this value is fixed for certain chipidea IP usb controller. If the number of endpoints cannot be increased, would it be possible to map an unused endpoint number to a higher endpoint number. For example let’s say I want my device to use endpoint 9, but endpoint 9 is not defined due to the DEN value of 8. Endpoint 7 exists and is not being used. Would it be possible to customize the chipidea drivers to map endpoint 9 to use endpoint 7 for a custom application or does the USB OTG chipidea core perform HW controlled endpoint addressing (HW looks at endpoint and sends data to the appropriate endpoint queue independent of the driver)? If endpoint number is 8, for chipidea udc driver, the ci_hw_ep[0..7] is the physical RX endpoint 0-7, , the name is ep[0..7]out, the ci_hw_ep[8..15] is the physical TX endpoint 0-7, the name is ep[0..7]in. What's the reason you want to customize endpoint number? Currently, it will allocate the smallest un-used endpoint number for application. -- Best Regards, Peter Chen
Re: Deadlock v3.10.35 with FTD_SIO usb-serial adapter
On Fri, Apr 11, 2014 at 12:19:55PM +0200, Matteo Fortini wrote: We are experiencing stuck processes (D state) which are talking to an FTD_SIO usb_serial adapter. The process sometimes has to close the serial device when it detects an error or a timeout. Does this also happen with 3.14? 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] [media] Prefer gspca_sonixb over sn9c102 for all devices
On Fri, Apr 11, 2014 at 09:15:32AM +0200, Jean Delvare wrote: The sn9c102 driver is deprecated. It was moved to staging in anticipation of its removal in a future kernel version. However, USB devices 0C45:6024 and 0C45:6025 are still handled by sn9c102 when both sn9c102 and gspca_sonixb are enabled. We must migrate all the users of these devices to the gspca_sonixb driver now, so that it gets sufficient testing before the sn9c102 driver is finally phased out. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Hans de Goede hdego...@redhat.com Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: Luca Risolia luca.riso...@studio.unibo.it Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- I consider this a bug fix, I believe it should go upstream ASAP. Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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: libusbg and vbus detection for UDC driver
Hey, Nice to know that someone else is also interested in usage of libusbg library:) -Original Message- From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- ow...@vger.kernel.org] On Behalf Of Matt Porter Sent: Thursday, April 10, 2014 11:14 PM To: Philippe De Swert Cc: linux-usb@vger.kernel.org Subject: Re: libusbg and vbus detection for UDC driver On Thu, Apr 10, 2014 at 11:24:49PM +0300, Philippe De Swert wrote: Hi all, On first sight it seems that the two things in the subject have nothing to do with each other, so I will quickly explain why they do (at least for me). So for some time already I have been working on usb_moded, which is a small daemon which handles setting up gadget drivers, so that a device can offer several different levels of functionality (for this it is also capable of setting up network and start/stop services over dbus/systemd/upstart when needed) Now I would like to add support for the new gadgetfs. And there I run into two issues. I looked into code of usb_moded (just looked, didn't read the whole code). I found it really interesting, a lot of work has been done. Good to know that someone is also working with userspace usb gadget:) We are also working on such daemon and we found libusbg suitable for it. Usb_moded does quite a lot of things I see. We also considered such approach but we found out that this will not be suitable for us because things like setting network interfaces or other should be done by specialized daemons (like connman). We try to make a demon which will be as much generic as possible. We have chosen a design in which gadgetd (our daemon, will be open-sourced shortly;) ) does only required things connected directly with usb. So it should be a simple daemon which will only get messages via dbus or other IPC's and execute (with some policy like pollkit or sth) demands from user apps (for example settings). Things like setting network interface or ssh we would like to export from our daemon because they are not directly connected with usb. When I'm talking about demands I think about some gadget settings or loading created before gadget. Our goal is to provide support for functionFS, so applications will only select which function to use and if some instance of ffs has been chosen the daemon will take care of all required things before enabling gadget (mount ffs etc.). Maybe it would be beneficial to get into cooperation? What do you think about such approach? How your daemon integrate with whole system environment and policy? 1. It seems that libusbg from Matt Porter seems the library to use. Is that correct? I saw patches on the mailing list, but they did not seem to have made it to: https://github.com/libusbg/libusbg I think it's the right choice. :) As of last week, all but the latest two series that have been posted have been merged to master as I work through some backlog in my copious spare time. @Matt Not all changes has been merged. Remove gadget functionality which I have fixed according to your remarks last week is still waiting for merge both on the list and in pull request on github. -- BR's Krzysztof Opasiak -- 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: libusbg and vbus detection for UDC driver
On Fri, Apr 11, 2014 at 06:20:42PM +0200, Krzysztof Opasiak wrote: 1. It seems that libusbg from Matt Porter seems the library to use. Is that correct? I saw patches on the mailing list, but they did not seem to have made it to: https://github.com/libusbg/libusbg I think it's the right choice. :) As of last week, all but the latest two series that have been posted have been merged to master as I work through some backlog in my copious spare time. @Matt Not all changes has been merged. Remove gadget functionality which I have fixed according to your remarks last week is still waiting for merge both on the list and in pull request on github. Yes, I plan to get to that within the day. Regards, Matt -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/4] dwc3: host: Set xhci quirk for LPM if a platform supports it
On Fri, Apr 11, 2014 at 03:50:04PM +0530, Pratyush Anand wrote:
If a platform supports LPM then enable quirk in XHCI for the same.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/core.c | 1 +
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/host.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 358375e..119dea3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -490,6 +490,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
+ dwc-lpm_capable = of_property_read_bool(node, lpm-capable);
if we really don't have any way of detecting in runtime this feature, we
*must* give platform_data the same support.
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 27dad99..f7bf6da 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -725,6 +725,7 @@ struct dwc3 {
unsignedsetup_packet_pending:1;
unsigneddelayed_status:1;
unsignedneeds_fifo_resize:1;
+ unsignedlpm_capable:1;
missing documentation!!!
--
balbi
signature.asc
Description: Digital signature
Re: [RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable
On Fri, Apr 11, 2014 at 03:50:03PM +0530, Pratyush Anand wrote:
If a dwc3 host implementation is lpm capable then enable lpm_capable in
device tree.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..a7a48f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - lpm-capable: determines if xhci host is lpm capable
This is usually a subnode to DWC3 glue to which it is connected.
@@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
+ lpm-capable;
I think there's a way to detect this in runtime but I can't seem to find
it on databook. Perhaps check with your IP designer/integrator which
HWPARAMS register we can poke to verify core was configured with LPM ?
Another is to ask Paul :-)
Hey Paul, do you know if there's a way to detect in runtime if $this
dwc3 implementation was configured with LPM enabled ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv5 2/4] usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
On Fri, Mar 14, 2014 at 01:51:50PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Moves the s3c-hsotg driver into the dwc2 folder and use the dwc2 defines in hw.h. Renamed the s3c-hsotg.c to gadget.c. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com --- v5: none v4: none v3: - Renamed s3c-hsotg to dwc2/gadget - Remove the edits to the Kconfig and Makefile as that will be in a separate patch for v4. v2: - Fix whitespace damage - Redo s3c_hsotg_handle_rx() to use dwc2 definitions - Use FIFOSIZE_DEPTH_GET --- For gadget part: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCHv5 3/4] usb: s3c-hsotg: Move s3c-hsotg data structures
On Fri, Mar 14, 2014 at 01:51:51PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com This patch moves the data structures that are in the s3c-hsotg source into core.h. This is a necessary step towards unifying the s3c-hsotg and dwc2 into a single DRD. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com --- v5: none v4: none v3: none v2: none --- drivers/usb/dwc2/core.h | 182 + drivers/usb/dwc2/gadget.c | 180 +--- for gadget: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [RFC 3/4] xhci: A default implementation for Ux timeout calculation and tier policy check
On Fri, Apr 11, 2014 at 03:50:05PM +0530, Pratyush Anand wrote:
As best case, a host controller should support U0 to U1 switching for
the devices connected below any tier of hub level supported by usb
specification. Therefore xhci_check_default_tier_policy always returns
success.
A host should be able to issue LGO_Ux after the timeout calculated as
per definition of system exit latency defined in C.1.5.2. Therefore
xhci_calculate_default_ux_timeout returns ux_params.sel as the default
implementation.
Use default calculation in absence of any vendor specific limitations.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/host/xhci.c | 61
+
1 file changed, 61 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6cc58fe..930c01f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4140,6 +4140,53 @@ static u16 xhci_get_timeout_no_hub_lpm(struct
usb_device *udev,
return USB3_LPM_DISABLED;
}
+/* Returns the default hub-encoded U1 timeout value.
+ */
fits in one line
+static u16 xhci_calculate_default_u1_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u1_params.sel;
+
+ /* The U1 timeout is encoded in 1us intervals. */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
+ /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
+ if (timeout_ns == USB3_LPM_DISABLED)
will this *ever* happen ? you're using DIV_ROUND_UP...
+ timeout_ns++;
+
+ /* If the necessary timeout value is bigger than what we can set in the
+ * USB 3.0 hub, we have to disable hub-initiated U1.
+ */
+ if (timeout_ns = USB3_LPM_U1_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U1 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
+}
+
+/* Returns the default hub-encoded U2 timeout value.
+ */
+static u16 xhci_calculate_default_u2_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u2_params.sel;
+
+ /* The U2 timeout is encoded in 256us intervals */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
+ /* If the necessary timeout value is bigger than what we can set in the
+ * USB 3.0 hub, we have to disable hub-initiated U2.
+ */
+ if (timeout_ns = USB3_LPM_U2_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U2 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U2);
this function is mostly duplicated with default_u1, perhaps refactor it
a bit and pass one extra argument which will tell you if you're
calculating U1 or U2 ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv5 4/4] usb: dwc2: Edit the Kconfig and Makefile to build dwc2_gadget driver
On Fri, Mar 14, 2014 at 01:51:52PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Modify the dwc2 Kconfig and Makefile so that it will build the dwc2_gadget driver when peripheral only mode is selected. The dwc_platform.ko and dwc2.ko will get built when dynamic linked modules are selected for Host mode. For peripheral mode only dwc2_gadget.ko will get built. NOTE: You can build both host and peripheral as a dynamically linked module, but be aware that if you insmod dwc2_gadget, then rmmod it, then insmod dwc2 and dwc2_platform for host mode, this will not work. As the step to rmmod dwc2_gadget.ko will turn off the clock to the USB IP. The dwc2 host driver currently does not look to turn on a clock yet. A patch to fix that will be coming soon. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable
On Fri, Apr 11, 2014 at 11:24 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Apr 11, 2014 at 03:50:03PM +0530, Pratyush Anand wrote:
If a dwc3 host implementation is lpm capable then enable lpm_capable in
device tree.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..a7a48f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - lpm-capable: determines if xhci host is lpm capable
This is usually a subnode to DWC3 glue to which it is connected.
@@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
+ lpm-capable;
I think there's a way to detect this in runtime but I can't seem to find
it on databook. Perhaps check with your IP designer/integrator which
HWPARAMS register we can poke to verify core was configured with LPM ?
I too tried to look into databook first, But could not find. Lets see, what Paul
says.
Pratyush
Another is to ask Paul :-)
Hey Paul, do you know if there's a way to detect in runtime if $this
dwc3 implementation was configured with LPM enabled ?
--
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: [PATCHv5 2/4] usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
On Fri, Apr 11, 2014 at 01:01:31PM -0500, Felipe Balbi wrote: On Fri, Mar 14, 2014 at 01:51:50PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Moves the s3c-hsotg driver into the dwc2 folder and use the dwc2 defines in hw.h. Renamed the s3c-hsotg.c to gadget.c. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com --- v5: none v4: none v3: - Renamed s3c-hsotg to dwc2/gadget - Remove the edits to the Kconfig and Makefile as that will be in a separate patch for v4. v2: - Fix whitespace damage - Redo s3c_hsotg_handle_rx() to use dwc2 definitions - Use FIFOSIZE_DEPTH_GET --- For gadget part: Acked-by: Felipe Balbi ba...@ti.com actually, scratch that. This patch adds a build error to the tree as it moves one file out of drivers/usb/gadget/ without removing Makefile/Kconfig rules first, so we will try to build a file that doesn't exist. NAK -- balbi signature.asc Description: Digital signature
Re: [RFC 2/4] dwc3: host: Set xhci quirk for LPM if a platform supports it
On Fri, Apr 11, 2014 at 11:26 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Apr 11, 2014 at 03:50:04PM +0530, Pratyush Anand wrote:
If a platform supports LPM then enable quirk in XHCI for the same.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/dwc3/core.c | 1 +
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/host.c | 2 ++
3 files changed, 4 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 358375e..119dea3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -490,6 +490,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
+ dwc-lpm_capable = of_property_read_bool(node, lpm-capable);
if we really don't have any way of detecting in runtime this feature, we
*must* give platform_data the same support.
OK.
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 27dad99..f7bf6da 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -725,6 +725,7 @@ struct dwc3 {
unsignedsetup_packet_pending:1;
unsigneddelayed_status:1;
unsignedneeds_fifo_resize:1;
+ unsignedlpm_capable:1;
missing documentation!!!
Will add.
Pratyush
--
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: [RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable
On Fri, Apr 11, 2014 at 11:36:18PM +0530, Pratyush Anand wrote:
On Fri, Apr 11, 2014 at 11:24 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Apr 11, 2014 at 03:50:03PM +0530, Pratyush Anand wrote:
If a dwc3 host implementation is lpm capable then enable lpm_capable in
device tree.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..a7a48f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - lpm-capable: determines if xhci host is lpm capable
This is usually a subnode to DWC3 glue to which it is connected.
@@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
+ lpm-capable;
I think there's a way to detect this in runtime but I can't seem to find
it on databook. Perhaps check with your IP designer/integrator which
HWPARAMS register we can poke to verify core was configured with LPM ?
I too tried to look into databook first, But could not find. Lets see,
what Paul says.
I found a few mentions of if HW LPM is enabled which hints that there
is a way to enable/disable LPM in coreConsultant and I find it weird
that Synopsys didn't add such flag to HWPARAMS*.
Anyway, Paul to the rescue :-)
--
balbi
signature.asc
Description: Digital signature
RE: [RFC 1/4] dwc3: dts: Binding information for an optional property lpm_capable
From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
Sent: Friday, April 11, 2014 11:06 AM
On Fri, Apr 11, 2014 at 11:24 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Apr 11, 2014 at 03:50:03PM +0530, Pratyush Anand wrote:
If a dwc3 host implementation is lpm capable then enable lpm_capable in
device tree.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..a7a48f1 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,6 +10,7 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - lpm-capable: determines if xhci host is lpm capable
This is usually a subnode to DWC3 glue to which it is connected.
@@ -19,4 +20,5 @@ dwc3@4a03 {
interrupts = 0 92 4
usb-phy = usb2_phy, usb3,phy;
tx-fifo-resize;
+ lpm-capable;
I think there's a way to detect this in runtime but I can't seem to find
it on databook. Perhaps check with your IP designer/integrator which
HWPARAMS register we can poke to verify core was configured with LPM ?
I too tried to look into databook first, But could not find. Lets see, what
Paul
says.
Hi guys,
The Power Management section of the databook talks about hardware-
controlled LPM. It's section 12.4 in the latest databook. LPM is a
standard xHCI feature, so you can look at the xHCI spec to find the
info about it.
In the xHCI spec, section 4.23.5.1.1 USB2 LPM Support says this:
This section applies only if a USB2 xHCI Supported Protocol Capability
structure (section 7.2) is declared (i.e. the Major Revision field = 02h).
And if you look at section 7.2.2.1.3.2 USB2, it shows that bit 19 in
the Protocol Defined field of the USB2 xHCI Supported Protocol Capability
structure indicates whether the controller supports hardware-controlled
LPM.
--
Paul
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/4] xhci: A default implementation for Ux timeout calculation and tier policy check
On Fri, Apr 11, 2014 at 11:29 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Apr 11, 2014 at 03:50:05PM +0530, Pratyush Anand wrote:
As best case, a host controller should support U0 to U1 switching for
the devices connected below any tier of hub level supported by usb
specification. Therefore xhci_check_default_tier_policy always returns
success.
A host should be able to issue LGO_Ux after the timeout calculated as
per definition of system exit latency defined in C.1.5.2. Therefore
xhci_calculate_default_ux_timeout returns ux_params.sel as the default
implementation.
Use default calculation in absence of any vendor specific limitations.
Signed-off-by: Pratyush Anand pratyush.an...@st.com
---
drivers/usb/host/xhci.c | 61
+
1 file changed, 61 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6cc58fe..930c01f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4140,6 +4140,53 @@ static u16 xhci_get_timeout_no_hub_lpm(struct
usb_device *udev,
return USB3_LPM_DISABLED;
}
+/* Returns the default hub-encoded U1 timeout value.
+ */
fits in one line
Ok.
+static u16 xhci_calculate_default_u1_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u1_params.sel;
+
+ /* The U1 timeout is encoded in 1us intervals. */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
+ /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
+ if (timeout_ns == USB3_LPM_DISABLED)
will this *ever* happen ? you're using DIV_ROUND_UP...
Only when timeout_ns was zero before DIV_* operation.
+ timeout_ns++;
+
+ /* If the necessary timeout value is bigger than what we can set in the
+ * USB 3.0 hub, we have to disable hub-initiated U1.
+ */
+ if (timeout_ns = USB3_LPM_U1_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U1 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
+}
+
+/* Returns the default hub-encoded U2 timeout value.
+ */
+static u16 xhci_calculate_default_u2_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u2_params.sel;
+
+ /* The U2 timeout is encoded in 256us intervals */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
+ /* If the necessary timeout value is bigger than what we can set in the
+ * USB 3.0 hub, we have to disable hub-initiated U2.
+ */
+ if (timeout_ns = USB3_LPM_U2_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U2 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U2);
this function is mostly duplicated with default_u1, perhaps refactor it
a bit and pass one extra argument which will tell you if you're
calculating U1 or U2 ?
Can be done.
Will wait for Mathias comments and then will send another version.
Pratyush
--
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: [PATCHv5 2/4] usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, April 11, 2014 11:04 AM On Fri, Apr 11, 2014 at 01:01:31PM -0500, Felipe Balbi wrote: On Fri, Mar 14, 2014 at 01:51:50PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Moves the s3c-hsotg driver into the dwc2 folder and use the dwc2 defines in hw.h. Renamed the s3c-hsotg.c to gadget.c. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com --- v5: none v4: none v3: - Renamed s3c-hsotg to dwc2/gadget - Remove the edits to the Kconfig and Makefile as that will be in a separate patch for v4. v2: - Fix whitespace damage - Redo s3c_hsotg_handle_rx() to use dwc2 definitions - Use FIFOSIZE_DEPTH_GET --- For gadget part: Acked-by: Felipe Balbi ba...@ti.com actually, scratch that. This patch adds a build error to the tree as it moves one file out of drivers/usb/gadget/ without removing Makefile/Kconfig rules first, so we will try to build a file that doesn't exist. NAK Right you are. I'll fix that up before I send this series to Greg. -- Paul -- 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: [PATCHv5 2/4] usb: s3c-hsotg: Move s3c-hsotg into dwc2 folder
On Fri, Apr 11, 2014 at 06:40:36PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, April 11, 2014 11:04 AM On Fri, Apr 11, 2014 at 01:01:31PM -0500, Felipe Balbi wrote: On Fri, Mar 14, 2014 at 01:51:50PM -0500, dingu...@altera.com wrote: From: Dinh Nguyen dingu...@altera.com Moves the s3c-hsotg driver into the dwc2 folder and use the dwc2 defines in hw.h. Renamed the s3c-hsotg.c to gadget.c. Signed-off-by: Dinh Nguyen dingu...@altera.com Tested-by: Jingoo Han jg1@samsung.com Tested-by: Paul Zimmerman pa...@synopsys.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Felipe Balbi ba...@ti.com Cc: Ben Dooks ben-li...@fluff.org Cc: Matt Porter mpor...@linaro.org Cc: Kukjin Kim kgene@samsung.com Cc: Stephen Warren swar...@wwwdotorg.org Cc: Matthijs Kooijman matth...@stdin.nl Cc: Sachin Kamat sachin.ka...@linaro.org Cc: Robert Baldyga r.bald...@samsung.com Cc: Federico Vaga federico.v...@gmail.com --- v5: none v4: none v3: - Renamed s3c-hsotg to dwc2/gadget - Remove the edits to the Kconfig and Makefile as that will be in a separate patch for v4. v2: - Fix whitespace damage - Redo s3c_hsotg_handle_rx() to use dwc2 definitions - Use FIFOSIZE_DEPTH_GET --- For gadget part: Acked-by: Felipe Balbi ba...@ti.com actually, scratch that. This patch adds a build error to the tree as it moves one file out of drivers/usb/gadget/ without removing Makefile/Kconfig rules first, so we will try to build a file that doesn't exist. NAK Right you are. I'll fix that up before I send this series to Greg. alright thanks. Can you make sure to Cc me just so I can give you my Acked-by later ? Thank you -- balbi signature.asc Description: Digital signature
Re: [RFC 3/4] xhci: A default implementation for Ux timeout calculation and tier policy check
Hi,
On Sat, Apr 12, 2014 at 12:04:27AM +0530, Pratyush Anand wrote:
+static u16 xhci_calculate_default_u1_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u1_params.sel;
+
+ /* The U1 timeout is encoded in 1us intervals. */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
+ /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED.
*/
+ if (timeout_ns == USB3_LPM_DISABLED)
will this *ever* happen ? you're using DIV_ROUND_UP...
Only when timeout_ns was zero before DIV_* operation.
but then I guess it's cheaper to just return 1 in that case and avoid
doing a division at all:
if (timeout_ns == 0)
return 1;
+ timeout_ns++;
+
+ /* If the necessary timeout value is bigger than what we can set in
the
+ * USB 3.0 hub, we have to disable hub-initiated U1.
+ */
+ if (timeout_ns = USB3_LPM_U1_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U1 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
+}
+
+/* Returns the default hub-encoded U2 timeout value.
+ */
+static u16 xhci_calculate_default_u2_timeout(struct usb_device *udev,
+ struct usb_endpoint_descriptor *desc)
+{
+ unsigned long long timeout_ns;
+
+ timeout_ns = udev-u2_params.sel;
+
+ /* The U2 timeout is encoded in 256us intervals */
+ timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
+ /* If the necessary timeout value is bigger than what we can set in
the
+ * USB 3.0 hub, we have to disable hub-initiated U2.
+ */
+ if (timeout_ns = USB3_LPM_U2_MAX_TIMEOUT)
+ return timeout_ns;
+ dev_dbg(udev-dev, Hub-initiated U2 disabled
+ due to long timeout %llu ms\n, timeout_ns);
+ return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U2);
this function is mostly duplicated with default_u1, perhaps refactor it
a bit and pass one extra argument which will tell you if you're
calculating U1 or U2 ?
Can be done.
Will wait for Mathias comments and then will send another version.
alright.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] Fix USB deadlock caused by SCSI error handling
I did set the scsi_logging_level as you wrote, but it still resulted into exactly the same dmesg (resp. sudo journalctl -b 0) output with the entire patchset (including the scmd-eh_eflags = 0;). Except for the reverted do nothings, for course. However, I did miss to mention the following which is printed once with or without the scsi_logging_level change: [16254.735372] sd 9:0:0:0: Device offlined - not ready after error recovery [16254.735393] sd 9:0:0:0: rejecting I/O to offline device [16254.735397] sd 9:0:0:0: [sdf] killing request [16254.735488] sd 9:0:0:0: [sdf] Unhandled error code [16254.735489] sd 9:0:0:0: [sdf] [16254.735490] Result: hostbyte=0x01 driverbyte=0x00 [16254.735492] sd 9:0:0:0: [sdf] CDB: [16254.735493] cdb[0]=0x2a: 2a 00 03 1c 10 f8 00 00 f0 00 [16254.735498] end_request: I/O error, dev sdf, sector 52171000 Another: [19389.907015] sd 11:0:0:0: Device offlined - not ready after error recovery [19389.907037] sd 11:0:0:0: [sdf] Unhandled error code [19389.907044] sd 11:0:0:0: [sdf] [19389.907049] Result: hostbyte=0x05 driverbyte=0x00 [19389.907055] sd 11:0:0:0: [sdf] CDB: [19389.907060] cdb[0]=0x28: 28 00 03 13 0d 28 00 00 08 00 [19389.907083] end_request: I/O error, dev sdf, sector 51580200 [19389.907121] sd 11:0:0:0: rejecting I/O to offline device [19389.907126] sd 11:0:0:0: killing request In case it matters, the stick's partition stays readable with regard to any data on it that has been cached. On 10.04.2014 13:37, Hannes Reinecke wrote: Andreas, can you test with the entire patch series and enable 'scsi_logging_level -s -E 5' prior to running the tests? -- 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: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate()
If acm_submit_read_urbs() fails in acm_port_activate(), error handling
code calls usb_autopm_put_interface() while it is already called
before acm_submit_read_urbs(). The patch reorganizes error handling code
to avoid double decrement of USB interface's PM-usage counter.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/usb/class/cdc-acm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff805ee..d5d2c922186a 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -518,13 +518,16 @@ static int acm_port_activate(struct tty_port *port,
struct tty_struct *tty)
if (usb_submit_urb(acm-ctrlurb, GFP_KERNEL)) {
dev_err(acm-control-dev,
%s - usb_submit_urb(ctrl irq) failed\n, __func__);
+ usb_autopm_put_interface(acm-control);
goto error_submit_urb;
}
acm-ctrlout = ACM_CTRL_DTR | ACM_CTRL_RTS;
if (acm_set_control(acm, acm-ctrlout) 0
- (acm-ctrl_caps USB_CDC_CAP_LINE))
+ (acm-ctrl_caps USB_CDC_CAP_LINE)) {
+ usb_autopm_put_interface(acm-control);
goto error_set_control;
+ }
usb_autopm_put_interface(acm-control);
@@ -549,7 +552,6 @@ error_submit_read_urbs:
error_set_control:
usb_kill_urb(acm-ctrlurb);
error_submit_urb:
- usb_autopm_put_interface(acm-control);
error_get_interface:
disconnected:
mutex_unlock(acm-mutex);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the DRD mode implementation of DWC3 driver]
Hi, On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote: Hi Balbi, At first, thank you to help give the response in patience. Hi, On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote: Glad to see the OTG mode is prepare to support in your dwc3-role-switch branch. But it is not fit for intel Merrfield/Moorfield platforms. :( that's not what I heard when I asked some friends to test that branch on different platforms. It's certainly not perfect yet and that's why the code isn't merged in mainline, but claiming that it's not fit for Merrifield/Moorfield is just a lie. Can I get your friends' email address if they are in Intel? I would like to You already have that. Just look at Cc list. contact them to make the branch work on my Merrifield/Moorefield board too. Currently I can't see any link change event with the branch. how did you test it ? According to [1] Merrifield won't work for more than 20s or so with v3.14 and, since there is no resolution on the thread, I assume today's mainline won't work either. Anyway, if you really did test, test again with enabling verbose debug on dwc3 and show me the logs, I'm interested in what the IP is doing. The reason is we implemented DRD mode instead of OTG mode. So the GCTL.PortCapDir will be set as 01 for host mode, and 10 for device mode. from a SW perspective there is *no* difference. The only reason for using PortCapDir is to cope with platforms which want to switch roles but have screwed up ID pin reporting. And since most of the platforms actually have tha problem, it's just easier to implement it that way. Ok. Just confirm with you that you think it's not a matter to use GCTL.PortCapDir or OCTL.PeriMode to switch role, right? As of today, I don't see a difference. Things *can* change though. We can find out more details about the HW which forces us to use one of the other. If no cable connected, we will trigger D0i3cold which will power gate every clock/power used by dwc3 controller. that's not in mainline though, why should I care ? Show me code adding support for D0i3cold for dwc3 then we can talk. Until then, I'll continue assuming there's no such PM state and continue with happy hacking sessions. And entering D0i3hot with hibernation mode when acting as host mode (micro A cable connected), also during device mode(micro B cable connected to PC host). Current driver also doesn't support any runtime PM, so why should I care about your out-of-tree changes ? If you have any code which is not in mainline and I change something in mainline you have to deal to with it, not me. Get it. So we can treat this solution is working w/o PM implementation so far. And maybe we need to re-design DRD/OTG when we consider to support PM, right? We probably don't need to redesign anything when adding PM. What we need is that when we start to add PM support to this driver, in case there is any regression, we find out why there is a regression. Then we solve it properly, after looking at logs and fully understanding what's breaking the driver. In any case, that's something that won't happen in mainline for at least a couple more major releases since there are still quite a few changes pending. I just cannot spend time imagining all twisted scenarios Vendors (including my employer, for that matter) want to support with whatever hacked up version of mainline drivers they might have. My plan is to *not* add a lot of PM support until I know all other features are functional. When I'm happy with those features and know they have been thoroughly tested on *all* users of dwc3 then we can all get together in a conference (maybe have a DWC3 mini-summit or whatever) and discuss how we're gonna implement PM *together*. Since the driver is used by many different vendors, it would be unfair for me to treat Intel (or any vendor, really) differently just because someone dropped me an email commenting about all the out-of-tree changes they have. Understand. What are the other features you mean that need thorough testing before adding PM support? DRD for one. Then there is a redesign of parts of the gadget API that I want to do before PM too. Then there is the whole Link Power Management (which has *nothing* to do with Linux PM - system or runtime; we can put the USB bus in low power mode even though we don't gate any of the USB IP's clocks or power rails). For ID/VBus detection, we are using PMIC to do detect. So we will also power gate the USB PHY for D0i3cold. yeah, everybody does that. Everybody I've seen so far have moved the analog comparators for VBUS and ID out of the PHY and into the PMIC. We even have a very nice framework to cope with that (see drivers/extcon/extcon-palmas.c for an example). Thanks for pointing it out. We will use it too. When we plug in micro A/B cable, the PMIC will report the
Re: [PATCH] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off
On Wed, Apr 09, 2014 at 05:24:45PM +0530, Vivek Gautam wrote:
Adding support to enable/disable VBUS hooked to a gpio
to enable vbus supply on the port.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Based on 'phy-exynos5-usbdrd' patches:
[PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
http://www.spinics.net/lists/linux-usb/msg105507.html
drivers/phy/phy-exynos5-usbdrd.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c
b/drivers/phy/phy-exynos5-usbdrd.c
index ff54a7c..5ca7485 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -18,6 +18,7 @@
#include linux/module.h
#include linux/of.h
#include linux/of_address.h
+#include linux/of_gpio.h
#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/mutex.h
@@ -176,6 +177,7 @@ struct exynos5_usbdrd_phy {
struct clk *ref_clk;
unsigned long ref_rate;
unsigned int refclk_reg;
+ int gpio;
};
#define to_usbdrd_phy(inst) \
@@ -460,6 +462,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
if (!IS_ERR(phy_drd-usb30_sclk))
clk_prepare_enable(phy_drd-usb30_sclk);
+ /* Toggle VBUS gpio - on */
+ gpio_set_value(phy_drd-gpio, 1);
It seems like you'd be better off using a regulator_enable() call for
this.
--
balbi
signature.asc
Description: Digital signature
[PATCH v4] Add support for using a MAX3421E chip as a host driver.
This is v4 of the patch. Compared to v3, the only changes are: - addition of a platform-data header file which allows a platform to define which general-purpose output pin controls Vbus (if any) - spi_wr_fifo/spi_rd_fifo got renamed to spi_wr_buf/spi_rd_buf, respectively, since that more accurately reflects their function (whether or not a FIFO is being written depends on the register number). Signed-off-by: David Mosberger dav...@egauge.net --- drivers/usb/Makefile |1 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/max3421-hcd.c| 1937 + include/linux/platform_data/max3421-hcd.h | 23 + 5 files changed, 1973 insertions(+) create mode 100644 drivers/usb/host/max3421-hcd.c create mode 100644 include/linux/platform_data/max3421-hcd.h diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index 1ae2bf3..9bb6721 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -28,6 +28,7 @@ obj-$(CONFIG_USB_IMX21_HCD) += host/ obj-$(CONFIG_USB_FSL_MPH_DR_OF)+= host/ obj-$(CONFIG_USB_FUSBH200_HCD) += host/ obj-$(CONFIG_USB_FOTG210_HCD) += host/ +obj-$(CONFIG_USB_MAX3421_HCD) += host/ obj-$(CONFIG_USB_C67X00_HCD) += c67x00/ diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 3d9e540..e9cd7d8 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -343,6 +343,17 @@ config USB_FOTG210_HCD To compile this driver as a module, choose M here: the module will be called fotg210-hcd. +config USB_MAX3421_HCD + tristate MAX3421 HCD (USB-over-SPI) support + depends on USB + ---help--- + The Maxim MAX3421E chip supports standard USB 2.0-compliant + full-speed devices either in host or peripheral mode. This + driver supports the host-mode of the MAX3421E only. + + To compile this driver as a module, choose M here: the module will + be called max3421-hcd. + config USB_OHCI_HCD tristate OHCI HCD (USB 1.1) support select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index 7530468..ea2bec5 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -70,3 +70,4 @@ obj-$(CONFIG_USB_HCD_BCMA)+= bcma-hcd.o obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o obj-$(CONFIG_USB_FOTG210_HCD) += fotg210-hcd.o +obj-$(CONFIG_USB_MAX3421_HCD) += max3421-hcd.o diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c new file mode 100644 index 000..fe931ea --- /dev/null +++ b/drivers/usb/host/max3421-hcd.c @@ -0,0 +1,1937 @@ +/* + * MAX3421 Host Controller driver for USB. + * + * Author: David Mosberger-Tang dav...@egauge.net + * + * (C) Copyright 2014 David Mosberger-Tang dav...@egauge.net + * + * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host + * controller on a SPI bus. + * + * Based on: + * o MAX3421E datasheet + * http://datasheets.maximintegrated.com/en/ds/MAX3421E.pdf + * o MAX3421E Programming Guide + * http://www.hdl.co.jp/ftpdata/utl-001/AN3785.pdf + * o gadget/dummy_hcd.c + * For USB HCD implementation. + * o Arduino MAX3421 driver + * https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp + * + * This file is licenced under the GPL v2. + * + * Important note on worst-case (full-speed) packet size constraints + * (See USB 2.0 Section 5.6.3 and following): + * + * - control:64 bytes + * - isochronous: 1023 bytes + * - interrupt: 64 bytes + * - bulk: 64 bytes + * + * Since the MAX3421 FIFO size is 64 bytes, we do not have to work about + * multi-FIFO writes/reads for a single USB packet *except* for isochronous + * transfers. We don't support isochronous transfers at this time, so we + * just assume that a USB packet always fits into a single FIFO buffer. + * + * NOTE: The June 2006 version of MAX3421E Programming Guide + * (AN3785) has conflicting info for the RCVDAVIRQ bit: + * + * The description of RCVDAVIRQ says The CPU *must* clear + * this IRQ bit (by writing a 1 to it) before reading the + * RCVFIFO data. + * + * However, the earlier section on Programming BULK-IN + * Transfers says * that: + * + * After the CPU retrieves the data, it clears the + * RCVDAVIRQ bit. + * + * The December 2006 version has been corrected and it consistently + * states the second behavior is the correct one. + * + * Synchronous SPI transactions sleep so we can't perform any such + * transactions while holding a spin-lock (and/or while interrupts are + * masked). To achieve this, all SPI transactions are issued from a + * single thread (max3421_spi_thread). + */ + +#include linux/module.h +#include
