date:20131115

[PATCH net v3 1/4] r8152: fix tx/rx memory overflow

2013-11-15 Thread Hayes Wang

The tx/rx would access the memory which is out of the desired range.
Modify the method of checking the end of the memory to avoid it.

For r8152_tx_agg_fill(), the variable remain may become negative.
However, the declaration is unsigned, so the while loop wouldn't
break when reaching the end of the desied memory. Although to change
the declaration from unsigned to signed is enough to fix it, I also
modify the checking method for safe. Replace

remain = rx_buf_sz - sizeof(*tx_desc) -
 (u32)((void *)tx_data - agg-head);

with

remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);

to make sure the variable remain is always positive. Then, the
overflow wouldn't happen.

For rx_bottom(), the rx_desc should not be used to calculate the
packet length before making sure the rx_desc is in the desired range.
Change the checking to two parts. First, check the descriptor is in
the memory. The other, using the descriptor to find out the packet
length and check if the packet is in the memory.

Signed-off-by: Hayes Wang hayesw...@realtek.com
---
 drivers/net/usb/r8152.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3fce41..5dbfe50 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
 #include linux/ipv6.h
 
 /* Version Information */
-#define DRIVER_VERSION v1.01.0 (2013/08/12)
+#define DRIVER_VERSION v1.02.0 (2013/10/28)
 #define DRIVER_AUTHOR Realtek linux nic maintainers nic_s...@realtek.com
 #define DRIVER_DESC Realtek RTL8152 Based USB 2.0 Ethernet Adapters
 #define MODULENAME r8152
