Re: Bug 60738 - USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive
Hi Alexandre, I'm new to kernel development. I want to explore this bug. From you dmesg output I'm unable to get the driver your device is using. can you tell me which driver are you using? regards Kumar Gaurav On Tuesday 13 August 2013 11:15 AM, Alexandre Demers wrote: Sorry, here are more details. I'm refering to https://bugzilla.kernel.org/show_bug.cgi?id=60738 To sum up: Most of the time, my HP USB 3.0 hard drive will not be properly mounted when booting or when connecting it. I usually end up with something similar to the following in dmesg: [ 204.081693] usb usb9: usb wakeup-resume [ 204.081700] usb usb9: usb auto-resume [ 204.081711] hub 9-0:1.0: hub_resume [ 204.081722] hub 9-0:1.0: port 1: status 02c1 change 0001 [ 204.090114] usb usb8: usb wakeup-resume [ 204.090119] usb usb8: usb auto-resume [ 204.090131] hub 8-0:1.0: hub_resume [ 204.090140] hub 8-0:1.0: port 1: status 0101 change 0001 [ 204.182172] hub 9-0:1.0: state 7 ports 2 chg 0002 evt [ 204.182192] hub 9-0:1.0: port 1, status 02a0, change 0001, 5.0 Gb/s [ 204.286239] hub 9-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x2a0 [ 204.286250] hub 8-0:1.0: state 7 ports 2 chg 0002 evt 0002 [ 204.286262] hub 8-0:1.0: port 1, status 0101, change 0001, 12 Mb/s [ 204.286285] hub 9-0:1.0: hub_suspend [ 204.286291] usb usb9: bus auto-suspend, wakeup 1 [ 204.390320] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 [ 204.492391] usb 8-1: new high-speed USB device number 8 using xhci_hcd [ 204.697607] usb 8-1: Device not responding to set address. [ 204.898877] usb 8-1: Device not responding to set address. [ 205.099841] usb 8-1: device not accepting address 8, error -71 [ 205.099868] kobject: '8-1' (88020d7fe098): kobject_cleanup [ 205.099870] kobject: '8-1' (88020d7fe098): calling ktype release [ 205.099883] kobject: '8-1': free name [ 205.150907] kobject: '8-1' (88020a605898): kobject_cleanup [ 205.150918] kobject: '8-1' (88020a605898): calling ktype release [ 205.150921] kobject: '8-1': free name [ 205.150929] hub 8-0:1.0: state 7 ports 2 chg evt 0002 [ 205.150939] hub 8-0:1.0: port 1, status 0100, change 0001, 12 Mb/s [ 205.254964] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 [ 205.254978] hub 8-0:1.0: hub_suspend [ 205.254983] usb usb8: bus auto-suspend, wakeup 1 To make it work, when the USB drive is already plugged in, if I can disconnect it and reconnect it in the USB 3.0 port fast enough, it works most of the time. This problem is not seen under Windows. According to Windows Hardware Certification Requirements (part 1): Next, the time between the time that RxDetect succeeds and the time that the device enters U0 can be up to 300 ms. With an extra margin for hub control transfers and other delays, the total comes to 500 ms. Also, when the hard drive is plugged in a USB 2.0 port, it works like a charm. Are we too aggressive when we are waking up the device? Alexandre Demers On 08/13/2013 12:26 AM, Alexandre Demers wrote: Hi, As requested by Greg Kroah, please see bug 60738 - Summary: USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive. I'll be pleased to help you as much as possible. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug 60738 - USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive
lsusb gives me the following: sudo lsusb --verbose -t /: Bus 13.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M /: Bus 12.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 11.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M /: Bus 10.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 09.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/4p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8712u, 480M So I assume it is a combinaision of usb-storage over xhci_hcd (the hp hard drive is working right now and is on Bus 09). Alex On Tue 13 Aug 2013 02:23:50 AM EDT, Kumar Gaurav wrote: Hi Alexandre, I'm new to kernel development. I want to explore this bug. From you dmesg output I'm unable to get the driver your device is using. can you tell me which driver are you using? regards Kumar Gaurav On Tuesday 13 August 2013 11:15 AM, Alexandre Demers wrote: Sorry, here are more details. I'm refering to https://bugzilla.kernel.org/show_bug.cgi?id=60738 To sum up: Most of the time, my HP USB 3.0 hard drive will not be properly mounted when booting or when connecting it. I usually end up with something similar to the following in dmesg: [ 204.081693] usb usb9: usb wakeup-resume [ 204.081700] usb usb9: usb auto-resume [ 204.081711] hub 9-0:1.0: hub_resume [ 204.081722] hub 9-0:1.0: port 1: status 02c1 change 0001 [ 204.090114] usb usb8: usb wakeup-resume [ 204.090119] usb usb8: usb auto-resume [ 204.090131] hub 8-0:1.0: hub_resume [ 204.090140] hub 8-0:1.0: port 1: status 0101 change 0001 [ 204.182172] hub 9-0:1.0: state 7 ports 2 chg 0002 evt [ 204.182192] hub 9-0:1.0: port 1, status 02a0, change 0001, 5.0 Gb/s [ 204.286239] hub 9-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x2a0 [ 204.286250] hub 8-0:1.0: state 7 ports 2 chg 0002 evt 0002 [ 204.286262] hub 8-0:1.0: port 1, status 0101, change 0001, 12 Mb/s [ 204.286285] hub 9-0:1.0: hub_suspend [ 204.286291] usb usb9: bus auto-suspend, wakeup 1 [ 204.390320] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101 [ 204.492391] usb 8-1: new high-speed USB device number 8 using xhci_hcd [ 204.697607] usb 8-1: Device not responding to set address. [ 204.898877] usb 8-1: Device not responding to set address. [ 205.099841] usb 8-1: device not accepting address 8, error -71 [ 205.099868] kobject: '8-1' (88020d7fe098): kobject_cleanup [ 205.099870] kobject: '8-1' (88020d7fe098): calling ktype release [ 205.099883] kobject: '8-1': free name [ 205.150907] kobject: '8-1' (88020a605898): kobject_cleanup [ 205.150918] kobject: '8-1' (88020a605898): calling ktype release [ 205.150921] kobject: '8-1': free name [ 205.150929] hub 8-0:1.0: state 7 ports 2 chg evt 0002 [ 205.150939] hub 8-0:1.0: port 1, status 0100, change 0001, 12 Mb/s [ 205.254964] hub 8-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100 [ 205.254978] hub 8-0:1.0: hub_suspend [ 205.254983] usb usb8: bus auto-suspend, wakeup 1 To make it work, when the USB drive is already plugged in, if I can disconnect it and reconnect it in the USB 3.0 port fast enough, it works most of the time. This problem is not seen under Windows. According to Windows Hardware Certification Requirements (part 1): Next, the time between the time that RxDetect succeeds and the time that the device enters U0 can be up to 300 ms. With an extra margin for hub control transfers and other delays, the total comes to 500 ms. Also, when the hard drive is plugged in a USB 2.0 port, it works like a charm. Are we too aggressive when we are waking up the device? Alexandre Demers On 08/13/2013 12:26 AM, Alexandre Demers wrote: Hi, As requested by Greg Kroah, please see bug 60738 - Summary: USB 3.0 connection delay seems to be too short for HP USB 3.0 hard drive. I'll be pleased to help you as much as possible. -- 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 -- Alexandre Demers -- To unsubscribe
Re: [PATCH] dwc3: dwc3-pci: Use SIMPLE_DEV_PM_OPS
On Wed, Aug 7, 2013 at 7:51 PM, Fabio Estevam feste...@gmail.com wrote:
From: Fabio Estevam fabio.este...@freescale.com
Using SIMPLE_DEV_PM_OPS can make the code simpler and cleaner.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/usb/dwc3/dwc3-pci.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 5d746e5..b922315 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -191,7 +191,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_id_table) = {
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int dwc3_pci_suspend(struct device *dev)
{
struct pci_dev *pci = to_pci_dev(dev);
@@ -216,15 +216,10 @@ static int dwc3_pci_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM_SLEEP */
-static const struct dev_pm_ops dwc3_pci_dev_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(dwc3_pci_suspend, dwc3_pci_resume)
-};
-
-#define DEV_PM_OPS (dwc3_pci_dev_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(dwc3_pci_dev_pm_ops, dwc3_pci_suspend,
+dwc3_pci_resume);
static struct pci_driver dwc3_pci_driver = {
.name = dwc3-pci,
@@ -232,7 +227,7 @@ static struct pci_driver dwc3_pci_driver = {
.probe = dwc3_pci_probe,
.remove = dwc3_pci_remove,
.driver = {
- .pm = DEV_PM_OPS,
+ .pm = dwc3_pci_dev_pm_ops,
},
};
It seems .pm is not NULL if CONFIG_PM_SLEEP is not defined
which is not the same with former code.
--
BR,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: at91_udc: add usb_clk for transition to common clk framework
On 12/08/2013 22:42, boris brezillon :
Hello Nicolas,
On 12/08/2013 15:52, Nicolas Ferre wrote:
On 01/08/2013 08:18, Boris BREZILLON :
The AT91 PMC (Power Management Controller) provides an USB clock used by
USB Full Speed host (ohci) and USB Full Speed device (udc).
The usb drivers (ohci and udc) must configure this clock to 48Mhz.
This configuration was formely done in mach-at91/clock.c, but this
implementation will be removed when moving to common clk framework.
This patch adds support for usb clock retrieval and configuration,
and is
backward compatible with the current at91 clk implementation (if usb clk
is not found, it does not configure/enable it).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Is there a reason you acked this version but not the 3rd one
(https://lkml.org/lkml/2013/8/2/102).
No, only flow of emails while getting back online ;-)
Bye,
---
drivers/usb/gadget/at91_udc.c | 17 -
drivers/usb/gadget/at91_udc.h |2 +-
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c
b/drivers/usb/gadget/at91_udc.c
index fce8e4e..ae06585 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -870,6 +870,11 @@ static void clk_on(struct at91_udc *udc)
if (udc-clocked)
return;
udc-clocked = 1;
+
+if (!IS_ERR(udc-uclk)) {
+clk_set_rate(udc-uclk, 4800);
+clk_prepare_enable(udc-uclk);
+}
clk_prepare_enable(udc-iclk);
clk_prepare_enable(udc-fclk);
}
@@ -882,6 +887,8 @@ static void clk_off(struct at91_udc *udc)
udc-gadget.speed = USB_SPEED_UNKNOWN;
clk_disable_unprepare(udc-fclk);
clk_disable_unprepare(udc-iclk);
+if (!IS_ERR(udc-uclk))
+clk_disable_unprepare(udc-uclk);
}
/*
@@ -1774,10 +1781,10 @@ static int at91udc_probe(struct
platform_device *pdev)
/* get interface and function clocks */
udc-iclk = clk_get(dev, udc_clk);
udc-fclk = clk_get(dev, udpck);
+udc-uclk = clk_get(dev, usb_clk);
if (IS_ERR(udc-iclk) || IS_ERR(udc-fclk)) {
DBG(clocks missing\n);
retval = -ENODEV;
-/* NOTE: we know here that refcounts on these are NOPs */
goto fail1;
}
@@ -1851,6 +1858,12 @@ fail3:
fail2:
free_irq(udc-udp_irq, udc);
fail1:
+if (!IS_ERR(udc-uclk))
+clk_put(udc-uclk);
+if (!IS_ERR(udc-fclk))
+clk_put(udc-fclk);
+if (!IS_ERR(udc-iclk))
+clk_put(udc-iclk);
iounmap(udc-udp_baseaddr);
fail0a:
if (cpu_is_at91rm9200())
@@ -1894,6 +1907,8 @@ static int __exit at91udc_remove(struct
platform_device *pdev)
clk_put(udc-iclk);
clk_put(udc-fclk);
+if (!IS_ERR(udc-uclk))
+clk_put(udc-uclk);
return 0;
}
diff --git a/drivers/usb/gadget/at91_udc.h
b/drivers/usb/gadget/at91_udc.h
index e647d1c..0175246 100644
--- a/drivers/usb/gadget/at91_udc.h
+++ b/drivers/usb/gadget/at91_udc.h
@@ -126,7 +126,7 @@ struct at91_udc {
unsignedactive_suspend:1;
u8addr;
struct at91_udc_databoard;
-struct clk*iclk, *fclk;
+struct clk*iclk, *fclk, *uclk;
struct platform_device*pdev;
struct proc_dir_entry*pde;
void __iomem*udp_baseaddr;
--
Nicolas Ferre
--
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: musb: am335x: Do not remove the session bin HOST-only mode
On 08/09/2013 10:30 PM, Sergei Shtylyov wrote:
Hello.
Hi Sergei,
+if (musb-port_mode == MUSB_PORT_MODE_HOST) {
+val = USBMODE_IDDIG_A;
+val |= USBMODE_ID_MUX_REG;
Why not do the above in one line and save on {} {}? It will look more
aesthetically pleasing IMHO.
I'm going to redo this if it is agreed that we want to fix it that way.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next 2/3] net/usb/r8152: enable tx checksum
Enable tx checksum.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 63 +
1 file changed, 58 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6c5aa2..5d9d949 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -20,6 +20,8 @@
#include linux/if_vlan.h
#include linux/uaccess.h
#include linux/list.h
+#include linux/ip.h
+#include linux/ipv6.h
/* Version Information */
#define DRIVER_VERSION v1.01.0 (2013/08/12)
@@ -314,8 +316,13 @@ struct tx_desc {
u32 opts1;
#define TX_FS (1 31) /* First segment of a packet */
#define TX_LS (1 30) /* Final segment of a packet */
-#define TX_LEN_MASK0x
+#define TX_LEN_MASK0x3
+
u32 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 */
+#define IPV6_CS(1 28) /* Calculate IPv6 checksum */
};
struct rx_agg {
@@ -964,6 +971,51 @@ err1:
return -ENOMEM;
}
+static void
+r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, struct sk_buff *skb)
+{
+ memset(desc, 0, sizeof(*desc));
+
+ desc-opts1 = cpu_to_le32((skb-len TX_LEN_MASK) | TX_FS | TX_LS);
+
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ __be16 protocol;
+ u8 ip_protocol;
+ u32 opts2 = 0;
+
+ if (skb-protocol == htons(ETH_P_8021Q))
+ protocol = vlan_eth_hdr(skb)-h_vlan_encapsulated_proto;
+ else
+ protocol = skb-protocol;
+
+ switch (protocol) {
+ case htons(ETH_P_IP):
+ opts2 |= IPV4_CS;
+ ip_protocol = ip_hdr(skb)-protocol;
+ break;
+
+ case htons(ETH_P_IPV6):
+ opts2 |= IPV6_CS;
+ ip_protocol = ipv6_hdr(skb)-nexthdr;
+ break;
+
+ default:
+ ip_protocol = IPPROTO_RAW;
+ break;
+ }
+
+ if (ip_protocol == IPPROTO_TCP) {
+ opts2 |= TCP_CS;
+ opts2 |= (skb_transport_offset(skb) 0x7fff) 17;
+ } else if (ip_protocol == IPPROTO_UDP) {
+ opts2 |= UDP_CS;
+ } else
+ WARN_ON_ONCE(1);
+
+ desc-opts2 = cpu_to_le32(opts2);
+ }
+}
+
static void rx_bottom(struct r8152 *tp)
{
struct net_device_stats *stats;
@@ -1100,8 +1152,7 @@ next_agg:
tx_desc = (struct tx_desc *)agg-data;
agg-data += sizeof(*tx_desc);
- tx_desc-opts1 = cpu_to_le32((skb-len TX_LEN_MASK) | TX_FS |
-TX_LS);
+ r8152_tx_csum(tp, tx_desc, skb);
memcpy(agg-data, skb-data, len);
agg-skb_num++;
agg-skb_len += len;
@@ -1249,7 +1300,7 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
agg-skb_num = agg-skb_len = 0;
len = skb-len;
- tx_desc-opts1 = cpu_to_le32((skb-len TX_LEN_MASK) | TX_FS | TX_LS);
+ r8152_tx_csum(tp, tx_desc, skb);
memcpy(agg-data, skb-data, len);
dev_kfree_skb_any(skb);
agg-skb_num++;
@@ -1957,7 +2008,9 @@ static int rtl8152_probe(struct usb_interface *intf,
tp-netdev = netdev;
netdev-netdev_ops = rtl8152_netdev_ops;
netdev-watchdog_timeo = RTL8152_TX_TIMEOUT;
- netdev-features = ~NETIF_F_IP_CSUM;
+
+ netdev-features |= NETIF_F_IP_CSUM;
+ netdev-hw_features = NETIF_F_IP_CSUM;
SET_ETHTOOL_OPS(netdev, ops);
tp-speed = 0;
--
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-next 3/3] net/usb/r8152: enable interrupt transfer
Use the interrupt transfer to replace polling link status. Delay
to update the link down status, because some of them result from
the change of speed.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 134 ++--
1 file changed, 107 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5d9d949..32af41a 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -272,6 +272,9 @@ enum rtl_register_content {
#define RTL8152_MAX_TX 10
#define RTL8152_MAX_RX 10
+#define INTBUFSIZE 2
+
+#define INTR_LINK 0x0004
#define RTL8152_REQT_READ 0xc0
#define RTL8152_REQT_WRITE 0x40
@@ -292,7 +295,8 @@ enum rtl_register_content {
enum rtl8152_flags {
RTL8152_UNPLUG = 0,
RTL8152_SET_RX_MODE,
- WORK_ENABLE
+ WORK_ENABLE,
+ RTL8152_LINK_CHG,
};
/* Define these values to match your device */
@@ -349,7 +353,9 @@ struct r8152 {
unsigned long flags;
struct usb_device *udev;
struct tasklet_struct tl;
+ struct usb_interface *intf;
struct net_device *netdev;
+ struct urb *intr_urb;
struct tx_agg tx_info[RTL8152_MAX_TX];
struct rx_agg rx_info[RTL8152_MAX_RX];
struct list_head rx_done, tx_free;
@@ -357,8 +363,10 @@ struct r8152 {
spinlock_t rx_lock, tx_lock;
struct delayed_work schedule;
struct mii_if_info mii;
+ int intr_interval;
u32 msg_enable;
u16 ocp_base;
+ u8 *intr_buff;
u8 version;
u8 speed;
};
@@ -855,6 +863,56 @@ static void write_bulk_callback(struct urb *urb)
tasklet_schedule(tp-tl);
}
+static void intr_callback(struct urb *urb)
+{
+ struct r8152 *tp;
+ __u16 *d;
+ int status = urb-status;
+ int res;
+
+ tp = urb-context;
+ if (!tp)
+ return;
+
+ switch (status) {
+ case 0: /* success */
+ break;
+ case -ECONNRESET: /* unlink */
+ case -ESHUTDOWN:
+ netif_device_detach(tp-netdev);
+ case -ENOENT:
+ return;
+ case -EOVERFLOW:
+ netif_info(tp, intr, tp-netdev, intr status -EOVERFLOW\n);
+ goto resubmit;
+ /* -EPIPE: should clear the halt */
+ default:
+ netif_info(tp, intr, tp-netdev, intr status %d\n, status);
+ goto resubmit;
+ }
+
+ d = urb-transfer_buffer;
+ if (INTR_LINK __le16_to_cpu(d[0])) {
+ if (!(tp-speed LINK_STATUS)) {
+ set_bit(RTL8152_LINK_CHG, tp-flags);
+ schedule_delayed_work(tp-schedule, 0);
+ }
+ } else {
+ if (tp-speed LINK_STATUS) {
+ set_bit(RTL8152_LINK_CHG, tp-flags);
+ schedule_delayed_work(tp-schedule, 5 * HZ);
+ }
+ }
+
+resubmit:
+ res = usb_submit_urb(urb, GFP_ATOMIC);
+ if (res == -ENODEV)
+ netif_device_detach(tp-netdev);
+ else if (res)
+ netif_err(tp, intr, tp-netdev,
+ can't resubmit intr, status %d\n, res);
+}
+
static inline void *rx_agg_align(void *data)
{
return (void *)ALIGN((uintptr_t)data, 8);
@@ -894,11 +952,24 @@ static void free_all_mem(struct r8152 *tp)
tp-tx_info[i].head = tp-tx_info[i].data = NULL;
}
}
+
+ if (tp-intr_urb) {
+ usb_free_urb(tp-intr_urb);
+ tp-intr_urb = NULL;
+ }
+
+ if (tp-intr_buff) {
+ kfree(tp-intr_buff);
+ tp-intr_buff = NULL;
+ }
}
static int alloc_all_mem(struct r8152 *tp)
{
struct net_device *netdev = tp-netdev;
+ struct usb_interface *intf = tp-intf;
+ struct usb_host_interface *alt = intf-cur_altsetting;
+ struct usb_host_endpoint *ep_intr = alt-endpoint + 2;
struct urb *urb;
int node, i;
u8 *buf;
@@ -964,6 +1035,19 @@ static int alloc_all_mem(struct r8152 *tp)
list_add_tail(tp-tx_info[i].list, tp-tx_free);
}
+ tp-intr_urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!tp-intr_urb)
+ goto err1;
+
+ tp-intr_buff = kmalloc(INTBUFSIZE, GFP_KERNEL);
+ if (!tp-intr_buff)
+ goto err1;
+
+ tp-intr_interval = (int)ep_intr-desc.bInterval;
+ usb_fill_int_urb(tp-intr_urb, tp-udev, usb_rcvintpipe(tp-udev, 3),
+tp-intr_buff, INTBUFSIZE, intr_callback,
+tp, tp-intr_interval);
+
return 0;
err1:
@@ -1221,8 +1305,10 @@ static void rtl8152_set_rx_mode(struct net_device
*netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- if (tp-speed LINK_STATUS)
+ if (tp-speed LINK_STATUS) {
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-08-12 at 13:04 -0500, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) probably good to spell out Synopsys rather than SNPS Synopsys (the company) has always used snps in their bindings though. +Required properities : +- compatible : sould be qcom,dwc3-hsphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + sleep_a_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation I believe these regulators belong to the PHY, not DWC3. Please write a PHY driver. There is already usb phy drivers for these?? [PATCH v2 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref_clk : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation likewise, these regulators should be moved to the PHY driver. +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core_clk : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi_clk : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. + +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. + +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in the binding. AFAICT that's only needed for OMAP5 ES1.0. Unless Qualcomm also screwed up default TX FIFO sizes :-p Or it is intentional? :-) Look at [1] dwc3@f920 Ivan [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/boot/dts/apq8084.dtsi?h=msm-3.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] ath9k-htc: convert EP3 and EP4 back from bulk to int
If usb auto suspend is enabled or system run in to suspend/resume
cycle ath9k-htc adapter will stop to response. It is reproducible on xhci HCs.
Host part of problem:
XHCI do timing calculation based on Transfer Type and bInterval,
immediately after device was detected. Ath9k-htc try to overwrite
this parameters on module probe and some changes in FW,
since we do not initiate usb reset from the driver this changes
are not took to account. So, before any kind of suspend or reset,
host controller will operate with old parameters. Only after suspend/resume
and if interface id stay unchanged, new parameters will by applied. Host
will send bulk data with no intervals (?), which will cause
overflow on FIFO of EP4.
Firmware part of problem:
By default, ath9k-htc adapters configured with EP3 and EP4
as interrupt endpoints. Current firmware will try to overwrite
ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints
stay not reconfigured, so under the hood it is still Int EP.
Signed-off-by: Oleksij Rempel li...@rempel-privat.de
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 36 ++--
1 file changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 5205a36..d99ea45 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -115,10 +115,10 @@ static int hif_usb_send_regout(struct hif_device_usb
*hif_dev,
cmd-skb = skb;
cmd-hif_dev = hif_dev;
- usb_fill_bulk_urb(urb, hif_dev-udev,
-usb_sndbulkpipe(hif_dev-udev, USB_REG_OUT_PIPE),
+ usb_fill_int_urb(urb, hif_dev-udev,
+usb_sndintpipe(hif_dev-udev, USB_REG_OUT_PIPE),
skb-data, skb-len,
-hif_usb_regout_cb, cmd);
+hif_usb_regout_cb, cmd, 1);
usb_anchor_urb(urb, hif_dev-regout_submitted);
ret = usb_submit_urb(urb, GFP_KERNEL);
@@ -723,11 +723,11 @@ static void ath9k_hif_usb_reg_in_cb(struct urb *urb)
return;
}
- usb_fill_bulk_urb(urb, hif_dev-udev,
-usb_rcvbulkpipe(hif_dev-udev,
+ usb_fill_int_urb(urb, hif_dev-udev,
+usb_rcvintpipe(hif_dev-udev,
USB_REG_IN_PIPE),
nskb-data, MAX_REG_IN_BUF_SIZE,
-ath9k_hif_usb_reg_in_cb, nskb);
+ath9k_hif_usb_reg_in_cb, nskb, 1);
}
resubmit:
@@ -909,11 +909,11 @@ static int ath9k_hif_usb_alloc_reg_in_urbs(struct
hif_device_usb *hif_dev)
goto err_skb;
}
- usb_fill_bulk_urb(urb, hif_dev-udev,
- usb_rcvbulkpipe(hif_dev-udev,
+ usb_fill_int_urb(urb, hif_dev-udev,
+ usb_rcvintpipe(hif_dev-udev,
USB_REG_IN_PIPE),
skb-data, MAX_REG_IN_BUF_SIZE,
- ath9k_hif_usb_reg_in_cb, skb);
+ ath9k_hif_usb_reg_in_cb, skb, 1);
/* Anchor URB */
usb_anchor_urb(urb, hif_dev-reg_in_submitted);
@@ -1033,7 +1033,7 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb
*hif_dev)
{
struct usb_host_interface *alt = hif_dev-interface-altsetting[0];
struct usb_endpoint_descriptor *endp;
- int ret, idx;
+ int ret;
ret = ath9k_hif_usb_download_fw(hif_dev);
if (ret) {
@@ -1043,20 +1043,6 @@ static int ath9k_hif_usb_dev_init(struct hif_device_usb
*hif_dev)
return ret;
}
- /* On downloading the firmware to the target, the USB descriptor of EP4
-* is 'patched' to change the type of the endpoint to Bulk. This will
-* bring down CPU usage during the scan period.
-*/
- for (idx = 0; idx alt-desc.bNumEndpoints; idx++) {
- endp = alt-endpoint[idx].desc;
- if ((endp-bmAttributes USB_ENDPOINT_XFERTYPE_MASK)
- == USB_ENDPOINT_XFER_INT) {
- endp-bmAttributes = ~USB_ENDPOINT_XFERTYPE_MASK;
- endp-bmAttributes |= USB_ENDPOINT_XFER_BULK;
- endp-bInterval = 0;
- }
- }
-
/* Alloc URBs */
ret = ath9k_hif_usb_alloc_urbs(hif_dev);
if (ret) {
@@ -1268,7 +1254,7 @@ static void ath9k_hif_usb_reboot(struct usb_device *udev)
if (!buf)
return;
- ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, USB_REG_OUT_PIPE),
+ ret = usb_interrupt_msg(udev, usb_sndintpipe(udev, USB_REG_OUT_PIPE),
buf, 4, NULL, HZ);
if (ret)
Re: [PATCH] usb: phy: samsung-usb2: Toggle HSIC GPIO from device tree
On 12 July 2013 12:27, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Jul 10, 2013 at 10:42:27AM -0700, Julius Werner wrote: Hi Felipe, This is intended to pull down a reset signal line, not to switch power to the device. I could implement that with the regulator framework too, but I think that would just be confusing and harder to understand without providing any benefit. It's really just a plain old GPIO. alright, in that case how about using drivers/reset/ ? IIUC, reset-gpio driver only provides APIs for reset controls (reset, assert, deassert). We still need to find out the location from where we would be calling the reset function. -- Tushar Behera -- 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: am335x: include linux/err.h
Stephen Rothwell reported that this driver does not compile on PowerPC due to this missing include. One could argue why this driver is enabled on PowerPC in the first place but it sure isn't wrong to include headers for used function instead of to rely that they sneak in. Reported-by: Stephen Rothwell s...@canb.auug.org.au Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/phy/phy-am335x-control.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/phy/phy-am335x-control.c b/drivers/usb/phy/phy-am335x-control.c index 35494f1..7597545 100644 --- a/drivers/usb/phy/phy-am335x-control.c +++ b/drivers/usb/phy/phy-am335x-control.c @@ -1,5 +1,6 @@ #include linux/module.h #include linux/platform_device.h +#include linux/err.h #include linux/of.h #include linux/io.h -- 1.8.4.rc1 -- 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
Undetected Fresco Logic FL1000G USB 3.0 controller in Asus N43SN after replace a motherboard
Hi, I had no problem with a USB 3.0 port in my Asus N43SN since I bought a laptop (~2 years). Recently I replaced a motherboard to the new one (N43SL.413 looks the same as the first one) due to a problem with a graphical chipset and after that a USB3 controller stopped to be even detected. $ lspci | grep -i USB 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) (in the past there was also an additional USB3 controller - AFAIR Fresco Logic FL1000G USB 3.0). I though it was a problem with a motherboard, but after boot with different kernel the controller showed up. I started to suspect a bug in kernel, but after two days (I use it only from time to time with my USB3 hard drive) I noticed that USB3 port/controller is not visible anymore with any kernel. I don't know if this behavior is normal for a hardware malfunction. In /var/log/messages there is no info about the USB3 controller (see log below). I tried pci=nomsi in Grub, but with no effect. I could try to replace the motherboard to the new one once again (I don't have the old one), but it could be hard to convince procucer that this is a problem with hardware (the port in the new motherboard worked fine twice). I don't have any other OS to test it on it. Tested with following kernels (Fedora 18): kernel-3.10.4-100.fc18.x86_64 kernel-3.9.11-200.fc18.x86_64 kernel-3.9.9-201.fc18.x86_64 and in addition with quite recent System Rescue CD. What could be a reason? Can I force kernel to see it (there is no module xhci_hcd to load manually - it is built into a kernel in Fedora)? Marcin [1.424160] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.424162] ehci-pci: EHCI PCI platform driver [1.424249] ehci-pci :00:1a.0: EHCI Host Controller [1.424310] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.424327] ehci-pci :00:1a.0: debug port 2 [1.428259] ehci-pci :00:1a.0: irq 16, io mem 0xdf008000 [1.433314] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.43] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.45] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.47] usb usb1: Product: EHCI Host Controller [1.49] usb usb1: Manufacturer: Linux 3.9.9-201.fc18.x86_64 ehci_hcd [1.433341] usb usb1: SerialNumber: :00:1a.0 [1.433438] hub 1-0:1.0: USB hub found [1.433442] hub 1-0:1.0: 2 ports detected [1.433581] ehci-pci :00:1d.0: EHCI Host Controller [1.433621] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.433638] ehci-pci :00:1d.0: debug port 2 [1.437561] ehci-pci :00:1d.0: irq 23, io mem 0xdf007000 [1.443310] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.443323] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.443325] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.443327] usb usb2: Product: EHCI Host Controller [1.443329] usb usb2: Manufacturer: Linux 3.9.9-201.fc18.x86_64 ehci_hcd [1.443331] usb usb2: SerialNumber: :00:1d.0 [1.443414] hub 2-0:1.0: USB hub found [1.443418] hub 2-0:1.0: 2 ports detected [1.443485] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.443495] uhci_hcd: USB Universal Host Controller Interface driver === this part is currently missing - START === [1.443569] xhci_hcd :04:00.0: xHCI Host Controller [1.443608] xhci_hcd :04:00.0: new USB bus registered, assigned bus number 3 [1.572613] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.572616] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.572617] usb usb3: Product: xHCI Host Controller [1.572620] usb usb3: Manufacturer: Linux 3.9.9-201.fc18.x86_64 xhci_hcd [1.572621] usb usb3: SerialNumber: :04:00.0 [1.572706] hub 3-0:1.0: USB hub found [1.572712] hub 3-0:1.0: 1 port detected [1.572761] xhci_hcd :04:00.0: xHCI Host Controller [1.572802] xhci_hcd :04:00.0: new USB bus registered, assigned bus number 4 [1.572829] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.572831] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.572833] usb usb4: Product: xHCI Host Controller [1.572835] usb usb4: Manufacturer: Linux 3.9.9-201.fc18.x86_64 xhci_hcd [1.572837] usb usb4: SerialNumber: :04:00.0 [1.572911] hub 4-0:1.0: USB hub found [1.572916] hub 4-0:1.0: 1 port detected === this part is currently missing - END === [1.580289] usbcore: registered new interface driver usbserial [1.580295] usbcore: registered new interface driver usbserial_generic -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to
[PATCH 1/2] usb: musb: convert to devm_* to allocate resources
No functional change. Used devm_kzalloc and devm_clk_get instead of
kzalloc and clk_get.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
only *compile* tested.
drivers/usb/musb/am35x.c | 40 ++--
drivers/usb/musb/blackfin.c |8 ++--
drivers/usb/musb/da8xx.c | 28 ++--
drivers/usb/musb/davinci.c | 28 ++--
drivers/usb/musb/musb_dsps.c |4 +---
drivers/usb/musb/tusb6010.c | 16 ++--
drivers/usb/musb/ux500.c | 28 ++--
7 files changed, 53 insertions(+), 99 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 5c310c6..50ba013 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -465,7 +465,7 @@ static int am35x_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
@@ -474,33 +474,33 @@ static int am35x_probe(struct platform_device *pdev)
musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err0;
}
- phy_clk = clk_get(pdev-dev, fck);
+ phy_clk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
- goto err3;
+ goto err1;
}
- clk = clk_get(pdev-dev, ick);
+ clk = devm_clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
- goto err4;
+ goto err1;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
- goto err5;
+ goto err1;
}
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
- goto err6;
+ goto err2;
}
musb-dev.parent= pdev-dev;
@@ -520,40 +520,31 @@ static int am35x_probe(struct platform_device *pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err7;
+ goto err3;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err7;
+ goto err3;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err7;
+ goto err3;
}
return 0;
-err7:
+err3:
clk_disable(clk);
-err6:
+err2:
clk_disable(phy_clk);
-err5:
- clk_put(clk);
-
-err4:
- clk_put(phy_clk);
-
-err3:
- platform_device_put(musb);
-
err1:
- kfree(glue);
+ platform_device_put(musb);
err0:
return ret;
@@ -566,9 +557,6 @@ static int am35x_remove(struct platform_device *pdev)
platform_device_unregister(glue-musb);
clk_disable(glue-clk);
clk_disable(glue-phy_clk);
- clk_put(glue-clk);
- clk_put(glue-phy_clk);
- kfree(glue);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 72e2056..70f4c5d 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -457,7 +457,7 @@ static int bfin_probe(struct platform_device *pdev)
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
@@ -466,7 +466,7 @@ static int bfin_probe(struct platform_device *pdev)
musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err0;
}
musb-dev.parent= pdev-dev;
@@ -517,9 +517,6 @@ static int bfin_probe(struct platform_device *pdev)
err3:
platform_device_put(musb);
-err1:
- kfree(glue);
-
err0:
return ret;
}
@@ -529,7 +526,6 @@ static int bfin_remove(struct platform_device *pdev)
struct bfin_glue*glue = platform_get_drvdata(pdev);
platform_device_unregister(glue-musb);
- kfree(glue);
[PATCH 2/2] usb: musb: pass on all the required resources from glue to musb core
musb glue have to pass either 2 resources or 3 resources to the musb
core (musb core irq number, dma irq number and a memory
resource). So allocated *resource* for musb core in glue (based on the number
of resources in glue), copy all the resources from glue to core before creating
the musb core device. This prevents the need to know the number of resources
beforehand.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Tested omap4 panda and omap3 beagle for enumeration .
All other platforms compile tested only.
drivers/usb/musb/am35x.c| 16 +++-
drivers/usb/musb/blackfin.c | 28 ++--
drivers/usb/musb/da8xx.c| 28 ++--
drivers/usb/musb/davinci.c | 28 ++--
drivers/usb/musb/omap2430.c | 33 ++---
drivers/usb/musb/tusb6010.c | 33 ++---
drivers/usb/musb/ux500.c| 28 ++--
7 files changed, 99 insertions(+), 95 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 50ba013..6ea907d 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -457,8 +457,10 @@ static u64 am35x_dmamask = DMA_BIT_MASK(32);
static int am35x_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
+ struct resource *musb_resources;
struct platform_device *musb;
struct am35x_glue *glue;
+ int i;
struct clk *phy_clk;
struct clk *clk;
@@ -477,6 +479,11 @@ static int am35x_probe(struct platform_device *pdev)
goto err0;
}
+ musb_resources = devm_kzalloc(pdev-dev, pdev-num_resources *
+ sizeof(*musb_resources), GFP_KERNEL);
+ if (!musb_resources)
+ goto err1;
+
phy_clk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
@@ -516,7 +523,14 @@ static int am35x_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- ret = platform_device_add_resources(musb, pdev-resource,
+ for (i = 0; i pdev-num_resources; i++) {
+ musb_resources[i].name = pdev-resource[i].name;
+ musb_resources[i].start = pdev-resource[i].start;
+ musb_resources[i].end = pdev-resource[i].end;
+ musb_resources[i].flags = pdev-resource[i].flags;
+ }
+
+ ret = platform_device_add_resources(musb, musb_resources,
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 70f4c5d..9331ca9 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -450,10 +450,11 @@ static u64 bfin_dmamask = DMA_BIT_MASK(32);
static int bfin_probe(struct platform_device *pdev)
{
- struct resource musb_resources[2];
+ struct resource *musb_resources;
struct musb_hdrc_platform_data *pdata = dev_get_platdata(pdev-dev);
struct platform_device *musb;
struct bfin_glue*glue;
+ int i;
int ret = -ENOMEM;
@@ -469,6 +470,11 @@ static int bfin_probe(struct platform_device *pdev)
goto err0;
}
+ musb_resources = devm_kzalloc(pdev-dev, pdev-num_resources *
+ sizeof(*musb_resources), GFP_KERNEL);
+ if (!musb_resources)
+ goto err3;
+
musb-dev.parent= pdev-dev;
musb-dev.dma_mask = bfin_dmamask;
musb-dev.coherent_dma_mask = bfin_dmamask;
@@ -480,21 +486,15 @@ static int bfin_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, glue);
- memset(musb_resources, 0x00, sizeof(*musb_resources) *
- ARRAY_SIZE(musb_resources));
-
- musb_resources[0].name = pdev-resource[0].name;
- musb_resources[0].start = pdev-resource[0].start;
- musb_resources[0].end = pdev-resource[0].end;
- musb_resources[0].flags = pdev-resource[0].flags;
-
- musb_resources[1].name = pdev-resource[1].name;
- musb_resources[1].start = pdev-resource[1].start;
- musb_resources[1].end = pdev-resource[1].end;
- musb_resources[1].flags = pdev-resource[1].flags;
+ for (i = 0; i pdev-num_resources; i++) {
+ musb_resources[i].name = pdev-resource[i].name;
+ musb_resources[i].start = pdev-resource[i].start;
+ musb_resources[i].end = pdev-resource[i].end;
+ musb_resources[i].flags = pdev-resource[i].flags;
+ }
ret = platform_device_add_resources(musb, musb_resources,
-
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
correct binding information to the PHY framework. I think we can drop having
this non-dt support in PHY framework? I see only one platform (OMAP3) going
to
be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the controller?
It should be deterministic as the PHY framework assigns its own id and we
*don't* want to add any requirement that the ID must be assigned manually
without using PLATFORM_DEVID_AUTO. We can get rid of *phy_init_data* in the v10
patch series.
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
[PATCH] usb: musb: dsps: depend on of_irq
Fengguang Wu' bot noticed that dsps won't compile without of_irq* available. I limit this to OF_IRQ for that reason. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig index 04658d7..f03f82c 100644 --- a/drivers/usb/musb/Kconfig +++ b/drivers/usb/musb/Kconfig @@ -83,6 +83,7 @@ config USB_MUSB_AM35X config USB_MUSB_DSPS tristate TI DSPS platforms + depends on OF_IRQ select USB_MUSB_AM335X_CHILD config USB_MUSB_BLACKFIN -- 1.8.4.rc1 -- 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/7] USB: mos7720: fix broken control requests
The parallel-port code of the drivers used a stack allocated
control-request buffer for asynchronous (and possibly deferred) control
requests. This not only violates the no-DMA-from-stack requirement but
could also lead to corrupt control requests being submitted.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7720.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 51da424..b013001 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -90,6 +90,7 @@ struct urbtracker {
struct list_headurblist_entry;
struct kref ref_count;
struct urb *urb;
+ struct usb_ctrlrequest *setup;
};
enum mos7715_pp_modes {
@@ -271,6 +272,7 @@ static void destroy_urbtracker(struct kref *kref)
struct mos7715_parport *mos_parport = urbtrack-mos_parport;
usb_free_urb(urbtrack-urb);
+ kfree(urbtrack-setup);
kfree(urbtrack);
kref_put(mos_parport-ref_count, destroy_mos_parport);
}
@@ -355,7 +357,6 @@ static int write_parport_reg_nonblock(struct
mos7715_parport *mos_parport,
struct urbtracker *urbtrack;
int ret_val;
unsigned long flags;
- struct usb_ctrlrequest setup;
struct usb_serial *serial = mos_parport-serial;
struct usb_device *usbdev = serial-dev;
@@ -373,14 +374,20 @@ static int write_parport_reg_nonblock(struct
mos7715_parport *mos_parport,
kfree(urbtrack);
return -ENOMEM;
}
- setup.bRequestType = (__u8)0x40;
- setup.bRequest = (__u8)0x0e;
- setup.wValue = get_reg_value(reg, dummy);
- setup.wIndex = get_reg_index(reg);
- setup.wLength = 0;
+ urbtrack-setup = kmalloc(sizeof(*urbtrack-setup), GFP_KERNEL);
+ if (!urbtrack-setup) {
+ usb_free_urb(urbtrack-urb);
+ kfree(urbtrack);
+ return -ENOMEM;
+ }
+ urbtrack-setup-bRequestType = (__u8)0x40;
+ urbtrack-setup-bRequest = (__u8)0x0e;
+ urbtrack-setup-wValue = get_reg_value(reg, dummy);
+ urbtrack-setup-wIndex = get_reg_index(reg);
+ urbtrack-setup-wLength = 0;
usb_fill_control_urb(urbtrack-urb, usbdev,
usb_sndctrlpipe(usbdev, 0),
-(unsigned char *)setup,
+(unsigned char *)urbtrack-setup,
NULL, 0, async_complete, urbtrack);
kref_init(urbtrack-ref_count);
INIT_LIST_HEAD(urbtrack-urblist_entry);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] USB: keyspan: fix serial DMA-buffer allocations
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/keyspan.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 58c17fd..8afde57 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -56,17 +56,17 @@ struct keyspan_serial_private {
const struct keyspan_device_details *device_details;
struct urb *instat_urb;
- charinstat_buf[INSTAT_BUFLEN];
+ char*instat_buf;
/* added to support 49wg, where data from all 4 ports comes in
on 1 EP and high-speed supported */
struct urb *indat_urb;
- charindat_buf[INDAT49W_BUFLEN];
+ char*indat_buf;
/* XXX this one probably will need a lock */
struct urb *glocont_urb;
- charglocont_buf[GLOCONT_BUFLEN];
- charctrl_buf[8];/* for EP0 control message */
+ char*glocont_buf;
+ char*ctrl_buf; /* for EP0 control message */
};
struct keyspan_port_private {
@@ -2313,6 +2313,22 @@ static int keyspan_startup(struct usb_serial *serial)
return -ENOMEM;
}
+ s_priv-instat_buf = kzalloc(INSTAT_BUFLEN, GFP_KERNEL);
+ if (!s_priv-instat_buf)
+ goto err_instat_buf;
+
+ s_priv-indat_buf = kzalloc(INDAT49W_BUFLEN, GFP_KERNEL);
+ if (!s_priv-indat_buf)
+ goto err_indat_buf;
+
+ s_priv-glocont_buf = kzalloc(GLOCONT_BUFLEN, GFP_KERNEL);
+ if (!s_priv-glocont_buf)
+ goto err_glocont_buf;
+
+ s_priv-ctrl_buf = kzalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL);
+ if (!s_priv-ctrl_buf)
+ goto err_ctrl_buf;
+
s_priv-device_details = d_details;
usb_set_serial_data(serial, s_priv);
@@ -2330,6 +2346,17 @@ static int keyspan_startup(struct usb_serial *serial)
}
return 0;
+
+err_ctrl_buf:
+ kfree(s_priv-glocont_buf);
+err_glocont_buf:
+ kfree(s_priv-indat_buf);
+err_indat_buf:
+ kfree(s_priv-instat_buf);
+err_instat_buf:
+ kfree(s_priv);
+
+ return -ENOMEM;
}
static void keyspan_disconnect(struct usb_serial *serial)
@@ -2353,6 +2380,11 @@ static void keyspan_release(struct usb_serial *serial)
usb_free_urb(s_priv-indat_urb);
usb_free_urb(s_priv-glocont_urb);
+ kfree(s_priv-ctrl_buf);
+ kfree(s_priv-glocont_buf);
+ kfree(s_priv-indat_buf);
+ kfree(s_priv-instat_buf);
+
kfree(s_priv);
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] USB: keyspan: fix null-deref at disconnect and release
Make sure to fail properly if the device is not accepted during attach
in order to avoid null-pointer derefs (of missing interface private
data) at disconnect or release.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/keyspan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 5a97972..58c17fd 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -2303,7 +2303,7 @@ static int keyspan_startup(struct usb_serial *serial)
if (d_details == NULL) {
dev_err(serial-dev-dev, %s - unknown product id %x\n,
__func__, le16_to_cpu(serial-dev-descriptor.idProduct));
- return 1;
+ return -ENODEV;
}
/* Setup private data for serial driver */
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] USB: quatech2: fix port DMA-buffer allocations
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/quatech2.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index 79c9b2b..a24d59a 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -122,7 +122,7 @@ struct qt2_port_private {
spinlock_t urb_lock;
bool urb_in_use;
struct urb *write_urb;
- char write_buffer[QT2_WRITE_BUFFER_SIZE];
+ char *write_buffer;
spinlock_t lock;
u8 shadowLSR;
@@ -755,21 +755,29 @@ static int qt2_port_probe(struct usb_serial_port *port)
spin_lock_init(port_priv-urb_lock);
port_priv-port = port;
+ port_priv-write_buffer = kmalloc(QT2_WRITE_BUFFER_SIZE, GFP_KERNEL);
+ if (!port_priv-write_buffer)
+ goto err_buf;
+
port_priv-write_urb = usb_alloc_urb(0, GFP_KERNEL);
- if (!port_priv-write_urb) {
- kfree(port_priv);
- return -ENOMEM;
- }
+ if (!port_priv-write_urb)
+ goto err_urb;
+
bEndpointAddress = serial-port[0]-bulk_out_endpointAddress;
usb_fill_bulk_urb(port_priv-write_urb, serial-dev,
usb_sndbulkpipe(serial-dev, bEndpointAddress),
port_priv-write_buffer,
- sizeof(port_priv-write_buffer),
+ QT2_WRITE_BUFFER_SIZE,
qt2_write_bulk_callback, port);
usb_set_serial_port_data(port, port_priv);
return 0;
+err_urb:
+ kfree(port_priv-write_buffer);
+err_buf:
+ kfree(port_priv);
+ return -ENOMEM;
}
static int qt2_port_remove(struct usb_serial_port *port)
@@ -778,6 +786,7 @@ static int qt2_port_remove(struct usb_serial_port *port)
port_priv = usb_get_serial_port_data(port);
usb_free_urb(port_priv-write_urb);
+ kfree(port_priv-write_buffer);
kfree(port_priv);
return 0;
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] USB: keyspan: fix port DMA-buffer allocations
Make sure port DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/keyspan.c | 64 ++--
1 file changed, 56 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 8afde57..d6960ae 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -50,6 +50,10 @@
#define INSTAT_BUFLEN 32
#define GLOCONT_BUFLEN 64
#define INDAT49W_BUFLEN512
+#define IN_BUFLEN 64
+#define OUT_BUFLEN 64
+#define INACK_BUFLEN 1
+#define OUTCONT_BUFLEN 64
/* Per device and per port private data */
struct keyspan_serial_private {
@@ -81,18 +85,18 @@ struct keyspan_port_private {
/* Input endpoints and buffer for this port */
struct urb *in_urbs[2];
- charin_buffer[2][64];
+ char*in_buffer[2];
/* Output endpoints and buffer for this port */
struct urb *out_urbs[2];
- charout_buffer[2][64];
+ char*out_buffer[2];
/* Input ack endpoint */
struct urb *inack_urb;
- charinack_buffer[1];
+ char*inack_buffer;
/* Output control endpoint */
struct urb *outcont_urb;
- charoutcont_buffer[64];
+ char*outcont_buffer;
/* Settings for the port */
int baud;
@@ -2406,6 +2410,26 @@ static int keyspan_port_probe(struct usb_serial_port
*port)
if (!p_priv)
return -ENOMEM;
+ for (i = 0; i ARRAY_SIZE(p_priv-in_buffer); ++i) {
+ p_priv-in_buffer[i] = kzalloc(IN_BUFLEN, GFP_KERNEL);
+ if (!p_priv-in_buffer[i])
+ goto err_in_buffer;
+ }
+
+ for (i = 0; i ARRAY_SIZE(p_priv-out_buffer); ++i) {
+ p_priv-out_buffer[i] = kzalloc(OUT_BUFLEN, GFP_KERNEL);
+ if (!p_priv-out_buffer[i])
+ goto err_out_buffer;
+ }
+
+ p_priv-inack_buffer = kzalloc(INACK_BUFLEN, GFP_KERNEL);
+ if (!p_priv-inack_buffer)
+ goto err_inack_buffer;
+
+ p_priv-outcont_buffer = kzalloc(OUTCONT_BUFLEN, GFP_KERNEL);
+ if (!p_priv-outcont_buffer)
+ goto err_outcont_buffer;
+
p_priv-device_details = d_details;
/* Setup values for the various callback routines */
@@ -2418,7 +2442,8 @@ static int keyspan_port_probe(struct usb_serial_port
*port)
for (i = 0; i = d_details-indat_endp_flip; ++i, ++endp) {
p_priv-in_urbs[i] = keyspan_setup_urb(serial, endp,
USB_DIR_IN, port,
- p_priv-in_buffer[i], 64,
+ p_priv-in_buffer[i],
+ IN_BUFLEN,
cback-indat_callback);
}
/* outdat endpoints also have flip */
@@ -2426,25 +2451,41 @@ static int keyspan_port_probe(struct usb_serial_port
*port)
for (i = 0; i = d_details-outdat_endp_flip; ++i, ++endp) {
p_priv-out_urbs[i] = keyspan_setup_urb(serial, endp,
USB_DIR_OUT, port,
- p_priv-out_buffer[i], 64,
+ p_priv-out_buffer[i],
+ OUT_BUFLEN,
cback-outdat_callback);
}
/* inack endpoint */
p_priv-inack_urb = keyspan_setup_urb(serial,
d_details-inack_endpoints[port_num],
USB_DIR_IN, port,
- p_priv-inack_buffer, 1,
+ p_priv-inack_buffer,
+ INACK_BUFLEN,
cback-inack_callback);
/* outcont endpoint */
p_priv-outcont_urb = keyspan_setup_urb(serial,
d_details-outcont_endpoints[port_num],
USB_DIR_OUT, port,
- p_priv-outcont_buffer, 64,
+ p_priv-outcont_buffer,
+ OUTCONT_BUFLEN,
cback-outcont_callback);
usb_set_serial_port_data(port, p_priv);
return 0;
+
+err_outcont_buffer:
+ kfree(p_priv-inack_buffer);
+err_inack_buffer:
+ for (i = 0; i ARRAY_SIZE(p_priv-out_buffer); ++i)
+ kfree(p_priv-out_buffer[i]);
+err_out_buffer:
+ for (i = 0; i
[PATCH 7/7] USB: uss720: fix DMA-buffer allocation
Make sure the USB control request is allocated separately from
containing structure to prevent potential memory corruption on
non-cache-coherent systems.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/misc/uss720.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index e129cf6..40ef40a 100644
--- a/drivers/usb/misc/uss720.c
+++ b/drivers/usb/misc/uss720.c
@@ -75,7 +75,7 @@ struct uss720_async_request {
struct list_head asynclist;
struct completion compl;
struct urb *urb;
- struct usb_ctrlrequest dr;
+ struct usb_ctrlrequest *dr;
__u8 reg[7];
};
@@ -98,6 +98,7 @@ static void destroy_async(struct kref *kref)
if (likely(rq-urb))
usb_free_urb(rq-urb);
+ kfree(rq-dr);
spin_lock_irqsave(priv-asynclock, flags);
list_del_init(rq-asynclist);
spin_unlock_irqrestore(priv-asynclock, flags);
@@ -120,7 +121,7 @@ static void async_complete(struct urb *urb)
if (status) {
dev_err(urb-dev-dev, async_complete: urb error %d\n,
status);
- } else if (rq-dr.bRequest == 3) {
+ } else if (rq-dr-bRequest == 3) {
memcpy(priv-reg, rq-reg, sizeof(priv-reg));
#if 0
dev_dbg(priv-usbdev-dev,
@@ -152,7 +153,7 @@ static struct uss720_async_request
*submit_async_request(struct parport_uss720_p
usbdev = priv-usbdev;
if (!usbdev)
return NULL;
- rq = kmalloc(sizeof(struct uss720_async_request), mem_flags);
+ rq = kzalloc(sizeof(struct uss720_async_request), mem_flags);
if (!rq) {
dev_err(usbdev-dev, submit_async_request out of memory\n);
return NULL;
@@ -168,13 +169,18 @@ static struct uss720_async_request
*submit_async_request(struct parport_uss720_p
dev_err(usbdev-dev, submit_async_request out of memory\n);
return NULL;
}
- rq-dr.bRequestType = requesttype;
- rq-dr.bRequest = request;
- rq-dr.wValue = cpu_to_le16(value);
- rq-dr.wIndex = cpu_to_le16(index);
- rq-dr.wLength = cpu_to_le16((request == 3) ? sizeof(rq-reg) : 0);
+ rq-dr = kmalloc(sizeof(*rq-dr), mem_flags);
+ if (!rq-dr) {
+ kref_put(rq-ref_count, destroy_async);
+ return NULL;
+ }
+ rq-dr-bRequestType = requesttype;
+ rq-dr-bRequest = request;
+ rq-dr-wValue = cpu_to_le16(value);
+ rq-dr-wIndex = cpu_to_le16(index);
+ rq-dr-wLength = cpu_to_le16((request == 3) ? sizeof(rq-reg) : 0);
usb_fill_control_urb(rq-urb, usbdev, (requesttype 0x80) ?
usb_rcvctrlpipe(usbdev, 0) : usb_sndctrlpipe(usbdev, 0),
-(unsigned char *)rq-dr,
+(unsigned char *)rq-dr,
(request == 3) ? rq-reg : NULL, (request == 3) ?
sizeof(rq-reg) : 0, async_complete, rq);
/* rq-urb-transfer_flags |= URB_ASYNC_UNLINK; */
spin_lock_irqsave(priv-asynclock, flags);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] USB: fixes for v3.11 (and v3.12)
Greg, Here's a bunch of fixes for v3.11 and (possibly) v3.12. The first two I think should go into v3.11 whereas the remaining patches could wait for v3.12, unless you think otherwise. I don't have access to these devices so have only done minimal testing of the serial ones using the dynamic-id interface (i.e. allocation / deallocation). Furthermore, any potential cache-coherence problems should be rare. I therefore left the last ones without a stable tag for now. Thanks, Johan Johan Hovold (7): USB: mos7720: fix broken control requests USB: keyspan: fix null-deref at disconnect and release USB: keyspan: fix serial DMA-buffer allocations USB: keyspan: fix port DMA-buffer allocations USB: quatech2: fix serial DMA-buffer allocations USB: quatech2: fix port DMA-buffer allocations USB: uss720: fix DMA-buffer allocation drivers/usb/misc/uss720.c | 24 ++ drivers/usb/serial/keyspan.c | 106 -- drivers/usb/serial/mos7720.c | 21 ++--- drivers/usb/serial/quatech2.c | 35 ++ 4 files changed, 149 insertions(+), 37 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] USB: quatech2: fix serial DMA-buffer allocations
Make sure serial DMA-buffers are allocated separately from containing
structure to prevent potential memory corruption on non-cache-coherent
systems.
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/quatech2.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/quatech2.c b/drivers/usb/serial/quatech2.c
index d997432..79c9b2b 100644
--- a/drivers/usb/serial/quatech2.c
+++ b/drivers/usb/serial/quatech2.c
@@ -62,6 +62,7 @@
#define MAX_BAUD_RATE 921600
#define DEFAULT_BAUD_RATE 9600
+#define QT2_READ_BUFFER_SIZE512 /* size of read buffer */
#define QT2_WRITE_BUFFER_SIZE 512 /* size of write buffer */
#define QT2_WRITE_CONTROL_SIZE 5/* control bytes used for a write */
@@ -112,7 +113,7 @@ struct qt2_serial_private {
unsigned char current_port; /* current port for incoming data */
struct urb *read_urb; /* shared among all ports */
- charread_buffer[512];
+ char*read_buffer;
};
struct qt2_port_private {
@@ -142,6 +143,7 @@ static void qt2_release(struct usb_serial *serial)
serial_priv = usb_get_serial_data(serial);
usb_free_urb(serial_priv-read_urb);
+ kfree(serial_priv-read_buffer);
kfree(serial_priv);
}
@@ -683,7 +685,7 @@ static int qt2_setup_urbs(struct usb_serial *serial)
usb_rcvbulkpipe(serial-dev,
port0-bulk_in_endpointAddress),
serial_priv-read_buffer,
- sizeof(serial_priv-read_buffer),
+ QT2_READ_BUFFER_SIZE,
qt2_read_bulk_callback, serial);
status = usb_submit_urb(serial_priv-read_urb, GFP_KERNEL);
@@ -718,6 +720,12 @@ static int qt2_attach(struct usb_serial *serial)
return -ENOMEM;
}
+ serial_priv-read_buffer = kmalloc(QT2_READ_BUFFER_SIZE, GFP_KERNEL);
+ if (!serial_priv-read_buffer) {
+ status = -ENOMEM;
+ goto err_buf;
+ }
+
usb_set_serial_data(serial, serial_priv);
status = qt2_setup_urbs(serial);
@@ -727,6 +735,8 @@ static int qt2_attach(struct usb_serial *serial)
return 0;
attach_failed:
+ kfree(serial_priv-read_buffer);
+err_buf:
kfree(serial_priv);
return status;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
Best regards,
Tomasz
--
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 RFC] ath9k-htc: convert EP3 and EP4 back from bulk to int
Am 13.08.2013 10:09, schrieb Oleksij Rempel:
If usb auto suspend is enabled or system run in to suspend/resume
cycle ath9k-htc adapter will stop to response. It is reproducible on xhci HCs.
Host part of problem:
XHCI do timing calculation based on Transfer Type and bInterval,
immediately after device was detected. Ath9k-htc try to overwrite
this parameters on module probe and some changes in FW,
since we do not initiate usb reset from the driver this changes
are not took to account. So, before any kind of suspend or reset,
host controller will operate with old parameters. Only after suspend/resume
and if interface id stay unchanged, new parameters will by applied. Host
will send bulk data with no intervals (?), which will cause
overflow on FIFO of EP4.
Firmware part of problem:
By default, ath9k-htc adapters configured with EP3 and EP4
as interrupt endpoints. Current firmware will try to overwrite
ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints
stay not reconfigured, so under the hood it is still Int EP.
After some digging in the code, i see that converting EP3 and EP4 to
bulk was a bug. This endpoints can't handle more then 64bytes, and
normally if we would provide it as usb descriptor, we would got warned.
See this code:
drivers/usb/core/config.c
/*
* Some buggy high speed devices have bulk endpoints using
* maxpacket sizes other than 512. High speed HCDs may not
* be able to handle that particular bug, so let's warn...
*/
if (to_usb_device(ddev)-speed == USB_SPEED_HIGH
usb_endpoint_xfer_bulk(d)) {
unsigned maxp;
maxp = usb_endpoint_maxp(endpoint-desc) 0x07ff;
if (maxp != 512)
dev_warn(ddev, config %d interface %d
altsetting %d
bulk endpoint 0x%X has invalid
maxpacket %d\n,
cfgno, inum, asnum, d-bEndpointAddress,
maxp);
}
--
Regards,
Oleksij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 13 August 2013 05:07 PM, Tomasz Figa wrote:
On Tuesday 13 of August 2013 16:14:44 Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 31 July 2013 11:45 AM, Felipe Balbi wrote:
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex
cases
when passing just a name using platform data will not work. I
would
second what Stephen said [1] and define a structure doing things
in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used
while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods
already
use ID to identify devices (see regulators, clkdev, PWMs, i2c,
...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways
when
devices get added to systems, making these strings constantly have
to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes
the
clock code wrong. Others have already said that this is wrong there
as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we
refuse to
learn from them...
So again, the find a phy by a string functions should be removed,
the
device id should be automatically created by the phy core just to
make
things unique in sysfs, and no driver code should _ever_ be reliant
on
the number that is being created, and the pointer to the phy
structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem,
but
without them, sorry, I will not.
I'll agree with Greg here, the very fact that we see people trying to
add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points
to a
big problem in the framework.
The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
adding similar infrastructure to the driver themselves to make sure
we
don't end up with duplicate names in sysfs in case we have multiple
instances of the same IP in the SoC (or several of the same PCIe
card).
I really don't want to go back to that.
If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can
give the correct binding information to the PHY framework. I think we
can drop having this non-dt support in PHY framework? I see only one
platform (OMAP3) going to be needing this non-dt support and we can
use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
hmm..
how about passing the device names of PHY in platform data of the
controller? It should be deterministic as the PHY framework assigns its
own id and we *don't* want to add any requirement that the ID must be
assigned manually without using PLATFORM_DEVID_AUTO. We can get rid of
*phy_init_data* in the v10 patch series.
What about slightly altering the concept of v9 to pass a pointer to struct
device instead of device name inside phy_init_data?
The problem is device might be created very late. (For example in omap4, usb2
phy device gets created when ocp2scp bus is probed). And we have to pass the
init data in board file.
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
[PATCH] usb: musb dsps: fix pdev cast in suspend/resume
dsps_suspend() and dsps_resume() are called with the device that has the
glue assigned as drvdata. Using dev-parent seems wrong and causes a
NULL pointer exception on an AM33xx board.
The code was introduced by commit c68bb4c6 (usb: musb: dsps: control
module handling (quirk)) but I wonder whether it was ever used.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 5233804..f20218e 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -692,7 +692,7 @@ static int dsps_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int dsps_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev-parent);
+ struct platform_device *pdev = to_platform_device(dev);
struct dsps_glue *glue = platform_get_drvdata(pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
@@ -705,7 +705,7 @@ static int dsps_suspend(struct device *dev)
static int dsps_resume(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev-parent);
+ struct platform_device *pdev = to_platform_device(dev);
struct dsps_glue *glue = platform_get_drvdata(pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
--
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: dwc3: core: clarify usb-phy array binding
On Mon, Aug 12, 2013 at 07:05:53PM +0100, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 01:42:15PM -0500, Kumar Gala wrote: On Aug 9, 2013, at 11:28 AM, Mark Rutland wrote: On Fri, Aug 09, 2013 at 04:40:32PM +0100, Kumar Gala wrote: The binding spec wasn't clear that the order of the phandles in the usb-phy array has meaning. Clarify this point in the binding that it should be USB2-HS-PHY, USB3-SS-PHY. Signed-off-by: Kumar Gala ga...@codeaurora.org --- Documentation/devicetree/bindings/usb/dwc3.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 7a95c65..8a9770b 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -6,7 +6,9 @@ Required properties: - compatible: must be synopsys,dwc3 - reg : Address and length of the register set for the device - interrupts: Interrupts used by the dwc3 controller. - - usb-phy : array of phandle for the PHY device + - usb-phy : array of phandle for the PHY device. The first element + in the array is expected to be a handle to the USB2/HS PHY and + the second element is expected to be a handle to the USB3/SS PHY Just to check - it's not valid to have a USB3 phy without a USB2 phy? Don't know, hopefully Felipe will chime in on that. that'd be a really non-standard implementation. Per-spec, USB3 is *always* backwards compatible with USB2. I'm slightly confused here. From a quick look at the driver, it expects two separate phys to be present -- one handling only USB2, and one handling USB3 (with USB2 backwards compatibility). So it's not physically possible for someone to just wire up a single phy to the device, either USB2-only or USB3? You can describe the USB2-only case in the dt by only listing the first phy (though the driver won't support it as it expects both to be present), but it's impossible to describe that you've wired up a single phy that's USB3 capable. Thanks, Mark. -- 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: musb: am335x: Do not remove the session bin HOST-only mode
On 08/13/2013 03:33 PM, Bin Liu wrote:
Sebastian,
Hi Bin,
I've been looking at the wiki page and it did not mention the ID pin
for the second port. If it is grounded then this piece can be removed
I thought you have already tried that without setting the mode
register the session bit cannot stay set.
This was a misunderstanding then. Sorry. I understood that the bin has
to be unset and then the controller set it once a device there.
I am not sure if anywhere mentioned about the ID pin, but ASAIK all
the different boards using am335x have ID pin grounded for host port.
evm is the only I am aware of. The evm-sk and beagle bone have just one
port. Beagle bone black is not mainline.
and the magic trick is just to skip the try_idle() call.
Agreed.
I haven't found anything saying that it is required to clear the
session bin in host mode, only in OTG. And then, I would assume to
Agreed.
receive a session interrupt once we have the proper VBUS level which
does not happen.
The TI 3.2 kernel for am335x sets the session bit in musb_start() for
host-only mode. Maybe we can do something similar in here? (I noticed
mush_start() has gone in mainline, but have not got a chance to check
the details...)
This is the case already. From musb_start()
…
if (musb-port_mode != MUSB_PORT_MODE_HOST
(devctl MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
musb-is_active = 1;
} else {
devctl |= MUSB_DEVCTL_SESSION;
}
…
-Bin.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: am335x: Do not remove the session bin HOST-only mode
Sebastian,
On Tue, Aug 13, 2013 at 8:44 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
This was a misunderstanding then. Sorry. I understood that the bin has
to be unset and then the controller set it once a device there.
You meant ID pin? I think it should be set all the time since the
driver initialized for host-only mode, if it is unset, the controller
has not way to know if a device is plugged or not.
I am not sure if anywhere mentioned about the ID pin, but ASAIK all
the different boards using am335x have ID pin grounded for host port.
evm is the only I am aware of. The evm-sk and beagle bone have just one
port. Beagle bone black is not mainline.
You meant the dts only supports one port for evm-sk and bone? The
boards physically have two ports, usb0 is device only, usb1 is host
only.
This is the case already. From musb_start()
…
if (musb-port_mode != MUSB_PORT_MODE_HOST
(devctl MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
musb-is_active = 1;
} else {
devctl |= MUSB_DEVCTL_SESSION;
}
…
great! then the host port on gp evm should work now, right?
-Bin.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dwc3: dwc3-pci: Use SIMPLE_DEV_PM_OPS
On Tue, Aug 13, 2013 at 8:59 PM, Fabio Estevam feste...@gmail.com wrote:
On Tue, Aug 13, 2013 at 3:59 AM, Peter Chen hzpeterc...@gmail.com wrote:
It seems .pm is not NULL if CONFIG_PM_SLEEP is not defined
which is not the same with former code.
With SIMPLE_DEV_PM_OPS macro we don't need to define the NULL function
variants.
Take a look at include/linux/pm.h to get a clear picture.
But what I see is the dwc3_pci_dev_pm_ops is not NULL if CONFIG_PM_SLEEP
is not defined.
static foo(void)
{}
static goo(void)
{}
struct dev_pm_ops {
int a;
int b;
};
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
}
SIMPLE_DEV_PM_OPS(test_name, foo, goo);
void main(void)
{
printf(the pointer of name is %p\n, test_name);
return;
}
--
BR,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: add Kconfig option for EHSET
On Mon, 12 Aug 2013, Jack Pham wrote: commit 9841f37a1c (usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET) added additional code to the EHCI hub driver but it is anticipated to only have a limited audience (e.g. embedded silicon vendors and integrators). Avoid subjecting all EHCI (and in the future maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally compiling the EHSET-specific additions with a new Kconfig option, CONFIG_USB_HCD_TEST_MODE. Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Jack Pham ja...@codeaurora.org Quick work, thank you. Greg, do you object to this new Kconfig option? diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index cf521d6..b009368 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -722,3 +722,18 @@ config USB_HCD_SSB for ehci and ohci. If unsure, say N. + +config USB_HCD_TEST_MODE + bool HCD test mode support + ---help--- + Say 'Y' to enable additional software test modes that may be + supported by the host controller drivers. + + One such test mode is the Embedded High-speed Host Electrical Test + (EHSET) for EHCI host controller hardware, specifically the Single + Step Set Feature test. Typically this will be enabled for On-the-Go + or embedded hosts that need to undergo USB-IF compliance testing with + the aid of a special test fixture. In the future, this may expand to s/a special test fixture/special testing hardware/ + include other tests that require support from a HCD driver. + + If unsure, say N. There should be something along the lines of: This option is of interest only to developers who need to validate their USB hardware designs. It is not needed for normal use. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] ath9k-htc: convert EP3 and EP4 back from bulk to int
On Tue, 13 Aug 2013, Oleksij Rempel wrote: If usb auto suspend is enabled or system run in to suspend/resume cycle ath9k-htc adapter will stop to response. It is reproducible on xhci HCs. Host part of problem: XHCI do timing calculation based on Transfer Type and bInterval, immediately after device was detected. Ath9k-htc try to overwrite this parameters on module probe and some changes in FW, since we do not initiate usb reset from the driver this changes are not took to account. So, before any kind of suspend or reset, host controller will operate with old parameters. Only after suspend/resume and if interface id stay unchanged, new parameters will by applied. Host will send bulk data with no intervals (?), which will cause overflow on FIFO of EP4. Firmware part of problem: By default, ath9k-htc adapters configured with EP3 and EP4 as interrupt endpoints. Current firmware will try to overwrite ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints stay not reconfigured, so under the hood it is still Int EP. One little comment on the patch title. You aren't converting the endpoints back from bulk to interrupt; rather you are preventing the driver and firmware from trying to convert them from interrupt to bulk. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dwc3: dwc3-pci: Use SIMPLE_DEV_PM_OPS
On Tue, Aug 13, 2013 at 11:05 AM, Peter Chen hzpeterc...@gmail.com wrote: But what I see is the dwc3_pci_dev_pm_ops is not NULL if CONFIG_PM_SLEEP is not defined. The point of this macro is that we do not need to provide the .suspend and .resume NULL version when !CONFIG_PM_SLEEP because the macro takes care of this for us: #ifdef CONFIG_PM_SLEEP #define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \ .suspend = suspend_fn, \ .resume = resume_fn, \ .freeze = suspend_fn, \ .thaw = resume_fn, \ .poweroff = suspend_fn, \ .restore = resume_fn, #else #define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) #endif -- 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: musb: am335x: Do not remove the session bin HOST-only mode
On 08/13/2013 04:01 PM, Bin Liu wrote:
Sebastian,
Hi Bin,
On Tue, Aug 13, 2013 at 8:44 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
This was a misunderstanding then. Sorry. I understood that the bin has
to be unset and then the controller set it once a device there.
You meant ID pin? I think it should be set all the time since the
driver initialized for host-only mode, if it is unset, the controller
has not way to know if a device is plugged or not.
Okay.
I am not sure if anywhere mentioned about the ID pin, but ASAIK all
the different boards using am335x have ID pin grounded for host port.
evm is the only I am aware of. The evm-sk and beagle bone have just one
port. Beagle bone black is not mainline.
You meant the dts only supports one port for evm-sk and bone? The
boards physically have two ports, usb0 is device only, usb1 is host
only.
Where is my memory going? So now I have a beagle bone in front of me
and I see a micro USB port a standard A connector. My memory was
different.
The micro USB is the UART and standard is most likely the first musb
instance. So this should run also in host mode and not in OTG mode.
Hmmm. Let me double check this.
This is the case already. From musb_start()
…
if (musb-port_mode != MUSB_PORT_MODE_HOST
(devctl MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
musb-is_active = 1;
} else {
devctl |= MUSB_DEVCTL_SESSION;
}
…
great! then the host port on gp evm should work now, right?
With the change where don't can try_idle() in host mode, yes.
-Bin.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: am335x: Do not remove the session bin HOST-only mode
Sebastian, On Tue, Aug 13, 2013 at 9:23 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Where is my memory going? So now I have a beagle bone in front of me and I see a micro USB port a standard A connector. My memory was different. The micro USB is the UART and standard is most likely the first musb instance. So this should run also in host mode and not in OTG mode. Hmmm. Let me double check this. I don't know how dts instances both in mainline, but I would think if you create two musb instances, and load a gadget driver for this micro USB port, the USB host should enumerate it. The standard port should be the 2nd instance which has its ID pin grounded and work in host-only mode. This is how they work in TI 3.2 kernel. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/3] net/usb/r8152: enable tx checksum
Hello.
On 08/13/2013 11:28 AM, Hayes Wang wrote:
Enable tx checksum.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 63 +
1 file changed, 58 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6c5aa2..5d9d949 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
[...]
@@ -964,6 +971,51 @@ err1:
return -ENOMEM;
}
+static void
+r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, struct sk_buff *skb)
+{
[...]
+ if (ip_protocol == IPPROTO_TCP) {
+ opts2 |= TCP_CS;
+ opts2 |= (skb_transport_offset(skb) 0x7fff) 17;
+ } else if (ip_protocol == IPPROTO_UDP) {
+ opts2 |= UDP_CS;
+ } else
+ WARN_ON_ONCE(1);
Stange, why *else if* branch has {} and *else* don't. It should, according
to Documentation/CodingStyle.
+
+ desc-opts2 = cpu_to_le32(opts2);
+ }
+}
+
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/3] net/usb/r8152: support aggregation
On Tue, 2013-08-13 at 20:32 +0800, hayeswang wrote:
Oliver Neukum [mailto:oneu...@suse.de]
Sent: Tuesday, August 13, 2013 4:49 PM
To: Hayeswang
Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-usb@vger.kernel.org
Subject: Re: [PATCH net-next 1/3] net/usb/r8152: support aggregation
[...]
+ len_used = 0;
+ rx_desc = agg-head;
+ rx_data = agg-head;
+ smp_wmb();
+ pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
+ len_used += sizeof(struct rx_desc) + pkt_len;
+
+ while (urb-actual_length = len_used) {
+ if (pkt_len ETH_ZLEN)
+ break;
+
+ pkt_len -= 4; /* CRC */
+ rx_data += sizeof(struct rx_desc);
+
+ skb = netdev_alloc_skb_ip_align(netdev,
pkt_len);
+ if (!skb) {
+ stats-rx_dropped++;
+ break;
+ }
+ memcpy(skb-data, rx_data, pkt_len);
+ skb_put(skb, pkt_len);
+ skb-protocol = eth_type_trans(skb, netdev);
+ netif_rx(skb);
+ stats-rx_packets++;
+ stats-rx_bytes += pkt_len;
+
+ rx_data = rx_agg_align(rx_data +
pkt_len + 4);
+ rx_desc = (struct rx_desc *)rx_data;
+ smp_wmb();
Against what is the memory barrier?
Excuse me. I don't understand your question. Do you mean the function should
not
be used here?
I don't understand what problem the function is supposed to fix. As long
as I don't understand it I cannot say for sure whether it is correct.
There seems no obvious reason for a memory barrier, but there may be a
hidden reason I don't see.
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: [RFC/PATCH 2/2] usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET
On Mon, Aug 12, 2013 at 02:52:33PM -0400, Alan Stern wrote:
On Mon, 12 Aug 2013, Felipe Balbi wrote:
maybe a single callback for supporting 'testmodes' ? which receives the
test mode as argument ?
I don't have a clear picture of how you would apply such an approach to
this case. There would have to be a way to tell the HCD to insert a
15-second delay between the Setup and Data stages of a particular
control URB. How would you do that? Whatever method you choose,
each test is started after enumerating a known Vid/Pid pair. Based on
that, you *know* which test to run.
That's not what I meant. Yes, the test-device driver knows what test
it wants to run, based on the VID/PID. I was asking how it would
communicate this knowledge to the HCD.
For example, it doesn't make sense to have a callback that means
Insert a 15-second delay into the next URB that I submit, because the
HCD doesn't know where URBs come from.
static int ehci_test_mode(struct usb_hcd *hcd, unsigned int test)
{
struct ehci_hcd *ehci = to_ehci(hcd);
switch (test) {
case USB_TEST_SINGLE_STEP_GET_DESC:
start_test();
wait_15_seconds();
finish_test();
break;
...
default:
return -ENOTSUP;
}
return ret;
}
...
static struct hc_driver ehci_hcd_driver = {
.test_mode = ehci_test_mode,
...
};
What other test modes would you want to support?
anything that USB[23]0CV supports today. There are even link layer tests
for USB3 and a bunch of others. This SINGLE_STEP_SET_FEATURE is but one
of a large(-ish) test suite which needs to be supported.
That's what I'm trying to find out. What are the special features that
we would need to implement in order to support the entire test suite?
I haven't looked at USB??CV spec for a while, maybe Jack knows better ?
Is it worth adding this support to the standard host controller
drivers, or should there be a special version (a Kconfig option like
CONFIG_RCU_TORTURE_TEST) to enable it? Putting a lot of testing code
in distribution kernels where it will never be used seems like a big
waste.
right, I think it should be hidden by Kconfig, not arguing against that.
Therefore we both agree the $SUBJECT patch should not be accepted in
its current form. At the very least, the new code in ehci-hcd should
be conditional on a CONFIG_USB_HCD_TEST_MODE option. In addition, we
may want some of the work (though at this point I'm not still clear on
exactly what parts) to be moved into usbcore.
right
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: musb dsps: fix pdev cast in suspend/resume
On Tue, Aug 13, 2013 at 02:40:30PM +0200, Daniel Mack wrote:
dsps_suspend() and dsps_resume() are called with the device that has the
glue assigned as drvdata. Using dev-parent seems wrong and causes a
NULL pointer exception on an AM33xx board.
The code was introduced by commit c68bb4c6 (usb: musb: dsps: control
module handling (quirk)) but I wonder whether it was ever used.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_dsps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 5233804..f20218e 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -692,7 +692,7 @@ static int dsps_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int dsps_suspend(struct device *dev)
{
- struct platform_device *pdev = to_platform_device(dev-parent);
+ struct platform_device *pdev = to_platform_device(dev);
struct dsps_glue *glue = platform_get_drvdata(pdev);
actually, can you get rid of the platform_device access here ? The
following should work:
struct dsps_glue *glue = dev_get_drvdata(dev);
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/2] Revert Revert HID: Fix logitech-dj: missing Unifying device issue
On Tuesday 13 August 2013 08:13:17 Peter Hurley wrote: On 08/12/2013 05:54 PM, Peter Wu wrote: On Thursday 18 July 2013 16:28:01 Peter Hurley wrote: Before we revert to using the workaround, I'd like to suggest that this new hidden problem may be an interaction with the xhci_hcd host controller driver only. Looking at the related bug, the OP indicates the machine only has USB3 ports. Additionally, comments #7, #100, and #104 of the original bug report add additional information that would seem to confirm this suspicion. Let me add I have this USB device running on the uhci_hcd driver with or without this workaround on v3.10. This problem does not seem specific to xhci, uhci seems also effected. If true, it would certainly help to have a bug report confirming uhci failure from a bare-metal system which contained: 1) kernel version 2) complete dmesg output 3) lsusb -v output 4) lsmod output 5) usbmon capture from a plug attempt I was too fast in drawing a conclusion, besides the kernel I also upgraded some other packages. Today the issue also showed up in 3.9.9 + updated packages. When checking the dmesg, the issue solved by this patch did not occur (the enumeration was successful). Today I upgraded a system (running Arch Linux) from kernel 3.9.9 to 3.10.5. After a reboot to 3.10.5, things broke. The setup: - There are two USB receivers plugged into USB 1.1 ports (different buses according to lsusb, uhci), each receiver is paired to a K360 keyboard. - One of the receivers are passed to a QEMU guest with -usbdevice host:$busid. $devid. This keyboard is working (probably because QEMU performed a reset). - Since 3.10.5, the keyboard that is *not* passed to the QEMU guest is not functioning on reboot. After closing the QEMU guest, the USB bus gets reset(?) after which the other keyboard suddenly gets detected. I had only booted 3.10.5 twice before rolling back to 3.9.9, both boots triggered the issue. Do I need to provide a usbmon, lsusb, dmesg and/ or other details from 3.10.5? Do both keyboards work on bare metal? Seems like this problem might be specific to qemu (or kvm) and you may get more insight on those lists. I haven't tested that, the system automatically boots into openbox + QEMU. Previously, both keyboards worked on bare metal, so I think it still works. Note that there are other Arch Linux users who have reported issues[1][2] Unfortunately, not even one user in the referenced reports identified the usb hub the receiver was plugged into. I've asked it now. since upgrading to 3.10.z. Triggering a re-enumeration by writing the magic HID++ message[3] makes the paired devices appear again (as reported in forums[1], I haven't tried this on the affected UHCI machine). While the underlying bug is fixed, can this patch be forwarded to stable? I see that 3.10.6 has been released, but still without this patch. This is still a workaround and not really a fix for the underlying bug. I meant to say, while the underlying bug is *being* fixed. Anyway, can this patch be applied to 3.10? Sorry for the confusion with uhci, looking further it seems that the wrong USB receiver is being passed to QEMU. It's not a kernel issue, perhaps I can blame libusbx. Regards, Peter -- 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: musb: dsps: depend on of_irq
On 08/13/2013 05:36 PM, Felipe Balbi wrote: Hi, Hi, I sent this patch yesterday. And how did you know about zhis yesterday? The bot reached me today. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] staging: ozwpan: Simply if condition
Making code simpler for readability.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 5a417c8..4b658d4 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -478,7 +478,7 @@ static int oz_enqueue_ep_urb(struct oz_port *port, u8
ep_addr, int in_dir,
struct urb *urb, u8 req_id)
{
struct oz_urb_link *urbl;
- struct oz_endpoint *ep;
+ struct oz_endpoint *ep = NULL;
int err = 0;
if (ep_addr = OZ_NB_ENDPOINTS) {
@@ -506,11 +506,12 @@ static int oz_enqueue_ep_urb(struct oz_port *port, u8
ep_addr, int in_dir,
oz_free_urb_link(urbl);
return 0;
}
- if (in_dir port-in_ep[ep_addr])
+
+ if (in_dir)
ep = port-in_ep[ep_addr];
- else if (!in_dir port-out_ep[ep_addr])
+ else
ep = port-out_ep[ep_addr];
- else {
+ if (!ep) {
err = -ENOMEM;
goto out;
}
--
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 02/10] staging: ozwpan: Add a blank line between functions declarations.
This patch adds a blank line between global declarations
functions for readability.
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozcdev.c| 17
drivers/staging/ozwpan/ozeltbuf.c | 12 ++
drivers/staging/ozwpan/ozhcd.c | 68
drivers/staging/ozwpan/ozmain.c|3 ++
drivers/staging/ozwpan/ozpd.c | 40 +++
drivers/staging/ozwpan/ozproto.c | 26
drivers/staging/ozwpan/ozurbparanoia.c |2 +
drivers/staging/ozwpan/ozusbsvc.c |9 +
drivers/staging/ozwpan/ozusbsvc1.c | 12 ++
9 files changed, 189 insertions(+)
diff --git a/drivers/staging/ozwpan/ozcdev.c b/drivers/staging/ozwpan/ozcdev.c
index 0c79fd0..01673d4 100644
--- a/drivers/staging/ozwpan/ozcdev.c
+++ b/drivers/staging/ozwpan/ozcdev.c
@@ -43,6 +43,7 @@ struct oz_serial_ctx {
*/
static struct oz_cdev g_cdev;
static struct class *g_oz_class;
+
/*--
* Context: process and softirq
*/
@@ -57,6 +58,7 @@ static struct oz_serial_ctx *oz_cdev_claim_ctx(struct oz_pd
*pd)
spin_unlock_bh(pd-app_lock[OZ_APPID_SERIAL-1]);
return ctx;
}
+
/*--
* Context: softirq or process
*/
@@ -67,6 +69,7 @@ static void oz_cdev_release_ctx(struct oz_serial_ctx *ctx)
kfree(ctx);
}
}
+
/*--
* Context: process
*/
@@ -79,6 +82,7 @@ static int oz_cdev_open(struct inode *inode, struct file
*filp)
filp-private_data = dev;
return 0;
}
+
/*--
* Context: process
*/
@@ -86,6 +90,7 @@ static int oz_cdev_release(struct inode *inode, struct file
*filp)
{
return 0;
}
+
/*--
* Context: process
*/
@@ -138,6 +143,7 @@ out2:
oz_pd_put(pd);
return count;
}
+
/*--
* Context: process
*/
@@ -195,6 +201,7 @@ out:
oz_pd_put(pd);
return count;
}
+
/*--
* Context: process
*/
@@ -229,6 +236,7 @@ static int oz_set_active_pd(const u8 *addr)
}
return rc;
}
+
/*--
* Context: process
*/
@@ -296,6 +304,7 @@ static long oz_cdev_ioctl(struct file *filp, unsigned int
cmd,
}
return rc;
}
+
/*--
* Context: process
*/
@@ -319,6 +328,7 @@ static unsigned int oz_cdev_poll(struct file *filp,
poll_table *wait)
poll_wait(filp, dev-rdq, wait);
return ret;
}
+
/*--
*/
static const struct file_operations oz_fops = {
@@ -330,6 +340,7 @@ static const struct file_operations oz_fops = {
.unlocked_ioctl = oz_cdev_ioctl,
.poll = oz_cdev_poll
};
+
/*--
* Context: process
*/
@@ -374,6 +385,7 @@ unregister:
unregister_chrdev_region(g_cdev.devnum, 1);
return err;
}
+
/*--
* Context: process
*/
@@ -387,6 +399,7 @@ int oz_cdev_deregister(void)
}
return 0;
}
+
/*--
* Context: process
*/
@@ -395,6 +408,7 @@ int oz_cdev_init(void)
oz_app_enable(OZ_APPID_SERIAL, 1);
return 0;
}
+
/*--
* Context: process
*/
@@ -402,6 +416,7 @@ void oz_cdev_term(void)
{
oz_app_enable(OZ_APPID_SERIAL, 0);
}
+
/*--
* Context: softirq-serialized
*/
@@ -439,6 +454,7 @@ int oz_cdev_start(struct oz_pd *pd, int resume)
oz_dbg(ON, Serial service started\n);
return 0;
}
+
/*--
* Context: softirq or process
*/
@@ -468,6 +484,7 @@ void oz_cdev_stop(struct oz_pd *pd, int pause)
}
oz_dbg(ON, Serial service stopped\n);
}
+
/*--
* Context: softirq-serialized
*/
diff --git a/drivers/staging/ozwpan/ozeltbuf.c
b/drivers/staging/ozwpan/ozeltbuf.c
index 0b8b468..4844d9f 100644
--- a/drivers/staging/ozwpan/ozeltbuf.c
+++
[PATCH 10/10] staging: ozwpan: Separate success failure case for oz_hcd_pd_arrived()
From: Dan Carpenter dan.carpen...@oracle.com
This patch separates success failure block along with fixing
following issues:-
1. The way oz_hcd_pd_arrived() looks now it's easy to think we free ep but
actually we do this spaghetti thing of setting it to NULL on success.
2. It is hard to read it because there are unlocks scattered throughout.
3. Currently we set ep to NULL on the success path and then test it and or
free it. In current code you have to scroll to the start of the function
to read code.
Original patch was submitted by Dan here :-
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2013-August/040113.html
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c | 54
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 0b21c9f..4cd08da 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -668,50 +668,50 @@ struct oz_port *oz_hcd_pd_arrived(void *hpd)
struct oz_endpoint *ep;
ozhcd = oz_hcd_claim();
- if (ozhcd == NULL)
+ if (!ozhcd)
return NULL;
/* Allocate an endpoint object in advance (before holding hcd lock) to
* use for out endpoint 0.
*/
ep = oz_ep_alloc(0, GFP_ATOMIC);
+ if (!ep)
+ goto err_put;
+
spin_lock_bh(ozhcd-hcd_lock);
- if (ozhcd-conn_port = 0) {
- spin_unlock_bh(ozhcd-hcd_lock);
- oz_dbg(ON, conn_port = 0\n);
- goto out;
- }
+ if (ozhcd-conn_port = 0)
+ goto err_unlock;
+
for (i = 0; i OZ_NB_PORTS; i++) {
struct oz_port *port = ozhcd-ports[i];
+
spin_lock(port-port_lock);
- if ((port-flags OZ_PORT_F_PRESENT) == 0) {
+ if (!(port-flags OZ_PORT_F_PRESENT)) {
oz_acquire_port(port, hpd);
spin_unlock(port-port_lock);
break;
}
spin_unlock(port-port_lock);
}
- if (i OZ_NB_PORTS) {
- oz_dbg(ON, Setting conn_port = %d\n, i);
- ozhcd-conn_port = i;
- /* Attach out endpoint 0.
-*/
- ozhcd-ports[i].out_ep[0] = ep;
- ep = NULL;
- hport = ozhcd-ports[i];
- spin_unlock_bh(ozhcd-hcd_lock);
- if (ozhcd-flags OZ_HDC_F_SUSPENDED) {
- oz_dbg(ON, Resuming root hub\n);
- usb_hcd_resume_root_hub(ozhcd-hcd);
- }
- usb_hcd_poll_rh_status(ozhcd-hcd);
- } else {
- spin_unlock_bh(ozhcd-hcd_lock);
- }
-out:
- if (ep) /* ep is non-null if not used. */
- oz_ep_free(NULL, ep);
+ if (i == OZ_NB_PORTS)
+ goto err_unlock;
+
+ ozhcd-conn_port = i;
+ hport = ozhcd-ports[i];
+ hport-out_ep[0] = ep;
+ spin_unlock_bh(ozhcd-hcd_lock);
+ if (ozhcd-flags OZ_HDC_F_SUSPENDED)
+ usb_hcd_resume_root_hub(ozhcd-hcd);
+ usb_hcd_poll_rh_status(ozhcd-hcd);
oz_hcd_put(ozhcd);
+
return hport;
+
+err_unlock:
+ spin_unlock_bh(ozhcd-hcd_lock);
+ oz_ep_free(NULL, ep);
+err_put:
+ oz_hcd_put(ozhcd);
+ return NULL;
}
/*--
--
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 09/10] staging: ozwpan: Swap arguments of oz_ep_alloc() to match kmalloc()
Swap arguments of oz_ep_alloc() to match kmalloc() for better readability.
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 0fd3fea..0b21c9f 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -327,7 +327,7 @@ static void oz_empty_link_pool(void)
* allocated it immediately follows the endpoint structure.
* Context: softirq
*/
-static struct oz_endpoint *oz_ep_alloc(gfp_t mem_flags, int buffer_size)
+static struct oz_endpoint *oz_ep_alloc(int buffer_size, gfp_t mem_flags)
{
struct oz_endpoint *ep =
kzalloc(sizeof(struct oz_endpoint)+buffer_size, mem_flags);
@@ -673,7 +673,7 @@ struct oz_port *oz_hcd_pd_arrived(void *hpd)
/* Allocate an endpoint object in advance (before holding hcd lock) to
* use for out endpoint 0.
*/
- ep = oz_ep_alloc(GFP_ATOMIC, 0);
+ ep = oz_ep_alloc(0, GFP_ATOMIC);
spin_lock_bh(ozhcd-hcd_lock);
if (ozhcd-conn_port = 0) {
spin_unlock_bh(ozhcd-hcd_lock);
@@ -1268,7 +1268,7 @@ static int oz_build_endpoints_for_interface(struct
usb_hcd *hcd,
}
}
- ep = oz_ep_alloc(mem_flags, buffer_size);
+ ep = oz_ep_alloc(buffer_size, mem_flags);
if (!ep) {
oz_clean_endpoints_for_interface(hcd, port, if_ix);
return -ENOMEM;
--
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 07/10] staging: ozwpan: Make oz_hcd_pd_departed() take a struct pointer.
oz_hcd_pd_departed() takes struct oz_port pointer instead of
void *, change function declaration to avoid ambiguity.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |4 ++--
drivers/staging/ozwpan/ozhcd.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 73d80f2..ed3ffeb 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -720,9 +720,9 @@ out:
* polled. We release the reference we hold on the PD.
* Context: softirq
*/
-void oz_hcd_pd_departed(void *hport)
+void oz_hcd_pd_departed(struct oz_port *hport)
{
- struct oz_port *port = (struct oz_port *)hport;
+ struct oz_port *port = hport;
struct oz_hcd *ozhcd;
void *hpd;
struct oz_endpoint *ep = NULL;
diff --git a/drivers/staging/ozwpan/ozhcd.h b/drivers/staging/ozwpan/ozhcd.h
index ef3202f..55e97b1 100644
--- a/drivers/staging/ozwpan/ozhcd.h
+++ b/drivers/staging/ozwpan/ozhcd.h
@@ -7,8 +7,8 @@
int oz_hcd_init(void);
void oz_hcd_term(void);
-void oz_hcd_pd_departed(void *ctx);
struct oz_port *oz_hcd_pd_arrived(void *ctx);
+void oz_hcd_pd_departed(struct oz_port *hport);
void oz_hcd_pd_reset(void *hpd, void *hport);
#endif /* _OZHCD_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] staging: ozwpan: Make oz_hcd_pd_arrived() return a struct pointer
oz_hcd_pd_arrived returns struct oz_port *, change function
declaration to avoid ambiguity.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |4 ++--
drivers/staging/ozwpan/ozhcd.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c
index 8633f0c..73d80f2 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -660,10 +660,10 @@ static inline void oz_hcd_put(struct oz_hcd *ozhcd)
* probably very rare indeed.
* Context: softirq
*/
-void *oz_hcd_pd_arrived(void *hpd)
+struct oz_port *oz_hcd_pd_arrived(void *hpd)
{
int i;
- void *hport = NULL;
+ struct oz_port *hport = NULL;
struct oz_hcd *ozhcd = NULL;
struct oz_endpoint *ep;
diff --git a/drivers/staging/ozwpan/ozhcd.h b/drivers/staging/ozwpan/ozhcd.h
index 9b30dfd..ef3202f 100644
--- a/drivers/staging/ozwpan/ozhcd.h
+++ b/drivers/staging/ozwpan/ozhcd.h
@@ -7,8 +7,8 @@
int oz_hcd_init(void);
void oz_hcd_term(void);
-void *oz_hcd_pd_arrived(void *ctx);
void oz_hcd_pd_departed(void *ctx);
+struct oz_port *oz_hcd_pd_arrived(void *ctx);
void oz_hcd_pd_reset(void *hpd, void *hport);
#endif /* _OZHCD_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] staging: ozwpan: Swap arguments of oz_ep_alloc() to match kmalloc()
On Tue, 2013-08-13 at 18:29 +0100, Rupesh Gujare wrote: Swap arguments of oz_ep_alloc() to match kmalloc() for better readability. [] diff --git a/drivers/staging/ozwpan/ozhcd.c b/drivers/staging/ozwpan/ozhcd.c [] -static struct oz_endpoint *oz_ep_alloc(gfp_t mem_flags, int buffer_size) +static struct oz_endpoint *oz_ep_alloc(int buffer_size, gfp_t mem_flags) could use size_t buffer_size instead. -- 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: musb: honour the return value of dma_map_single()
Since dma_map_single() may fail it is good to actually check the return
code to see if it succeeded.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_gadget.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 96632f9..d81c6ef 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -76,13 +76,21 @@ static inline void map_dma_buffer(struct musb_request
*request,
return;
if (request-request.dma == DMA_ADDR_INVALID) {
- request-request.dma = dma_map_single(
+ dma_addr_t dma_addr;
+ int ret;
+
+ dma_addr = dma_map_single(
musb-controller,
request-request.buf,
request-request.length,
request-tx
? DMA_TO_DEVICE
: DMA_FROM_DEVICE);
+ ret = dma_mapping_error(musb-controller, dma_addr);
+ if (ret)
+ return;
+
+ request-request.dma = dma_addr;
request-map_state = MUSB_MAPPED;
} else {
dma_sync_single_for_device(musb-controller,
--
1.8.4.rc1
--
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] usb: rh_call_control tbuf overflow fix
rh_call_control() contains a buffer, tbuf, which it uses to hold
USB descriptors. These discriptors are eventually copied into the
transfer_buffer in the URB. The buffer in the URB is dynamically
defined and is always large enough to hold the amount of data it
requests.
tbuf is currently statically allocated on the stack with a size
of 15 bytes, regardless of the size specified in the URB.
This patch dynamically allocates tbuf, and ensures that tbuf is
at least as big as the buffer in the URB.
If an hcd attempts to write a descriptor containing more than
15 bytes ( such as the Standard BOS Descriptor for hubs, defined
in the USB3.0 Spec, section 10.13.1 ) the write would overflow
the buffer and corrupt the stack. This patch addresses this
behavior.
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Sean O. Stalley sean.stal...@intel.com
---
drivers/usb/core/hcd.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 014dc99..3e64e2d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -464,17 +464,13 @@ static int rh_call_control (struct usb_hcd *hcd, struct
urb *urb)
struct usb_ctrlrequest *cmd;
u16 typeReq, wValue, wIndex, wLength;
u8 *ubuf = urb-transfer_buffer;
- /*
-* tbuf should be as big as the BOS descriptor and
-* the USB hub descriptor.
-*/
- u8 tbuf[USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE]
- __attribute__((aligned(4)));
- const u8*bufp = tbuf;
unsignedlen = 0;
int status;
u8 patch_wakeup = 0;
u8 patch_protocol = 0;
+ u16 tbuf_size;
+ u8 *tbuf = NULL;
+ const u8*bufp;
might_sleep();
@@ -494,6 +490,18 @@ static int rh_call_control (struct usb_hcd *hcd, struct
urb *urb)
if (wLength urb-transfer_buffer_length)
goto error;
+ /*
+* tbuf should be at least as big as the
+* USB hub descriptor.
+*/
+ tbuf_size = max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
+ tbuf = kzalloc(tbuf_size, GFP_KERNEL);
+ if (!tbuf)
+ return -ENOMEM;
+
+ bufp = tbuf;
+
+
urb-actual_length = 0;
switch (typeReq) {
@@ -691,6 +699,8 @@ error:
bDeviceProtocol = USB_HUB_PR_HS_SINGLE_TT;
}
+ kfree(tbuf);
+
/* any errors get returned through the urb completion */
spin_lock_irq(hcd_root_hub_lock);
usb_hcd_unlink_urb_from_ep(hcd, urb);
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
enable device mode for cppi41
Hi, tested a little with g_ncm on amm35x-evm. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: musb: cppi41: Enable in device-TX mode
Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_cppi41.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c index a74259e..e64701d 100644 --- a/drivers/usb/musb/musb_cppi41.c +++ b/drivers/usb/musb/musb_cppi41.c @@ -362,6 +362,9 @@ static int cppi41_is_compatible(struct dma_channel *channel, u16 maxpacket, WARN_ON(1); return 1; } + if (cppi41_channel-is_tx) + return 1; + /* AM335x Advisory 1.0.13. No workaround for device RX mode */ return 0; } -- 1.8.4.rc1 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: Use is_cppi_enabled() and tusb_dma_omap() instead of the ifdef
This patch makes use of the two function is_cppi_enabled() and
tusb_dma_omap() instead of the ifdef for the proper DMA implementation
setup code. It basically shifts the code right by one indention level
and adds a few line breaks once the chars are crossed.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_gadget.c | 82 +-
1 file changed, 42 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index d81c6ef..696e9e0 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -365,47 +365,49 @@ static void txstate(struct musb *musb, struct
musb_request *req)
}
}
-#elif defined(CONFIG_USB_TI_CPPI_DMA)
- /* program endpoint CSR first, then setup DMA */
- csr = ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);
- csr |= MUSB_TXCSR_DMAENAB | MUSB_TXCSR_DMAMODE |
- MUSB_TXCSR_MODE;
- musb_writew(epio, MUSB_TXCSR,
- (MUSB_TXCSR_P_WZC_BITS ~MUSB_TXCSR_P_UNDERRUN)
- | csr);
-
- /* ensure writebuffer is empty */
- csr = musb_readw(epio, MUSB_TXCSR);
-
- /* NOTE host side sets DMAENAB later than this; both are
-* OK since the transfer dma glue (between CPPI and Mentor
-* fifos) just tells CPPI it could start. Data only moves
-* to the USB TX fifo when both fifos are ready.
-*/
-
- /* mode is irrelevant here; handle terminating ZLPs like
-* PIO does, since the hardware RNDIS mode seems unreliable
-* except for the last-packet-is-already-short case.
-*/
- use_dma = use_dma c-channel_program(
- musb_ep-dma, musb_ep-packet_sz,
- 0,
- request-dma + request-actual,
- request_size);
- if (!use_dma) {
- c-channel_release(musb_ep-dma);
- musb_ep-dma = NULL;
- csr = ~MUSB_TXCSR_DMAENAB;
- musb_writew(epio, MUSB_TXCSR, csr);
- /* invariant: prequest-buf is non-null */
- }
-#elif defined(CONFIG_USB_TUSB_OMAP_DMA)
- use_dma = use_dma c-channel_program(
- musb_ep-dma, musb_ep-packet_sz,
- request-zero,
- request-dma + request-actual,
- request_size);
#endif
+ if (is_cppi_enabled()) {
+ /* program endpoint CSR first, then setup DMA */
+ csr = ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);
+ csr |= MUSB_TXCSR_DMAENAB | MUSB_TXCSR_DMAMODE |
+ MUSB_TXCSR_MODE;
+ musb_writew(epio, MUSB_TXCSR, (MUSB_TXCSR_P_WZC_BITS
+ ~MUSB_TXCSR_P_UNDERRUN) | csr);
+
+ /* ensure writebuffer is empty */
+ csr = musb_readw(epio, MUSB_TXCSR);
+
+ /*
+* NOTE host side sets DMAENAB later than this; both are
+* OK since the transfer dma glue (between CPPI and
+* Mentor fifos) just tells CPPI it could start. Data
+* only moves to the USB TX fifo when both fifos are
+* ready.
+*/
+ /*
+* mode is irrelevant here; handle terminating ZLPs
+* like PIO does, since the hardware RNDIS mode seems
+* unreliable except for the
+* last-packet-is-already-short case.
+*/
+ use_dma = use_dma c-channel_program(
+ musb_ep-dma, musb_ep-packet_sz,
+ 0,
+ request-dma + request-actual,
+ request_size);
+ if (!use_dma) {
+ c-channel_release(musb_ep-dma);
+ musb_ep-dma = NULL;
+ csr = ~MUSB_TXCSR_DMAENAB;
+ musb_writew(epio, MUSB_TXCSR, csr);
+ /* invariant: prequest-buf is non-null */
+ }
+ } else if (tusb_dma_omap())
+ use_dma = use_dma c-channel_program(
+ musb_ep-dma, musb_ep-packet_sz,
+
Re: [PATCH 07/10] staging: ozwpan: Make oz_hcd_pd_departed() take a struct pointer.
On 13/08/13 18:35, Sergei Shtylyov wrote:
Hello.
On 08/13/2013 09:29 PM, Rupesh Gujare wrote:
oz_hcd_pd_departed() takes struct oz_port pointer instead of
void *, change function declaration to avoid ambiguity.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Signed-off-by: Rupesh Gujare rupesh.guj...@atmel.com
---
drivers/staging/ozwpan/ozhcd.c |4 ++--
drivers/staging/ozwpan/ozhcd.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/ozwpan/ozhcd.c
b/drivers/staging/ozwpan/ozhcd.c
index 73d80f2..ed3ffeb 100644
--- a/drivers/staging/ozwpan/ozhcd.c
+++ b/drivers/staging/ozwpan/ozhcd.c
@@ -720,9 +720,9 @@ out:
* polled. We release the reference we hold on the PD.
* Context: softirq
*/
-void oz_hcd_pd_departed(void *hport)
+void oz_hcd_pd_departed(struct oz_port *hport)
{
-struct oz_port *port = (struct oz_port *)hport;
+struct oz_port *port = hport;
Do you really need a copy? Isn't it better to rename the parameter
and remove this line altogether?
WBR, Sergei
Yes, that is the idea, for next patch series, as I don't want to mix
two changes in single patch.
--
Regards,
Rupesh Gujare
--
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 v3] xhci-hub: Roothub USB2.0 descriptor for BESL DBESL
On Sat, Aug 10, 2013 at 04:04:02AM +, Paul Zimmerman wrote:
From: linux-usb-ow...@vger.kernel.org
[mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Alexandra Yates
Sent: Friday, August 09, 2013 12:21 PM
Hi Alexandra,
snip
+/* USB 2.0 BOS descriptor and a capability descriptor, combined */
+static u8 usb2_bos_descriptor[] = {
+ USB_DT_BOS_SIZE,/* __u8 bLength, 5 bytes */
+ USB_DT_BOS, /* __u8 bDescriptorType */
+ 0x0c, 0x00, /* __le16 wTotalLength, 15 bytes */
+ 0x1,/* __u8 bNumDeviceCaps */
+ /* First device capability */
+ USB_DT_USB_EXT_CAP_SIZE,/* 7 bits USB2 ext */
+ USB_DT_DEVICE_CAPABILITY, /* Device Capability */
+ USB_CAP_TYPE_EXT, /* DevCapability Type, USB2.0 ext */
+ 0x1e, /* bmAttributes first byte: bit1:LPM
+ Supported, bit2: BESL supported,
+ bit3:valid baseline BESL, bit4:
+ valid Deep BESL, bits5-7 */
Here you hard-code the first byte of bmAttributes, so LPM Supported, BESL
Supported etc. are already set...
Yes, Paul is right, you need to set this value to 0x00 in the initial
structure.
+ 0xff, /* bmAttributes - second byte:
+ 8-11bit:BESL and 12-16bit:DBESL*/
You also need to set this to 0x00.
+ 0x00, /* bmAttribute - third byte: reserved,
+ must be zero */
+ 0x00, /* bmAttribute - fourth byte: reserved,
+ must be zero */
+};
+
static void xhci_common_hub_descriptor(struct xhci_hcd *xhci,
struct usb_hub_descriptor *desc, int ports)
@@ -577,12 +599,33 @@ int xhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
if ((wValue 0xff00) != (USB_DT_BOS 8))
goto error;
- if (hcd-speed != HCD_USB3)
+ if (hcd-speed == HCD_USB3) {
+ /* Set the U1 and U2 exit latencies. */
+ memcpy(buf, usb3_bos_descriptor,
+ USB_DT_BOS_SIZE + USB_DT_USB_SS_CAP_SIZE);
+ } else if (hcd -speed == HCD_USB2) {
+ memcpy(buf, usb2_bos_descriptor,
+ USB_DT_BOS_SIZE + USB_DT_USB_EXT_CAP_SIZE);
+
+/* Set first byte of bmAttributes in the
+ * usb2_bos_descriptor */
+ if (xhci-hw_lpm_support)
+ buf[8] |= USB_LPM_SUPPORT;
...so these two lines have no effect, the bit is already set.
Then OR'ing in the USB_LPM_SUPPORT bit will work here.
Further, we want to tell lsusb that the USB 2.0 roothub has Link PM
support if the host controller supports either software-controlled Link
PM, or hardware-controlled link PM. The USB core only works with
hardware-controlled Link PM, but we could add software controlled link
PM in the future.
In xhci-mem.c:xhci_add_in_port(), xhci-sw_lpm_support is set if the
host supports USB 2.0 link PM. If the host supports hardware-controlled
Link PM, xhci-hw_lpm_support is additionally set.
Your code currently only works for hosts that support
hardware-controlled Link PM. You should change this line:
+ if (xhci-hw_lpm_support)
+ buf[8] |= USB_LPM_SUPPORT;
To
+ if (xhci-sw_lpm_support)
+ buf[8] |= USB_LPM_SUPPORT;
+ /* Set the BESL support bit in bmAttributes first
+* byte */
+ if (XHCI_BLC)
+ buf[8] |= USB_BESL_SUPPORT;
+ if (xhci-dbesl) {
+ buf[8] = USB_BESL_DEEP_VALID;
+ buf[9] = xhci-dbesl;
+ }
+ if (xhci-dbesld) {
+ buf[8] = USB_BESL_DEEP_VALID;
+ buf[9] = xhci-dbesl 4;
+ }
The math here is off, and your initialization of the structure hid those
issues. You should have used USB_BESL_BASELINE_VALID in the second if
block instead of using USB_BESL_DEEP_VALID twice. In the third if
statement block, I think you meant to use xhci-dbesld not xhci-dbesl.
Finally, you overwrote the contents of buf[8] and buf[9] in the two if
statements, which means USB_LPM_SUPPORT and USB_BESL_SUPPORT would never
be set in buf[8], and if xhci-dbesl and xhci-dbesld were both set,
buf[9] would only contain the deep BESL value. You probably meant to
use |= instead of = for all the assignments in
[PATCH 3/4] usb: musb: dma: use check macros with a type
Now pass the dma_controller to the macro that checks if a given dma
engine is available.
For consistency the all the macros start if is_dma_. The mentor and TUSB
is added and will be used later.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/davinci.c | 2 +-
drivers/usb/musb/musb_core.c | 2 +-
drivers/usb/musb/musb_dma.h| 20
drivers/usb/musb/musb_gadget.c | 9 +
drivers/usb/musb/musb_host.c | 21 +
drivers/usb/musb/tusb6010.c| 2 +-
drivers/usb/musb/tusb6010.h| 6 --
7 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index ed0834e..4dda846 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -285,7 +285,7 @@ static irqreturn_t davinci_musb_interrupt(int irq, void
*__hci)
* mask, state, vector, and EOI registers.
*/
cppi = container_of(musb-dma_controller, struct cppi, controller);
- if (is_cppi_enabled() musb-dma_controller !cppi-irq)
+ if (is_dma_cppi(musb-dma_controller) !cppi-irq)
retval = cppi_interrupt(irq, __hci);
/* ack and handle non-CPPI interrupts */
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b9d7416..ae96227 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1541,7 +1541,7 @@ void musb_dma_completion(struct musb *musb, u8 epnum, u8
transmit)
if (!epnum) {
#ifndef CONFIG_USB_TUSB_OMAP_DMA
- if (!is_cppi_enabled()) {
+ if (!is_dma_cppi(musb-dma_controller)) {
/* endpoint 0 */
if (devctl MUSB_DEVCTL_HM)
musb_h_ep0_irq(musb);
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 7a8bfb5..19f66ca 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -69,15 +69,27 @@ struct musb_hw_ep;
#endif
#if defined(CONFIG_USB_TI_CPPI_DMA) || defined(CONFIG_USB_TI_CPPI41_DMA)
-#defineis_cppi_enabled() 1
+#defineis_dma_cppi(x) (x x-type == MSUB_DMA_CPPI)
#else
-#defineis_cppi_enabled() 0
+#defineis_dma_cppi(x) (x 0)
#endif
#ifdef CONFIG_USB_TUSB_OMAP_DMA
-#define tusb_dma_omap()1
+#define is_dma_tusb(x) (x x-type == MSUB_DMA_TUSB6010)
#else
-#define tusb_dma_omap()0
+#define is_dma_tusb(x) (x 0)
+#endif
+
+#ifdef CONFIG_USB_INVENTRA_DMA
+#define is_dma_inventra(x) (x x-type == MSUB_DMA_MENTOR)
+#else
+#define is_dma_inventra(x) (x 0)
+#endif
+
+#ifdef CONFIG_USB_UX500_DMA
+#define is_dma_ux500(x)(x x-type == MSUB_DMA_UX500)
+#else
+#define is_dma_ux500(x)(x 0)
#endif
/* Anomaly 05000456 - USB Receive Interrupt Is Not Generated in DMA Mode 1
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 06ceaf1..c685905 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -366,7 +366,7 @@ static void txstate(struct musb *musb, struct musb_request
*req)
}
#endif
- if (is_cppi_enabled() use_dma) {
+ if (is_dma_cppi(c) use_dma) {
/* program endpoint CSR first, then setup DMA */
csr = ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);
csr |= MUSB_TXCSR_DMAENAB | MUSB_TXCSR_DMAMODE |
@@ -402,7 +402,7 @@ static void txstate(struct musb *musb, struct musb_request
*req)
musb_writew(epio, MUSB_TXCSR, csr);
/* invariant: prequest-buf is non-null */
}
- } else if (tusb_dma_omap() use_dma)
+ } else if (is_dma_tusb(c) use_dma)
use_dma = c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
request-zero,
@@ -595,7 +595,7 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
return;
}
- if (is_cppi_enabled() is_buffer_mapped(req)) {
+ if (is_dma_cppi(musb-dma_controller) is_buffer_mapped(req)) {
struct dma_controller *c = musb-dma_controller;
struct dma_channel *channel = musb_ep-dma;
@@ -772,7 +772,8 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
fifo_count = min_t(unsigned, len, fifo_count);
#ifdef CONFIG_USB_TUSB_OMAP_DMA
- if (tusb_dma_omap() is_buffer_mapped(req)) {
+ if (is_dma_tusb(musb-dma_controller)
+ is_buffer_mapped(req)) {
struct dma_controller *c = musb-dma_controller;
struct dma_channel
[PATCH 1/4] usb: musb: gadget: move the use_dma to the upper if
If we check the use_dma before calling -channel_program() then in case
of use_dma is 0 we don't have to remove the MUSB_TXCSR_DMAENAB bit
because we never set it.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_gadget.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 696e9e0..06ceaf1 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -366,7 +366,7 @@ static void txstate(struct musb *musb, struct musb_request
*req)
}
#endif
- if (is_cppi_enabled()) {
+ if (is_cppi_enabled() use_dma) {
/* program endpoint CSR first, then setup DMA */
csr = ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);
csr |= MUSB_TXCSR_DMAENAB | MUSB_TXCSR_DMAMODE |
@@ -390,7 +390,7 @@ static void txstate(struct musb *musb, struct musb_request
*req)
* unreliable except for the
* last-packet-is-already-short case.
*/
- use_dma = use_dma c-channel_program(
+ use_dma = c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
0,
request-dma + request-actual,
@@ -402,8 +402,8 @@ static void txstate(struct musb *musb, struct musb_request
*req)
musb_writew(epio, MUSB_TXCSR, csr);
/* invariant: prequest-buf is non-null */
}
- } else if (tusb_dma_omap())
- use_dma = use_dma c-channel_program(
+ } else if (tusb_dma_omap() use_dma)
+ use_dma = c-channel_program(
musb_ep-dma, musb_ep-packet_sz,
request-zero,
request-dma + request-actual,
--
1.8.4.rc1
--
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] try to detetmine musb dma engine at runtime
Hi, the musb dma engine abstraction is basically hidden behind ifdefs and set at compile time. This little incomplete series tries to push this check to runtime time so we could enable more than one at compile time. Any comments? Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] usb: musb: dma: use is_dma_inventra() and is_dma_ux500() in more places
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_gadget.c | 76 --
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index c685905..05a59d0 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -313,8 +313,8 @@ static void txstate(struct musb *musb, struct musb_request
*req)
/* MUSB_TXCSR_P_ISO is still set correctly */
-#if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_UX500_DMA)
- {
+ if (is_dma_inventra(c) || is_dma_ux500(c)) {
+
if (request_size musb_ep-packet_sz)
musb_ep-dma-desired_mode = 0;
else
@@ -365,7 +365,6 @@ static void txstate(struct musb *musb, struct musb_request
*req)
}
}
-#endif
if (is_dma_cppi(c) use_dma) {
/* program endpoint CSR first, then setup DMA */
csr = ~(MUSB_TXCSR_P_UNDERRUN | MUSB_TXCSR_TXPKTRDY);
@@ -510,11 +509,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
if ((request-zero request-length
(request-length % musb_ep-packet_sz == 0)
(request-actual == request-length))
-#if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_UX500_DMA)
- || (is_dma (!dma-desired_mode ||
+ || ((is_dma_inventra(c) || is_dma_ux500(c))
+ (is_dma (!dma-desired_mode ||
(request-actual
- (musb_ep-packet_sz - 1
-#endif
+ (musb_ep-packet_sz - 1)
) {
/*
* On DMA completion, FIFO may not be
@@ -637,8 +635,9 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
use_mode_1 = 0;
if (request-actual request-length) {
-#ifdef CONFIG_USB_INVENTRA_DMA
- if (is_buffer_mapped(req)) {
+ struct dma_controller *c = musb-dma_controller;
+
+ if (is_dma_inventra(c) is_buffer_mapped(req)) {
struct dma_controller *c;
struct dma_channel *channel;
int use_dma = 0;
@@ -712,8 +711,8 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (use_dma)
return;
}
-#elif defined(CONFIG_USB_UX500_DMA)
- if ((is_buffer_mapped(req))
+
+ if (is_dma_ux500(c) (is_buffer_mapped(req))
(request-actual request-length)) {
struct dma_controller *c;
@@ -761,7 +760,6 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
return;
}
-#endif /* Mentor's DMA */
len = request-length - request-actual;
dev_dbg(musb-controller, %s OUT/RX pio fifo %d/%d,
maxpacket %d\n,
@@ -771,7 +769,6 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
fifo_count = min_t(unsigned, len, fifo_count);
-#ifdef CONFIG_USB_TUSB_OMAP_DMA
if (is_dma_tusb(musb-dma_controller)
is_buffer_mapped(req)) {
struct dma_controller *c = musb-dma_controller;
@@ -787,7 +784,6 @@ static void rxstate(struct musb *musb, struct musb_request
*req)
if (ret)
return;
}
-#endif
/*
* Unmap the dma buffer back to cpu if dma channel
* programming fails. This buffer is mapped if the
@@ -887,6 +883,8 @@ void musb_g_rx(struct musb *musb, u8 epnum)
}
if (dma (csr MUSB_RXCSR_DMAENAB)) {
+ struct dma_controller *c = musb-dma_controller;
+
csr = ~(MUSB_RXCSR_AUTOCLEAR
| MUSB_RXCSR_DMAENAB
| MUSB_RXCSR_DMAMODE);
@@ -900,31 +898,32 @@ void musb_g_rx(struct musb *musb, u8 epnum)
musb_readw(epio, MUSB_RXCSR),
musb_ep-dma-actual_len, request);
-#if defined(CONFIG_USB_INVENTRA_DMA) || defined(CONFIG_USB_TUSB_OMAP_DMA) || \
- defined(CONFIG_USB_UX500_DMA)
- /* Autoclear doesn't clear RxPktRdy for short packets */
- if ((dma-desired_mode == 0 !hw_ep-rx_double_buffered)
-
[PATCH 2/4] usb: musb: add a type to each dma engine
This patch defines four types of current supported DMA engines and
assignes them to each dma engine. This should get rid of a few ifdefs
later on.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/cppi_dma.c | 1 +
drivers/usb/musb/musb_cppi41.c | 1 +
drivers/usb/musb/musb_dma.h | 9 +
drivers/usb/musb/musbhsdma.c | 1 +
drivers/usb/musb/tusb6010_omap.c | 1 +
drivers/usb/musb/ux500_dma.c | 1 +
6 files changed, 14 insertions(+)
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 904fb85..e4cdcdd 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -1312,6 +1312,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *mr
controller-tibase = mregs - DAVINCI_BASE_OFFSET;
controller-musb = musb;
+ controller-controller.type = MSUB_DMA_CPPI;
controller-controller.channel_alloc = cppi_channel_allocate;
controller-controller.channel_release = cppi_channel_release;
controller-controller.channel_program = cppi_channel_program;
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index e64701d..a16a93c 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -537,6 +537,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb,
controller-musb = musb;
+ controller-controller.type = MSUB_DMA_CPPI;
controller-controller.channel_alloc = cppi41_dma_channel_allocate;
controller-controller.channel_release = cppi41_dma_channel_release;
controller-controller.channel_program = cppi41_dma_channel_program;
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 1345a4f..7a8bfb5 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -145,6 +145,14 @@ dma_channel_status(struct dma_channel *c)
return (is_dma_capable() c) ? c-status : MUSB_DMA_STATUS_UNKNOWN;
}
+enum musb_dma_type {
+ MSUB_DMA_INVALID = 0,
+ MSUB_DMA_MENTOR,
+ MSUB_DMA_UX500,
+ MSUB_DMA_CPPI,
+ MSUB_DMA_TUSB6010,
+};
+
/**
* struct dma_controller - A DMA Controller.
* @start: call this to start a DMA controller;
@@ -159,6 +167,7 @@ dma_channel_status(struct dma_channel *c)
* Controllers manage dma channels.
*/
struct dma_controller {
+ enum musb_dma_type type;
struct dma_channel *(*channel_alloc)(struct dma_controller *,
struct musb_hw_ep *, u8 is_tx);
void(*channel_release)(struct dma_channel *);
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index e8e9f9a..df2048d 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -389,6 +389,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *ba
controller-private_data = musb;
controller-base = base;
+ controller-controller.type = MSUB_DMA_MENTOR;
controller-controller.channel_alloc = dma_channel_allocate;
controller-controller.channel_release = dma_channel_release;
controller-controller.channel_program = dma_channel_program;
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index b8794eb..1591d50 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -673,6 +673,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb, void __iomem *ba
tusb_dma-dmareq = -1;
tusb_dma-sync_dev = -1;
+ tusb_dma-controller.type = MSUB_DMA_TUSB6010;
tusb_dma-controller.channel_alloc = tusb_omap_dma_allocate;
tusb_dma-controller.channel_release = tusb_omap_dma_release;
tusb_dma-controller.channel_program = tusb_omap_dma_program;
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index e51dd9b..b3c3bd3 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -390,6 +390,7 @@ struct dma_controller *dma_controller_create(struct musb
*musb,
controller-phy_base = (dma_addr_t) iomem-start;
+ controller-controller.type = MSUB_DMA_MENTOR;
controller-controller.channel_alloc = ux500_dma_channel_allocate;
controller-controller.channel_release = ux500_dma_channel_release;
controller-controller.channel_program = ux500_dma_channel_program;
--
1.8.4.rc1
--
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 2/2] usb: musb: cppi41: Enable in device-TX mode
Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? Regards, -Bin. -- 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] Bug 60699 - Stalled state of endpoint will not be cleared
On Tuesday 13 August 2013 19:27:52 Sergei Shtylyov wrote:
Hello.
On 08/13/2013 08:52 PM, Florian Wolter wrote:
Patch to Fix Problem with not cleared halted endpoint.
See Bugtracker Bug 60699
Hi Florian,
You need to send your patch inline, not as an attachment.
Thanks,
Sarah Sharp
Hi Sarah,
Sorry now the Patch is in-lined.
Subject: [PATCH] Fix for Bug 60699 (Stalled state of endpoint will not be
cleared)
Signed-off-by: Florian Wolter woll...@web.de
---
drivers/usb/host/xhci-ring.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5b08cd8..c2daaf7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -847,8 +847,12 @@ remove_finished_td:
/* Otherwise ring the doorbell(s) to restart queued transfers
*/ ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
-ep-stopped_td = NULL;
-ep-stopped_trb = NULL;
+
+/* Clear stopped_td and stopped_trb if endpoint is not halted */
+if (!(ep-ep_state EP_HALTED)) {
+ep-stopped_td = NULL;
+ep-stopped_trb = NULL;
+}
/*
* Drop the lock and complete the URBs in the cancelled TD list.
All the tabs have been replaced by spaces in your patch. See
Documentation/email-clients.txt on how to avoid this.
WBR, Sergei
Subject: [PATCH] Fix for Bug 60699 (Stalled state of endpoint will not be
cleared)
Signed-off-by: Florian Wolter woll...@web.de
---
drivers/usb/host/xhci-ring.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5b08cd8..c2daaf7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -847,8 +847,12 @@ remove_finished_td:
/* Otherwise ring the doorbell(s) to restart queued transfers */
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
- ep-stopped_td = NULL;
- ep-stopped_trb = NULL;
+
+ /* Clear stopped_td and stopped_trb if endpoint is not halted */
+ if (!(ep-ep_state EP_HALTED)) {
+ ep-stopped_td = NULL;
+ ep-stopped_trb = NULL;
+ }
/*
* Drop the lock and complete the URBs in the cancelled TD list.
--
1.7.10.4
Thanks for the information I hope the are now shown.
Florian
--
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: host: add Kconfig option for EHSET
On Tue, 13 Aug 2013, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 10:07:58AM -0400, Alan Stern wrote: On Mon, 12 Aug 2013, Jack Pham wrote: commit 9841f37a1c (usb: ehci: Add support for SINGLE_STEP_SET_FEATURE test of EHSET) added additional code to the EHCI hub driver but it is anticipated to only have a limited audience (e.g. embedded silicon vendors and integrators). Avoid subjecting all EHCI (and in the future maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally compiling the EHSET-specific additions with a new Kconfig option, CONFIG_USB_HCD_TEST_MODE. Cc: Alan Stern st...@rowland.harvard.edu Signed-off-by: Jack Pham ja...@codeaurora.org Quick work, thank you. Greg, do you object to this new Kconfig option? No, as long as: + include other tests that require support from a HCD driver. + + If unsure, say N. There should be something along the lines of: This option is of interest only to developers who need to validate their USB hardware designs. It is not needed for normal use. This needs to be added, to help the distro people out in determining if the option should be enabled or not (I'm guessing they will all turn it off, right?) They should. Jack, can you resubmit with this change? 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
URBs active during clear endpoint halt?
Hi Alan, Do you know if there's a chance that any USB drivers (or userspace) would try to clear an endpoint halt when there are active URBs that have not completed on for the endpoint? I ask because in order to handle the case where userspace wants to reset the toggles with a clear halt control transfer, but the endpoint is not actually halted, the xHCI driver needs to wipe out the contents of the endpoint ring and reset the dequeue pointer. (The dequeue pointer alignment for the Configure Endpoint command forces us to set the pointer the top of the ring, or every fourth TRB.) Re-initializing the ring would be bad to do if there were pending URBs that hadn't been canceled before the driver tried to clear the halt. I think it's pretty unlikely for this corner case to occur, but I could potentially see a driver queueing multiple URBs to an endpoint, and clearing the halt that occurred on the first URB, and then expecting the other URB to complete successfully. What would happen under EHCI in this case? Would it be OK to simply return the second URB with a -EPROTO in this case? Or should we save the URBs, re-init the endpoint ring, requeue the URB to the ring, and ring the endpoint doorbell? Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the hibernation feature implementation in dwc3 driver
Hi, On Mon, Aug 05, 2013 at 03:41:57PM +, Wang, Yu Y wrote: Hi Balbi, Please check the attached logs. The kernel base one kernel3.10. you didn't take the regdump after xHCI :-( I need to check if erst_base is being mirrored to DEPCMDPAR* -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] usb: musb: cppi41: Enable in device-TX mode
On Tue, Aug 13, 2013 at 01:11:47PM -0500, Bin Liu wrote: Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? it would be quite difficult to check PG revision from this driver. It would have to be passed as a flag through DT or something similar. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb-gadget-audio-file-wake-up-sleep-thread
Hi, On Mon, Aug 12, 2013 at 09:43:24AM +0800, Qiao Zhou wrote: On 08/02/2013 03:31 PM, Felipe Balbi wrote: Hi, On Fri, Aug 02, 2013 at 01:15:33PM +0800, Qiao Zhou wrote: On 08/01/2013 06:21 PM, Qiao Zhou wrote: v2-v1: stop pcm stream instead of wake up the sleep thread, which is more reasonable. Qiao Zhou (1): usb: gadget: audio file: wake up sleep thread when device unbind drivers/usb/gadget/f_audio_source.c | 11 +-- 1 files changed, 9 insertions(+), 2 deletions(-) Hi Felipe, Greg Do you have any suggestion/comment for this patch? not even 24 hours of waiting time ? Settle down a bit, have a beer, seat back and relax. Meanwhile I'll dig through the other tens of unread emails in multiple maildirs... cheers ;-) Hi Felipe, Greg Do you have any suggestion/comment? thanks. doesn't apply. What do you depend on ? -- balbi signature.asc Description: Digital signature
[GIT PULL] USB patches for v3.12 merge window
Hi Greg, Here's my pull request for v3.12 merge window. I know there are a bunch of patches pending in the mailing list but I won't have time to fully review them before merging so I decided that it's best to delay a merge window than it is to cause a bunch of regressions. Oh yeah, the patches under arch/arm got Acked by Tony Lindgren. Let me know if you want any changes to the pull request. cheers The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12 for you to fetch changes up to 13266fea59f6f55e98d61e66707d784b9e947c84: usb: musb: cppi41: Enable in device-TX mode (2013-08-13 14:21:42 -0500) usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Signed-of-by: Felipe Balbi ba...@ti.com Alexey Khoroshilov (1): usb: gadget: amd5536udc: unconditionally use GFP_ATOMIC in udc_queue() Boris BREZILLON (3): usb: gadget: atmel_usba: prepare clk before calling enable usb: gadget: at91_udc: add missing clk_put on fclk and iclk usb: gadget: at91_udc: add usb_clk for transition to common clk framework Fabio Estevam (1): usb: phy: phy-mxs-usb: Check the return value from stmp_reset_block() Felipe Balbi (28): usb: dwc3: make glue layers selectable usb: gadget: remove imx_udc usb: dwc3: gadget: don't request IRQs in atomic usb: dwc3: switch to GPL v2 only usb: phy: protect against NULL phy pointers usb: common: introduce of_usb_get_maximum_speed() usb: dwc3: let non-DT platforms pass tx-fifo-resize flag; usb: dwc3: make maximum-speed a per-instance attribute usb: dwc3: core: switch to snps,dwc3 usb: dwc3: gadget: drop dwc3 manual phy control usb: dwc3: omap: switch over to devm_ioremap_resource() usb: dwc3: core: switch over to devm_ioremap_resource() usb: dwc3: gadget: move debugging print around usb: dwc3: gadget: move direction setting up usb: dwc3: gadget: add a debugging print when initializing endpoints usb: dwc3: core: don't redefine DWC3_DCFG_LPM_CAP usb: dwc3: gadget: don't enable LPM early usb: dwc3: core: introduce and use macros for Event Size register usb: dwc3: gadget: get rid of IRQF_ONESHOT usb: dwc3: gadget: rename dwc3_process_event_buf usb: dwc3: gadget: introduce dwc3_process_event_buf usb: gadget: udc-core: move sysfs_notify() to a workqueue usb: dwc3: ep0: only change to ADDRESS if set_config() succeeds usb: dwc3: ep0: don't change to configured state too early usb: of: fix build breakage caused by recent patches usb: dwc3: use dev_get_platdata() Merge branch 'nop-phy-rename' into next usb: musb: dsps: make it depend on OF_IRQ Greg Kroah-Hartman (1): usb: musb: get rid of unused proc_dir_entry Huang Rui (2): usb: dwc3: clean up redundant parameter comment usb: dwc3: fix typo in comment of dwc3_ep Ivan T. Ivanov (1): usb: dwc3: core: modify IO memory resource after deferred probe completes Jingoo Han (13): usb: gadget: use dev_get_platdata() usb: phy: use dev_get_platdata() usb: musb: use dev_get_platdata() usb: renesas: use dev_get_platdata() usb: dwc3: pci: add CONFIG_PM_SLEEP to suspend/resume functions usb: gadget: goku_udc: use NULL instead of 0 usb: gadget: fusb300_udc: Staticize fusb300_rdcxf() usb: gadget: f_mass_storage: use NULL instead of 0 usb: gadget: rndis: Staticize rndis_init()/rndis_exit() usb: gadget: u_uac1: add __user annotation usb: gadget: f_uac1: Staticize local functions usb: phy: mv-u3d: Staticize mv_u3d_phy_shutdown() usb: phy: mv-usb: remove incorrect __exit_p annotation Kumar Gala (1): usb: dwc3: core: clarify usb-phy array binding Kuninori Morimoto (1): usb: renesas_usbhs: tidyup original usbhsx_for_each_xxx macro Laurent Pinchart (1): usb: gadget: uvc: Fix error handling in uvc_queue_buffer() Mikko Perttunen (6): arm: dts: tegra20: Rename USB UTMI parameters according to new definitions usb: phy: tegra: Read UTMIP parameters from device tree usb: tegra: Use regulators instead of GPIOs for USB PHY VBUS usb: tegra: Add vbus-supply property
[PATCH] usb: phy: am335x-control: include linux/err.h
that driver uses IS_ERR() macro which is
defined by linux/err.h.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/phy/phy-am335x-control.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/phy/phy-am335x-control.c
b/drivers/usb/phy/phy-am335x-control.c
index 35494f1..7fa8e0d 100644
--- a/drivers/usb/phy/phy-am335x-control.c
+++ b/drivers/usb/phy/phy-am335x-control.c
@@ -2,6 +2,7 @@
#include linux/platform_device.h
#include linux/of.h
#include linux/io.h
+#include linux/err.h
struct phy_control {
void (*phy_power)(struct phy_control *phy_ctrl, u32 id, bool on);
--
1.8.3.4.840.g6a90778
--
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 1/3] usb: dwc3: msm: Add device tree binding information
On 08/09/2013 03:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) and HS, SS PHY's controll and configuration registers. s/controll/control/ It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt b/Documentation/devicetree/bindings/usb/msm-ssusb.txt +MSM SuperSpeed DWC3 USB SoC controller + +Required properities : +- compatible : sould be qcom,dwc3-hsphy; ... +Required properities : +- compatible : sould be qcom,dwc3-ssphy; I would expect different compatible values to be documented in different files. +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. Which of the 3 compatible values that were described above is that property optional for? +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Why not represent the PHY and USB controller as separate top-level nodes? They can point at each-other with phandles if they need to know each-others' identity. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] pl2303: improve the chip type information output on startup
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 15 ++-
1 Datei geändert, 10 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 7efb39c..5ca1443 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -177,6 +177,7 @@ static int pl2303_startup(struct usb_serial *serial)
{
struct pl2303_serial_private *spriv;
enum pl2303_type type = type_0;
+ char *type_str = unknown (treating as type_0);
unsigned char *buf;
spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
@@ -189,14 +190,18 @@ static int pl2303_startup(struct usb_serial *serial)
return -ENOMEM;
}
- if (serial-dev-descriptor.bDeviceClass == 0x02)
+ if (serial-dev-descriptor.bDeviceClass == 0x02) {
type = type_0;
- else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40)
+ type_str = type_0;
+ } else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40) {
type = HX;
- else if (serial-dev-descriptor.bDeviceClass == 0x00
-|| serial-dev-descriptor.bDeviceClass == 0xFF)
+ type_str = X/HX;
+ } else if (serial-dev-descriptor.bDeviceClass == 0x00
+ || serial-dev-descriptor.bDeviceClass == 0xFF) {
type = type_1;
- dev_dbg(serial-interface-dev, device type: %d\n, type);
+ type_str = type_1;
+ }
+ dev_info(serial-interface-dev, device type: %s\n, type_str);
spriv-type = type;
usb_set_serial_data(serial, spriv);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] pl2303: improve the chip type detection/distinction
The driver currently knows about 3 different PL2303 chip types:
The two legacy chip types type_0 and type_1 (PL2303H ?) and the HX
type.
The device distinction is currently completely based on the examination
of the USB descriptors.
During the last years, Prolific has introduced further PL2303 chips,
such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA,
RA, EA and TB variants.
Unfortunately, all these new chips are currently detected as HX chips,
because they are all using the same bMaxPacketSize0 = 0x40 value in the
USB device descriptor.
At this point it is not clear if these chips are really working with
the driver, there are just some positive indicators (like device
manufacturers claiming Linux support for these devices or commit
8d48fdf689 correctly handle baudrates above 115200 which should only
be necessary for newer devices, ...)
For a complete support of all devices, we need to distinguish between
them, because they differ in several functional aspects, such as the
maximum supported baud rate (HXD, TB, EA: 12Mbps, HX, TA: 6Mbps,
RA: 1Mbps, SA: 115.2kbps), handshaking line support, RS422/485 and
GPIO ports support (currently not supported by the driver).
And there might be further differences that we don't know yet.
This patch improves the chip type detection by evaluating the bcdDevice
value of the device descriptor. The values are taken from the
datasheets and are safe to use because manufacturers can't change them:
3.00: X/HX, TA
4.00: HXD, EA, RA, SA
5.00: TB
The rest of the device descriptors is completely identical, so no
further distinction is possible this way.
Anyway, Prolifics checkChipVersion.exe-tool is definitely able to
distinguish for example between the X/HX and the TA chips, so there
must be a possibility to improve the distinction further...
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 95 ---
1 Datei geändert, 72 Zeilen hinzugefügt(+), 23 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 5ca1443..5f97c44 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -134,10 +134,17 @@ MODULE_DEVICE_TABLE(usb, id_table);
enum pl2303_type {
- type_0, /* don't know the difference between type 0 and */
- type_1, /* type 1, until someone from prolific tells us... */
- HX, /* HX version of the pl2303 chip */
+ type_0, /* H version ? */
+ type_1, /* H version ? */
+ HX_TA, /* HX(A) / X(A) / TA version */ /* TODO: improve */
+ HXD_EA_RA_SA, /* HXD / EA / RA / SA version */ /* TODO: improve */
+ TB, /* TB version */
};
+/*
+ * NOTE: don't know the difference between type 0 and type 1,
+ * until someone from Prolific tells us...
+ * TODO: distinguish between X/HX, TA and HXD, EA, RA, SA variants
+ */
struct pl2303_serial_private {
enum pl2303_type type;
@@ -194,8 +201,28 @@ static int pl2303_startup(struct usb_serial *serial)
type = type_0;
type_str = type_0;
} else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40) {
- type = HX;
- type_str = X/HX;
+ /*
+* NOTE: The bcdDevice version is the only difference between
+* the device descriptors of the X/HX, HXD, EA, RA, SA, TA, TB
+*/
+ if (le16_to_cpu(serial-dev-descriptor.bcdDevice) == 0x300) {
+ type = HX_TA;
+ type_str = X/HX/TA;
+ } else if (le16_to_cpu(serial-dev-descriptor.bcdDevice)
+== 0x400) {
+ type = HXD_EA_RA_SA;
+ type_str = HXD/EA/RA/SA;
+ } else if (le16_to_cpu(serial-dev-descriptor.bcdDevice)
+== 0x500) {
+ type = TB;
+ type_str = TB;
+ } else {
+ dev_info(serial-interface-dev,
+ unknown/unsupported device type\n);
+ kfree(spriv);
+ kfree(buf);
+ return -ENODEV;
+ }
} else if (serial-dev-descriptor.bDeviceClass == 0x00
|| serial-dev-descriptor.bDeviceClass == 0xFF) {
type = type_1;
@@ -216,10 +243,10 @@ static int pl2303_startup(struct usb_serial *serial)
pl2303_vendor_read(0x8383, 0, serial, buf);
pl2303_vendor_write(0, 1, serial);
pl2303_vendor_write(1, 0, serial);
- if (type == HX)
- pl2303_vendor_write(2, 0x44, serial);
- else
+ if (type == type_0 || type == type_1)
pl2303_vendor_write(2, 0x24, serial);
+ else
+
Re: [PATCH] usb: phy: am335x-control: include linux/err.h
On Tue, Aug 13, 2013 at 02:51:00PM -0500, Felipe Balbi wrote: that driver uses IS_ERR() macro which is defined by linux/err.h. Signed-off-by: Felipe Balbi ba...@ti.com let's ignore this one since Sebastian had already sent the same patch before me. -- balbi signature.asc Description: Digital signature
[PATCH 0/3] pl2303: improve the chip type distinction
The chip type distinction is one of the weak spots of the pl2303 driver. It currently knows 3 different PL2303 chip types only (the two legacy chip types type_0 and type_1 (PL2303H ?) and the HX type). During the last 2-3 years Prolific has introduced additional PL2303 chips, such as the HXD (HX rev. D), TA (which replaced the X/HX chips), SA, RA, EA and TB variants. Unfortunately, all these new chips are currently detected as HX chips (see patch 3 for further details). This patch series improves the situation a bit. Patch 1 is just a minor code simplification, patch 2 improves the chip type information output. Patch 3 finally improves the chip type detection/distinction by splitting the HX chip type into 3 chip groups. The 3 groups need to be split further, but we don't know yet how to do this. Frank Schäfer (3): pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup() pl2303: improve the chip type information output on startup pl2303: improve the chip type detection/distinction drivers/usb/serial/pl2303.c | 109 --- 1 Datei geändert, 81 Zeilen hinzugefügt(+), 28 Zeilen entfernt(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] pl2303: simplify the else-if contruct for type_1 chips in pl2303_startup()
There is no need for two else-if constructs for the type_1 chip detection in pl2303_startup(), so merge them. Signed-off-by: Frank Schäfer fschaefer@googlemail.com --- drivers/usb/serial/pl2303.c |5 ++--- 1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-) diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c index 6638c5d..7efb39c 100644 --- a/drivers/usb/serial/pl2303.c +++ b/drivers/usb/serial/pl2303.c @@ -193,9 +193,8 @@ static int pl2303_startup(struct usb_serial *serial) type = type_0; else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40) type = HX; - else if (serial-dev-descriptor.bDeviceClass == 0x00) - type = type_1; - else if (serial-dev-descriptor.bDeviceClass == 0xFF) + else if (serial-dev-descriptor.bDeviceClass == 0x00 +|| serial-dev-descriptor.bDeviceClass == 0xFF) type = type_1; dev_dbg(serial-interface-dev, device type: %d\n, type); -- 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: [GIT PULL] USB patches for v3.12 merge window
Hi, On Tue, Aug 13, 2013 at 02:48:42PM -0500, Felipe Balbi wrote: On Tue, Aug 13, 2013 at 02:41:25PM -0500, Felipe Balbi wrote: Hi Greg, Here's my pull request for v3.12 merge window. I know there are a bunch of patches pending in the mailing list but I won't have time to fully review them before merging so I decided that it's best to delay a merge window than it is to cause a bunch of regressions. Oh yeah, the patches under arch/arm got Acked by Tony Lindgren. Let me know if you want any changes to the pull request. just now I saw the build failure Stephen reported. Please don't merge this in yet, I'll put a patch on top to fix the build failure. now fixed, here's the pull updated pull request: The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12 for you to fetch changes up to 8b841cb217fac676498de3dfe8fabe38b39cba4e: usb: phy: am335x: include linux/err.h (2013-08-13 14:59:13 -0500) usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Signed-of-by: Felipe Balbi ba...@ti.com Alexey Khoroshilov (1): usb: gadget: amd5536udc: unconditionally use GFP_ATOMIC in udc_queue() Boris BREZILLON (3): usb: gadget: atmel_usba: prepare clk before calling enable usb: gadget: at91_udc: add missing clk_put on fclk and iclk usb: gadget: at91_udc: add usb_clk for transition to common clk framework Fabio Estevam (1): usb: phy: phy-mxs-usb: Check the return value from stmp_reset_block() Felipe Balbi (28): usb: dwc3: make glue layers selectable usb: gadget: remove imx_udc usb: dwc3: gadget: don't request IRQs in atomic usb: dwc3: switch to GPL v2 only usb: phy: protect against NULL phy pointers usb: common: introduce of_usb_get_maximum_speed() usb: dwc3: let non-DT platforms pass tx-fifo-resize flag; usb: dwc3: make maximum-speed a per-instance attribute usb: dwc3: core: switch to snps,dwc3 usb: dwc3: gadget: drop dwc3 manual phy control usb: dwc3: omap: switch over to devm_ioremap_resource() usb: dwc3: core: switch over to devm_ioremap_resource() usb: dwc3: gadget: move debugging print around usb: dwc3: gadget: move direction setting up usb: dwc3: gadget: add a debugging print when initializing endpoints usb: dwc3: core: don't redefine DWC3_DCFG_LPM_CAP usb: dwc3: gadget: don't enable LPM early usb: dwc3: core: introduce and use macros for Event Size register usb: dwc3: gadget: get rid of IRQF_ONESHOT usb: dwc3: gadget: rename dwc3_process_event_buf usb: dwc3: gadget: introduce dwc3_process_event_buf usb: gadget: udc-core: move sysfs_notify() to a workqueue usb: dwc3: ep0: only change to ADDRESS if set_config() succeeds usb: dwc3: ep0: don't change to configured state too early usb: of: fix build breakage caused by recent patches usb: dwc3: use dev_get_platdata() Merge branch 'nop-phy-rename' into next usb: musb: dsps: make it depend on OF_IRQ Greg Kroah-Hartman (1): usb: musb: get rid of unused proc_dir_entry Huang Rui (2): usb: dwc3: clean up redundant parameter comment usb: dwc3: fix typo in comment of dwc3_ep Ivan T. Ivanov (1): usb: dwc3: core: modify IO memory resource after deferred probe completes Jingoo Han (13): usb: gadget: use dev_get_platdata() usb: phy: use dev_get_platdata() usb: musb: use dev_get_platdata() usb: renesas: use dev_get_platdata() usb: dwc3: pci: add CONFIG_PM_SLEEP to suspend/resume functions usb: gadget: goku_udc: use NULL instead of 0 usb: gadget: fusb300_udc: Staticize fusb300_rdcxf() usb: gadget: f_mass_storage: use NULL instead of 0 usb: gadget: rndis: Staticize rndis_init()/rndis_exit() usb: gadget: u_uac1: add __user annotation usb: gadget: f_uac1: Staticize local functions usb: phy: mv-u3d: Staticize mv_u3d_phy_shutdown() usb: phy: mv-usb: remove incorrect __exit_p annotation Kumar Gala (1): usb: dwc3: core: clarify usb-phy array binding Kuninori Morimoto (1): usb: renesas_usbhs: tidyup original usbhsx_for_each_xxx macro Laurent Pinchart (1): usb:
RE: About the hibernation feature implementation in dwc3 driver
From: Felipe Balbi Sent: Tuesday, August 13, 2013 12:20 PM On Mon, Aug 05, 2013 at 03:41:57PM +, Wang, Yu Y wrote: Hi Balbi, Please check the attached logs. The kernel base one kernel3.10. you didn't take the regdump after xHCI :-( I need to check if erst_base is being mirrored to DEPCMDPAR* Hi Felipe, There seems to be some basic misunderstanding here. ALL versions of the Synopsys core share the internal RAM between device and host modes. So the only supported way of switching modes is to shut down the driver for the mode you are leaving, then start up the driver for the mode you are entering and re-initialize (most of) the registers. This is described in the databook in the OTG - Software Flow and OTG - Programming Model chapters. So whether a particular set of RAM-based registers is mirrored between modes does not matter. And I don't see what this has to do with hibernation? -- 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: About the hibernation feature implementation in dwc3 driver
Hi, On Tue, Aug 13, 2013 at 08:04:26PM +, Paul Zimmerman wrote: From: Felipe Balbi Sent: Tuesday, August 13, 2013 12:20 PM On Mon, Aug 05, 2013 at 03:41:57PM +, Wang, Yu Y wrote: Hi Balbi, Please check the attached logs. The kernel base one kernel3.10. you didn't take the regdump after xHCI :-( I need to check if erst_base is being mirrored to DEPCMDPAR* Hi Felipe, There seems to be some basic misunderstanding here. ALL versions of the Synopsys core share the internal RAM between device and host modes. So the only supported way of switching modes is to shut down the driver for the mode you are leaving, then start up the driver for the mode you are entering and re-initialize (most of) the registers. This is described in the databook in the OTG - Software Flow and OTG - Programming Model chapters. sure. So whether a particular set of RAM-based registers is mirrored between modes does not matter. fair enough. And I don't see what this has to do with hibernation? I have lost track of the conversation, probably. but I believe Yu mentioned resetting the IP everytime when coming out of hibernation and, for whatever reason, I confused myself with the other problem. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] pl2303: improve the chip type information output on startup
On Tue, Aug 13, 2013 at 10:03:01PM +0200, Frank Schäfer wrote:
The chip type distinction is getting more and more relevant and
complicating, so always print the chip type.
Printing a name string is also much better than just printing an
internal index number.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/usb/serial/pl2303.c | 15 ++-
1 Datei geändert, 10 Zeilen hinzugefügt(+), 5 Zeilen entfernt(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index 7efb39c..5ca1443 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -177,6 +177,7 @@ static int pl2303_startup(struct usb_serial *serial)
{
struct pl2303_serial_private *spriv;
enum pl2303_type type = type_0;
+ char *type_str = unknown (treating as type_0);
unsigned char *buf;
spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
@@ -189,14 +190,18 @@ static int pl2303_startup(struct usb_serial *serial)
return -ENOMEM;
}
- if (serial-dev-descriptor.bDeviceClass == 0x02)
+ if (serial-dev-descriptor.bDeviceClass == 0x02) {
type = type_0;
- else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40)
+ type_str = type_0;
+ } else if (serial-dev-descriptor.bMaxPacketSize0 == 0x40) {
type = HX;
- else if (serial-dev-descriptor.bDeviceClass == 0x00
- || serial-dev-descriptor.bDeviceClass == 0xFF)
+ type_str = X/HX;
+ } else if (serial-dev-descriptor.bDeviceClass == 0x00
+|| serial-dev-descriptor.bDeviceClass == 0xFF) {
type = type_1;
- dev_dbg(serial-interface-dev, device type: %d\n, type);
+ type_str = type_1;
+ }
+ dev_info(serial-interface-dev, device type: %s\n, type_str);
No, that's just noise in the system, no one really cares about this.
Leave it as dev_dbg() please. The string is nice to have though.
Can you resend this?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: host: add Kconfig option for EHSET
commit 9841f37a1c (usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET) added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Jack Pham ja...@codeaurora.org
---
drivers/usb/host/Kconfig| 17 +
drivers/usb/host/ehci-hub.c |8 +++-
drivers/usb/host/ehci-q.c |2 ++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index cf521d6..4b6ff21 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -722,3 +722,20 @@ config USB_HCD_SSB
for ehci and ohci.
If unsure, say N.
+
+config USB_HCD_TEST_MODE
+ bool HCD test mode support
+ ---help---
+ Say 'Y' to enable additional software test modes that may be
+ supported by the host controller drivers.
+
+ One such test mode is the Embedded High-speed Host Electrical Test
+ (EHSET) for EHCI host controller hardware, specifically the Single
+ Step Set Feature test. Typically this will be enabled for On-the-Go
+ or embedded hosts that need to undergo USB-IF compliance testing with
+ the aid of special testing hardware. In the future, this may expand
+ to include other tests that require support from a HCD driver.
+
+ This option is of interest only to developers who need to validate
+ their USB hardware designs. It is not needed for normal use. If
+ unsure, say N.
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9b222e4..d0edf53 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -711,6 +711,8 @@ ehci_hub_descriptor (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
+
#define EHSET_TEST_SINGLE_STEP_SET_FEATURE 0x06
static void usb_ehset_completion(struct urb *urb)
@@ -846,6 +848,7 @@ cleanup:
kfree(buf);
return retval;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
static int ehci_hub_control (
@@ -1221,13 +1224,16 @@ static int ehci_hub_control (
* about the EHCI-specific stuff.
*/
case USB_PORT_FEAT_TEST:
+#ifdef CONFIG_USB_HCD_TEST_MODE
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
wIndex);
spin_lock_irqsave(ehci-lock, flags);
break;
- } else if (!selector || selector 5)
+ }
+#endif
+ if (!selector || selector 5)
goto error;
spin_unlock_irqrestore(ehci-lock, flags);
ehci_quiesce(ehci);
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 702a0e9..c8d432f 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1144,6 +1144,7 @@ submit_async (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
/*
* This function creates the qtds and submits them for the
* SINGLE_STEP_SET_FEATURE Test.
@@ -1243,6 +1244,7 @@ cleanup:
qtd_list_free(ehci, urb, head);
return -1;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: About the hibernation feature implementation in dwc3 driver
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, August 13, 2013 1:30 PM On Tue, Aug 13, 2013 at 08:04:26PM +, Paul Zimmerman wrote: From: Felipe Balbi Sent: Tuesday, August 13, 2013 12:20 PM On Mon, Aug 05, 2013 at 03:41:57PM +, Wang, Yu Y wrote: Hi Balbi, Please check the attached logs. The kernel base one kernel3.10. you didn't take the regdump after xHCI :-( I need to check if erst_base is being mirrored to DEPCMDPAR* Hi Felipe, There seems to be some basic misunderstanding here. ALL versions of the Synopsys core share the internal RAM between device and host modes. So the only supported way of switching modes is to shut down the driver for the mode you are leaving, then start up the driver for the mode you are entering and re-initialize (most of) the registers. This is described in the databook in the OTG - Software Flow and OTG - Programming Model chapters. sure. So whether a particular set of RAM-based registers is mirrored between modes does not matter. fair enough. And I don't see what this has to do with hibernation? I have lost track of the conversation, probably. but I believe Yu mentioned resetting the IP everytime when coming out of hibernation and, for whatever reason, I confused myself with the other problem. OK :) By the way, I wanted to tell Yu that you (Felipe) are correct about not resetting the core when coming out of hibernation. That is definitely not required, and would probably break the resume from hibernation. I think we (Synopsys) should update the databook to mention that explicitly, since it is different from the normal initialization flow. -- 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
[PATCH v2 RESEND] usb: host: add Kconfig option for EHSET
commit 9841f37a1c (usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET) added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Jack Pham ja...@codeaurora.org
---
Resending with 'v2' in subject tag.
v2: Updated Kconfig description per Alan's comments
drivers/usb/host/Kconfig| 17 +
drivers/usb/host/ehci-hub.c |8 +++-
drivers/usb/host/ehci-q.c |2 ++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index cf521d6..4b6ff21 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -722,3 +722,20 @@ config USB_HCD_SSB
for ehci and ohci.
If unsure, say N.
+
+config USB_HCD_TEST_MODE
+ bool HCD test mode support
+ ---help---
+ Say 'Y' to enable additional software test modes that may be
+ supported by the host controller drivers.
+
+ One such test mode is the Embedded High-speed Host Electrical Test
+ (EHSET) for EHCI host controller hardware, specifically the Single
+ Step Set Feature test. Typically this will be enabled for On-the-Go
+ or embedded hosts that need to undergo USB-IF compliance testing with
+ the aid of special testing hardware. In the future, this may expand
+ to include other tests that require support from a HCD driver.
+
+ This option is of interest only to developers who need to validate
+ their USB hardware designs. It is not needed for normal use. If
+ unsure, say N.
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9b222e4..d0edf53 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -711,6 +711,8 @@ ehci_hub_descriptor (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
+
#define EHSET_TEST_SINGLE_STEP_SET_FEATURE 0x06
static void usb_ehset_completion(struct urb *urb)
@@ -846,6 +848,7 @@ cleanup:
kfree(buf);
return retval;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
static int ehci_hub_control (
@@ -1221,13 +1224,16 @@ static int ehci_hub_control (
* about the EHCI-specific stuff.
*/
case USB_PORT_FEAT_TEST:
+#ifdef CONFIG_USB_HCD_TEST_MODE
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
wIndex);
spin_lock_irqsave(ehci-lock, flags);
break;
- } else if (!selector || selector 5)
+ }
+#endif
+ if (!selector || selector 5)
goto error;
spin_unlock_irqrestore(ehci-lock, flags);
ehci_quiesce(ehci);
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 702a0e9..c8d432f 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1144,6 +1144,7 @@ submit_async (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
/*
* This function creates the qtds and submits them for the
* SINGLE_STEP_SET_FEATURE Test.
@@ -1243,6 +1244,7 @@ cleanup:
qtd_list_free(ehci, urb, head);
return -1;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/2] usb: musb: cppi41: Enable in device-TX mode
On Tue, Aug 13, 2013 at 2:21 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 01:11:47PM -0500, Bin Liu wrote: Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? it would be quite difficult to check PG revision from this driver. It would have to be passed as a flag through DT or something similar. To make the code logic simple, I would think to ignore the rev check and enable CPPI for RX in device mode. I think in theory the controller in device mode will never hit on this hw bug. Regards, -Bin. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: URBs active during clear endpoint halt?
On Tue, 13 Aug 2013, Sarah Sharp wrote: Hi Alan, Do you know if there's a chance that any USB drivers (or userspace) would try to clear an endpoint halt when there are active URBs that have not completed on for the endpoint? They might, but they shouldn't. It would be a bug. I ask because in order to handle the case where userspace wants to reset the toggles with a clear halt control transfer, but the endpoint is not actually halted, the xHCI driver needs to wipe out the contents of the endpoint ring and reset the dequeue pointer. (The dequeue pointer alignment for the Configure Endpoint command forces us to set the pointer the top of the ring, or every fourth TRB.) Re-initializing the ring would be bad to do if there were pending URBs that hadn't been canceled before the driver tried to clear the halt. I think it's pretty unlikely for this corner case to occur, but I could potentially see a driver queueing multiple URBs to an endpoint, and clearing the halt that occurred on the first URB, and then expecting the other URB to complete successfully. What would happen under EHCI in this case? There's a WARN_ONCE for this case, and the endpoint_reset call generated by the clear-halt is otherwise ignored. Would it be OK to simply return the second URB with a -EPROTO in this case? Or should we save the URBs, re-init the endpoint ring, requeue the URB to the ring, and ring the endpoint doorbell? Pretty much anything you do will be okay. I recommend copying what ehci-hcd does. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: add Kconfig option for EHSET
On Tue, 13 Aug 2013, Jack Pham wrote:
commit 9841f37a1c (usb: ehci: Add support for SINGLE_STEP_SET_FEATURE
test of EHSET) added additional code to the EHCI hub driver but it is
anticipated to only have a limited audience (e.g. embedded silicon
vendors and integrators). Avoid subjecting all EHCI (and in the future
maybe xHCI/OHCI, etc.) HCD users to code bloat by conditionally
compiling the EHSET-specific additions with a new Kconfig option,
CONFIG_USB_HCD_TEST_MODE.
Cc: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Jack Pham ja...@codeaurora.org
---
drivers/usb/host/Kconfig| 17 +
drivers/usb/host/ehci-hub.c |8 +++-
drivers/usb/host/ehci-q.c |2 ++
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index cf521d6..4b6ff21 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -722,3 +722,20 @@ config USB_HCD_SSB
for ehci and ohci.
If unsure, say N.
+
+config USB_HCD_TEST_MODE
+ bool HCD test mode support
+ ---help---
+ Say 'Y' to enable additional software test modes that may be
+ supported by the host controller drivers.
+
+ One such test mode is the Embedded High-speed Host Electrical Test
+ (EHSET) for EHCI host controller hardware, specifically the Single
+ Step Set Feature test. Typically this will be enabled for On-the-Go
+ or embedded hosts that need to undergo USB-IF compliance testing with
+ the aid of special testing hardware. In the future, this may expand
+ to include other tests that require support from a HCD driver.
+
+ This option is of interest only to developers who need to validate
+ their USB hardware designs. It is not needed for normal use. If
+ unsure, say N.
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 9b222e4..d0edf53 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -711,6 +711,8 @@ ehci_hub_descriptor (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
+
#define EHSET_TEST_SINGLE_STEP_SET_FEATURE 0x06
static void usb_ehset_completion(struct urb *urb)
@@ -846,6 +848,7 @@ cleanup:
kfree(buf);
return retval;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
static int ehci_hub_control (
@@ -1221,13 +1224,16 @@ static int ehci_hub_control (
* about the EHCI-specific stuff.
*/
case USB_PORT_FEAT_TEST:
+#ifdef CONFIG_USB_HCD_TEST_MODE
if (selector == EHSET_TEST_SINGLE_STEP_SET_FEATURE) {
spin_unlock_irqrestore(ehci-lock, flags);
retval = ehset_single_step_set_feature(hcd,
wIndex);
spin_lock_irqsave(ehci-lock, flags);
break;
- } else if (!selector || selector 5)
+ }
+#endif
+ if (!selector || selector 5)
goto error;
spin_unlock_irqrestore(ehci-lock, flags);
ehci_quiesce(ehci);
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 702a0e9..c8d432f 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -1144,6 +1144,7 @@ submit_async (
}
/*-*/
+#ifdef CONFIG_USB_HCD_TEST_MODE
/*
* This function creates the qtds and submits them for the
* SINGLE_STEP_SET_FEATURE Test.
@@ -1243,6 +1244,7 @@ cleanup:
qtd_list_free(ehci, urb, head);
return -1;
}
+#endif /* CONFIG_USB_HCD_TEST_MODE */
/*-*/
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] USB patches for v3.12 merge window
From: Felipe Balbi Sent: Tuesday, August 13, 2013 1:01 PM On Tue, Aug 13, 2013 at 02:48:42PM -0500, Felipe Balbi wrote: On Tue, Aug 13, 2013 at 02:41:25PM -0500, Felipe Balbi wrote: Hi Greg, Here's my pull request for v3.12 merge window. I know there are a bunch of patches pending in the mailing list but I won't have time to fully review them before merging so I decided that it's best to delay a merge window than it is to cause a bunch of regressions. Oh yeah, the patches under arch/arm got Acked by Tony Lindgren. Let me know if you want any changes to the pull request. just now I saw the build failure Stephen reported. Please don't merge this in yet, I'll put a patch on top to fix the build failure. now fixed, here's the pull updated pull request: The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12 for you to fetch changes up to 8b841cb217fac676498de3dfe8fabe38b39cba4e: usb: phy: am335x: include linux/err.h (2013-08-13 14:59:13 -0500) usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Hi Felipe, I think f7e846f0956 make maximum-speed a per-instance attribute causes an oops when using the dwc3-pci glue layer. At least when I tried your testing branch a couple of days ago, that's what I saw. Because in that case 'pdata' is NULL. Or has some other commit since then fixed that? Sorry for not reporting it sooner, I got busy with other stuff and forgot. -- 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 inclusion in kernel?
On Tue, 13 Aug 2013, James Stone wrote:
http://www.spinics.net/lists/linux-usb/msg90457.html
This patch is definitely not the way to go. A week ago I posted a
completely different approach here:
http://marc.info/?l=linux-usbm=137537866909950w=2
So far there has been no feedback on it; I'm still waiting to hear from
any of the ALSA people (hint).
Even that patch is not totally right. If the ALSA buffer size is
larger than the minimum hardware requirement, then an entire buffer's
worth of data should be queued at all times. Regardless, it's
probably too big for a stable kernel, which means it won't appear
before the 3.12 release is out. Maybe not even then.
This patch does not seem to be needed at all. Performance is better without
it.
Like I said, it isn't totally right. But _something_ is definitely
needed.
On a slightly different note, the big patch below should speed up the
bandwidth calculations in ehci-hcd quite a lot. Please try it out and
see if you still get those underrun warnings when the camera or
whatever is plugged in. Also, see what the irqsoff tracer has to say
about the interrupt latency when these events occur.
Alan Stern
Index: usb-3.11/include/linux/usb/hcd.h
===
--- usb-3.11.orig/include/linux/usb/hcd.h
+++ usb-3.11/include/linux/usb/hcd.h
@@ -479,6 +479,7 @@ struct usb_tt {
struct usb_device *hub; /* upstream highspeed hub */
int multi; /* true means one TT per port */
unsignedthink_time; /* think time in ns */
+ void*hcpriv;/* HCD private data */
/* for control/bulk error recovery (CLEAR_TT_BUFFER) */
spinlock_t lock;
@@ -537,9 +538,8 @@ extern void usb_ep0_reinit(struct usb_de
* of (7/6 * 8 * bytecount) = 9.33 * bytecount */
/* bytecount = data payload byte count */
-#define NS_TO_US(ns) ((ns + 500L) / 1000L)
- /* convert round nanoseconds to microseconds */
-
+#define NS_TO_US(ns) DIV_ROUND_UP(ns, 1000L)
+ /* convert nanoseconds to microseconds, rounding up */
/*
* Full/low speed bandwidth allocation constants/support.
Index: usb-3.11/drivers/usb/host/ehci.h
===
--- usb-3.11.orig/drivers/usb/host/ehci.h
+++ usb-3.11/drivers/usb/host/ehci.h
@@ -54,6 +54,28 @@ struct ehci_stats {
unsigned long unlink;
};
+/*
+ * Scheduling and budgeting information for periodic transfers, for both
+ * high-speed devices and full/low-speed devices lying behind a TT.
+ */
+struct ehci_per_sched {
+ struct usb_device *udev; /* access to the TT */
+ struct usb_host_endpoint *ep;
+ struct list_headps_list;/* node on ehci_tt's ps_list */
+ u16 tt_usecs; /* time on the FS/LS bus */
+ u16 cs_mask;/* C-mask and S-mask bytes */
+ u16 period; /* actual period in frames */
+ u16 phase; /* actual phase, frame part */
+ u8 bw_phase; /* same, for bandwidth
+ reservation */
+ u8 phase_uf; /* uframe part of the phase */
+ u8 usecs, c_usecs; /* times on the HS bus */
+ u8 bw_uperiod; /* period in microframes, for
+ bandwidth reservation */
+ u8 bw_period; /* same, in frames */
+};
+#define NO_FRAME 2 /* frame not assigned yet */
+
/* ehci_hcd-lock guards shared data against other CPUs:
* ehci_hcd: async, unlink, periodic (and shadow), ...
* usb_host_endpoint: hcpriv
@@ -226,6 +248,15 @@ struct ehci_hcd { /* one per controlle
struct dentry *debug_dir;
#endif
+ /* bandwidth usage */
+#define EHCI_BANDWIDTH_SIZE64
+#define EHCI_BANDWIDTH_FRAMES (EHCI_BANDWIDTH_SIZE 3)
+ u8 bandwidth[EHCI_BANDWIDTH_SIZE];
+ /* us allocated per uframe */
+ u8 tt_budget[EHCI_BANDWIDTH_SIZE];
+ /* us budgeted per uframe */
+ struct list_headtt_list;
+
/* platform-specific data -- must come last */
unsigned long priv[0] __aligned(sizeof(s64));
};
@@ -381,6 +412,7 @@ struct ehci_qh {
struct list_headintr_node; /* list of intr QHs */
struct ehci_qtd *dummy;
struct list_headunlink_node;
+ struct ehci_per_sched ps; /* scheduling info */
Re: [GIT PULL] USB patches for v3.12 merge window
Hi, On Tue, Aug 13, 2013 at 08:51:27PM +, Paul Zimmerman wrote: From: Felipe Balbi Sent: Tuesday, August 13, 2013 1:01 PM On Tue, Aug 13, 2013 at 02:48:42PM -0500, Felipe Balbi wrote: On Tue, Aug 13, 2013 at 02:41:25PM -0500, Felipe Balbi wrote: Hi Greg, Here's my pull request for v3.12 merge window. I know there are a bunch of patches pending in the mailing list but I won't have time to fully review them before merging so I decided that it's best to delay a merge window than it is to cause a bunch of regressions. Oh yeah, the patches under arch/arm got Acked by Tony Lindgren. Let me know if you want any changes to the pull request. just now I saw the build failure Stephen reported. Please don't merge this in yet, I'll put a patch on top to fix the build failure. now fixed, here's the pull updated pull request: The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.12 for you to fetch changes up to 8b841cb217fac676498de3dfe8fabe38b39cba4e: usb: phy: am335x: include linux/err.h (2013-08-13 14:59:13 -0500) usb: patches for v3.12 merge window All patches here have been pending on linux-usb and sitting in linux-next for a while now. The biggest things in this tag are: DWC3 learned proper usage of threaded IRQ handlers and now we spend very little time in hardirq context. MUSB now has proper support for BeagleBone and Beaglebone Black. Tegra's USB support also got quite a bit of love and is learning to use PHY layer and generic DT attributes. Other than that, the usual pack of cleanups and non-critical fixes follow. Hi Felipe, I think f7e846f0956 make maximum-speed a per-instance attribute causes an oops when using the dwc3-pci glue layer. At least when I tried your testing branch a couple of days ago, that's what I saw. Because in that case 'pdata' is NULL. Or has some other commit since then fixed that? heh, I can now see how that could happen. I'll add a patch to the branch taking care of that. Sorry for not reporting it sooner, I got busy with other stuff and forgot. better late than never ;-) -- balbi signature.asc Description: Digital signature
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
On Mon, 12 Aug 2013, Alan Stern wrote: On Mon, 12 Aug 2013, Takashi Iwai wrote: So... Clemens, Daniel, Eldad, could you guys review the latest version of Alan's patch? I'd love to sort this out for 3.12. Here's a revised version of the patch (still untested). The difference is that this version tries always to keep a period's worth of bytes in the USB hardware queue. This will provide better protection against underruns when the period is larger than the queue's minimum requirement. After more thought, I decided that patch does too much. It's not necessary to keep track of the number of packets. Instead, the driver should always try to keep as much data in the USB hardware queue as it is allowed to. In other words, there should be enough URBs so that an entire ALSA buffer can be queued at any time, subject only to the limit on the maximum number of URBs and packets. It doesn't make sense to allocate just enough URBs to cover a single period. Does this seem reasonable? 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] usb: dwc3: core: cope with NULL pdata
if pdata is a NULL pointer we could cause a
kernel oops when probing the driver. Make sure
to cope with systems which won't pass pdata
to the driver.
Reported-by: Paul Zimmerman pa...@synopsys.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 3ff6f0a..577af1b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -393,7 +393,7 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
- } else {
+ } else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
@@ -401,6 +401,9 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
+ } else {
+ dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
/* default to superspeed if no maximum_speed passed */
--
1.8.3.4.840.g6a90778
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] USB patches for v3.12 merge window
From: Felipe Balbi [mailto:ba...@ti.com] Sent: Tuesday, August 13, 2013 2:05 PM On Tue, Aug 13, 2013 at 08:51:27PM +, Paul Zimmerman wrote: Hi Felipe, I think f7e846f0956 make maximum-speed a per-instance attribute causes an oops when using the dwc3-pci glue layer. At least when I tried your testing branch a couple of days ago, that's what I saw. Because in that case 'pdata' is NULL. Or has some other commit since then fixed that? heh, I can now see how that could happen. I'll add a patch to the branch taking care of that. Sorry for not reporting it sooner, I got busy with other stuff and forgot. better late than never ;-) I guess you don't have your PCI-based platform any more to test with? If you give me a shout a few days before you submit DWC3 stuff for mainline, I can test it for you. If I'm not up to my eyeballs with other stuff, anyway. -- 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 1/2] net: asix: Staticise non-exported symbols
From: Mark Brown broo...@kernel.org Date: Fri, 9 Aug 2013 18:31:21 +0100 From: Mark Brown broo...@linaro.org Make functions that are only referenced from ops structures static, they do not need to be in the global namespace and sparse complains about this. Signed-off-by: Mark Brown broo...@linaro.org Applied. -- 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 2/2] usb: musb: cppi41: Enable in device-TX mode
On Tue, Aug 13, 2013 at 03:41:01PM -0500, Bin Liu wrote: On Tue, Aug 13, 2013 at 2:21 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 01:11:47PM -0500, Bin Liu wrote: Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? it would be quite difficult to check PG revision from this driver. It would have to be passed as a flag through DT or something similar. To make the code logic simple, I would think to ignore the rev check and enable CPPI for RX in device mode. I think in theory the controller in device mode will never hit on this hw bug. this patch is already in my branch going upstream. I think Sebastian has a point in leaving this disabled until he knows it's working fine. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/2] usb: musb: cppi41: Enable in device-TX mode
On Tue, Aug 13, 2013 at 4:13 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 03:41:01PM -0500, Bin Liu wrote: On Tue, Aug 13, 2013 at 2:21 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 01:11:47PM -0500, Bin Liu wrote: Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? it would be quite difficult to check PG revision from this driver. It would have to be passed as a flag through DT or something similar. To make the code logic simple, I would think to ignore the rev check and enable CPPI for RX in device mode. I think in theory the controller in device mode will never hit on this hw bug. this patch is already in my branch going upstream. I think Sebastian has a point in leaving this disabled until he knows it's working fine. Ok. at least we have dma enabled for tx now ;) -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: musb: cppi41: Enable in device-TX mode
On Tue, Aug 13, 2013 at 04:17:26PM -0500, Bin Liu wrote: On Tue, Aug 13, 2013 at 4:13 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 03:41:01PM -0500, Bin Liu wrote: On Tue, Aug 13, 2013 at 2:21 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 13, 2013 at 01:11:47PM -0500, Bin Liu wrote: Sebastian, On Tue, Aug 13, 2013 at 12:38 PM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: Since the musb-gadget code now calls the dma engine properly it is possible to enable it for the TX path in device mode. AM335x Advisory 1.0.13 says that we may lose the toggle bit on multiple RX transfers. There is a workaround in host mode but none in device mode and therefore RX transfers are disabled. 1.0.13 only presents in PG1.0. It has been fixed in PG2.x. Maybe we should check for silicon rev here? it would be quite difficult to check PG revision from this driver. It would have to be passed as a flag through DT or something similar. To make the code logic simple, I would think to ignore the rev check and enable CPPI for RX in device mode. I think in theory the controller in device mode will never hit on this hw bug. this patch is already in my branch going upstream. I think Sebastian has a point in leaving this disabled until he knows it's working fine. Ok. at least we have dma enabled for tx now ;) true, I'm sure Sebastian has plans on adding RX support, but only after he knows it's working fine ;-) -- balbi signature.asc Description: Digital signature
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
Hi Alan, On 13.08.2013 23:06, Alan Stern wrote: On Mon, 12 Aug 2013, Alan Stern wrote: On Mon, 12 Aug 2013, Takashi Iwai wrote: So... Clemens, Daniel, Eldad, could you guys review the latest version of Alan's patch? I'd love to sort this out for 3.12. Here's a revised version of the patch (still untested). The difference is that this version tries always to keep a period's worth of bytes in the USB hardware queue. This will provide better protection against underruns when the period is larger than the queue's minimum requirement. After more thought, I decided that patch does too much. It's not necessary to keep track of the number of packets. Instead, the driver should always try to keep as much data in the USB hardware queue as it is allowed to. In other words, there should be enough URBs so that an entire ALSA buffer can be queued at any time, subject only to the limit on the maximum number of URBs and packets. It doesn't make sense to allocate just enough URBs to cover a single period. Does this seem reasonable? I think so, yes. But I'd like to comment on the actual patch, and also give it a try first of course. It took me some days to gather my setup again, but if you send a revised version, I hope to be able to test it in the next days. Thanks, Daniel -- 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: Commit 09fc7d22b0 (usb: musb: fix incorrect usage of resource pointer) questions
Hello. On 08/14/2013 01:33 AM, Felipe Balbi wrote: I have basically two questions on this change: [...] 2) why you omitted am35x.c from this commit? mistake Are you going to fix it, or should I? I'm just not sure how many resources there are with all these hwmod complications... tell me about it. I hoped you tell me. :-) Kishon was going to send a patch which would allocate and copy those resources dynamically based on pdev-num_resources. That would be undesirable in the light of my WIP patch making MUSB truly a sub-device of the glue drivers and passing always 2 resources to it... hmm.. you're right, but not completely. MUSB itself has 2 resources: 1 IRQ and 1 memory base. The other resources are part of the DMA. But at least for arches with the Inventra DMA, they'll need the DMA IRQ and Not only them, CPPI 3.1 on DM6467 too. since that's likely not going to use DMA Engine, I'm not sure we have a way out. We can always use musb-controller-parent to get to the glue DMA resources. At least that's what I'm going to do. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Buffer size for ALSA USB PCM audio
Alan Stern wrote:
On Mon, 12 Aug 2013, Takashi Iwai wrote:
So... Clemens, Daniel, Eldad, could you guys review the latest version
of Alan's patch? I'd love to sort this out for 3.12.
Here's a revised version of the patch (still untested).
- maxsize = ((ep-freqmax + 0x) * (frame_bits 3))
- (16 - ep-datainterval);
+ maxsize = ((ep-freqmax + 0x) (16 - ep-datainterval))
+ * (frame_bits 3);
What do you assume prevents firmware writers from splitting frames
across packages? The specification? Sanity? :) (see txfr_quirk)
The difference is that this version tries always to keep a period's
worth of bytes in the USB hardware queue.
Having truncated URBs is possible only when URBs are shorter than one
period, so I think that a queue length of at least two periods, together
with a minimum period size, should ensure the isochrounous scheduling
threshold.
This isn't tested either.
Regards,
Clemens
sound/usb/endpoint.c |3 ++-
sound/usb/pcm.c | 16 ++--
2 files changed, 16 insertions(+), 3 deletions(-)
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -638,7 +638,8 @@ static int data_ep_set_params(struct snd_usb_endpoint *ep,
if (sync_ep)
minsize -= minsize 3;
minsize = max(minsize, 1u);
- total_packs = (period_bytes + minsize - 1) / minsize;
+ /* try to make the queue length the same as two periods */
+ total_packs = (2 * period_bytes + minsize - 1) / minsize;
/* we need at least two URBs for queueing */
if (total_packs 2) {
total_packs = 2;
--- a/sound/usb/pcm.c
+++ b/sound/usb/pcm.c
@@ -1131,10 +1131,22 @@ static int setup_hw_info(struct snd_pcm_runtime
*runtime, struct snd_usb_substre
return err;
param_period_time_if_needed = SNDRV_PCM_HW_PARAM_PERIOD_TIME;
- if (subs-speed == USB_SPEED_FULL)
+ switch (subs-speed) {
+ case USB_SPEED_FULL:
/* full speed devices have fixed data packet interval */
ptmin = 1000;
- if (ptmin == 1000)
+ break;
+ case USB_SPEED_HIGH:
+ /*
+* Assume we have an EHCI controller with an Isochronous
+* Scheduling Threshold of one frame (8 microframes), and
+* add 2 microframes for boundary cases. Increase by 4%
+* to have a margin for clock inaccuracies.
+*/
+ ptmin = max(ptmin, (8 + 2) * 130u);
+ break;
+ }
+ if (ptmin = 1000)
/* if period time doesn't go below 1 ms, no rules needed */
param_period_time_if_needed = -1;
snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_TIME,
--
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
