Re: imx27.dtsi usbotg/usbh2 oops in fsl_usb2_mph_dr_of_probe
Hi ,
please notice blow./
On Tuesday, October 29, 2013 09:06 AM, Chris Ruehl wrote:
Hi,
when tried to activate the USB-OTG or USBH2 with the FDT the system oops
[ 1.034403] ehci-mxc: Freescale On-Chip EHCI Host driver
[ 1.041158] Unable to handle kernel NULL pointer dereference at
virtual address
[ 1.049406] pgd = c0004000
[ 1.052219] [] *pgd=
[ 1.055868] Internal error: Oops: 5 [#1] ARM
[ 1.060167] Modules linked in:
[ 1.063287] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc7 #2
[ 1.069429] task: c7836000 ti: c783c000 task.ti: c783c000
[ 1.074888] PC is at fsl_usb2_mph_dr_of_probe+0x314/0x428
[ 1.080342] LR is at platform_device_alloc+0x5c/0x6c
[ 1.085362] pc : [] lr : [] psr: a013
[ 1.085362] sp : c783dd68 ip : fp : c783ddf4
[ 1.096888] r10: c7872500 r9 : c79ed600 r8 : 0002
[ 1.102154] r7 : c0564c40 r6 : r5 : c7873110 r4 : c7873100
[ 1.108722] r3 : r2 : r1 : r0 : c79ed600
[ 1.115291] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[ 1.122643] Control: 0005317f Table: a0004000 DAC: 0017
[ 1.128427] Process swapper (pid: 1, stack limit = 0xc783c1c0)
[ 1.134299] Stack: (0xc783dd68 to 0xc783e000)
[ 1.138718] dd60: c783dd94 c0564c40 c00dac3c 0001 0001
[ 1.146962] dd80:
0010
[ 1.155204] dda0:
[ 1.163452] ddc0: c783dde4 c7873110 c7873144
c0564c00 c058f0b0
[ 1.171703] dde0: c783c020 c783de04 c783ddf8 c021bde0
c028c0b0 c783de24 c783de08
[ 1.179953] de00: c021ab48 c021bdd4 c7873110 c7873144 c0564c00
c783de44 c783de28
[ 1.188204] de20: c021ad40 c021aaac c021acd0 c0564c00
c021acd0 c783de6c c783de48
[ 1.196457] de40: c02191c4 c021ace0 c7823f4c c786a450 c79f77b4
c0564c00 c055b2b0 c79f7780
[ 1.204709] de60: c783de7c c783de70 c021a6ac c0219158 c783dea4
c783de80 c021a23c c021a69c
[ 1.212962] de80: c04d71b6 c783de90 c0564c00 c053ae0c c0530264
c0572980 c783debc c783dea8
[ 1.221213] dea0: c021b384 c021a168 0006 c053ae0c c783decc
c783dec0 c021c3a8 c021b2f0
[ 1.229466] dec0: c783dedc c783ded0 c053027c c021c368 c783df54
c783dee0 c000888c c0530274
[ 1.237719] dee0: c00d2cb8 c00d29c8 c783df0c c783def8 c051b400
c01c8b84 c069ca87 c069ca8c
[ 1.245969] df00: c783df54 c783df10 c002c26c c051b4d8
c05198fc 0006 0006
[ 1.254219] df20: 0086 c051909c c00313d0 0006 0006
c053ae0c c053fb70 c0572980
[ 1.262469] df40: c0572980 0086 c783df94 c783df58 c051bb50
c0008804 0006 0006
[ 1.270717] df60: c051b4c8 c783df10 0001 01234567
c03f72fc
[ 1.278964] df80: c783dfac c783df98 c03f730c
c051ba60
[ 1.287212] dfa0: c783dfb0 c0009450 c03f730c
[ 1.295453] dfc0:
[ 1.303696] dfe0: 0013
[ 1.311897] Backtrace:
[ 1.314448] [] (fsl_usb2_mph_dr_of_probe+0x0/0x428) from
[] (platform_drv_probe+0x1c/0x20)
[ 1.324544] [] (platform_drv_probe+0x0/0x20) from
[] (driver_probe_device+0xac/0x1e8)
[ 1.334204] [] (driver_probe_device+0x0/0x1e8) from
[] (__driver_attach+0x70/0x94)
[ 1.343544] r7: r6:c0564c00 r5:c7873144 r4:c7873110
[ 1.349383] [] (__driver_attach+0x0/0x94) from []
(bus_for_each_dev+0x7c/0x90)
[ 1.358375] r6:c021acd0 r5:c0564c00 r4: r3:c021acd0
[ 1.364210] [] (bus_for_each_dev+0x0/0x90) from []
(driver_attach+0x20/0x28)
[ 1.373026] r6:c79f7780 r5:c055b2b0 r4:c0564c00
[ 1.377796] [] (driver_attach+0x0/0x28) from []
(bus_add_driver+0xe4/0x24c)
[ 1.386573] [] (bus_add_driver+0x0/0x24c) from []
(driver_register+0xa4/0xe8)
[ 1.395478] r7:c0572980 r6:c0530264 r5:c053ae0c r4:c0564c00
[ 1.401303] [] (driver_register+0x0/0xe8) from []
(__platform_driver_register+0x50/0x64)
[ 1.411163] r5:c053ae0c r4:0006
[ 1.414862] [] (__platform_driver_register+0x0/0x64) from
[] (fsl_usb2_mph_dr_driver_init+0x18/0x20)
[ 1.425812] [] (fsl_usb2_mph_dr_driver_init+0x0/0x20) from
[] (do_one_initcall+0x98/0x140)
[ 1.435889] [] (do_one_initcall+0x0/0x140) from []
(kernel_init_freeable+0x100/0x1c4)
[ 1.445488] r9:0086 r8:c0572980 r7:c0572980 r6:c053fb70 r5:c053ae0c
r4:0006
[ 1.453532] [] (kernel_init_freeable+0x0/0x1c4) from
[] (kernel_init+0x10/0xec)
[ 1.462610] r9: r8: r7: r6: r5:c03f72fc
r4:
[ 1.470645] [] (kernel_init+0x0/0xec) from []
(ret_from_fork+0x14/0x24)
[ 1.479027] r4: r3:
[ 1.482703] Code: e1c429d0 e1c929f0 e599c08c e594108c (e1c120d0)
[ 1.489025] ---[ end trace 1b9409ded9abd572 ]---
[ 1.493810] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
config: (imx27.dtsi)
usbotg: usb@10024000 {
compatible = "fsl-usb2-dr";
reg = <0
[PATCH net 1/3] r8152: fix tx/rx memory overflow
The tx/rx would access the memory which is out of the desired range.
Modify the method of checking the end of the memory to avoid it.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3fce41..5dbfe50 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
#include
/* Version Information */
-#define DRIVER_VERSION "v1.01.0 (2013/08/12)"
+#define DRIVER_VERSION "v1.02.0 (2013/10/28)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
#define DRIVER_DESC "Realtek RTL8152 Based USB 2.0 Ethernet Adapters"
#define MODULENAME "r8152"
@@ -1136,14 +1136,14 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
struct sk_buff *skb)
static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
{
- u32 remain;
+ int remain;
u8 *tx_data;
tx_data = agg->head;
agg->skb_num = agg->skb_len = 0;
- remain = rx_buf_sz - sizeof(struct tx_desc);
+ remain = rx_buf_sz;
- while (remain >= ETH_ZLEN) {
+ while (remain >= ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
struct sk_buff *skb;
unsigned int len;
@@ -1152,12 +1152,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
if (!skb)
break;
+ remain -= sizeof(*tx_desc);
len = skb->len;
if (remain < len) {
skb_queue_head(&tp->tx_queue, skb);
break;
}
+ tx_data = tx_agg_align(tx_data);
tx_desc = (struct tx_desc *)tx_data;
tx_data += sizeof(*tx_desc);
@@ -1167,9 +1169,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
agg->skb_len += len;
dev_kfree_skb_any(skb);
- tx_data = tx_agg_align(tx_data + len);
- remain = rx_buf_sz - sizeof(*tx_desc) -
-(u32)((void *)tx_data - agg->head);
+ tx_data += len;
+ remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
@@ -1188,7 +1189,6 @@ static void rx_bottom(struct r8152 *tp)
list_for_each_safe(cursor, next, &tp->rx_done) {
struct rx_desc *rx_desc;
struct rx_agg *agg;
- unsigned pkt_len;
int len_used = 0;
struct urb *urb;
u8 *rx_data;
@@ -1204,17 +1204,22 @@ static void rx_bottom(struct r8152 *tp)
rx_desc = agg->head;
rx_data = agg->head;
- pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
- while (urb->actual_length >= len_used) {
+ while (urb->actual_length > len_used) {
struct net_device *netdev = tp->netdev;
struct net_device_stats *stats;
+ unsigned pkt_len;
struct sk_buff *skb;
+ pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
if (pkt_len < ETH_ZLEN)
break;
+ len_used += pkt_len;
+ if (urb->actual_length < len_used)
+ break;
+
stats = rtl8152_get_stats(netdev);
pkt_len -= 4; /* CRC */
@@ -1234,9 +1239,8 @@ static void rx_bottom(struct r8152 *tp)
rx_data = rx_agg_align(rx_data + pkt_len + 4);
rx_desc = (struct rx_desc *)rx_data;
- pkt_len = le32_to_cpu(rx_desc->opts1) & RX_LEN_MASK;
len_used = (int)(rx_data - (u8 *)agg->head);
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
}
submit:
--
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
[PATCH net 3/3] r8152: fix incorrect type in assignment
Correct some declaration.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 1647931..b92b7f4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -309,22 +309,22 @@ enum rtl8152_flags {
#define MCU_TYPE_USB 0x
struct rx_desc {
- u32 opts1;
+ __le32 opts1;
#define RX_LEN_MASK0x7fff
- u32 opts2;
- u32 opts3;
- u32 opts4;
- u32 opts5;
- u32 opts6;
+ __le32 opts2;
+ __le32 opts3;
+ __le32 opts4;
+ __le32 opts5;
+ __le32 opts6;
};
struct tx_desc {
- u32 opts1;
+ __le32 opts1;
#define TX_FS (1 << 31) /* First segment of a packet */
#define TX_LS (1 << 30) /* Final segment of a packet */
#define TX_LEN_MASK0x3
- u32 opts2;
+ __le32 opts2;
#define UDP_CS (1 << 31) /* Calculate UDP/IP checksum */
#define TCP_CS (1 << 30) /* Calculate TCP/IP checksum */
#define IPV4_CS(1 << 29) /* Calculate IPv4 checksum */
@@ -878,7 +878,7 @@ static void write_bulk_callback(struct urb *urb)
static void intr_callback(struct urb *urb)
{
struct r8152 *tp;
- __u16 *d;
+ __le16 *d;
int status = urb->status;
int res;
--
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
[PATCH net 0/3] r8152 bug fixes
These could fix some driver issues. Hayes Wang (3): r8152: fix tx/rx memory overflow r8152: modify the tx flow r8152: fix incorrect type in assignment drivers/net/usb/r8152.c | 100 +--- 1 file changed, 36 insertions(+), 64 deletions(-) -- 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
[PATCH net 2/3] r8152: modify the tx flow
Let rtl8152_start_xmit() to queue packet only, and tx_bottom() would
send all of the packets. This simplify the code and make sure all the
packet would be sent by the original order.
Support stopping and waking tx queue. The maximum tx queue length
is 60.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 52 ++---
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5dbfe50..1647931 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -276,6 +276,8 @@ enum rtl_register_content {
#define INTR_LINK 0x0004
+#define TX_QLEN60
+
#define RTL8152_REQT_READ 0xc0
#define RTL8152_REQT_WRITE 0x40
#define RTL8152_REQ_GET_REGS 0x05
@@ -1173,6 +1175,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg->head);
}
+ if (netif_queue_stopped(tp->netdev))
+ netif_wake_queue(tp->netdev);
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
agg->head, (int)(tx_data - (u8 *)agg->head),
(usb_complete_t)write_bulk_callback, agg);
@@ -1388,53 +1393,16 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- struct net_device_stats *stats = rtl8152_get_stats(netdev);
- unsigned long flags;
- struct tx_agg *agg = NULL;
- struct tx_desc *tx_desc;
- unsigned int len;
- u8 *tx_data;
- int res;
skb_tx_timestamp(skb);
- /* If tx_queue is not empty, it means at least one previous packt */
- /* is waiting for sending. Don't send current one before it. */
- if (skb_queue_empty(&tp->tx_queue))
- agg = r8152_get_tx_agg(tp);
-
- if (!agg) {
- skb_queue_tail(&tp->tx_queue, skb);
- return NETDEV_TX_OK;
- }
+ skb_queue_tail(&tp->tx_queue, skb);
- tx_desc = (struct tx_desc *)agg->head;
- tx_data = agg->head + sizeof(*tx_desc);
- agg->skb_num = agg->skb_len = 0;
+ if (skb_queue_len(&tp->tx_queue) > TX_QLEN)
+ netif_stop_queue(netdev);
- len = skb->len;
- r8152_tx_csum(tp, tx_desc, skb);
- memcpy(tx_data, skb->data, len);
- dev_kfree_skb_any(skb);
- agg->skb_num++;
- agg->skb_len += len;
- usb_fill_bulk_urb(agg->urb, tp->udev, usb_sndbulkpipe(tp->udev, 2),
- agg->head, len + sizeof(*tx_desc),
- (usb_complete_t)write_bulk_callback, agg);
- res = usb_submit_urb(agg->urb, GFP_ATOMIC);
- if (res) {
- /* Can we get/handle EPIPE here? */
- if (res == -ENODEV) {
- netif_device_detach(tp->netdev);
- } else {
- netif_warn(tp, tx_err, netdev,
- "failed tx_urb %d\n", res);
- stats->tx_dropped++;
- spin_lock_irqsave(&tp->tx_lock, flags);
- list_add_tail(&agg->list, &tp->tx_free);
- spin_unlock_irqrestore(&tp->tx_lock, flags);
- }
- }
+ if (!list_empty(&tp->tx_free))
+ tasklet_schedule(&tp->tl);
return NETDEV_TX_OK;
}
--
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] net/cdc_ncm: fix null pointer panic at usbnet_link_change
"Du, ChangbinX" writes:
> From: "Du, Changbin"
>
> In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb.
> But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect()
> be called which calls free_netdev(net).
I am sure you are right, but I really don't see how that can happen.
AFAICS, we ensure that the intfdata is set to NULL before calling
usb_driver_release_interface() in the error cleanup in
cdc_ncm_bind_common():
error2:
usb_set_intfdata(ctx->control, NULL);
usb_set_intfdata(ctx->data, NULL);
if (ctx->data != ctx->control)
usb_driver_release_interface(driver, ctx->data);
error:
cdc_ncm_free((struct cdc_ncm_ctx *)dev->data[0]);
dev->data[0] = 0;
dev_info(&dev->udev->dev, "bind() failure\n");
return -ENODEV;
Thus we hit the test in disconnect, and usbnet_disconnect() is never
called:
static void cdc_ncm_disconnect(struct usb_interface *intf)
{
struct usbnet *dev = usb_get_intfdata(intf);
if (dev == NULL)
return; /* already disconnected */
usbnet_disconnect(intf);
}
So we should really be OK, but we are not I would appreciate it if
anyone took the time to feed me why, with a very small spoon...
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 43afde8..af37ecf 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -603,14 +603,15 @@ static int cdc_ncm_bind(struct usbnet *dev, struct
> usb_interface *intf)
>
> /* NCM data altsetting is always 1 */
> ret = cdc_ncm_bind_common(dev, intf, 1);
> -
> - /*
> - * We should get an event when network connection is "connected" or
> - * "disconnected". Set network connection in "disconnected" state
> - * (carrier is OFF) during attach, so the IP network stack does not
> - * start IPv6 negotiation and more.
> - */
> - usbnet_link_change(dev, 0, 0);
> + if (!ret) {
> + /*
> + * We should get an event when network connection is "connected"
> + * or "disconnected". Set network connection in "disconnected"
> + * state (carrier is OFF) during attach, so the IP network stack
> + * does not start IPv6 negotiation and more.
> + */
> + usbnet_link_change(dev, 0, 0);
> + }
> return ret;
> }
This change does of course make sense in any case, so no objections
there. But maybe you could modify cdc_ncm to set the new FLAG_LINK_INTR
instead, and completely drop the usbnet_link_change() from this driver?
This will make usbnet_probe() handle the call, and it will avoid it if
cdc_ncm_bind() failed.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
Greg Suarez writes: > Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE > notifications > when sending a message over multiple fragments or when there are unsolicited > messages available. > > Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications > received > and decrement the count and submit the urb for the next response each time > userspace > completes a read the response. > > Signed-off-by: Greg Suarez Thanks for doing this. Looks very good to me. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: cdc-wdm: ignore speed change notifications
The only notification supported by the Device Management class is Response Available. But this driver is also used as a subdriver of other CDC classes, allowing notifications like Speed Change and Network Connection. This results in log messages which are only confusing to an end user: [66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 len 8 These drivers use cdc-wdm as a subdriver to allow access to an embedded management protocol, and all management is expected to use this protocol. There is therefore no need to handle any of these optional CDC notifications. Instead we can let the cdc-wdm driver recognize them and log a debug level message instead of an error. Reported-by: Rob Gardner Signed-off-by: Bjørn Mork --- drivers/usb/class/cdc-wdm.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c index d3318a0..89816ad 100644 --- a/drivers/usb/class/cdc-wdm.c +++ b/drivers/usb/class/cdc-wdm.c @@ -253,6 +253,10 @@ static void wdm_int_callback(struct urb *urb) "NOTIFY_NETWORK_CONNECTION %s network", dr->wValue ? "connected to" : "disconnected from"); goto exit; + case USB_CDC_NOTIFY_SPEED_CHANGE: + dev_dbg(&desc->intf->dev, "SPEED_CHANGE received (len %u)", + urb->actual_length); + goto exit; default: clear_bit(WDM_POLL_RUNNING, &desc->flags); dev_err(&desc->intf->dev, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote: > Mika Westerberg has reported that the fixed+improved divisor based baud rate > encoding method doesn't work anymore with his HXD device. > So until we've found out what's going on, reintroduce the old encoding > algorithm > and use it for this and all newer chips for baud rates > 115200 baud. > Also switch back to the direct encoding method for baud rates <= 115200, > because > it's unclear if the old divisor based encoding algorithm works for them. > > Reported-by: Mika Westerberg > Signed-off-by: Frank Schäfer Tried this and with 115200 it works and fixes the problem. However, with speeds like 230400 and 460800 it still corrupts data. I also got few whitespace warnings when applied this using 'git am'. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: cdc-wdm: ignore speed change notifications
On Tue, 2013-10-29 at 09:52 +0100, Bjørn Mork wrote: > The only notification supported by the Device Management class is > Response Available. But this driver is also used as a subdriver of > other CDC classes, allowing notifications like Speed Change and > Network Connection. This results in log messages which are only > confusing to an end user: > > [66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 > len 8 > > These drivers use cdc-wdm as a subdriver to allow access to an > embedded management protocol, and all management is expected to > use this protocol. There is therefore no need to handle any of > these optional CDC notifications. Instead we can let the cdc-wdm > driver recognize them and log a debug level message instead of an > error. Good. But you need to put GregKH in CC. 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
Re: imx27.dtsi usbotg/usbh2 oops in fsl_usb2_mph_dr_of_probe
Hi Chris,
On Tue, Oct 29, 2013 at 5:15 AM, Chris Ruehl wrote:
> Fabio was right, the imx27 uses the ChipIdea for its USB my dts config was
> wrong.
> More accurate settings for the OTG and H2 are:
>
> usbotg: usb@10024000 {
> compatible = "fsl,imx27-usb";
>
> reg = <0x10024000 0x200>;
> interrupts = <56>;
> clocks = <&clks 75>, <&clks 62>;
> clock-names = "ipg", "ahb";
>
> dr_mode = "host";
> phy_type = "ulpi";
> status = "disabled";
> };
>
> usbh1: usb@10024200 {
> compatible = "fsl,imx27-usb";
> reg = <0x10024200 0x200>;
> interrupts = <54>;
> clocks = <&clks 75>, <&clks 62>;
> clock-names = "ipg", "ahb";
> dr_mode = "host";
> phy_type = "serial";
> status = "disabled";
> };
>
> usbh2: usb@10024400 {
> compatible = "fsl,imx27-usb";
> reg = <0x10024400 0x200>;
> interrupts = <55>;
> clocks = <&clks 75>, <&clks 62>;
> clock-names = "ipg", "ahb";
>
> dr_mode = "host";
> phy_type = "ulpi";
> status = "disabled";
> };
Where do you configure the pins as USB functionality?
I would expect a 'pinctrl-0' into your board dts file that configure
the USB pins.
> and add to usbmisc_imx.c
>
> --- linux-3.12-rc7/drivers/usb/chipidea/usbmisc_imx.c 2013-10-28
> 07:12:03.0 +0800
> +++ linux-3.12-rc7-gtsys/drivers/usb/chipidea/usbmisc_imx.c 2013-10-29
> 13:31:45.523288470 +0800
> @@ -21,6 +21,11 @@
> #define MX25_USB_PHY_CTRL_OFFSET 0x08
> #define MX25_BM_EXTERNAL_VBUS_DIVIDER BIT(23)
>
> +#define MX27_USB_PHY_CTRL_OFFSET 0x600 /* MCIMX27RM Reference Manual v0.4
> */
> +#define MX27_BM_OVER_CUR_DIS_H1 BIT(8) /* 30.5.1.1 USBCONTROL—USB Control
> Register (USB_CTRL) */
> +#define MX27_BM_OVER_CUR_DIS_H2 BIT(16)
> +#define MX27_BM_OVER_CUR_DIS_OTG BIT(24)
> +
> #define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
> #define MX53_USB_UH2_CTRL_OFFSET 0x14
> #define MX53_USB_UH3_CTRL_OFFSET 0x18
> @@ -68,6 +73,37 @@
> return 0;
> }
>
> +static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
> +{
> + void __iomem *reg = NULL;
> + unsigned long flags;
> + u32 val = 0;
> +
> + if (data->index > 3)
> + return -EINVAL;
> +
> + if (data->disable_oc) {
> + spin_lock_irqsave(&usbmisc->lock, flags);
> + reg = usbmisc->base + MX27_USB_PHY_CTRL_OFFSET;
> + switch (data->index) {
> + case 0:
> + val = readl(reg) | MX27_BM_OVER_CUR_DIS_OTG;
> + break;
> + case 1:
> + val = readl(reg) | MX27_BM_OVER_CUR_DIS_H1;
> + break;
> + case 2:
> + val = readl(reg) | MX27_BM_OVER_CUR_DIS_H2;
> + break;
> + }
> + if (reg && val)
> + writel(val, reg);
> + spin_unlock_irqrestore(&usbmisc->lock, flags);
> + }
> +
> + return 0;
> +}
> +
> static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
> {
> void __iomem *reg = NULL;
> @@ -128,6 +164,10 @@
> .post = usbmisc_imx25_post,
> };
>
> +static const struct usbmisc_ops imx27_usbmisc_ops = {
> + .init = usbmisc_imx27_init,
> +};
> +
> static const struct usbmisc_ops imx53_usbmisc_ops = {
> .init = usbmisc_imx53_init,
> };
> @@ -162,6 +202,10 @@
> .data = &imx25_usbmisc_ops,
> },
> {
> + .compatible = "fsl,imx27-usbmisc",
> + .data = &imx27_usbmisc_ops,
> + },
> + {
> .compatible = "fsl,imx53-usbmisc",
> .data = &imx53_usbmisc_ops,
> },
>
> [ 1.104173] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f4424100
> op: f4424140
> [ 1.104243] ci_hdrc ci_hdrc.0: It is OTG capable controller
> [ 1.104732] ci_hdrc ci_hdrc.0: EHCI Host Controller
> [ 1.109861] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
> [ 1.128447] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
> [ 1.134640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [ 1.141599] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [ 1.148958] usb usb1: Product: EHCI Host Controller
> [ 1.153963] usb usb1: Manufacturer: Linux 3.12.0-rc7 ehci_hcd
> [ 1.159831] usb usb1: SerialNumber: ci_hdrc.0
> [ 1.167399] hub 1-0:1.0: USB hub found
> [ 1.171457] hub 1-0:1.0: 1 port detected
> [ 1.177957] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f4424500
> op: f4424540
> [ 1.178071] ci_hdrc ci_hdrc.1: EHCI Host Controller
> [ 1.183226] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 2
> [ 1.200450] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
> [ 1.206643] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [ 1.213601] usb usb2: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [ 1.220962] usb usb2: Product: EHCI Host Controller
> [ 1.225968] usb usb2: Manufacturer: Linux 3.12.0-rc7 ehci_hcd
> [ 1.231835] usb usb2: SerialNumber: ci_hdrc.1
> [ 1.239414] hub 2-0:1.0: USB hub found
> [ 1.243500] hub 2-0:1.0: 1 port detected
>
> A problem persists the ULPI 1504 not get detected
>
> any help here?
Looks like you are in the right track.
Have you selected the USB_ULPI in your .config?
Also, please read this thread:
http://www.spinics.net/lists/linux-usb/msg94584.html
It talks about the non-dt mxc ehci driver, but could help you to fix
the initialization order to get the 1504 detected.
Regards,
Fabio Estevam
--
To unsubscribe from this list: send the line "unsub
Re: [PATCH] usb: cdc-wdm: ignore speed change notifications
Oliver Neukum writes: > On Tue, 2013-10-29 at 09:52 +0100, Bjørn Mork wrote: >> The only notification supported by the Device Management class is >> Response Available. But this driver is also used as a subdriver of >> other CDC classes, allowing notifications like Speed Change and >> Network Connection. This results in log messages which are only >> confusing to an end user: >> >> [66255.801874] cdc_mbim 1-3:1.5: unknown notification 42 received: index 5 >> len 8 >> >> These drivers use cdc-wdm as a subdriver to allow access to an >> embedded management protocol, and all management is expected to >> use this protocol. There is therefore no need to handle any of >> these optional CDC notifications. Instead we can let the cdc-wdm >> driver recognize them and log a debug level message instead of an >> error. > > Good. But you need to put GregKH in CC. Thanks. Forgot about that. Been too long since I was able to send anything in that direction. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/12] usb: gadget: r8a66597-udc: Convert to clk_prepare/unprepare
Hi Laurent-san,
(2013/10/29 7:49), Laurent Pinchart wrote:
> Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> clk_disable_unprepare() to get ready for the migration to the common
> clock framework.
>
> Cc: Felipe Balbi
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Laurent Pinchart
Thank you for the patch.
Acked-by: Yoshihiro Shimoda
Best regards,
Yoshihro Shimoda
> ---
> drivers/usb/gadget/r8a66597-udc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/r8a66597-udc.c
> b/drivers/usb/gadget/r8a66597-udc.c
> index 68be48d..4728751 100644
> --- a/drivers/usb/gadget/r8a66597-udc.c
> +++ b/drivers/usb/gadget/r8a66597-udc.c
> @@ -1833,7 +1833,7 @@ static int __exit r8a66597_remove(struct
> platform_device *pdev)
> r8a66597_free_request(&r8a66597->ep[0].ep, r8a66597->ep0_req);
>
> if (r8a66597->pdata->on_chip) {
> - clk_disable(r8a66597->clk);
> + clk_disable_unprepare(r8a66597->clk);
> clk_put(r8a66597->clk);
> }
>
> @@ -1931,7 +1931,7 @@ static int __init r8a66597_probe(struct platform_device
> *pdev)
> ret = PTR_ERR(r8a66597->clk);
> goto clean_up;
> }
> - clk_enable(r8a66597->clk);
> + clk_prepare_enable(r8a66597->clk);
> }
>
> if (r8a66597->pdata->sudmac) {
> @@ -1996,7 +1996,7 @@ clean_up3:
> free_irq(irq, r8a66597);
> clean_up2:
> if (r8a66597->pdata->on_chip) {
> - clk_disable(r8a66597->clk);
> + clk_disable_unprepare(r8a66597->clk);
> clk_put(r8a66597->clk);
> }
> clean_up:
>
--
Yoshihiro Shimoda
EC No.
--
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 10/12] usb: r8a66597-hcd: Convert to clk_prepare/unprepare
Hi Laurent-san,
(2013/10/29 7:49), Laurent Pinchart wrote:
> Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
> clk_disable_unprepare() to get ready for the migration to the common
> clock framework.
>
> Cc: Greg Kroah-Hartman
> Cc: Yoshihiro Shimoda
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Laurent Pinchart
Thank you for the patch.
Acked-by: Yoshihiro Shimoda
Best regards,
Yoshihro Shimoda
> ---
> drivers/usb/host/r8a66597-hcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
> index 2ad004a..a2fdd85 100644
> --- a/drivers/usb/host/r8a66597-hcd.c
> +++ b/drivers/usb/host/r8a66597-hcd.c
> @@ -95,7 +95,7 @@ static int r8a66597_clock_enable(struct r8a66597 *r8a66597)
> int i = 0;
>
> if (r8a66597->pdata->on_chip) {
> - clk_enable(r8a66597->clk);
> + clk_prepare_enable(r8a66597->clk);
> do {
> r8a66597_write(r8a66597, SCKE, SYSCFG0);
> tmp = r8a66597_read(r8a66597, SYSCFG0);
> @@ -139,7 +139,7 @@ static void r8a66597_clock_disable(struct r8a66597
> *r8a66597)
> udelay(1);
>
> if (r8a66597->pdata->on_chip) {
> - clk_disable(r8a66597->clk);
> + clk_disable_unprepare(r8a66597->clk);
> } else {
> r8a66597_bclr(r8a66597, PLLC, SYSCFG0);
> r8a66597_bclr(r8a66597, XCKE, SYSCFG0);
>
--
Yoshihiro Shimoda
EC No.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Hi,
On Monday 28 October 2013 07:22 PM, Kamil Debski wrote:
> Hi Kishon,
>
> Thank you for your review! I will answer your comments below.
>
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: Friday, October 25, 2013 5:40 PM
>>
>> Hi,
>>
>> On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
>>> Add a new driver for the Exynos USB PHY. The new driver uses the
>>> generic PHY framework. The driver includes support for the Exynos
>> 4x10
>>> and 4x12 SoC families.
>>>
>>> Signed-off-by: Kamil Debski
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> .../devicetree/bindings/phy/samsung-usbphy.txt | 51 +++
>>> drivers/phy/Kconfig| 21 ++
>>> drivers/phy/Makefile |3 +
>>> drivers/phy/phy-exynos-usb.c | 245
>> ++
>>> drivers/phy/phy-exynos-usb.h | 94 ++
>>> drivers/phy/phy-exynos4210-usb.c | 295
>> +
>>> drivers/phy/phy-exynos4212-usb.c | 343
>>
>>> 7 files changed, 1052 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/phy/samsung-usbphy.txt
>>> create mode 100644 drivers/phy/phy-exynos-usb.c create mode 100644
>>> drivers/phy/phy-exynos-usb.h create mode 100644
>>> drivers/phy/phy-exynos4210-usb.c create mode 100644
>>> drivers/phy/phy-exynos4212-usb.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
>>> b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
>>> new file mode 100644
>>> index 000..f112b37
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-usbphy.txt
>>> @@ -0,0 +1,51 @@
>>> +Samsung S5P/EXYNOS SoC series USB PHY
>>> +-
>>> +
>>> +Required properties:
>>> +- compatible : should be one of the listed compatibles:
>>> + - "samsung,exynos4210-usbphy"
>>> + - "samsung,exynos4212-usbphy"
>>> +- reg : a list of registers used by phy driver
>>> + - first and obligatory is the location of phy modules registers
>>> + - second and also required is the location of isolation registers
>>> + (isolation registers control the physical connection between
>> the in
>>> + SoC modules and outside of the SoC, this also can be called
>> enable
>>> + control in the documentation of the SoC)
>>> + - third is the location of the mode switch register, this only
>> applies
>>> + to SoCs that have such a feature; mode switching enables to
>> have
>>> + both host and device used the same SoC pins and is commonly
>> used
>>> + when OTG is supported
>>> +- #phy-cells : from the generic phy bindings, must be 1;
>>> +
>>> +The second cell in the PHY specifier identifies the PHY its meaning
>>> +is SoC dependent. For the currently supported SoCs (Exynos 4210 and
>>> +Exynos 4212) it is as follows:
>>> + 0 - USB device,
>>> + 1 - USB host,
>>> + 2 - HSIC0,
>>> + 3 - HSIC1,
>>
>> HSIC is supposedly to be transceiver less no? You have to program
>> something in the digital side?
>> You have a single IP that have all these functionalities?
>
> There is a single USB PHY controller for all the above functionalities
> (i.e. host, device, hsic 0 and 1).
Ok.
>
>>> +
>>> +Example:
>>> +
>>> +For Exynos 4412 (compatible with Exynos 4212):
>>> +
>>> +exynos_usbphy: exynos-usbphy@125B {
>>> + compatible = "samsung,exynos4212-usbphy";
>>> + reg = <0x125B 0x100 0x10020704 0x0c 0x1001021c 0x4>;
>>> + ranges;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>
>> The above 3 properties aren't documented? Are they needed here?
>
> My bad. I was working on two branches and corrected it in only one
> of them.
>
>>> + clocks = <&clock 305>, <&clock 2>, <&clock 2>, <&clock 2>,
>>> + <&clock 2>;
>>> + clock-names = "phy", "device", "host", "hsic0", "hsic1";
>>> + status = "okay";
>>> + #phy-cells = <1>;
>>> +};
>>> +
>>> +Then the PHY can be used in other nodes such as:
>>> +
>>> +ehci@1258 {
>>> + status = "okay";
>>> + phys = <&exynos_usbphy 2>;
>>> + phy-names = "hsic0";
>>> +};
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
>>> 349bef2..2f7ac0a 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -15,4 +15,25 @@ config GENERIC_PHY
>>> phy users can obtain reference to the PHY. All the users of
>> this
>>> framework should select this config.
>>>
>>> +config PHY_EXYNOS_USB
>>> + tristate "Samsung USB PHY driver (using the Generic PHY
>> Framework)"
>> Mentioning *Generic PHY Framework* is not necessary.
>> *select GENERIC_PHY* here
>
> This was added to distinguish this driver from the ols USB PHY driver.
> I agree that in the final version it should be removed. I understand that
> the correct way to do this is by removing the old driver when the new gets
> merged. Yes?
right.
>
>>> + help
>>>
Re: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi,
On Monday 28 October 2013 08:11 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Fri, Oct 25, 2013 at 9:13 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
>>> Add support for Exynos 5250. This is work-in-progress commit. Not
>>> for merging.
>>>
>>> Signed-off-by: Kamil Debski
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/phy/Kconfig |7 +
>>> drivers/phy/Makefile |1 +
>>> drivers/phy/phy-exynos-usb.c | 10 +
>>> drivers/phy/phy-exynos-usb.h |1 +
>>> drivers/phy/phy-exynos5250-usb.c | 411
>>> ++
>>> 5 files changed, 430 insertions(+)
>>> create mode 100644 drivers/phy/phy-exynos5250-usb.c
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index 2f7ac0a..0f598d0 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
>>> help
>>> Enable USB PHY support for Exynos 4212
>>>
>>> +config PHY_EXYNOS5250_USB
>>> + bool "Support for Exynos 5250"
>>> + depends on PHY_EXYNOS_USB
>>
>> This should be a separate driver. Not necessary to use PHY_EXYNOS_USB.
>>> + depends on SOC_EXYNOS5250
>>> + help
>>> + Enable USB PHY support for Exynos 5250
>>> +
>>> endmenu
>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>>> index ca3dc82..0dff0dd 100644
>>> --- a/drivers/phy/Makefile
>>> +++ b/drivers/phy/Makefile
>>> @@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
>>> obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
>>> obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
>>> obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
>>> +obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
>>> diff --git a/drivers/phy/phy-exynos-usb.c b/drivers/phy/phy-exynos-usb.c
>>> index d4a26df..172b774 100644
>>> --- a/drivers/phy/phy-exynos-usb.c
>>> +++ b/drivers/phy/phy-exynos-usb.c
>>> @@ -212,6 +212,10 @@ extern const struct uphy_config exynos4210_uphy_config;
>>> extern const struct uphy_config exynos4212_uphy_config;
>>> #endif
>>>
>>> +#ifdef CONFIG_PHY_EXYNOS5250_USB
>>> +extern const struct uphy_config exynos5250_uphy_config;
>>> +#endif
>>> +
>>> static const struct of_device_id exynos_uphy_of_match[] = {
>>> #ifdef CONFIG_PHY_EXYNOS4210_USB
>>> {
>>> @@ -225,6 +229,12 @@ static const struct of_device_id
>>> exynos_uphy_of_match[] = {
>>> .data = &exynos4212_uphy_config,
>>> },
>>> #endif
>>> +#ifdef CONFIG_PHY_EXYNOS5250_USB
>>> + {
>>> + .compatible = "samsung,exynos5250-usbphy",
>>> + .data = &exynos5250_uphy_config,
>>> + },
>>> +#endif
>>> { },
>>> };
>>>
>>> diff --git a/drivers/phy/phy-exynos-usb.h b/drivers/phy/phy-exynos-usb.h
>>> index f45cb3c..a9febfa 100644
>>> --- a/drivers/phy/phy-exynos-usb.h
>>> +++ b/drivers/phy/phy-exynos-usb.h
>>> @@ -42,6 +42,7 @@ enum samsung_cpu_type {
>>> TYPE_S3C64XX,
>>> TYPE_EXYNOS4210,
>>> TYPE_EXYNOS4212,
>>> + TYPE_EXYNOS5250,
>>
>> No cpu types here.
>
> One question here.
> In case we move to single driver for Exynos4 SoCs (4210, 4212 and 4412
> later) as well as S5PV210,
> there will be certain things changing from one SoC to another, how
> should we target that in case we
> don't have CPU types ?
> May be i am misinterpreting your suggestion ?
We should be using the IP revision register or check for compatible values.
Thanks
Kishon
--
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: imx27.dtsi usbotg/usbh2 oops in fsl_usb2_mph_dr_of_probe
Hi Fabio,
On Tuesday, October 29, 2013 05:32 PM, Fabio Estevam wrote:
Hi Chris,
On Tue, Oct 29, 2013 at 5:15 AM, Chris Ruehl wrote:
Fabio was right, the imx27 uses the ChipIdea for its USB my dts config was
wrong.
More accurate settings for the OTG and H2 are:
usbotg: usb@10024000 {
compatible = "fsl,imx27-usb";
reg = <0x10024000 0x200>;
interrupts = <56>;
clocks = <&clks 75>, <&clks 62>;
clock-names = "ipg", "ahb";
dr_mode = "host";
phy_type = "ulpi";
status = "disabled";
};
usbh1: usb@10024200 {
compatible = "fsl,imx27-usb";
reg = <0x10024200 0x200>;
interrupts = <54>;
clocks = <&clks 75>, <&clks 62>;
clock-names = "ipg", "ahb";
dr_mode = "host";
phy_type = "serial";
status = "disabled";
};
usbh2: usb@10024400 {
compatible = "fsl,imx27-usb";
reg = <0x10024400 0x200>;
interrupts = <55>;
clocks = <&clks 75>, <&clks 62>;
clock-names = "ipg", "ahb";
dr_mode = "host";
phy_type = "ulpi";
status = "disabled";
};
Where do you configure the pins as USB functionality?
I would expect a 'pinctrl-0' into your board dts file that configure
the USB pins.
pinctrl-0 ... ahhh , OK
I have a static function from the non-fdt version where I init all gpios
and set board specific
resets and user-space gpios (exports) which not yet supported in the fdt.
static void __init mx27gtsir_init_board(void)
{
int reg;
mxc_gpio_setup_multiple_pins(mx27gtsir_pins,
ARRAY_SIZE(mx27gtsir_pins),"mx27gtsir");
mx27gtsir_init_userspace_gpios();
gpio_set_value(GPIO_1504_RST2,0); /* Reset */
msleep(1);
gpio_set_value(GPIO_1504_RST2,1);
gpio_set_value(GPIO_1504_CSN,1); /* CS_N low active */
msleep(1);
gpio_set_value(GPIO_1504_CSN,0);
msleep(1);
gpio_set_value(GPIO_1504_RST,0); /* Reset */
msleep(1);
gpio_set_value(GPIO_1504_RST,1);
/* 22k pull up for sd1 pins SD1_D3_CSPI3_SS */
reg = __raw_readw(MX27_IO_ADDRESS(MX27_SYSCTRL_BASE_ADDR +
MX27_SYS_PSCR));
reg |= 0x0c;
__raw_writew(reg,MX27_IO_ADDRESS(MX27_SYSCTRL_BASE_ADDR +
MX27_SYS_PSCR));
/* 22k pull up for sd2 pins */
reg = __raw_readw(MX27_IO_ADDRESS(MX27_SYSCTRL_BASE_ADDR +
MX27_SYS_PSCR));
reg &= ~0xfff0;
reg |= 0xfff0;
__raw_writew(reg, MX27_IO_ADDRESS(MX27_SYSCTRL_BASE_ADDR +
MX27_SYS_PSCR));
}
called in the machine_init function.
and add to usbmisc_imx.c
--- linux-3.12-rc7/drivers/usb/chipidea/usbmisc_imx.c 2013-10-28
07:12:03.0 +0800
+++ linux-3.12-rc7-gtsys/drivers/usb/chipidea/usbmisc_imx.c 2013-10-29
13:31:45.523288470 +0800
@@ -21,6 +21,11 @@
#define MX25_USB_PHY_CTRL_OFFSET 0x08
#define MX25_BM_EXTERNAL_VBUS_DIVIDER BIT(23)
+#define MX27_USB_PHY_CTRL_OFFSET 0x600 /* MCIMX27RM Reference Manual v0.4
*/
+#define MX27_BM_OVER_CUR_DIS_H1 BIT(8) /* 30.5.1.1 USBCONTROL—USB Control
Register (USB_CTRL) */
+#define MX27_BM_OVER_CUR_DIS_H2 BIT(16)
+#define MX27_BM_OVER_CUR_DIS_OTG BIT(24)
+
#define MX53_USB_OTG_PHY_CTRL_0_OFFSET 0x08
#define MX53_USB_UH2_CTRL_OFFSET 0x14
#define MX53_USB_UH3_CTRL_OFFSET 0x18
@@ -68,6 +73,37 @@
return 0;
}
+static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
+{
+ void __iomem *reg = NULL;
+ unsigned long flags;
+ u32 val = 0;
+
+ if (data->index > 3)
+ return -EINVAL;
+
+ if (data->disable_oc) {
+ spin_lock_irqsave(&usbmisc->lock, flags);
+ reg = usbmisc->base + MX27_USB_PHY_CTRL_OFFSET;
+ switch (data->index) {
+ case 0:
+ val = readl(reg) | MX27_BM_OVER_CUR_DIS_OTG;
+ break;
+ case 1:
+ val = readl(reg) | MX27_BM_OVER_CUR_DIS_H1;
+ break;
+ case 2:
+ val = readl(reg) | MX27_BM_OVER_CUR_DIS_H2;
+ break;
+ }
+ if (reg && val)
+ writel(val, reg);
+ spin_unlock_irqrestore(&usbmisc->lock, flags);
+ }
+
+ return 0;
+}
+
static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
{
void __iomem *reg = NULL;
@@ -128,6 +164,10 @@
.post = usbmisc_imx25_post,
};
+static const struct usbmisc_ops imx27_usbmisc_ops = {
+ .init = usbmisc_imx27_init,
+};
+
static const struct usbmisc_ops imx53_usbmisc_ops = {
.init = usbmisc_imx53_init,
};
@@ -162,6 +202,10 @@
.data = &imx25_usbmisc_ops,
},
{
+ .compatible = "fsl,imx27-usbmisc",
+ .data = &imx27_usbmisc_ops,
+ },
+ {
.compatible = "fsl,imx53-usbmisc",
.data = &imx53_usbmisc_ops,
},
[ 1.104173] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f4424100
op: f4424140
[ 1.104243] ci_hdrc ci_hdrc.0: It is OTG capable controller
[ 1.104732] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.109861] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 1.128447] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 1.134640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.141599] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 1.148958] usb usb1: Product: EHCI Host Controller
[ 1.153963] usb usb1: Manufacturer: Linux 3.12.0-rc7 ehci_hcd
[ 1.159831] usb usb1: SerialNumber: ci_hdrc.0
[ 1.167399] hub 1-0:1.0: USB hub found
[ 1.171457] hub 1-0:1.0: 1 port detected
[ 1.177957] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f4424500
op: f442454
RE: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi,
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Tuesday, October 29, 2013 10:55 AM
>
> Hi,
>
> On Monday 28 October 2013 08:11 PM, Vivek Gautam wrote:
> > Hi Kishon,
> >
> >
> > On Fri, Oct 25, 2013 at 9:13 PM, Kishon Vijay Abraham I
> wrote:
> >> Hi,
> >>
> >> On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
> >>> Add support for Exynos 5250. This is work-in-progress commit. Not
> >>> for merging.
> >>>
> >>> Signed-off-by: Kamil Debski
> >>> Signed-off-by: Kyungmin Park
> >>> ---
> >>> drivers/phy/Kconfig |7 +
> >>> drivers/phy/Makefile |1 +
> >>> drivers/phy/phy-exynos-usb.c | 10 +
> >>> drivers/phy/phy-exynos-usb.h |1 +
> >>> drivers/phy/phy-exynos5250-usb.c | 411
> >>> ++
> >>> 5 files changed, 430 insertions(+)
> >>> create mode 100644 drivers/phy/phy-exynos5250-usb.c
> >>>
> >>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> >>> 2f7ac0a..0f598d0 100644
> >>> --- a/drivers/phy/Kconfig
> >>> +++ b/drivers/phy/Kconfig
> >>> @@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
> >>> help
> >>> Enable USB PHY support for Exynos 4212
> >>>
> >>> +config PHY_EXYNOS5250_USB
> >>> + bool "Support for Exynos 5250"
> >>> + depends on PHY_EXYNOS_USB
> >>
> >> This should be a separate driver. Not necessary to use
> PHY_EXYNOS_USB.
> >>> + depends on SOC_EXYNOS5250
> >>> + help
> >>> + Enable USB PHY support for Exynos 5250
> >>> +
> >>> endmenu
> >>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> >>> ca3dc82..0dff0dd 100644
> >>> --- a/drivers/phy/Makefile
> >>> +++ b/drivers/phy/Makefile
> >>> @@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> >>> obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
> >>> obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
> >>> obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
> >>> +obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
> >>> diff --git a/drivers/phy/phy-exynos-usb.c
> >>> b/drivers/phy/phy-exynos-usb.c index d4a26df..172b774 100644
> >>> --- a/drivers/phy/phy-exynos-usb.c
> >>> +++ b/drivers/phy/phy-exynos-usb.c
> >>> @@ -212,6 +212,10 @@ extern const struct uphy_config
> >>> exynos4210_uphy_config; extern const struct uphy_config
> >>> exynos4212_uphy_config; #endif
> >>>
> >>> +#ifdef CONFIG_PHY_EXYNOS5250_USB
> >>> +extern const struct uphy_config exynos5250_uphy_config; #endif
> >>> +
> >>> static const struct of_device_id exynos_uphy_of_match[] =
> { #ifdef
> >>> CONFIG_PHY_EXYNOS4210_USB
> >>> {
> >>> @@ -225,6 +229,12 @@ static const struct of_device_id
> exynos_uphy_of_match[] = {
> >>> .data = &exynos4212_uphy_config,
> >>> },
> >>> #endif
> >>> +#ifdef CONFIG_PHY_EXYNOS5250_USB
> >>> + {
> >>> + .compatible = "samsung,exynos5250-usbphy",
> >>> + .data = &exynos5250_uphy_config,
> >>> + },
> >>> +#endif
> >>> { },
> >>> };
> >>>
> >>> diff --git a/drivers/phy/phy-exynos-usb.h
> >>> b/drivers/phy/phy-exynos-usb.h index f45cb3c..a9febfa 100644
> >>> --- a/drivers/phy/phy-exynos-usb.h
> >>> +++ b/drivers/phy/phy-exynos-usb.h
> >>> @@ -42,6 +42,7 @@ enum samsung_cpu_type {
> >>> TYPE_S3C64XX,
> >>> TYPE_EXYNOS4210,
> >>> TYPE_EXYNOS4212,
> >>> + TYPE_EXYNOS5250,
> >>
> >> No cpu types here.
> >
> > One question here.
> > In case we move to single driver for Exynos4 SoCs (4210, 4212 and
> 4412
> > later) as well as S5PV210,
> > there will be certain things changing from one SoC to another, how
> > should we target that in case we don't have CPU types ?
> > May be i am misinterpreting your suggestion ?
>
> We should be using the IP revision register or check for compatible
> values.
>
In case of this driver the compatible is checked. Maybe it is not as
straight forward, but the choice is based on compatible value.
Compatible is matched to an appropriate data entry in the of_device_id
table. The data entry contains a cpu field which contains the information
which PHY version we have. Maybe the "cpu" name is confusing and should be
changed to something like "version" or "revision".
For example:
"samsung,exynos4212-usbphy" compatible is matched to exynos4212_uphy_config
via data field of of_device_id, and the cpu field of exynos4212_uphy_config
is equal to TYPE_EXYNOS4212.
This way in the code all what is needed is to check the value of cpu field.
It already got matched through the compatible.
Still, Tomasz Figa's idea sound good - using a boolean flag
"has_mode_switch".
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Hi,
> From: Tomasz Figa [mailto:tomasz.f...@gmail.com]
> Sent: Monday, October 28, 2013 9:00 PM
>
> Hi Kamil,
>
> On Monday 28 of October 2013 14:52:19 Kamil Debski wrote:
> > Hi Kishon,
> >
> > Thank you for your review! I will answer your comments below.
> [snip]
> > > > +
> > > > + switch (drv->cfg->cpu) {
> > > > + case TYPE_EXYNOS4210:
> > >
> > > > + case TYPE_EXYNOS4212:
> > > Lets not add such cpu checks inside driver.
> >
> > Some SoC have a special register, which switches the OTG lines
> between
> > device and host modes. I understand that it might not be the
> prettiest
> > code. I see this as a good compromise between having a single huge
> > driver for all Exynos SoCs and having a multiple drivers for each SoC
> > version. PHY IPs in these chips very are similar but have to be
> > handled differently. Any other ideas to solve this issue?
>
> Maybe adding a flag in drv->cfg called, for example, .has_mode_switch
> could solve this problem without having to check the SoC type
> explicitly?
Sounds like a good idea.
> [snip]
> > > > +#ifdef CONFIG_PHY_EXYNOS4210_USB
> > >
> > > Do we really need this?
> >
> > No we don't. The driver can always support all Exynos SoC versions.
> > These config options were added for flexibility.
> >
> > > > +extern const struct uphy_config exynos4210_uphy_config; #endif
> > > > +
> > > > +#ifdef CONFIG_PHY_EXYNOS4212_USB
> > >
> > > Same here.
> > >
> > > > +extern const struct uphy_config exynos4212_uphy_config; #endif
> > > > +
> > > > +static const struct of_device_id exynos_uphy_of_match[] = {
> > > > +#ifdef CONFIG_PHY_EXYNOS4210_USB
> > >
> > > #if not needed here.
> >
> > If the #ifdef CONFIG_PHY_EXYNOS4210_USB is removed then yes.
> Otherwise
> > it is necessary - exynos4210_uphy_config may be undefined.
>
> I believe this and other ifdefs below are needed, otherwise, with
> support for one of the SoCs disabled, the driver could still bind to
> its compatible value.
>
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the Exynos USB PHY driver
Hi,
On Tuesday 29 October 2013 03:44 PM, Kamil Debski wrote:
> Hi,
>
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: Tuesday, October 29, 2013 10:55 AM
>>
>> Hi,
>>
>> On Monday 28 October 2013 08:11 PM, Vivek Gautam wrote:
>>> Hi Kishon,
>>>
>>>
>>> On Fri, Oct 25, 2013 at 9:13 PM, Kishon Vijay Abraham I
>> wrote:
Hi,
On Friday 25 October 2013 07:45 PM, Kamil Debski wrote:
> Add support for Exynos 5250. This is work-in-progress commit. Not
> for merging.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> ---
> drivers/phy/Kconfig |7 +
> drivers/phy/Makefile |1 +
> drivers/phy/phy-exynos-usb.c | 10 +
> drivers/phy/phy-exynos-usb.h |1 +
> drivers/phy/phy-exynos5250-usb.c | 411
> ++
> 5 files changed, 430 insertions(+)
> create mode 100644 drivers/phy/phy-exynos5250-usb.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index
> 2f7ac0a..0f598d0 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -36,4 +36,11 @@ config PHY_EXYNOS4212_USB
> help
> Enable USB PHY support for Exynos 4212
>
> +config PHY_EXYNOS5250_USB
> + bool "Support for Exynos 5250"
> + depends on PHY_EXYNOS_USB
This should be a separate driver. Not necessary to use
>> PHY_EXYNOS_USB.
> + depends on SOC_EXYNOS5250
> + help
> + Enable USB PHY support for Exynos 5250
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index
> ca3dc82..0dff0dd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o
> obj-$(CONFIG_PHY_EXYNOS_USB) += phy-exynos-usb.o
> obj-$(CONFIG_PHY_EXYNOS4210_USB) += phy-exynos4210-usb.o
> obj-$(CONFIG_PHY_EXYNOS4212_USB) += phy-exynos4212-usb.o
> +obj-$(CONFIG_PHY_EXYNOS5250_USB) += phy-exynos5250-usb.o
> diff --git a/drivers/phy/phy-exynos-usb.c
> b/drivers/phy/phy-exynos-usb.c index d4a26df..172b774 100644
> --- a/drivers/phy/phy-exynos-usb.c
> +++ b/drivers/phy/phy-exynos-usb.c
> @@ -212,6 +212,10 @@ extern const struct uphy_config
> exynos4210_uphy_config; extern const struct uphy_config
> exynos4212_uphy_config; #endif
>
> +#ifdef CONFIG_PHY_EXYNOS5250_USB
> +extern const struct uphy_config exynos5250_uphy_config; #endif
> +
> static const struct of_device_id exynos_uphy_of_match[] =
>> { #ifdef
> CONFIG_PHY_EXYNOS4210_USB
> {
> @@ -225,6 +229,12 @@ static const struct of_device_id
>> exynos_uphy_of_match[] = {
> .data = &exynos4212_uphy_config,
> },
> #endif
> +#ifdef CONFIG_PHY_EXYNOS5250_USB
> + {
> + .compatible = "samsung,exynos5250-usbphy",
> + .data = &exynos5250_uphy_config,
> + },
> +#endif
> { },
> };
>
> diff --git a/drivers/phy/phy-exynos-usb.h
> b/drivers/phy/phy-exynos-usb.h index f45cb3c..a9febfa 100644
> --- a/drivers/phy/phy-exynos-usb.h
> +++ b/drivers/phy/phy-exynos-usb.h
> @@ -42,6 +42,7 @@ enum samsung_cpu_type {
> TYPE_S3C64XX,
> TYPE_EXYNOS4210,
> TYPE_EXYNOS4212,
> + TYPE_EXYNOS5250,
No cpu types here.
>>>
>>> One question here.
>>> In case we move to single driver for Exynos4 SoCs (4210, 4212 and
>> 4412
>>> later) as well as S5PV210,
>>> there will be certain things changing from one SoC to another, how
>>> should we target that in case we don't have CPU types ?
>>> May be i am misinterpreting your suggestion ?
>>
>> We should be using the IP revision register or check for compatible
>> values.
>>
>
> In case of this driver the compatible is checked. Maybe it is not as
> straight forward, but the choice is based on compatible value.
> Compatible is matched to an appropriate data entry in the of_device_id
> table. The data entry contains a cpu field which contains the information
> which PHY version we have. Maybe the "cpu" name is confusing and should be
> changed to something like "version" or "revision".
you don't have a revision register in the PHY IP which can be used?
>
> For example:
> "samsung,exynos4212-usbphy" compatible is matched to exynos4212_uphy_config
> via data field of of_device_id, and the cpu field of exynos4212_uphy_config
> is equal to TYPE_EXYNOS4212.
> This way in the code all what is needed is to check the value of cpu field.
> It already got matched through the compatible.
>
> Still, Tomasz Figa's idea sound good - using a boolean flag
> "has_mode_switch".
hmm, could be.
Thanks
Kishon
--
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.
Re: [RFC/PATCH 1/2] usb: gadget: re-introduce gadget_is_dwc3()
Hi,
On Mon, Oct 28, 2013 at 06:12:59PM -0700, David Cohen wrote:
> gadget_is_dwc3() is necessary to check whether we are running on
> Desineware USB3 DRD controller.
>
> This macro was previously removed by commit
> ed9cbda63d45638b69ce62412e3a3c7b00644835 due to it wasn't needed
> anymore. We're adding it again as things have changed.
>
> Signed-off-by: David Cohen
> ---
> drivers/usb/gadget/gadget_chips.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/gadget/gadget_chips.h
> b/drivers/usb/gadget/gadget_chips.h
> index bcd04bc..3186a5e 100644
> --- a/drivers/usb/gadget/gadget_chips.h
> +++ b/drivers/usb/gadget/gadget_chips.h
> @@ -28,6 +28,7 @@
> * do that for you.
> */
> #define gadget_is_at91(g)(!strcmp("at91_udc", (g)->name))
> +#define gadget_is_dwc3(g)(!strcmp("dwc3-gadget", (g)->name))
NAK, we want to get rid of all of them, in fact. gadget drivers
shouldn't have to know which controller they're running on, they need to
know about quirks and features the controller supports.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC/PATCH 2/2] usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize
Hi,
On Mon, Oct 28, 2013 at 06:13:00PM -0700, David Cohen wrote:
> DWC3 requires buffer size to be aligned to maxpacketsize of an out
> endpoint. ffs_epfile_io() needs to pad epout buffer to match above
> condition if DWC3 controller is used.
>
> This patch solves an specific situation but a more generic solution
> should be found.
>
> Signed-off-by: David Cohen
> ---
> drivers/usb/gadget/f_fs.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
> index 75e4b78..33880e6 100644
> --- a/drivers/usb/gadget/f_fs.c
> +++ b/drivers/usb/gadget/f_fs.c
> @@ -27,6 +27,7 @@
> #include
> #include
>
> +#include "gadget_chips.h"
>
> #define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
>
> @@ -755,10 +756,12 @@ static ssize_t ffs_epfile_io(struct file *file,
>char __user *buf, size_t len, int read)
> {
> struct ffs_epfile *epfile = file->private_data;
> + struct usb_gadget *gadget = epfile->ffs->gadget;
> struct ffs_ep *ep;
> char *data = NULL;
> ssize_t ret;
> int halt;
> + size_t orig_len = len;
>
> goto first_try;
> do {
> @@ -794,6 +797,22 @@ first_try:
> goto error;
> }
>
> + /*
> + * DWC3 requires buffer size to be aligned to maxpacketsize
> + * of an out endpoint.
> + * FIXME: a more generic solution might be necessary.
> + */
see, gadget drivers shouldn't have to know about DWC3 at all. They need
to know that current UDC has a quirk where EP OUT transactions need to
be aligned to wMaxPacketSize, so what I was expecting to see here was:
if (test_bit(USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE,
&gadget->qirks) &&
!IS_ALIGNED(len, ep->ep->desc->wMaxPacketSize))
len = align_length(orig_len, wMaxPacketSize);
--
balbi
signature.asc
Description: Digital signature
Re: khubd timed out on ep0in len=0/64 with 3.4 kernel
On Mon, 28 Oct 2013, Prasad Koya wrote:
> Hi
>
> I tried resetting usb device when it gets ETIMEDOUT during get
> descriptor. On second retry, I don't see timeout. Please see this
> patch:
>
> Index: linux-3.4/drivers/usb/core/hub.c
> ===
> --- linux-3.4.orig/drivers/usb/core/hub.c
> +++ linux-3.4/drivers/usb/core/hub.c
> @@ -3213,6 +3213,14 @@ hub_port_init (struct usb_hub *hub, stru
> r = -EPROTO;
> break;
> }
> +
> +if (r == -ETIMEDOUT) {
> + r = usb_reset_device(hdev);
> + if (r) {
> + dev_dbg(&udev->dev, "failed to reset usb %d\n", r);
> + }
> + }
> +
> if (r == 0)
> break;
> }
The patch has been whitespace-damaged. Besides, what is the point of
calling usb_reset_device()? You might as well just break out of the
loop, because just after the end of the loop there is a call to
hub_port_reset().
In addition, you run the risk of infinite recursion since
usb_reset_device() calls usb_reset_and_verify_device(), which calls
hub_port_init().
Finally, the patch is wrong because it never does carry out the
Get-Device-Descriptor(64) request. That means it won't work with a
full-speed device if the ep0 maxpacket size is smaller than 64.
What you could do instead is this:
Index: usb-3.12/drivers/usb/core/hub.c
===
--- usb-3.12.orig/drivers/usb/core/hub.c
+++ usb-3.12/drivers/usb/core/hub.c
@@ -4106,11 +4106,12 @@ hub_port_init (struct usb_hub *hub, stru
r = -EPROTO;
break;
}
- if (r == 0)
+ if (r == 0) {
+ udev->descriptor.bMaxPacketSize0 =
+ buf->bMaxPacketSize0;
break;
+ }
}
- udev->descriptor.bMaxPacketSize0 =
- buf->bMaxPacketSize0;
kfree(buf);
retval = hub_port_reset(hub, port1, udev, delay, false);
@@ -4126,8 +4127,15 @@ hub_port_init (struct usb_hub *hub, stru
if (r != -ENODEV)
dev_err(&udev->dev, "device descriptor
read/64, error %d\n",
r);
- retval = -EMSGSIZE;
- continue;
+
+ /*
+* For every speed except full speed, the
+* ep0 maxpacket size is already known.
+*/
+ if (udev->speed == USB_SPEED_FULL) {
+ retval = -EMSGSIZE;
+ continue;
+ }
}
#undef GET_DESCRIPTOR_BUFSIZE
}
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 2/2] usb: ffs/dwc3: pad epout buffer size when not aligned to maxpacketsize
>> +/* >> + * DWC3 requires buffer size to be aligned to maxpacketsize >> + * of an out endpoint. >> + * FIXME: a more generic solution might be necessary. >> + */ > > see, gadget drivers shouldn't have to know about DWC3 at all. They need > to know that current UDC has a quirk where EP OUT transactions need to > be aligned to wMaxPacketSize, so what I was expecting to see here was: > > if (test_bit(USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE, > &gadget->qirks) && > !IS_ALIGNED(len, ep->ep->desc->wMaxPacketSize)) > len = align_length(orig_len, wMaxPacketSize); That makes sense. I'll send a new version. Thanks, David Cohen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel NULL pointer dereference at (null) - inside hub_disconnect
On Mon, 28 Oct 2013, Luke-Jr wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=63961 > > Kernel version 3.10.15 > [1774470.503558] hub 2-1.3:1.0: hub_port_status failed (err = -71) > [1774475.483021] hub 2-1.4:1.0: config failed, can't get hub status (err -110) > [1774475.483042] BUG: unable to handle kernel NULL pointer dereference at > > (null) > [1774475.483075] IP: [] hub_quiesce+0x4e/0xb0 [usbcore] This bug has been fixed in 3.12-rc1 by commit d0308d4b6b02 (usb: fix cleanup after failure in hub_configure()). That commit has not been applied to the -stable branches. Greg, it looks like this commit together with e58547eb9561 (usb: fail on usb_hub_create_port_device() errors) should be queued for all stable kernels going back to 3.7.y. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/15] rework port power control
On Mon, 28 Oct 2013, Dan Williams wrote: > > In fact, the reason for calling usb_autopm_get_interface was to prevent > > the hub from being suspended while we change the port's power state. > > Something like this may still be needed. > > > > With the device model change and no longer telling the hub interface > device to pm_suspend_ignore_children() the pm subsystem will manage > this wake up for us. Provided you don't try to make any power changes while the port is suspended. For example, consider the case where a new SuperSpeed device is plugged into a USB-3 port. The peer USB-2 port has been suspended at full power. Now you will want to power it off. You can't just change its power level directly; you have to resume it and suspend it again. > > Since a port never needs to be connected to more than one other port, > > you could implement connectors simply by storing a "peer" pointer in > > the usb_port structure. > > Yes, no need to design for the non-existent 3 connection types in a > port case now. > > Another simplification is that a "struct usb_domain" is currently > known to never span a controller boundary. So, rather than adding > ports to a usb_connector / usb_domain container hierarchy I think we > can simply scan the child devices under the xhci device and look for > is_usb_port() instances. I'm not sure why you would want to do this. In order to identify which usb_port device matches a particular ACPI identifier? > In the meantime I am still thinking of the approach to reliably link > USB3 hub ports to their peers. The spec mandates that they be > labelled the same for this purpose (USB3 spec section 10.3.3). > However, to determine peer relationships for downstream hubs I think > we will need walk the hierarchy back to the root connector and compare > paths. Tier mismatch makes it so we can not look at the path back to > the root port. Unless there is some unique way to identify a hub? > Also need to think about what to do in the case a hub implementation > does not label its ports per the spec In the case of tier mismatches or other weirdness, there is no choice but to rely on the platform information. When there is no platform information (for example, in the case of a hotplugged hub), the process is simpler. Support hub H is plugged into parent port P, and you want to find the peer to port Q on the hub. Start by looking at P's peer -- call it P'. There should be a hub H' attached to P'. Then Q' (the peer to Q) is the port on H' having the same port number as Q. If either H' or Q' doesn't exist then there is no peer. (For example, H' might not exist if H is a USB-2 hub. If H' exists but Q' doesn't then something is wrong somewhere.) As for hubs with improper port labelling... We'll worry about that when we run across it. > All the questions about peering hub ports goes away if the policy on > those is forced to hotplug only. I think the patch that allows the > policy (connect_type) to be updated from userspace should also take > care to error out on hub ports. Follow-on patches can tackle the > external hub case. I'm not sure I follow. What's wrong with allowing the user to change the connect-type for a port on an external hub? At any rate, I suggest you do this by working on only one of the categories I listed earlier at a time. So, begin by submitting a patch series that redefines the meaning of putting a port into runtime suspend. Once that is accepted, move on. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: storage: use sg_miter_* APIs to access scsi buffer
We have sg_miter_* APIs for accessing scsi sg buffer, so
use them to make code clean and bug free.
Cc: Matthew Dharm
Cc: Alan Stern
Cc: Greg Kroah-Hartman
Signed-off-by: Ming Lei
---
drivers/usb/storage/protocol.c | 82 ++--
1 file changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/usb/storage/protocol.c b/drivers/usb/storage/protocol.c
index 5dfb4c3..01697e5 100644
--- a/drivers/usb/storage/protocol.c
+++ b/drivers/usb/storage/protocol.c
@@ -135,69 +135,43 @@ unsigned int usb_stor_access_xfer_buf(unsigned char
*buffer,
unsigned int buflen, struct scsi_cmnd *srb, struct scatterlist **sgptr,
unsigned int *offset, enum xfer_buf_dir dir)
{
- unsigned int cnt;
+ unsigned int cnt = 0;
struct scatterlist *sg = *sgptr;
+ struct sg_mapping_iter miter;
+ unsigned int nents = scsi_sg_count(srb);
- /* We have to go through the list one entry
-* at a time. Each s-g entry contains some number of pages, and
-* each page has to be kmap()'ed separately. If the page is already
-* in kernel-addressable memory then kmap() will return its address.
-* If the page is not directly accessible -- such as a user buffer
-* located in high memory -- then kmap() will map it to a temporary
-* position in the kernel's virtual address space.
-*/
-
- if (!sg)
+ if (sg)
+ nents -= sg - scsi_sglist(srb);
+ else
sg = scsi_sglist(srb);
- /* This loop handles a single s-g list entry, which may
-* include multiple pages. Find the initial page structure
-* and the starting offset within the page, and update
-* the *offset and **sgptr values for the next loop.
-*/
- cnt = 0;
- while (cnt < buflen && sg) {
- struct page *page = sg_page(sg) +
- ((sg->offset + *offset) >> PAGE_SHIFT);
- unsigned int poff = (sg->offset + *offset) & (PAGE_SIZE-1);
- unsigned int sglen = sg->length - *offset;
-
- if (sglen > buflen - cnt) {
-
- /* Transfer ends within this s-g entry */
- sglen = buflen - cnt;
- *offset += sglen;
- } else {
+ if (dir == FROM_XFER_BUF)
+ sg_miter_start(&miter, sg, nents, SG_MITER_FROM_SG);
+ else
+ sg_miter_start(&miter, sg, nents, SG_MITER_TO_SG);
- /* Transfer continues to next s-g entry */
- *offset = 0;
- sg = sg_next(sg);
- }
+ if (!sg_miter_skip(&miter, *offset))
+ return cnt;
+
+ while (sg_miter_next(&miter) && cnt < buflen) {
+ unsigned int len = min(miter.length, buflen - cnt);
+
+ if (dir == FROM_XFER_BUF)
+ memcpy(buffer + cnt, miter.addr, len);
+ else
+ memcpy(miter.addr, buffer + cnt, len);
- /* Transfer the data for all the pages in this
- * s-g entry. For each page: call kmap(), do the
- * transfer, and call kunmap() immediately after. */
- while (sglen > 0) {
- unsigned int plen = min(sglen, (unsigned int)
- PAGE_SIZE - poff);
- unsigned char *ptr = kmap(page);
-
- if (dir == TO_XFER_BUF)
- memcpy(ptr + poff, buffer + cnt, plen);
- else
- memcpy(buffer + cnt, ptr + poff, plen);
- kunmap(page);
-
- /* Start at the beginning of the next page */
- poff = 0;
- ++page;
- cnt += plen;
- sglen -= plen;
+ if (*offset + len < miter.piter.sg->length) {
+ *offset += len;
+ *sgptr = miter.piter.sg;
+ } else {
+ *offset = 0;
+ *sgptr = sg_next(miter.piter.sg);
}
+ cnt += len;
}
- *sgptr = sg;
+ sg_miter_stop(&miter);
- /* Return the amount actually transferred */
return cnt;
}
EXPORT_SYMBOL_GPL(usb_stor_access_xfer_buf);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] lib/scatterlist: export sg_miter_skip()
sg_copy_buffer() can't meet demand for some drrivers(such usb
mass storage), so we have to use the sg_miter_* APIs to access
sg buffer, then need export sg_miter_skip() for these drivers.
The API is needed for converting to sg_miter_* APIs in USB storage
driver for accessing sg buffer.
Cc: Andrew Morton ,
Cc: FUJITA Tomonori ,
Cc: Tejun Heo ,
Cc: Jens Axboe
Signed-off-by: Ming Lei
---
include/linux/scatterlist.h |1 +
lib/scatterlist.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index adae88f..a964f72 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -345,6 +345,7 @@ struct sg_mapping_iter {
void sg_miter_start(struct sg_mapping_iter *miter, struct scatterlist *sgl,
unsigned int nents, unsigned int flags);
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset);
bool sg_miter_next(struct sg_mapping_iter *miter);
void sg_miter_stop(struct sg_mapping_iter *miter);
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d16fa29..3a8e8e8 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -495,7 +495,7 @@ static bool sg_miter_get_next_page(struct sg_mapping_iter
*miter)
* true if @miter contains the valid mapping. false if end of sg
* list is reached.
*/
-static bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
+bool sg_miter_skip(struct sg_mapping_iter *miter, off_t offset)
{
sg_miter_stop(miter);
@@ -513,6 +513,7 @@ static bool sg_miter_skip(struct sg_mapping_iter *miter,
off_t offset)
return true;
}
+EXPORT_SYMBOL(sg_miter_skip);
/**
* sg_miter_next - proceed mapping iterator to the next mapping
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: Move R-Car Gen2 driver registration to postcore_inictall
USB phy controls USB channels 0 and 2 which are shared between
PCI USB host controllers and USBHS/USBSS respectively.
This Initializes USB phy driver earlier because we need it
before PCI USB host controllers are initialized.
Signed-off-by: Valentine Barshak
---
drivers/usb/phy/phy-rcar-gen2-usb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c
b/drivers/usb/phy/phy-rcar-gen2-usb.c
index db3ab34..32c8847 100644
--- a/drivers/usb/phy/phy-rcar-gen2-usb.c
+++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
@@ -241,7 +241,17 @@ static struct platform_driver rcar_gen2_usb_phy_driver = {
.remove = rcar_gen2_usb_phy_remove,
};
-module_platform_driver(rcar_gen2_usb_phy_driver);
+static int __init rcar_gen2_usb_phy_mod_init(void)
+{
+ return platform_driver_register(&rcar_gen2_usb_phy_driver);
+}
+postcore_initcall(rcar_gen2_usb_phy_mod_init);
+
+static void __exit rcar_gen2_usb_phy_mod_exit(void)
+{
+ platform_driver_unregister(&rcar_gen2_usb_phy_driver);
+}
+module_exit(rcar_gen2_usb_phy_mod_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Renesas R-Car Gen2 USB phy");
--
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] usb: phy: Move R-Car Gen2 driver registration to postcore_inictall
Hi Valentine,
Thank you for the patch.
On Tuesday 29 October 2013 20:21:06 Valentine Barshak wrote:
> USB phy controls USB channels 0 and 2 which are shared between
> PCI USB host controllers and USBHS/USBSS respectively.
>
> This Initializes USB phy driver earlier because we need it
> before PCI USB host controllers are initialized.
Can't you use deferred probing ?
> Signed-off-by: Valentine Barshak
> ---
> drivers/usb/phy/phy-rcar-gen2-usb.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c
> b/drivers/usb/phy/phy-rcar-gen2-usb.c index db3ab34..32c8847 100644
> --- a/drivers/usb/phy/phy-rcar-gen2-usb.c
> +++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
> @@ -241,7 +241,17 @@ static struct platform_driver rcar_gen2_usb_phy_driver
> = { .remove = rcar_gen2_usb_phy_remove,
> };
>
> -module_platform_driver(rcar_gen2_usb_phy_driver);
> +static int __init rcar_gen2_usb_phy_mod_init(void)
> +{
> + return platform_driver_register(&rcar_gen2_usb_phy_driver);
> +}
> +postcore_initcall(rcar_gen2_usb_phy_mod_init);
> +
> +static void __exit rcar_gen2_usb_phy_mod_exit(void)
> +{
> + platform_driver_unregister(&rcar_gen2_usb_phy_driver);
> +}
> +module_exit(rcar_gen2_usb_phy_mod_exit);
>
> MODULE_LICENSE("GPL v2");
> MODULE_DESCRIPTION("Renesas R-Car Gen2 USB phy");
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Am 29.10.2013 10:07, schrieb Mika Westerberg: > On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote: >> Mika Westerberg has reported that the fixed+improved divisor based baud rate >> encoding method doesn't work anymore with his HXD device. >> So until we've found out what's going on, reintroduce the old encoding >> algorithm >> and use it for this and all newer chips for baud rates > 115200 baud. >> Also switch back to the direct encoding method for baud rates <= 115200, >> because >> it's unclear if the old divisor based encoding algorithm works for them. >> >> Reported-by: Mika Westerberg >> Signed-off-by: Frank Schäfer > Tried this and with 115200 it works and fixes the problem. However, with > speeds like 230400 and 460800 it still corrupts data. Well, with this patch we go back to what we did since kernel 3.1 (since commit 8d48fdf689fe "USB: PL2303: correctly handle baudrates above 115200"), so you should face the same problems with these kernels, too. Please note that there are serious doubts with regards to the baud rate precision of this algorithm and if it has really ever been working with all chips. The commit description doesn't say where it comes from (likey based on reverse-enginnering) and which chips it tries to fix. :( We've contacted the author, but got no reply. With HX chips, it only worked "more or less" for baud rates ~115200 to ~50 and but the actual baud rate always differed a little. With commit 57ce61aad748 we fixed/improved this algorithm, but apparently this doesn't work for HXD chips (which is a bit surprising). I hope I'll get one of these devices at the end of this week. > I also got few whitespace warnings when applied this using 'git am'. Ick, thanks. Will send a fixed version. Regards, Frank -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: Move R-Car Gen2 driver registration to postcore_inictall
On 10/29/2013 09:00 PM, Laurent Pinchart wrote:
Hi Valentine,
Thank you for the patch.
On Tuesday 29 October 2013 20:21:06 Valentine Barshak wrote:
USB phy controls USB channels 0 and 2 which are shared between
PCI USB host controllers and USBHS/USBSS respectively.
This Initializes USB phy driver earlier because we need it
before PCI USB host controllers are initialized.
Can't you use deferred probing ?
No, unfortunately this doesn't work with PCI.
We need the USB PHY set up before the PCI driver starts.
PCI controllers should be initialized via subsys_initcall and can't be built as
a module.
Deferred probing is done at late_initcall and that's far too late in this case.
The MXS USB phy uses the similar approach, initializing the driver via
postcore_initcall.
I haven't observed any issues with it on R-Car Gen2 phy as well.
Thanks,
Val.
Signed-off-by: Valentine Barshak
---
drivers/usb/phy/phy-rcar-gen2-usb.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-rcar-gen2-usb.c
b/drivers/usb/phy/phy-rcar-gen2-usb.c index db3ab34..32c8847 100644
--- a/drivers/usb/phy/phy-rcar-gen2-usb.c
+++ b/drivers/usb/phy/phy-rcar-gen2-usb.c
@@ -241,7 +241,17 @@ static struct platform_driver rcar_gen2_usb_phy_driver
= { .remove = rcar_gen2_usb_phy_remove,
};
-module_platform_driver(rcar_gen2_usb_phy_driver);
+static int __init rcar_gen2_usb_phy_mod_init(void)
+{
+ return platform_driver_register(&rcar_gen2_usb_phy_driver);
+}
+postcore_initcall(rcar_gen2_usb_phy_mod_init);
+
+static void __exit rcar_gen2_usb_phy_mod_exit(void)
+{
+ platform_driver_unregister(&rcar_gen2_usb_phy_driver);
+}
+module_exit(rcar_gen2_usb_phy_mod_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Renesas R-Car Gen2 USB phy");
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
xhci probably to generates illegal TRB for fragmented sends.
I can't see any code in xhci-ring.c that ensures that a LINK TRB is always correctly aligned when a transfer descriptor has a link TRB in the middle of a chain of data TRBs. See section 4.11.7.1 of the 1.0 version of the xhci specification. I don't think we are seeing such issues, but any code that generates SG urb could easily do so. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications
Some MBIM devices send back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE
notifications
when sending a message over multiple fragments or when there are unsolicited
messages available.
Count up the number of USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications received
and decrement the count and submit the urb for the next response each time
userspace
completes a read the response.
Signed-off-by: Greg Suarez
---
drivers/usb/class/cdc-wdm.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index d3318a0..589ea58 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -101,6 +101,7 @@ struct wdm_device {
struct work_struct rxwork;
int werr;
int rerr;
+ int resp_count;
struct list_headdevice_list;
int (*manage_power)(struct usb_interface *, int);
@@ -262,9 +263,9 @@ static void wdm_int_callback(struct urb *urb)
}
spin_lock(&desc->iuspin);
- clear_bit(WDM_READ, &desc->flags);
responding = test_and_set_bit(WDM_RESPONDING, &desc->flags);
- if (!responding && !test_bit(WDM_DISCONNECTING, &desc->flags)
+ if (!desc->resp_count++ && !responding
+ && !test_bit(WDM_DISCONNECTING, &desc->flags)
&& !test_bit(WDM_SUSPENDING, &desc->flags)) {
rv = usb_submit_urb(desc->response, GFP_ATOMIC);
dev_dbg(&desc->intf->dev, "%s: usb_submit_urb %d",
@@ -521,10 +522,36 @@ retry:
desc->length -= cntr;
/* in case we had outstanding data */
- if (!desc->length)
+ if (!desc->length) {
clear_bit(WDM_READ, &desc->flags);
- spin_unlock_irq(&desc->iuspin);
+ if (--desc->resp_count) {
+ set_bit(WDM_RESPONDING, &desc->flags);
+ spin_unlock_irq(&desc->iuspin);
+
+ rv = usb_submit_urb(desc->response, GFP_KERNEL);
+ if (rv) {
+ dev_err(&desc->intf->dev,
+ "%s: usb_submit_urb failed with result
%d\n",
+ __func__, rv);
+ spin_lock_irq(&desc->iuspin);
+ clear_bit(WDM_RESPONDING, &desc->flags);
+ spin_unlock_irq(&desc->iuspin);
+
+ if (rv == -ENOMEM) {
+ rv = schedule_work(&desc->rxwork);
+ if (rv)
+ dev_err(&desc->intf->dev,
"Cannot schedule work\n");
+ } else {
+ spin_lock_irq(&desc->iuspin);
+ desc->resp_count = 0;
+ spin_unlock_irq(&desc->iuspin);
+ }
+ }
+ } else
+ spin_unlock_irq(&desc->iuspin);
+ } else
+ spin_unlock_irq(&desc->iuspin);
rv = cntr;
@@ -635,6 +662,9 @@ static int wdm_release(struct inode *inode, struct file
*file)
if (!test_bit(WDM_DISCONNECTING, &desc->flags)) {
dev_dbg(&desc->intf->dev, "wdm_release: cleanup");
kill_urbs(desc);
+ spin_lock_irq(&desc->iuspin);
+ desc->resp_count = 0;
+ spin_unlock_irq(&desc->iuspin);
desc->manage_power(desc->intf, 0);
} else {
/* must avoid dev_printk here as desc->intf is invalid
*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pl2303: restore the old baud rate encoding for HXD (and newer) chips
Am 29.10.2013 18:12, schrieb Frank Schäfer: > Am 29.10.2013 10:07, schrieb Mika Westerberg: >> On Mon, Oct 28, 2013 at 07:50:44PM +0100, Frank Schäfer wrote: >>> Mika Westerberg has reported that the fixed+improved divisor based baud >>> rate >>> encoding method doesn't work anymore with his HXD device. >>> So until we've found out what's going on, reintroduce the old encoding >>> algorithm >>> and use it for this and all newer chips for baud rates > 115200 baud. >>> Also switch back to the direct encoding method for baud rates <= 115200, >>> because >>> it's unclear if the old divisor based encoding algorithm works for them. >>> >>> Reported-by: Mika Westerberg >>> Signed-off-by: Frank Schäfer >> Tried this and with 115200 it works and fixes the problem. However, with >> speeds like 230400 and 460800 it still corrupts data. > Well, with this patch we go back to what we did since kernel 3.1 (since > commit 8d48fdf689fe "USB: PL2303: correctly handle baudrates above > 115200"), so you should face the same problems with these kernels, too. I've double checked that. With this patch applied to 3.12-rc the baud rate encoding is exactly the same as in 3.11 (for HXD chips). Are you sure your test setup is reliable / comparable ? Could you please re-check your results ? Regards, Frank > > Please note that there are serious doubts with regards to the baud rate > precision of this algorithm and if it has really ever been working with > all chips. > The commit description doesn't say where it comes from (likey based on > reverse-enginnering) and which chips it tries to fix. :( We've contacted > the author, but got no reply. > With HX chips, it only worked "more or less" for baud rates ~115200 to > ~50 and but the actual baud rate always differed a little. > With commit 57ce61aad748 we fixed/improved this algorithm, but > apparently this doesn't work for HXD chips (which is a bit surprising). > > I hope I'll get one of these devices at the end of this week. > >> I also got few whitespace warnings when applied this using 'git am'. > Ick, thanks. Will send a fixed version. > > Regards, > Frank > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LTE vodafone K5150 12d1 1f16 ; 12d1 1575 mbim IPV6/ipv4
Am Montag, 28. Oktober 2013, 09:46:30 schrieben Sie: > The patch requires v3.12 I tried it. It hasn't crashed, but it hasn't worked too. Two traces are attached. Regards, Thomas mbim-5150-20131029-any.pcapng.7z Description: application/7z-compressed mbim-5150-20131029-wwan0.pcapng.7z Description: application/7z-compressed
Re: LTE vodafone K5150 12d1 1f16 ; 12d1 1575 mbim IPV6/ipv4
Thomas Schäfer writes: > Am Montag, 28. Oktober 2013, 09:46:30 schrieben Sie: >> The patch requires v3.12 > > I tried it. > > It hasn't crashed, but it hasn't worked too. Then it's working a lot better than expected :-) > Two traces are attached. Thanks. I'll take a look, but I don't expect to be able to fix this without being able to test it. Sorry. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LTE vodafone K5150 12d1 1f16 ; 12d1 1575 mbim IPV6/ipv4
Thomas Schäfer writes: > Am Montag, 28. Oktober 2013, 09:46:30 schrieben Sie: >> The patch requires v3.12 > > I tried it. > > It hasn't crashed, but it hasn't worked too. > > Two traces are attached. OK, I see two issues: - dropping the incoming packets was not so smart wrt debugging. The dumps looks odd without the NS packets from the modem - The NAs look fine, but they don't include the (meaningless) link address option. Maybe the modem wants that? Worth trying Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/15] rework port power control
On Tue, Oct 29, 2013 at 8:05 AM, Alan Stern wrote: > On Mon, 28 Oct 2013, Dan Williams wrote: > >> > In fact, the reason for calling usb_autopm_get_interface was to prevent >> > the hub from being suspended while we change the port's power state. >> > Something like this may still be needed. >> > >> >> With the device model change and no longer telling the hub interface >> device to pm_suspend_ignore_children() the pm subsystem will manage >> this wake up for us. > > Provided you don't try to make any power changes while the port is > suspended. > > For example, consider the case where a new SuperSpeed device is plugged > into a USB-3 port. The peer USB-2 port has been suspended at full > power. Now you will want to power it off. You can't just change its > power level directly; you have to resume it and suspend it again. > Yes, that's handled by the PM core since it resumes devices before updating the flags. I'll update the policy to always >> > Since a port never needs to be connected to more than one other port, >> > you could implement connectors simply by storing a "peer" pointer in >> > the usb_port structure. >> >> Yes, no need to design for the non-existent 3 connection types in a >> port case now. >> >> Another simplification is that a "struct usb_domain" is currently >> known to never span a controller boundary. So, rather than adding >> ports to a usb_connector / usb_domain container hierarchy I think we >> can simply scan the child devices under the xhci device and look for >> is_usb_port() instances. > > I'm not sure why you would want to do this. In order to identify which > usb_port device matches a particular ACPI identifier? Right, the patches in this series create a list of "ports with platform data" at usb_acpi_find_device() time. Rather than maintain a separate list we can just use device_find_child() for the matching port. >> In the meantime I am still thinking of the approach to reliably link >> USB3 hub ports to their peers. The spec mandates that they be >> labelled the same for this purpose (USB3 spec section 10.3.3). >> However, to determine peer relationships for downstream hubs I think >> we will need walk the hierarchy back to the root connector and compare >> paths. Tier mismatch makes it so we can not look at the path back to >> the root port. Unless there is some unique way to identify a hub? >> Also need to think about what to do in the case a hub implementation >> does not label its ports per the spec > > In the case of tier mismatches or other weirdness, there is no choice > but to rely on the platform information. Yes, to seed the initial peers. > When there is no platform information (for example, in the case of a > hotplugged hub), the process is simpler. Support hub H is plugged into > parent port P, and you want to find the peer to port Q on the hub. > Start by looking at P's peer -- call it P'. There should be a hub H' > attached to P'. Then Q' (the peer to Q) is the port on H' having the > same port number as Q. If either H' or Q' doesn't exist then there is > no peer. (For example, H' might not exist if H is a USB-2 hub. If H' > exists but Q' doesn't then something is wrong somewhere.) ...like mistmatched debounce timing on the respective ports, but this should settle eventually. I think using the autosuspend timer fits nicely for this case. > > As for hubs with improper port labelling... We'll worry about that when > we run across it. > >> All the questions about peering hub ports goes away if the policy on >> those is forced to hotplug only. I think the patch that allows the >> policy (connect_type) to be updated from userspace should also take >> care to error out on hub ports. Follow-on patches can tackle the >> external hub case. > > I'm not sure I follow. What's wrong with allowing the user to change > the connect-type for a port on an external hub? Nothing wrong with that, I was just thinking out loud about the case where external hub peers are not being identified... but I'll include that implementation in the series so the point is moot. -- 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/PATCH v2 1/3] usb: gadget: add quirks field to struct usb_gadget
Due to USB controllers may have different restrictions, usb gadget layer
needs to provide a generic way to inform gadget functions to complain
with non-standard requirements.
This patch adds 'quirks' field to struct usb_gadget and the first quirk
called USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE necessary to inform when
controller's epout requires buffer size to be aligned to MaxPacketSize.
Signed-off-by: David Cohen
---
include/linux/usb/gadget.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 942ef5e..7014ad9 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -540,6 +540,11 @@ struct usb_gadget {
struct device dev;
unsignedout_epnum;
unsignedin_epnum;
+
+ u32 quirks;
+/* epout requires buffer size to be aligned to MaxPacketSize */
+#define USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE (1 << 0)
+
};
#define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
--
1.8.4.rc3
--
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/PATCH v2 2/3] usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize
Use USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE quirk to check if buffer size
requires to be aligned to maxpacketsize of an out endpoint.
ffs_epfile_io() needs to pad epout buffer to match above condition if
quirk is found.
Signed-off-by: David Cohen
---
drivers/usb/gadget/f_fs.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b78..2988eb7 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -755,10 +755,12 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file->private_data;
+ struct usb_gadget *gadget = epfile->ffs->gadget;
struct ffs_ep *ep;
char *data = NULL;
ssize_t ret;
int halt;
+ size_t orig_len = len;
goto first_try;
do {
@@ -794,6 +796,21 @@ first_try:
goto error;
}
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ if (gadget->quirks & USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE &&
+ read && !IS_ALIGNED(len, ep->ep->desc->wMaxPacketSize)) {
+ size_t old_len = len;
+ len = roundup(orig_len,
+ (size_t)ep->ep->desc->wMaxPacketSize);
+ if (unlikely(data) && len > old_len) {
+ kfree(data);
+ data = NULL;
+ }
+ }
+
/* Allocate & copy */
if (!halt && !data) {
data = kzalloc(len, GFP_KERNEL);
--
1.8.4.rc3
--
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/PATCH v2 0/3] add gadget quirk to adapt f_fs for DWC3
Hi, These patches are a proposal to add gadget quirks in an immediate objective to adapt f_fs when using DWC3 controller. But the quirk solution is generic and can be used by other controllers to adapt gadget functions to their non-standard restrictions. This change is necessary to make Android's adbd service to work on Intel Merrifield with f_fs instead of out-of-tree android gadget. --- David Cohen (3): usb: gadget: add quirks field to struct usb_gadget usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget driver drivers/usb/dwc3/gadget.c | 1 + drivers/usb/gadget/f_fs.c | 17 + include/linux/usb/gadget.h | 5 + 3 files changed, 23 insertions(+) -- 1.8.4.rc3 -- 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/PATCH v2 3/3] usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget driver
DWC3 requires epout to have buffer size aligned to MaxPacketSize value. This patch adds necessary quirk for it. Signed-off-by: David Cohen --- drivers/usb/dwc3/gadget.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 5452c0f..0dcc89f 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2598,6 +2598,7 @@ int dwc3_gadget_init(struct dwc3 *dwc) dwc->gadget.speed = USB_SPEED_UNKNOWN; dwc->gadget.sg_supported= true; dwc->gadget.name= "dwc3-gadget"; + dwc->gadget.quirks = USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE; /* * REVISIT: Here we should clear all pending IRQs to be -- 1.8.4.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 2/3] r8152: modify the tx flow
From: Hayes Wang Date: Tue, 29 Oct 2013 15:56:16 +0800 > Support stopping and waking tx queue. The maximum tx queue length > is 60. What is so special about the number 60? It seems arbitrary, and if it isn't arbitrary you haven't described why this value was choosen. I've asked you politely last time around to significantly improve the quality of your commit messages, and you haven't done this at all. I'm not applying any of these patches until your commit messages properly describe your changes completely. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v2 0/3] add gadget quirk to adapt f_fs for DWC3
> From: David Cohen > Sent: Tuesday, October 29, 2013 2:53 PM > > These patches are a proposal to add gadget quirks in an immediate objective to > adapt f_fs when using DWC3 controller. But the quirk solution is generic and > can be used by other controllers to adapt gadget functions to their > non-standard restrictions. > > This change is necessary to make Android's adbd service to work on Intel > Merrifield with f_fs instead of out-of-tree android gadget. > > --- > David Cohen (3): > usb: gadget: add quirks field to struct usb_gadget > usb: ffs: check quirk to pad epout buf size when not aligned to > maxpacketsize > usb: dwc3: add quirk USB_GADGET_QUIRK_EP_OUT_ALIGNED_SIZE to gadget > driver > > drivers/usb/dwc3/gadget.c | 1 + > drivers/usb/gadget/f_fs.c | 17 + > include/linux/usb/gadget.h | 5 + > 3 files changed, 23 insertions(+) Wouldn't it be simpler and safer to just do this unconditionally? Sure, you need it for DWC3 because the controller refuses to do an OUT transfer at all if the transfer size is less than maxpacketsize. But it's possible that other controllers allow the transfer, and it works in most cases, but if an error occurs and the host sends too much data, they could overrun the buffer and crash your device. For example, the DWC2 databook says "For OUT transfers, the Transfer Size field in the endpoint's Transfer Size register must be a multiple of the maximum packet size of the endpoint". But I don't think the controller enforces that, it is up to the programmer to do the right thing. So that controller probably needs this quirk also. There could be more like that which we don't know about. So unless the buffer allocation code is in a real fast path, I would suggest to just do the aligned buffer allocation always. -- 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: [PATCH v3 2/4] usb: usbtest: support usb2 extension descriptor test
On Mon, Oct 28, 2013 at 11:31:33PM +0800, Huang Rui wrote: > In Test 9 of usbtest module, it is used for performing chapter 9 tests N > times. > > USB2.0 Extension descriptor is one of the generic device-level capbility > descriptors which added in section 9.6.2.1 of USB 3.0 spec. > > This patch adds to support getting usb2.0 extension descriptor test > scenario for USB 3.0. > > Signed-off-by: Huang Rui This patch adds build warnings, so I can't take it: drivers/usb/misc/usbtest.c: In function ‘ch9_postconfig’: drivers/usb/misc/usbtest.c:754:48: warning: comparison of distinct pointer types lacks a cast [enabled by default] drivers/usb/misc/usbtest.c:769:39: warning: comparison of distinct pointer types lacks a cast [enabled by default] So does one of the other patches after this one as well. Please fix that up and resend and be more careful in the future. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] usb: chipidea: add freescale imx28 special write register method
On Mon, Oct 28, 2013 at 11:47:53AM +0100, Marek Vasut wrote:
> Dear Hector Palacios,
>
> > Dear Peter,
> >
> > On 10/25/2013 08:02 AM, Peter Chen wrote:
> > > According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> > > register error issue", All USB register write operations must
> > > use the ARM SWP instruction. So, we implement special hw_write
> > > and hw_test_and_clear for imx28.
> > >
> > > Discussion for it at below:
> > > http://marc.info/?l=linux-usb&m=137996395529294&w=2
> > >
> > > Signed-off-by: Peter Chen
> > > ---
> > > Changes for v2:
> > > - Rebase to latest usb-next tree
> > >
> > > drivers/usb/chipidea/ci.h| 23 +++
> > > drivers/usb/chipidea/core.c |2 ++
> > > drivers/usb/chipidea/host.c |1 +
> > > include/linux/usb/chipidea.h |1 +
> > > 4 files changed, 27 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> > > index 1c94fc5..4eb61d0 100644
> > > --- a/drivers/usb/chipidea/ci.h
> > > +++ b/drivers/usb/chipidea/ci.h
> > > @@ -173,6 +173,8 @@ struct ci_hdrc {
> > >
> > > struct dentry *debugfs;
> > > boolid_event;
> > > boolb_sess_valid_event;
> > >
> > > + /* imx28 needs swp instruction for writing */
> > > + boolimx28_write_fix;
> > >
> > > };
> > >
> > > static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
> > >
> > > @@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
> > > ci_hw_regs reg, u32 mask)
> > >
> > > return ioread32(ci->hw_bank.regmap[reg]) & mask;
> > >
> > > }
> > >
> > > +#ifdef CONFIG_SOC_IMX28
> > > +static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
> > > +{
> > > + __asm__ ("swp %0, %0, [%1]" : : "r"(val32), "r"(addr));
> > > +}
> > > +#endif
> > > +
> > >
> > > /**
> > >
> > >* hw_write: writes to a hw register
> > >* @reg: register index
> > >
> > > @@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci, enum
> > > ci_hw_regs reg,
> > >
> > > data = (ioread32(ci->hw_bank.regmap[reg]) & ~mask)
> > >
> > > | (data & mask);
> > >
> > > +#ifdef CONFIG_SOC_IMX28
> > > + if (ci->imx28_write_fix)
> > > + imx28_ci_writel(data, ci->hw_bank.regmap[reg]);
> > > + else
> > > + iowrite32(data, ci->hw_bank.regmap[reg]);
> > > +#else
> > >
> > > iowrite32(data, ci->hw_bank.regmap[reg]);
> > >
> > > +#endif
> > >
> > > }
> > >
> > > /**
> > >
> > > @@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct ci_hdrc
> > > *ci, enum ci_hw_regs reg,
> > >
> > > {
> > >
> > > u32 val = ioread32(ci->hw_bank.regmap[reg]) & mask;
> > >
> > > +#ifdef CONFIG_SOC_IMX28
> > > + if (ci->imx28_write_fix)
> > > + imx28_ci_writel(val, ci->hw_bank.regmap[reg]);
> > > + else
> > > + iowrite32(val, ci->hw_bank.regmap[reg]);
> > > +#else
> > >
> > > iowrite32(val, ci->hw_bank.regmap[reg]);
> > >
> > > +#endif
> > >
> > > return val;
> > >
> > > }
> >
> > Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
> > The check is done on the new flag ci->imx28_write_fix which exists for all
> > platforms, isn't it?.
>
> The SWP instruction is specific to ARM, so you'd need to stub-out the
> imx28_ci_writel() with ifdef then.
That's better than the mess of #ifdefs this patch adds, which isn't ok
at all :(
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: Move R-Car Gen2 driver registration to postcore_inictall
On Tue, Oct 29, 2013 at 09:19:09PM +0400, Valentine wrote: > On 10/29/2013 09:00 PM, Laurent Pinchart wrote: > >Hi Valentine, > > > >Thank you for the patch. > > > >On Tuesday 29 October 2013 20:21:06 Valentine Barshak wrote: > >>USB phy controls USB channels 0 and 2 which are shared between > >>PCI USB host controllers and USBHS/USBSS respectively. > >> > >>This Initializes USB phy driver earlier because we need it > >>before PCI USB host controllers are initialized. > > > >Can't you use deferred probing ? > > No, unfortunately this doesn't work with PCI. > We need the USB PHY set up before the PCI driver starts. > PCI controllers should be initialized via subsys_initcall and can't be built > as a module. > Deferred probing is done at late_initcall and that's far too late in this > case. > > The MXS USB phy uses the similar approach, initializing the driver via > postcore_initcall. I _HATE_ this "make this driver later than the others" mess. I'll not take patches that move drivers to different initcalls, sorry. Please fix up the link order, or use deferred probing, as that is why it was created. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] usb: chipidea: add freescale imx28 special write register method
On Tue, Oct 29, 2013 at 04:54:47PM -0700, gre...@linuxfoundation.org wrote:
> On Mon, Oct 28, 2013 at 11:47:53AM +0100, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> > > Dear Peter,
> > >
> > > On 10/25/2013 08:02 AM, Peter Chen wrote:
> > > > According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> > > > register error issue", All USB register write operations must
> > > > use the ARM SWP instruction. So, we implement special hw_write
> > > > and hw_test_and_clear for imx28.
> > > >
> > > > Discussion for it at below:
> > > > http://marc.info/?l=linux-usb&m=137996395529294&w=2
> > > >
> > > > Signed-off-by: Peter Chen
> > > > ---
> > > > Changes for v2:
> > > > - Rebase to latest usb-next tree
> > > >
> > > > drivers/usb/chipidea/ci.h| 23 +++
> > > > drivers/usb/chipidea/core.c |2 ++
> > > > drivers/usb/chipidea/host.c |1 +
> > > > include/linux/usb/chipidea.h |1 +
> > > > 4 files changed, 27 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> > > > index 1c94fc5..4eb61d0 100644
> > > > --- a/drivers/usb/chipidea/ci.h
> > > > +++ b/drivers/usb/chipidea/ci.h
> > > > @@ -173,6 +173,8 @@ struct ci_hdrc {
> > > >
> > > > struct dentry *debugfs;
> > > > boolid_event;
> > > > boolb_sess_valid_event;
> > > >
> > > > + /* imx28 needs swp instruction for writing */
> > > > + boolimx28_write_fix;
> > > >
> > > > };
> > > >
> > > > static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
> > > >
> > > > @@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
> > > > ci_hw_regs reg, u32 mask)
> > > >
> > > > return ioread32(ci->hw_bank.regmap[reg]) & mask;
> > > >
> > > > }
> > > >
> > > > +#ifdef CONFIG_SOC_IMX28
> > > > +static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
> > > > +{
> > > > + __asm__ ("swp %0, %0, [%1]" : : "r"(val32), "r"(addr));
> > > > +}
> > > > +#endif
> > > > +
> > > >
> > > > /**
> > > >
> > > >* hw_write: writes to a hw register
> > > >* @reg: register index
> > > >
> > > > @@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci,
> > > > enum
> > > > ci_hw_regs reg,
> > > >
> > > > data = (ioread32(ci->hw_bank.regmap[reg]) & ~mask)
> > > >
> > > > | (data & mask);
> > > >
> > > > +#ifdef CONFIG_SOC_IMX28
> > > > + if (ci->imx28_write_fix)
> > > > + imx28_ci_writel(data, ci->hw_bank.regmap[reg]);
> > > > + else
> > > > + iowrite32(data, ci->hw_bank.regmap[reg]);
> > > > +#else
> > > >
> > > > iowrite32(data, ci->hw_bank.regmap[reg]);
> > > >
> > > > +#endif
> > > >
> > > > }
> > > >
> > > > /**
> > > >
> > > > @@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct ci_hdrc
> > > > *ci, enum ci_hw_regs reg,
> > > >
> > > > {
> > > >
> > > > u32 val = ioread32(ci->hw_bank.regmap[reg]) & mask;
> > > >
> > > > +#ifdef CONFIG_SOC_IMX28
> > > > + if (ci->imx28_write_fix)
> > > > + imx28_ci_writel(val, ci->hw_bank.regmap[reg]);
> > > > + else
> > > > + iowrite32(val, ci->hw_bank.regmap[reg]);
> > > > +#else
> > > >
> > > > iowrite32(val, ci->hw_bank.regmap[reg]);
> > > >
> > > > +#endif
> > > >
> > > > return val;
> > > >
> > > > }
> > >
> > > Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
> > > The check is done on the new flag ci->imx28_write_fix which exists for all
> > > platforms, isn't it?.
> >
> > The SWP instruction is specific to ARM, so you'd need to stub-out the
> > imx28_ci_writel() with ifdef then.
>
> That's better than the mess of #ifdefs this patch adds, which isn't ok
> at all :(
>
You mean try to reduce the number of #ifdef?
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: chipidea: only get vbus regulator for non-peripheral mode
If the user chooses peripheral mode for this controller, the vbus
regulator doesn't need to get, since the host will supply the vbus,
it can save one vbus pin for other usage.
Signed-off-by: Peter Chen
Tested-by: Frank Li
---
drivers/usb/chipidea/core.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 357a059..e26e616 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -392,18 +392,6 @@ static irqreturn_t ci_irq(int irq, void *data)
static int ci_get_platdata(struct device *dev,
struct ci_hdrc_platform_data *platdata)
{
- /* Get the vbus regulator */
- platdata->reg_vbus = devm_regulator_get(dev, "vbus");
- if (PTR_ERR(platdata->reg_vbus) == -EPROBE_DEFER) {
- return -EPROBE_DEFER;
- } else if (PTR_ERR(platdata->reg_vbus) == -ENODEV) {
- platdata->reg_vbus = NULL; /* no vbus regualator is needed */
- } else if (IS_ERR(platdata->reg_vbus)) {
- dev_err(dev, "Getting regulator error: %ld\n",
- PTR_ERR(platdata->reg_vbus));
- return PTR_ERR(platdata->reg_vbus);
- }
-
if (!platdata->phy_mode)
platdata->phy_mode = of_usb_get_phy_mode(dev->of_node);
@@ -413,6 +401,21 @@ static int ci_get_platdata(struct device *dev,
if (platdata->dr_mode == USB_DR_MODE_UNKNOWN)
platdata->dr_mode = USB_DR_MODE_OTG;
+ if (platdata->dr_mode != USB_DR_MODE_PERIPHERAL) {
+ /* Get the vbus regulator */
+ platdata->reg_vbus = devm_regulator_get(dev, "vbus");
+ if (PTR_ERR(platdata->reg_vbus) == -EPROBE_DEFER) {
+ return -EPROBE_DEFER;
+ } else if (PTR_ERR(platdata->reg_vbus) == -ENODEV) {
+ /* no vbus regualator is needed */
+ platdata->reg_vbus = NULL;
+ } else if (IS_ERR(platdata->reg_vbus)) {
+ dev_err(dev, "Getting regulator error: %ld\n",
+ PTR_ERR(platdata->reg_vbus));
+ return PTR_ERR(platdata->reg_vbus);
+ }
+ }
+
return 0;
}
--
1.7.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 v3 2/4] usb: usbtest: support usb2 extension descriptor test
On Tue, Oct 29, 2013 at 04:50:25PM -0700, Greg Kroah-Hartman wrote: > On Mon, Oct 28, 2013 at 11:31:33PM +0800, Huang Rui wrote: > > In Test 9 of usbtest module, it is used for performing chapter 9 tests N > > times. > > > > USB2.0 Extension descriptor is one of the generic device-level capbility > > descriptors which added in section 9.6.2.1 of USB 3.0 spec. > > > > This patch adds to support getting usb2.0 extension descriptor test > > scenario for USB 3.0. > > > > Signed-off-by: Huang Rui > > This patch adds build warnings, so I can't take it: > > drivers/usb/misc/usbtest.c: In function ‘ch9_postconfig’: > drivers/usb/misc/usbtest.c:754:48: warning: comparison of distinct pointer > types lacks a cast [enabled by default] > drivers/usb/misc/usbtest.c:769:39: warning: comparison of distinct pointer > types lacks a cast [enabled by default] > > So does one of the other patches after this one as well. > > Please fix that up and resend and be more careful in the future. > Hi Greg, Sorry, I missed this warning. And will fix it soon and take care in future. Thanks, Rui -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/cdc_ncm: fix null pointer panic at usbnet_link_change
From: "Du, ChangbinX" Date: Tue, 29 Oct 2013 03:30:42 + > In cdc_ncm_bind() function, it call cdc_ncm_bind_common() to setup usb. > But cdc_ncm_bind_common() may meet error and cause usbnet_disconnect() > be called which calls free_netdev(net). Thus usbnet structure(alloced > with net_device structure) will be freed,too. > So we cannot call usbnet_link_change() if cdc_ncm_bind_common() return > error. This is not the bug. The problem is in cdc_ncm_bind_common(). It seems to leave dangling interface data pointers in some cases, and then branches just to "error" so that they don't get cleared back out. This bypasses the protection present in cdc_ncm_disconnect() meant to avoid this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: hcd: move controller wakeup setting initialization to individual driver
Individual controller driver has different requirement for wakeup
setting, so move it from core to itself. In order to align with
current etting the default wakeup setting is enabled (except for
chipidea host).
Pass compile test with below commands:
make O=outout/all allmodconfig
make -j$CPU_NUM O=outout/all drivers/usb
Signed-off-by: Peter Chen
---
drivers/usb/c67x00/c67x00-hcd.c |1 +
drivers/usb/core/hcd-pci.c |2 ++
drivers/usb/core/hcd.c |6 --
drivers/usb/gadget/dummy_hcd.c |2 ++
drivers/usb/host/ehci-atmel.c|1 +
drivers/usb/host/ehci-exynos.c |1 +
drivers/usb/host/ehci-fsl.c |1 +
drivers/usb/host/ehci-grlib.c|1 +
drivers/usb/host/ehci-mv.c |1 +
drivers/usb/host/ehci-mxc.c |1 +
drivers/usb/host/ehci-octeon.c |1 +
drivers/usb/host/ehci-omap.c |1 +
drivers/usb/host/ehci-orion.c|1 +
drivers/usb/host/ehci-platform.c |1 +
drivers/usb/host/ehci-pmcmsp.c |4 +++-
drivers/usb/host/ehci-ppc-of.c |1 +
drivers/usb/host/ehci-ps3.c |1 +
drivers/usb/host/ehci-sead3.c|1 +
drivers/usb/host/ehci-sh.c |1 +
drivers/usb/host/ehci-spear.c|1 +
drivers/usb/host/ehci-tegra.c|1 +
drivers/usb/host/ehci-tilegx.c |1 +
drivers/usb/host/ehci-w90x900.c |1 +
drivers/usb/host/ehci-xilinx-of.c|4 +++-
drivers/usb/host/fhci-hcd.c |1 +
drivers/usb/host/fotg210-hcd.c |1 +
drivers/usb/host/fusbh200-hcd.c |1 +
drivers/usb/host/hwa-hc.c|1 +
drivers/usb/host/imx21-hcd.c |1 +
drivers/usb/host/isp116x-hcd.c |1 +
drivers/usb/host/isp1362-hcd.c |1 +
drivers/usb/host/isp1760-hcd.c |1 +
drivers/usb/host/ohci-at91.c |4 +++-
drivers/usb/host/ohci-da8xx.c|2 ++
drivers/usb/host/ohci-exynos.c |1 +
drivers/usb/host/ohci-jz4740.c |1 +
drivers/usb/host/ohci-nxp.c |4 +++-
drivers/usb/host/ohci-octeon.c |1 +
drivers/usb/host/ohci-omap.c |1 +
drivers/usb/host/ohci-omap3.c|1 +
drivers/usb/host/ohci-platform.c |1 +
drivers/usb/host/ohci-ppc-of.c |4 +++-
drivers/usb/host/ohci-ps3.c |1 +
drivers/usb/host/ohci-pxa27x.c |4 +++-
drivers/usb/host/ohci-s3c2410.c |1 +
drivers/usb/host/ohci-sa.c |4 +++-
drivers/usb/host/ohci-sm501.c|1 +
drivers/usb/host/ohci-spear.c|4 +++-
drivers/usb/host/ohci-tilegx.c |1 +
drivers/usb/host/ohci-tmio.c |1 +
drivers/usb/host/oxu210hp-hcd.c |1 +
drivers/usb/host/r8a66597-hcd.c |1 +
drivers/usb/host/sl811-hcd.c |1 +
drivers/usb/host/u132-hcd.c |1 +
drivers/usb/host/uhci-grlib.c|1 +
drivers/usb/host/uhci-platform.c |1 +
drivers/usb/host/whci/hcd.c |1 +
drivers/usb/host/xhci-pci.c |1 +
drivers/usb/host/xhci-plat.c |2 ++
drivers/usb/musb/musb_host.c |1 +
drivers/usb/phy/phy-msm-usb.c|1 +
drivers/usb/phy/phy-mv-usb.c |6 --
drivers/usb/renesas_usbhs/mod_host.c |1 +
63 files changed, 85 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/c67x00/c67x00-hcd.c b/drivers/usb/c67x00/c67x00-hcd.c
index 75e47b8..1920fc1 100644
--- a/drivers/usb/c67x00/c67x00-hcd.c
+++ b/drivers/usb/c67x00/c67x00-hcd.c
@@ -384,6 +384,7 @@ int c67x00_hcd_probe(struct c67x00_sie *sie)
goto err2;
}
+ device_wakeup_enable(hcd->self.controller);
spin_lock_irqsave(&sie->lock, flags);
sie->private_data = c67x00;
sie->irq = c67x00_hcd_irq;
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index dfe9d0f..3ad2205 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -267,6 +267,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
retval = usb_add_hcd(hcd, hcd_irq, IRQF_SHARED);
if (retval != 0)
dev_set_drvdata(&dev->dev, NULL);
+ device_wakeup_enable(hcd->self.controller);
for_each_companion(dev, hcd, ehci_post_add);
up_write(&companions_rwsem);
} else {
@@ -277,6 +278,7 @@ int usb_hcd_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
dev_set_drvdata(&dev->dev, NULL);
else
for_each_companion(dev, hcd, non_ehci_add);
+ device_wakeup_enable(hcd->self.controller);
up_read(&companions_rwsem);
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 6bffb8c..03b77f8 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2693,
RE: [PATCH net 2/3] r8152: modify the tx flow
David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, October 30, 2013 5:50 AM > To: Hayeswang > Cc: net...@vger.kernel.org; nic_swsd; > linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org > Subject: Re: [PATCH net 2/3] r8152: modify the tx flow > > From: Hayes Wang > Date: Tue, 29 Oct 2013 15:56:16 +0800 > > > Support stopping and waking tx queue. The maximum tx queue length > > is 60. > > What is so special about the number 60? It seems arbitrary, and if > it isn't arbitrary you haven't described why this value was choosen. The value is arbitrary. I think it is better to stop tx when queuing many packets, otherwise all the available memory may be used for tx skb. The queue length could be any value or unlimited if the memory is enough. Should I remove it? > I've asked you politely last time around to significantly improve > the quality of your commit messages, and you haven't done this at > all. I thought you indicated the last patch only and the others are clear enough. I would improve them. > I'm not applying any of these patches until your commit messages > properly describe your changes completely. > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/5] usb: chipidea: add freescale imx28 special write register method
On Wed, Oct 30, 2013 at 08:53:42AM +0800, Peter Chen wrote:
> On Tue, Oct 29, 2013 at 04:54:47PM -0700, gre...@linuxfoundation.org wrote:
> > On Mon, Oct 28, 2013 at 11:47:53AM +0100, Marek Vasut wrote:
> > > Dear Hector Palacios,
> > >
> > > > Dear Peter,
> > > >
> > > > On 10/25/2013 08:02 AM, Peter Chen wrote:
> > > > > According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> > > > > register error issue", All USB register write operations must
> > > > > use the ARM SWP instruction. So, we implement special hw_write
> > > > > and hw_test_and_clear for imx28.
> > > > >
> > > > > Discussion for it at below:
> > > > > http://marc.info/?l=linux-usb&m=137996395529294&w=2
> > > > >
> > > > > Signed-off-by: Peter Chen
> > > > > ---
> > > > > Changes for v2:
> > > > > - Rebase to latest usb-next tree
> > > > >
> > > > > drivers/usb/chipidea/ci.h| 23 +++
> > > > > drivers/usb/chipidea/core.c |2 ++
> > > > > drivers/usb/chipidea/host.c |1 +
> > > > > include/linux/usb/chipidea.h |1 +
> > > > > 4 files changed, 27 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> > > > > index 1c94fc5..4eb61d0 100644
> > > > > --- a/drivers/usb/chipidea/ci.h
> > > > > +++ b/drivers/usb/chipidea/ci.h
> > > > > @@ -173,6 +173,8 @@ struct ci_hdrc {
> > > > >
> > > > > struct dentry *debugfs;
> > > > > boolid_event;
> > > > > boolb_sess_valid_event;
> > > > >
> > > > > + /* imx28 needs swp instruction for writing */
> > > > > + boolimx28_write_fix;
> > > > >
> > > > > };
> > > > >
> > > > > static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
> > > > >
> > > > > @@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci,
> > > > > enum
> > > > > ci_hw_regs reg, u32 mask)
> > > > >
> > > > > return ioread32(ci->hw_bank.regmap[reg]) & mask;
> > > > >
> > > > > }
> > > > >
> > > > > +#ifdef CONFIG_SOC_IMX28
> > > > > +static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
> > > > > +{
> > > > > + __asm__ ("swp %0, %0, [%1]" : : "r"(val32), "r"(addr));
> > > > > +}
> > > > > +#endif
> > > > > +
> > > > >
> > > > > /**
> > > > >
> > > > >* hw_write: writes to a hw register
> > > > >* @reg: register index
> > > > >
> > > > > @@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci,
> > > > > enum
> > > > > ci_hw_regs reg,
> > > > >
> > > > > data = (ioread32(ci->hw_bank.regmap[reg]) & ~mask)
> > > > >
> > > > > | (data & mask);
> > > > >
> > > > > +#ifdef CONFIG_SOC_IMX28
> > > > > + if (ci->imx28_write_fix)
> > > > > + imx28_ci_writel(data, ci->hw_bank.regmap[reg]);
> > > > > + else
> > > > > + iowrite32(data, ci->hw_bank.regmap[reg]);
> > > > > +#else
> > > > >
> > > > > iowrite32(data, ci->hw_bank.regmap[reg]);
> > > > >
> > > > > +#endif
> > > > >
> > > > > }
> > > > >
> > > > > /**
> > > > >
> > > > > @@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct
> > > > > ci_hdrc
> > > > > *ci, enum ci_hw_regs reg,
> > > > >
> > > > > {
> > > > >
> > > > > u32 val = ioread32(ci->hw_bank.regmap[reg]) & mask;
> > > > >
> > > > > +#ifdef CONFIG_SOC_IMX28
> > > > > + if (ci->imx28_write_fix)
> > > > > + imx28_ci_writel(val, ci->hw_bank.regmap[reg]);
> > > > > + else
> > > > > + iowrite32(val, ci->hw_bank.regmap[reg]);
> > > > > +#else
> > > > >
> > > > > iowrite32(val, ci->hw_bank.regmap[reg]);
> > > > >
> > > > > +#endif
> > > > >
> > > > > return val;
> > > > >
> > > > > }
> > > >
> > > > Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
> > > > The check is done on the new flag ci->imx28_write_fix which exists for
> > > > all
> > > > platforms, isn't it?.
> > >
> > > The SWP instruction is specific to ARM, so you'd need to stub-out the
> > > imx28_ci_writel() with ifdef then.
> >
> > That's better than the mess of #ifdefs this patch adds, which isn't ok
> > at all :(
> >
>
> You mean try to reduce the number of #ifdef?
Of course you should.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 2/3] r8152: modify the tx flow
From: hayeswang Date: Wed, 30 Oct 2013 11:03:55 +0800 > David Miller [mailto:da...@davemloft.net] >> Sent: Wednesday, October 30, 2013 5:50 AM >> To: Hayeswang >> Cc: net...@vger.kernel.org; nic_swsd; >> linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org >> Subject: Re: [PATCH net 2/3] r8152: modify the tx flow >> >> From: Hayes Wang >> Date: Tue, 29 Oct 2013 15:56:16 +0800 >> >> > Support stopping and waking tx queue. The maximum tx queue length >> > is 60. >> >> What is so special about the number 60? It seems arbitrary, and if >> it isn't arbitrary you haven't described why this value was choosen. > > The value is arbitrary. I think it is better to stop tx when > queuing many packets, otherwise all the available memory may > be used for tx skb. The queue length could be any value or > unlimited if the memory is enough. Should I remove it? You should at least pick some value that you have analyzed in some way. We've done a lot of work to strongly limit the amount of SKB data which sits in device queues on transmit, and what you're doing here works against to those goals. Ideally you should pick a value which is sufficient to meet two goals at the same time: 1) With constant transmit traffic coming from the networking stack, the device never starves for new transmit data to send. 2) We never queue up more traffic than we need to satisfy requirement #1. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28
Due to imx28 needs ARM swp instruction for writing, we set
CI_HDRC_IMX28_WRITE_FIX for imx28.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci_hdrc_imx.c | 32 ++--
1 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 023d3cb..68f7f5e 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -23,6 +23,26 @@
#include "ci.h"
#include "ci_hdrc_imx.h"
+#define CI_HDRC_IMX_IMX28_WRITE_FIX BIT(0)
+
+struct ci_hdrc_imx_platform_flag {
+ unsigned int flags;
+};
+
+static const struct ci_hdrc_imx_platform_flag imx27_usb_data = {
+};
+
+static const struct ci_hdrc_imx_platform_flag imx28_usb_data = {
+ .flags = CI_HDRC_IMX_IMX28_WRITE_FIX,
+};
+
+static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
+ { .compatible = "fsl,imx28-usb", .data = &imx28_usb_data},
+ { .compatible = "fsl,imx27-usb", .data = &imx27_usb_data},
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
+
struct ci_hdrc_imx_data {
struct usb_phy *phy;
struct platform_device *ci_pdev;
@@ -82,6 +102,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
CI_HDRC_DISABLE_STREAMING,
};
int ret;
+ const struct of_device_id *of_id =
+ of_match_device(ci_hdrc_imx_dt_ids, &pdev->dev);
+ const struct ci_hdrc_imx_platform_flag *imx_platform_flag = of_id->data;
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
if (!data) {
@@ -115,6 +138,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
pdata.phy = data->phy;
+ if (imx_platform_flag->flags & CI_HDRC_IMX_IMX28_WRITE_FIX)
+ pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
+
if (!pdev->dev.dma_mask)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
if (!pdev->dev.coherent_dma_mask)
@@ -174,12 +200,6 @@ static int ci_hdrc_imx_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id ci_hdrc_imx_dt_ids[] = {
- { .compatible = "fsl,imx27-usb", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, ci_hdrc_imx_dt_ids);
-
static struct platform_driver ci_hdrc_imx_driver = {
.probe = ci_hdrc_imx_probe,
.remove = ci_hdrc_imx_remove,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] usb: chipidea: add freescale imx28 special write register method
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement special hw_write
and hw_test_and_clear for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2
Signed-off-by: Peter Chen
---
Changes for v4:
- introducing __hw_write to encapsulate low level write,
it can reduce the duplicated code.
drivers/usb/chipidea/ci.h| 26 --
drivers/usb/chipidea/core.c |2 ++
drivers/usb/chipidea/host.c |1 +
include/linux/usb/chipidea.h |1 +
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 1c94fc5..f9b1914 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -173,6 +173,8 @@ struct ci_hdrc {
struct dentry *debugfs;
boolid_event;
boolb_sess_valid_event;
+ /* imx28 needs swp instruction for writing */
+ boolimx28_write_fix;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
@@ -253,6 +255,26 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
ci_hw_regs reg, u32 mask)
return ioread32(ci->hw_bank.regmap[reg]) & mask;
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
+{
+ __asm__ ("swp %0, %0, [%1]" : : "r"(val32), "r"(addr));
+}
+#endif
+
+static inline void __hw_write(struct ci_hdrc *ci, u32 val,
+ void __iomem *addr)
+{
+#ifdef CONFIG_SOC_IMX28
+ if (ci->imx28_write_fix)
+ imx28_ci_writel(val, addr);
+ else
+ iowrite32(val, addr);
+#else
+ iowrite32(val, addr);
+#endif
+}
+
/**
* hw_write: writes to a hw register
* @reg: register index
@@ -266,7 +288,7 @@ static inline void hw_write(struct ci_hdrc *ci, enum
ci_hw_regs reg,
data = (ioread32(ci->hw_bank.regmap[reg]) & ~mask)
| (data & mask);
- iowrite32(data, ci->hw_bank.regmap[reg]);
+ __hw_write(ci, data, ci->hw_bank.regmap[reg]);
}
/**
@@ -281,7 +303,7 @@ static inline u32 hw_test_and_clear(struct ci_hdrc *ci,
enum ci_hw_regs reg,
{
u32 val = ioread32(ci->hw_bank.regmap[reg]) & mask;
- iowrite32(val, ci->hw_bank.regmap[reg]);
+ __hw_write(ci, val, ci->hw_bank.regmap[reg]);
return val;
}
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 06204b7..357a059 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -551,6 +551,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci->dev = dev;
ci->platdata = dev->platform_data;
+ ci->imx28_write_fix = !!(ci->platdata->flags &
+ CI_HDRC_IMX28_WRITE_FIX);
ret = hw_device_init(ci, base);
if (ret < 0) {
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 59e6020..06fd042 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -65,6 +65,7 @@ static int host_start(struct ci_hdrc *ci)
ehci->caps = ci->hw_bank.cap;
ehci->has_hostpc = ci->hw_bank.lpm;
ehci->has_tdi_phy_lpm = ci->hw_bank.lpm;
+ ehci->imx28_write_fix = ci->imx28_write_fix;
if (ci->platdata->reg_vbus) {
ret = regulator_enable(ci->platdata->reg_vbus);
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 7d39967..708bd11 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -24,6 +24,7 @@ struct ci_hdrc_platform_data {
* but otg is not supported (no register otgsc).
*/
#define CI_HDRC_DUAL_ROLE_NOT_OTG BIT(4)
+#define CI_HDRC_IMX28_WRITE_FIXBIT(5)
enum usb_dr_modedr_mode;
#define CI_HDRC_CONTROLLER_RESET_EVENT 0
#define CI_HDRC_CONTROLLER_STOPPED_EVENT 1
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] usb: ehci: add freescale imx28 special write register method
According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
register error issue", All USB register write operations must
use the ARM SWP instruction. So, we implement a special ehci_write
for imx28.
Discussion for it at below:
http://marc.info/?l=linux-usb&m=137996395529294&w=2
Signed-off-by: Peter Chen
Acked-by: Alan Stern
---
drivers/usb/host/ehci.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index e8f41c5..535aa8b 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -225,6 +225,7 @@ struct ehci_hcd { /* one per controller */
unsignedhas_synopsys_hc_bug:1; /* Synopsys HC */
unsignedframe_index_bug:1; /* MosChip (AKA NetMos) */
unsignedneed_oc_pp_cycle:1; /* MPC834X port power */
+ unsignedimx28_write_fix:1; /* For Freescale i.MX28 */
/* required for usb32 quirk */
#define OHCI_CTRL_HCFS (3 << 6)
@@ -728,6 +729,13 @@ static inline unsigned int ehci_readl(const struct
ehci_hcd *ehci,
#endif
}
+#ifdef CONFIG_SOC_IMX28
+static inline void imx28_ehci_writel(u32 val32, volatile u32 *addr)
+{
+ __asm__ ("swp %0, %0, [%1]" : : "r"(val32), "r"(addr));
+}
+#endif
+
static inline void ehci_writel(const struct ehci_hcd *ehci,
const unsigned int val, __u32 __iomem *regs)
{
@@ -735,6 +743,11 @@ static inline void ehci_writel(const struct ehci_hcd *ehci,
ehci_big_endian_mmio(ehci) ?
writel_be(val, regs) :
writel(val, regs);
+#elif defined(CONFIG_SOC_IMX28)
+ if (ehci->imx28_write_fix)
+ imx28_ehci_writel(val, regs);
+ else
+ writel(val, regs);
#else
writel(val, regs);
#endif
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/4] usb: usbtest: support bos descriptor test for usb 3.0
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times. This patch adds to support getting bos descriptor test scenario for
USB 3.0.
Signed-off-by: Huang Rui
Acked-by: Alan Stern
---
drivers/usb/misc/usbtest.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3e91d3e9..38ebe1d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -689,6 +689,19 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return (retval < 0) ? retval : -EDOM;
}
+ /*
+* there's always [9.4.3] a bos device descriptor [9.6.2] in USB
+* 3.0 spec
+*/
+ if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0300) {
+ retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev->buf,
+ sizeof(*udev->bos->desc));
+ if (retval != sizeof(*udev->bos->desc)) {
+ dev_err(&iface->dev, "bos descriptor --> %d\n", retval);
+ return (retval < 0) ? retval : -EDOM;
+ }
+ }
+
/* there's always [9.4.3] at least one config descriptor [9.6.3] */
for (i = 0; i < udev->descriptor.bNumConfigurations; i++) {
retval = usb_get_descriptor(udev, USB_DT_CONFIG, i,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] usb: usbtest: support usb2 extension descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
USB2.0 Extension descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.1 of USB 3.0 spec.
This patch adds to support getting usb2.0 extension descriptor test
scenario for USB 3.0.
Signed-off-by: Huang Rui
Acked-by: Alan Stern
---
drivers/usb/misc/usbtest.c | 77 ++
1 file changed, 77 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 38ebe1d..84d491d 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -606,6 +606,28 @@ static int is_good_config(struct usbtest_dev *tdev, int
len)
return 0;
}
+static int is_good_ext(struct usbtest_dev *tdev, u8 *buf)
+{
+ struct usb_ext_cap_descriptor *ext;
+ u32 attr;
+
+ ext = (struct usb_ext_cap_descriptor *) buf;
+
+ if (ext->bLength != USB_DT_USB_EXT_CAP_SIZE) {
+ ERROR(tdev, "bogus usb 2.0 extension descriptor length\n");
+ return 0;
+ }
+
+ attr = le32_to_cpu(ext->bmAttributes);
+ /* bits[1:4] is used and others are reserved */
+ if (attr & ~0x1e) { /* reserved == 0 */
+ ERROR(tdev, "reserved bits set\n");
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -694,12 +716,67 @@ static int ch9_postconfig(struct usbtest_dev *dev)
* 3.0 spec
*/
if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0300) {
+ struct usb_bos_descriptor *bos = NULL;
+ struct usb_dev_cap_header *header = NULL;
+ unsigned total, num, length;
+ u8 *buf;
+
retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev->buf,
sizeof(*udev->bos->desc));
if (retval != sizeof(*udev->bos->desc)) {
dev_err(&iface->dev, "bos descriptor --> %d\n", retval);
return (retval < 0) ? retval : -EDOM;
}
+
+ bos = (struct usb_bos_descriptor *)dev->buf;
+ total = le16_to_cpu(bos->wTotalLength);
+ num = bos->bNumDeviceCaps;
+
+ if (total > TBUF_SIZE)
+ total = TBUF_SIZE;
+
+ /*
+* get generic device-level capability descriptors [9.6.2]
+* in USB 3.0 spec
+*/
+ retval = usb_get_descriptor(udev, USB_DT_BOS, 0, dev->buf,
+ total);
+ if (retval != total) {
+ dev_err(&iface->dev, "bos descriptor set --> %d\n",
+ retval);
+ return (retval < 0) ? retval : -EDOM;
+ }
+
+ length = sizeof(*udev->bos->desc);
+ buf = dev->buf;
+ for (i = 0; i < num; i++) {
+ buf += length;
+ if (buf + sizeof(struct usb_dev_cap_header) >
+ dev->buf + total)
+ break;
+
+ header = (struct usb_dev_cap_header *)buf;
+ length = header->bLength;
+
+ if (header->bDescriptorType !=
+ USB_DT_DEVICE_CAPABILITY) {
+ dev_warn(&udev->dev, "not device capability
descriptor, skip\n");
+ continue;
+ }
+
+ switch (header->bDevCapabilityType) {
+ case USB_CAP_TYPE_EXT:
+ if (buf + USB_DT_USB_EXT_CAP_SIZE >
+ dev->buf + total ||
+ !is_good_ext(dev, buf)) {
+ dev_err(&iface->dev, "bogus usb 2.0
extension descriptor\n");
+ return -EDOM;
+ }
+ break;
+ default:
+ break;
+ }
+ }
}
/* there's always [9.4.3] at least one config descriptor [9.6.3] */
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] usb: usbtest: support usb3.0 bos descriptor set test
Hi all, The following patches implement Binary Device Object Store (BOS) descriptor set tests in section 9.6.2 of USB 3.0 SPEC. At current usbtest module, it only supports USB 2.0 chapter 9 tests, so this updates extend the testing scope to cover the USB 3.0 new descriptors. Changes from v1 -> v2: - Update bcdUSB >= 0x0300 to support USB 3.1 in Patch 1. - Add "if total > TBUF_SIZE" to avoid buffer overflow. - Add local pointer "buf" to avoid change dev->buf. - Add "if buf >= dev->buf + total" to avoid to lie beyond the end of the dev->buf. - Add "if buf + USB_DT_..._SIZE > dev->buf + total" to make "header" pointer always available. Changes from v2 -> v3: - Update "if buf + sizeof(struct usb_dev_cap_header) > dev->buf + total" to make "buf" pointer always available. Changes from v3 -> v4: - Fix "comparison of distinct pointer types lacks a cast" warning with "u8 *" instead of "char *". Thanks, Rui Huang Rui (4): usb: usbtest: support bos descriptor test for usb 3.0 usb: usbtest: support usb2 extension descriptor test usb: usbtest: support superspeed device capbility descriptor test usb: usbtest: support container id descriptor test drivers/usb/misc/usbtest.c | 154 + 1 file changed, 154 insertions(+) -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/4] usb: usbtest: support superspeed device capbility descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
SuperSpeed USB Device Capability descriptor is one of the generic
device-level capbility descriptors which added in section 9.6.2.2 of USB
3.0 spec.
This patch adds to support getting SuperSpeed USB Device Capability
descriptor test scenario for USB 3.0.
Signed-off-by: Huang Rui
Acked-by: Alan Stern
---
drivers/usb/misc/usbtest.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 84d491d..d589d3c 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -628,6 +628,35 @@ static int is_good_ext(struct usbtest_dev *tdev, u8 *buf)
return 1;
}
+static int is_good_ss_cap(struct usbtest_dev *tdev, u8 *buf)
+{
+ struct usb_ss_cap_descriptor *ss;
+
+ ss = (struct usb_ss_cap_descriptor *) buf;
+
+ if (ss->bLength != USB_DT_USB_SS_CAP_SIZE) {
+ ERROR(tdev, "bogus superspeed device capability descriptor
length\n");
+ return 0;
+ }
+
+ /*
+* only bit[1] of bmAttributes is used for LTM and others are
+* reserved
+*/
+ if (ss->bmAttributes & ~0x02) { /* reserved == 0 */
+ ERROR(tdev, "reserved bits set in bmAttributes\n");
+ return 0;
+ }
+
+ /* bits[0:3] of wSpeedSupported is used and others are reserved */
+ if (le16_to_cpu(ss->wSpeedSupported) & ~0x0f) { /* reserved == 0 */
+ ERROR(tdev, "reserved bits set in wSpeedSupported\n");
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -773,6 +802,14 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return -EDOM;
}
break;
+ case USB_SS_CAP_TYPE:
+ if (buf + USB_DT_USB_SS_CAP_SIZE >
+ dev->buf + total ||
+ !is_good_ss_cap(dev, buf)) {
+ dev_err(&iface->dev, "bogus superspeed
device capability descriptor\n");
+ return -EDOM;
+ }
+ break;
default:
break;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] usb: usbtest: support container id descriptor test
In Test 9 of usbtest module, it is used for performing chapter 9 tests N
times.
Container ID descriptor is one of the generic device-level capbility
descriptors which added in section 9.6.2.3 of USB 3.0 spec.
This patch adds to support getting Container ID descriptor test scenario
for USB 3.0.
Signed-off-by: Huang Rui
Acked-by: Alan Stern
---
drivers/usb/misc/usbtest.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index d589d3c..6991bc6 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -657,6 +657,25 @@ static int is_good_ss_cap(struct usbtest_dev *tdev, u8
*buf)
return 1;
}
+static int is_good_con_id(struct usbtest_dev *tdev, u8 *buf)
+{
+ struct usb_ss_container_id_descriptor *con_id;
+
+ con_id = (struct usb_ss_container_id_descriptor *) buf;
+
+ if (con_id->bLength != USB_DT_USB_SS_CONTN_ID_SIZE) {
+ ERROR(tdev, "bogus container id descriptor length\n");
+ return 0;
+ }
+
+ if (con_id->bReserved) {/* reserved == 0 */
+ ERROR(tdev, "reserved bits set\n");
+ return 0;
+ }
+
+ return 1;
+}
+
/* sanity test for standard requests working with usb_control_mesg() and some
* of the utility functions which use it.
*
@@ -810,6 +829,14 @@ static int ch9_postconfig(struct usbtest_dev *dev)
return -EDOM;
}
break;
+ case CONTAINER_ID_TYPE:
+ if (buf + USB_DT_USB_SS_CONTN_ID_SIZE >
+ dev->buf + total ||
+ !is_good_con_id(dev, buf)) {
+ dev_err(&iface->dev, "bogus container
id descriptor\n");
+ return -EDOM;
+ }
+ break;
default:
break;
}
--
1.7.11.7
--
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