@@ -1136,14 +1136,14 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, 
struct sk_buff *skb)
 
 static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
 {
-   u32 remain;
+   int remain;
u8 *tx_data;
 
tx_data = agg-head;
agg-skb_num = agg-skb_len = 0;
-   remain = rx_buf_sz - sizeof(struct tx_desc);
+   remain = rx_buf_sz;
 
-   while (remain = ETH_ZLEN) {
+   while (remain = ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
struct sk_buff *skb;
unsigned int len;
@@ -1152,12 +1152,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
if (!skb)
break;
 
+   remain -= sizeof(*tx_desc);
len = skb-len;
if (remain  len) {
skb_queue_head(tp-tx_queue, skb);
break;
}
 
+   tx_data = tx_agg_align(tx_data);
tx_desc = (struct tx_desc *)tx_data;
tx_data += sizeof(*tx_desc);
 
@@ -1167,9 +1169,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
agg-skb_len += len;
dev_kfree_skb_any(skb);
 
-   tx_data = tx_agg_align(tx_data + len);
-   remain = rx_buf_sz - sizeof(*tx_desc) -
-(u32)((void *)tx_data - agg-head);
+   tx_data += len;
+   remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
}
 
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
@@ -1188,7 +1189,6 @@ static void rx_bottom(struct r8152 *tp)
list_for_each_safe(cursor, next, tp-rx_done) {
struct rx_desc *rx_desc;
struct rx_agg *agg;
-   unsigned pkt_len;
int len_used = 0;
struct urb *urb;
u8 *rx_data;
@@ -1204,17 +1204,22 @@ static void rx_bottom(struct r8152 *tp)
 
rx_desc = agg-head;
rx_data = agg-head;
-   pkt_len = le32_to_cpu(rx_desc-opts1)  RX_LEN_MASK;
-   len_used += sizeof(struct rx_desc) + pkt_len;
+   len_used += sizeof(struct rx_desc);
 
-   while (urb-actual_length = len_used) {
+   while (urb-actual_length  len_used) {
struct net_device *netdev = tp-netdev;
struct net_device_stats *stats;
+   unsigned pkt_len;
struct sk_buff *skb;
 
+   pkt_len = le32_to_cpu(rx_desc-opts1)  RX_LEN_MASK;
if (pkt_len  ETH_ZLEN)
break;
 
+   len_used += pkt_len;
+   if (urb-actual_length  len_used)
+   break;
+
stats = rtl8152_get_stats(netdev);
 
pkt_len -= 4; /* CRC */
@@ -1234,9 +1239,8 @@ static void rx_bottom(struct r8152 *tp)
 
rx_data = rx_agg_align(rx_data + pkt_len + 4);
rx_desc = (struct rx_desc *)rx_data;
-   pkt_len = le32_to_cpu(rx_desc-opts1)

[PATCH net v3 4/4] r8152: fix incorrect type in assignment

2013-11-15 Thread Hayes Wang

The data from the hardware should be little endian. Correct the
declaration.

Signed-off-by: Hayes Wang hayesw...@realtek.com
---
 drivers/net/usb/r8152.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 81a4171..25e8fa8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -307,22 +307,22 @@ enum rtl8152_flags {
 #define MCU_TYPE_USB   0x
 
 struct rx_desc {
-   u32 opts1;
+   __le32 opts1;
 #define RX_LEN_MASK0x7fff
-   u32 opts2;
-   u32 opts3;
-   u32 opts4;
-   u32 opts5;
-   u32 opts6;
+   __le32 opts2;
+   __le32 opts3;
+   __le32 opts4;
+   __le32 opts5;
+   __le32 opts6;
 };
 
 struct tx_desc {
-   u32 opts1;
+   __le32 opts1;
 #define TX_FS  (1  31) /* First segment of a packet */
 #define TX_LS  (1  30) /* Final segment of a packet */
 #define TX_LEN_MASK0x3
 
-   u32 opts2;
+   __le32 opts2;
 #define UDP_CS (1  31) /* Calculate UDP/IP checksum */
 #define TCP_CS (1  30) /* Calculate TCP/IP checksum */
 #define IPV4_CS(1  29) /* Calculate IPv4 checksum */
@@ -877,7 +877,7 @@ static void write_bulk_callback(struct urb *urb)
 static void intr_callback(struct urb *urb)
 {
struct r8152 *tp;
-   __u16 *d;
+   __le16 *d;
int status = urb-status;
int res;
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net v3 2/4] r8152: modify the tx flow

2013-11-15 Thread Hayes Wang

Remove the code for sending the packet in the rtl8152_start_xmit().
Let rtl8152_start_xmit() to queue the packet only, and schedule a
tasklet to send the queued packets. This simplify the code and make
sure all the packet would be sent by the original order.

Signed-off-by: Hayes Wang hayesw...@realtek.com
---
 drivers/net/usb/r8152.c | 46 +++---
 1 file changed, 3 insertions(+), 43 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5dbfe50..763234d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1388,53 +1388,13 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff 
*skb,
struct net_device *netdev)
 {
struct r8152 *tp = netdev_priv(netdev);
-   struct net_device_stats *stats = rtl8152_get_stats(netdev);
-   unsigned long flags;
-   struct tx_agg *agg = NULL;
-   struct tx_desc *tx_desc;
-   unsigned int len;
-   u8 *tx_data;
-   int res;
 
skb_tx_timestamp(skb);
 
-   /* If tx_queue is not empty, it means at least one previous packt */
-   /* is waiting for sending. Don't send current one before it.  */
-   if (skb_queue_empty(tp-tx_queue))
-   agg = r8152_get_tx_agg(tp);
-
-   if (!agg) {
-   skb_queue_tail(tp-tx_queue, skb);
-   return NETDEV_TX_OK;
-   }
-
-   tx_desc = (struct tx_desc *)agg-head;
-   tx_data = agg-head + sizeof(*tx_desc);
-   agg-skb_num = agg-skb_len = 0;
+   skb_queue_tail(tp-tx_queue, skb);
 
-   len = skb-len;
-   r8152_tx_csum(tp, tx_desc, skb);
-   memcpy(tx_data, skb-data, len);
-   dev_kfree_skb_any(skb);
-   agg-skb_num++;
-   agg-skb_len += len;
-   usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
- agg-head, len + sizeof(*tx_desc),
- (usb_complete_t)write_bulk_callback, agg);
-   res = usb_submit_urb(agg-urb, GFP_ATOMIC);
-   if (res) {
-   /* Can we get/handle EPIPE here? */
-   if (res == -ENODEV) {
-   netif_device_detach(tp-netdev);
-   } else {
-   netif_warn(tp, tx_err, netdev,
-  failed tx_urb %d\n, res);
-   stats-tx_dropped++;
-   spin_lock_irqsave(tp-tx_lock, flags);
-   list_add_tail(agg-list, tp-tx_free);
-   spin_unlock_irqrestore(tp-tx_lock, flags);
-   }
-   }
+   if (!list_empty(tp-tx_free))
+   tasklet_schedule(tp-tl);
 
return NETDEV_TX_OK;
 }
-- 
1.8.3.1

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] usb: phy: generic: clean up the probe function

2013-11-15 Thread Heikki Krogerus

Remove an extra return from the bottom.

Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
 drivers/usb/phy/phy-generic.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index 68c5548..2b96311 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -271,8 +271,6 @@ static int usb_phy_gen_xceiv_probe(struct platform_device 
*pdev)
platform_set_drvdata(pdev, nop);
 
return 0;
-
-   return err;
 }
 
 static int usb_phy_gen_xceiv_remove(struct platform_device *pdev)
-- 
1.8.4.3

--
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/3] usb: phy: generic: fix for dwc3-pci

2013-11-15 Thread Heikki Krogerus

Hi,

phy-generic broke dwc3-pci after the gpio support was added. The last
patch is fixing that issue. The other two are just cleanups.

Thanks,


Heikki Krogerus (3):
  usb: phy: generic: fix a compiler warning
  usb: phy: generic: clean up the probe function
  usb: dwc3: fix the glue drivers using the nop phy

 drivers/usb/dwc3/dwc3-exynos.c | 1 +
 drivers/usb/dwc3/dwc3-pci.c| 1 +
 drivers/usb/phy/phy-generic.c  | 4 +---
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
1.8.4.3

--
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] usb: phy: generic: fix a compiler warning

2013-11-15 Thread Heikki Krogerus

Just because it annoys me.

Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
 drivers/usb/phy/phy-generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index fce3a9e..68c5548 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -234,7 +234,7 @@ static int usb_phy_gen_xceiv_probe(struct platform_device 
*pdev)
 
if (dev-of_node) {
struct device_node *node = dev-of_node;
-   enum of_gpio_flags flags;
+   enum of_gpio_flags flags = 0;
 
if (of_property_read_u32(node, clock-frequency, clk_rate))
clk_rate = 0;
-- 
1.8.4.3

--
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: ohci-pxa27x: include linux/dma-mapping.h

2013-11-15 Thread Daniel Mack

Include linux/dma-mapping.h to make the new functions available that are
used since 22d9d8e83 (DMA-API: usb: use dma_set_coherent_mask()).

Signed-off-by: Daniel Mack zon...@gmail.com
---
I got the following error while building for PXA platforms from Linus'
current git head:

drivers/usb/host/ohci-pxa27x.c: In function ‘ohci_pxa_of_init’:
drivers/usb/host/ohci-pxa27x.c:310:2: error: implicit declaration of function 
‘dma_coerce_mask_and_coherent’ [-Werror=implicit-function-declaration]
drivers/usb/host/ohci-pxa27x.c:310:2: error: implicit declaration of function 
‘DMA_BIT_MASK’ [-Werror=implicit-function-declaration]


 drivers/usb/host/ohci-pxa27x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index e89ac4d..3963834 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -29,6 +29,7 @@
 #include linux/platform_data/usb-ohci-pxa27x.h
 #include linux/platform_data/usb-pxa3xx-ulpi.h
 #include linux/platform_device.h
+#include linux/dma-mapping.h
 #include linux/signal.h
 #include linux/usb.h
 #include linux/usb/hcd.h
-- 
1.8.4.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: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

2013-11-15 Thread Ulf Hansson

On 14 November 2013 18:57, Alan Stern st...@rowland.harvard.edu wrote:
 On Thu, 14 Nov 2013, Ulf Hansson wrote:

  Bear in mind that drivers _cannot_ rely on runtime PM to inactivate a
  device during system suspend.  The user can always prevent a device
  from going into runtime suspend by writing on to the
  /sys/.../power/control file.

 Good that you brought this up. From my point of view I think the sysfs
 for runtime PM could be debated whether it should exist at all, at
 least in it's current form.

 What other form would you suggest?

I think it is kind of strange to give provision to userspace to
control a request based power management feature in the kernel. Me
personally can't think of any good use case, but I comes from the
embedded/ARM world so I might not have the full picture.

What would make sense to me, is to move the runtime PM sysfs to
debugfs, because it is a good feature to make use of during
development and debugging.


 Anyway, if userspace decides to prevent runtime_suspend, I guess it
 will have take the consequences for it as well. :-)

 Right now, those consequences don't include also preventing the device
 from going to low power during system system.  What would you do if you
 had a buggy device, where you knew it couldn't handle runtime suspend?
 If you still wanted to put the whole system to sleep, you'd be stuck.

Hmm, this seems like a use case for runtime PM sysfs then. :-)

It sounds like vague arguments. If the driver has bugs we need to fix
them, right? Should we really let userspace workaround bugs in the
kernel?


 So as a way forward, I am thinking of a similar approach as you
 suggested with the generic suspend_late. But instead add a new
 runtime PM API, which intent is to let drivers to specify for PM core,
 if it should care to prevent the runtime suspend from happen during
 system system - or not. Could that work?

 I don't see what good it would do.  Instead of adding a new flag, why
 not just let drivers point their .suspend_late methods to the new
 generic function?  That would accomplish almost the same thing without
 changing the API.

Two minor functions will be added to the API, no big deal I think.
More importantly these will actually make life easier for some drivers
since they don't need to set up any additional PM callbacks.

Using the generic suspend_late approach would for sure work, but it
will spread to buses and power domains as well, which is not the case
when adding when adding a new API.


 (Actually, it would be superior.  The generic suspend_late approach
 will work even if the user writes on to /sys/.../power/control,
 whereas your approach won't work.)

We have different view here. :-)

Whether I like it or not, the sysfs interface exist and then I think
the kernel must act accordingly. We shouldn’t override it. I mean if
userspace has decided to keep a device active, there is probably a
reason.


Thanks a lot Alan for being patient with me and continuing the discussion!

Kind regards
Ulf Hansson


 Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

2013-11-15 Thread Bjørn Mork

Ulf Hansson ulf.hans...@linaro.org writes:

 I think it is kind of strange to give provision to userspace to
 control a request based power management feature in the kernel. Me
 personally can't think of any good use case, but I comes from the
 embedded/ARM world so I might not have the full picture.

Because resuming a device inevitably adds latency, and that only
userspace can decide the latency vs power policy for any given device,
system and user?

There are also other reasons, mostly related to device bugs.  But the
above is the most important in my view.  Without that control knob I
don't think I would have enabled runtime PM in any network driver while
the netif is running.  The additional latency is noticable.

Anyway, this is a pointless discussion.  The power/control ABI is in use
so many places that it cannot be changed.  I'd suggest googling break
userspace before even suggesting anything like that again.


Bjørn
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

xhci: complete USB freeze

2013-11-15 Thread dezifit

Accessing the audio capture device (Em28xxAudio) of a USB TV adapter
(Hauppauge HVR-900) causes a complete USB freeze (see lspci/lsusb and
logging extract at https://bugzilla.kernel.org/show_bug.cgi?id=65021).

Tested with various kernel releases up to 3.12 (currently in use is
3.11.8). This device is working at least until kernel 3.2 with the same
hardware (Intel DH87RL/Haswell, BIOS RLH8710H.86A.0320.2013.0606.1802).

Switching from a USB3 to a USB2 port doesn't change anything;
if xhci is available (xhci and ehci compiled into kernel), it is used and
the bus freezes. If ehci is forced by disabling xhci completely, the
capture device is working again.

Any feedback welcome.
-- 
Diese E-Mail wurde aus dem Sicherheitsverbund E-Mail made in
Germany versendet: http://www.gmx.net/e-mail-made-in-germany
--
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

Testing glue layer for DWC3 device controller

2013-11-15 Thread Amit Virdi


Hi All,

I'm new to this USB driver development so posting this email. Currently, 
I'm using Kernel version 3.12-rc5


In my SoC, there's Synopsys' DWC3 USB controller configured in device 
mode. This is integrated with our internal USB3.0 PHY and USB 2.0 PHY 
taken from synopsys. I'm done with the initial coding and now I want to 
test the glue layer logic implemented. I have compiled and statically 
linked the drivers.


When I boot my kernel, I see that the PHY and the DWC3 driver is probed 
successfully. However, the device doesn't enumerate. I debugged this and 
found that the device specific registers are not configured at all. More 
debugging followed and I figured out that the probe for zero gadget is 
called before the phy and the device is probed.


So, how can I test the driver by *not* modularizing the phy and the 
controller drivers.


I would be thankful for any help.

Regards
Amit Virdi
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] usb: xhci: Link TRB must not occur within a USB payload burst

2013-11-15 Thread David Laight

From: Sarah Sharp [mailto:sarah.a.sh...@linux.intel.com]

On Mon, Nov 11, 2013 at 12:26:54PM -, David Laight wrote:

Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for
480M).

If this isn't done the USB frames aren't formatted correctly and, for
example,
the USB3 ethernet ax88179_178a card will stop sending (while still
receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.

Can you send the exact command line you used to cause the stall? I'd
like to reproduce this with my USB 3.0 ethernet adapter.

Make sure you are running 3.12.0 or later. The usbnet code to support
segmentation isn't in anything much earlier and the as88179_178a
driver needs to have TSO enabled.

I'm using netperf 2.6 (compiled from source) running the netserver on
the system with the USB ethernet. The ethernet is directly connected to
an e1000 PCIe card on the other system (in a random subnet).
The control connection is using the main LAN.

I'm running netperf from a script that can loop through various parameters.
The TCP receive test should be from:

control=main LAN address of remote system
target=USB3 address of remote system
output=REQUEST_SIZE,PROTOCOL,ELAPSED_TIME,TRANSACTION_RATE,LOCAL_SEND_THROUGHPUT,LOCAL_RECV_THROUGHPUT,REMOTE_RECV_THROUGHPUT,THROUGHPUT_UNITS
netperf -l 60 -f B -D5 -t omni -H $control -- \
-T tcp -H $target -D -d in -r 8192 -O $output

I'd added some diagnostic prints to every TRB setup so I could see the fragment
sizes, ring slot addresses and the flags.
You should see URB for almost 64k split into 3 or 4 parts.
When it stopped it was always just after a LINK TRB that had been mid-TD.
The USB packets are still processed, but the TCP packets don't get transmitted.

If you have a USB3 analyser I think you'll see an unexpected short packet
if you split a data TRB across the link TRB on a non-1k boundary.

I then wrote the patch to see if it would make a difference - it did.

David

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Julien DELACOU

Pending interrupts clearing is done in dwc2_enable_common_interrupts
so we don't need to do it twice.

Signed-off-by: Julien Delacou julien.dela...@st.com
---
 drivers/staging/dwc2/core.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index c8ff668..8374ec3 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -533,9 +533,6 @@ void dwc2_enable_host_interrupts(struct dwc2_hsotg *hsotg)
writel(0, hsotg-regs + GINTMSK);
writel(0, hsotg-regs + HAINTMSK);
 
-   /* Clear any pending interrupts */
-   writel(0x, hsotg-regs + GINTSTS);
-
/* Enable the common interrupts */
dwc2_enable_common_interrupts(hsotg);
 
-- 
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] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Dan Carpenter

On Fri, Nov 15, 2013 at 11:39:38AM +0100, Julien DELACOU wrote:
 Pending interrupts clearing is done in dwc2_enable_common_interrupts
 so we don't need to do it twice.
 

Are there any user visible effects to this bug?  How did you spot it?

regards,
dan carpenter


--
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

1 2 >

1 - 100 of 160 matches

Mail list logo