RE: [PATCH net-next] net/usb: new driver for RTL8152

[hayeswang]

 Oliver Neukum [mailto:oneu...@suse.de] 
 Sent: Friday, April 26, 2013 7:57 PM
 To: Hayeswang
 Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; 
 linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; nic_swsd
 Subject: Re: [PATCH net-next] net/usb: new driver for RTL8152
 
[...]
  +static inline void set_ethernet_addr(struct r8152 *tp)
  +{
  +   struct net_device *dev = tp-netdev;
  +   u8 node_id[8] = {0};
  +
  +   if (pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id)  0)
 
 DMA coherency rules. No buffers on the stack.

Excuse me. I don't understand what you mean. I reference the rtl8150.c and it
uses the same way. Besides, when I check the other drivers, I find the data
pointer of the parameter of the usb_control_msg() may be a pointer of a local
variable from the other functions.

[...]
  +static void rtl_work_func_t(struct work_struct *work)
  +{
  +   struct r8152 *tp = container_of(work, struct r8152, 
 schedule.work);
  +
  +   if (!netif_running(tp-netdev))
  +   goto out1;
  +
  +   if (test_bit(RTL8152_UNPLUG, tp-flags))
  +   goto out1;
  +
  +   set_carrier(tp);
  +
  +   if (test_bit(RTL8152_SET_RX_MODE, tp-flags))
  +   _rtl8152_set_rx_mode(tp-netdev);
  +
  +   schedule_delayed_work(tp-schedule, HZ);
 
 Why does this need to run permanently?

It is used to periodically check the speed, link status, and any other tasks
which need to be finished.

[...]
  +static int rtl8152_close(struct net_device *netdev)
  +{
  +   struct r8152 *tp = netdev_priv(netdev);
  +   int res = 0;
  +
  +   cancel_delayed_work_sync(tp-schedule);
 
 Looks like a race. What makes sure the work isn't rescheduled?

netif_running would be checked.

 
Best Regards,
Hayes

--
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] net/usb: new driver for RTL8152

[Oliver Neukum]

On Thursday 02 May 2013 15:46:50 hayeswang wrote:
  Oliver Neukum [mailto:oneu...@suse.de] 
  Sent: Friday, April 26, 2013 7:57 PM
  To: Hayeswang
  Cc: gre...@linuxfoundation.org; net...@vger.kernel.org; 
  linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; nic_swsd
  Subject: Re: [PATCH net-next] net/usb: new driver for RTL8152
  
 [...]
   +static inline void set_ethernet_addr(struct r8152 *tp)
   +{
   + struct net_device *dev = tp-netdev;
   + u8 node_id[8] = {0};
   +
   + if (pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id)  0)
  
  DMA coherency rules. No buffers on the stack.
 
 Excuse me. I don't understand what you mean. I reference the rtl8150.c and it

On some CPUs special operations need to be performed on buffers
intended for DMA. After these operations until the DMA is over any cacheline
shared with the buffer must not be touched. In addition it is not guaranteed
that the stack is DMAable at all.
This is documented in DMA-API.txt

I know this a very common bug because it works on x86, but on some 
architectures it
fails.

 uses the same way. Besides, when I check the other drivers, I find the data
 pointer of the parameter of the usb_control_msg() may be a pointer of a local
 variable from the other functions.
 
 [...]
   +static void rtl_work_func_t(struct work_struct *work)
   +{
   + struct r8152 *tp = container_of(work, struct r8152, 
  schedule.work);
   +
   + if (!netif_running(tp-netdev))
   + goto out1;
   +
   + if (test_bit(RTL8152_UNPLUG, tp-flags))
   + goto out1;
   +
   + set_carrier(tp);
   +
   + if (test_bit(RTL8152_SET_RX_MODE, tp-flags))
   + _rtl8152_set_rx_mode(tp-netdev);
   +
   + schedule_delayed_work(tp-schedule, HZ);
  
  Why does this need to run permanently?
 
 It is used to periodically check the speed, link status, and any other tasks
 which need to be finished.

Unfortunate. It will hurt power consumption.

 
 [...]
   +static int rtl8152_close(struct net_device *netdev)
   +{
   + struct r8152 *tp = netdev_priv(netdev);
   + int res = 0;
   +
   + cancel_delayed_work_sync(tp-schedule);
  
  Looks like a race. What makes sure the work isn't rescheduled?
 
 netif_running would be checked.

I see.

HTH
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

[PATCH] staging: dwc2: use devm_ioremap_resource()

[Laurent Navet]

Replace a call to deprecated devm_request_and_ioremap by devm_ioremap_resource.

Found with coccicheck and this semantic patch:
 scripts/coccinelle/api/devm_request_and_ioremap.cocci.

Signed-off-by: Laurent Navet laurent.na...@gmail.com
---
 drivers/staging/dwc2/pci.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c
index 69c65eb..407e021 100644
--- a/drivers/staging/dwc2/pci.c
+++ b/drivers/staging/dwc2/pci.c
@@ -134,9 +134,9 @@ static int dwc2_driver_probe(struct pci_dev *dev,
pci_set_power_state(dev, PCI_D0);
 
hsotg-dev = dev-dev;
-   hsotg-regs = devm_request_and_ioremap(dev-dev, dev-resource[0]);
-   if (!hsotg-regs)
-   return -ENOMEM;
+   hsotg-regs = devm_ioremap_resource(dev-dev, dev-resource[0]);
+   if (IS_ERR(hsotg-regs))
+   return PTR_ERR(hsotg-regs);
 
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)pci_resource_start(dev, 0), hsotg-regs);
-- 
1.7.10.4

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

Re: [PATCH] staging: dwc2: use devm_ioremap_resource()

[Matthijs Kooijman]

Hi Laurent,

On Thu, May 02, 2013 at 01:23:17PM +0200, Laurent Navet wrote:
 Replace a call to deprecated devm_request_and_ioremap by 
 devm_ioremap_resource.
 
 Found with coccicheck and this semantic patch:
  scripts/coccinelle/api/devm_request_and_ioremap.cocci.
 
 Signed-off-by: Laurent Navet laurent.na...@gmail.com
 ---
  drivers/staging/dwc2/pci.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
Patch looks good, I had a bit-for-bit identical patch in my queue here
as well :-)

Reviewed-by: Matthijs Kooijman matth...@stdin.nl

Gr.

Matthijs

 diff --git a/drivers/staging/dwc2/pci.c b/drivers/staging/dwc2/pci.c
 index 69c65eb..407e021 100644
 --- a/drivers/staging/dwc2/pci.c
 +++ b/drivers/staging/dwc2/pci.c
 @@ -134,9 +134,9 @@ static int dwc2_driver_probe(struct pci_dev *dev,
   pci_set_power_state(dev, PCI_D0);
  
   hsotg-dev = dev-dev;
 - hsotg-regs = devm_request_and_ioremap(dev-dev, dev-resource[0]);
 - if (!hsotg-regs)
 - return -ENOMEM;
 + hsotg-regs = devm_ioremap_resource(dev-dev, dev-resource[0]);
 + if (IS_ERR(hsotg-regs))
 + return PTR_ERR(hsotg-regs);
  
   dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
   (unsigned long)pci_resource_start(dev, 0), hsotg-regs);
 -- 
 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
--
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 net-next] net/usb: new driver for RTL8152

[Hayes Wang]

Add new driver for supporting Realtek RTL8152 Based USB 2.0 Ethernet Adapters

Signed-off-by: Hayes Wang hayesw...@realtek.com
Cc: Realtek linux nic maintainers nic_s...@realtek.com
---
 drivers/net/usb/Kconfig |   11 +
 drivers/net/usb/Makefile|1 +
 drivers/net/usb/cdc_ether.c |   10 +
 drivers/net/usb/r8152.c | 1773 +++
 4 files changed, 1795 insertions(+)
 create mode 100644 drivers/net/usb/r8152.c

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 7c769d8..287cc62 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -93,6 +93,17 @@ config USB_RTL8150
  To compile this driver as a module, choose M here: the
  module will be called rtl8150.
 
+config USB_RTL8152
+   tristate Realtek RTL8152 Based USB 2.0 Ethernet Adapters
+   select NET_CORE
+   select MII
+   help
+ This option adds support for Realtek RTL8152 based USB 2.0
+ 10/100 Ethernet adapters.
+
+ To compile this driver as a module, choose M here: the
+ module will be called r8152.
+
 config USB_USBNET
tristate Multi-purpose USB Networking Framework
select NET_CORE
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 119b06c..9ab5c9d 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_USB_CATC)  += catc.o
 obj-$(CONFIG_USB_KAWETH)   += kaweth.o
 obj-$(CONFIG_USB_PEGASUS)  += pegasus.o
 obj-$(CONFIG_USB_RTL8150)  += rtl8150.o
+obj-$(CONFIG_USB_RTL8152)  += r8152.o
 obj-$(CONFIG_USB_HSO)  += hso.o
 obj-$(CONFIG_USB_NET_AX8817X)  += asix.o
 asix-y := asix_devices.o asix_common.o ax88172a.o
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4ff71d6..24fbec2 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -479,6 +479,7 @@ static const struct driver_info wwan_info = {
 #define NOVATEL_VENDOR_ID  0x1410
 #define ZTE_VENDOR_ID  0x19D2
 #define DELL_VENDOR_ID 0x413C
+#define REALTEK_VENDOR_ID  0x0bda
 
 static const struct usb_device_id  products [] = {
 /*
@@ -619,6 +620,15 @@ static const struct usb_device_id  products [] = {
.driver_info = 0,
 },
 
+/* Realtek RTL8152 Based USB 2.0 Ethernet Adapters */
+#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+{
+   USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+#endif
+
 /*
  * WHITELIST!!!
  *
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
new file mode 100644
index 000..33d4a9a
--- /dev/null
+++ b/drivers/net/usb/r8152.c
@@ -0,0 +1,1773 @@
+/*
+ *  Copyright (c) 2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ *  This product is covered by one or more of the following patents:
+ *  US6,570,884, US6,115,776, and US6,327,625.
+ */
+
+#include linux/init.h
+#include linux/signal.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/version.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/mii.h
+#include linux/ethtool.h
+#include linux/usb.h
+#include linux/crc32.h
+#include linux/if_vlan.h
+#include linux/uaccess.h
+
+/* Version Information */
+#define DRIVER_VERSION v1.0.0 (2013/04/25)
+#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
+
+#define PATENTSThis product is covered by one or more of the 
 \
+   following patents:\n \
+   \t\tUS6,570,884, US6,115,776, and US6,327,625.\n
+
+#define R8152_PHY_ID   32
+
+#define PLA_IDR0xc000
+#define PLA_RCR0xc010
+#define PLA_RMS0xc016
+#define PLA_RXFIFO_CTRL0   0xc0a0
+#define PLA_RXFIFO_CTRL1   0xc0a4
+#define PLA_RXFIFO_CTRL2   0xc0a8
+#define PLA_FMC0xc0b4
+#define PLA_CFG_WOL0xc0b6
+#define PLA_MAR0xcd00
+#define PAL_BDC_CR 0xd1a0
+#define PLA_LEDSEL 0xdd90
+#define PLA_LED_FEATURE0xdd92
+#define PLA_PHYAR  0xde00
+#define PLA_GPHY_INTR_IMR  0xe022
+#define PLA_EEE_CR 0xe040
+#define PLA_EEEP_CR0xe080
+#define PLA_MAC_PWR_CTRL   0xe0c0
+#define PLA_TCR0   0xe610
+#define PLA_TCR1   0xe612
+#define PLA_TXFIFO_CTRL0xe618
+#define PLA_RSTTELLY   0xe800
+#define PLA_CR 0xe813
+#define PLA_CRWECR 0xe81c
+#define PLA_CONFIG5 

Re: [PATCH V3 3/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework

[Laurent Pinchart]

Hi Michael,

On Thursday 02 May 2013 00:27:59 Michael Grzeschik wrote:
 On Mon, Apr 29, 2013 at 10:26:49PM +0200, Laurent Pinchart wrote:
  On Monday 29 April 2013 17:56:50 Michael Grzeschik wrote:
   On Mon, Feb 11, 2013 at 08:42:37PM +0100, Laurent Pinchart wrote:
On Monday 04 February 2013 11:58:27 Michael Grzeschik wrote:
 On Thu, Jan 17, 2013 at 04:23:51PM +0530, Bhupesh Sharma wrote:
  This patch reworks the videobuffer management logic present in the
  UVC webcam gadget and ports it to use the more apt videobuf2
  framework for video buffer management.
  
  To support routing video data captured from a real V4L2 video
  capture device with a zero copy operation on videobuffers (as
  they pass from the V4L2 domain to UVC domain via a user-space
  application), we need to support USER_PTR IO method at the UVC
  gadget side.
  
  So the V4L2 capture device driver can still continue to use MMAP
  IO method and now the user-space application can just pass a
  pointer to the video buffers being dequeued from the V4L2 device
  side while queueing them at the UVC gadget end. This ensures that
  we have a zero-copy design as the videobuffers pass from the
  V4L2 capture device to the UVC gadget.
  
  Note that there will still be a need to apply UVC specific payload
  headers on top of each UVC payload data, which will still require
  a copy operation to be performed in the 'encode' routines of the
  UVC gadget.
  
  This patch also addresses one issue found out while porting the
  UVC
  
  gadget to videobuf2 framework:
  - In case the usb requests queued by the gadget get completed
with a status of -ESHUTDOWN (disconnected from host),
the queue of videobuf2 should be cancelled to ensure that the
application space daemon is not left in a state waiting for
a vb2 to be successfully absorbed at the USB side.
  
  Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
  ---
  
   drivers/usb/gadget/Kconfig |1 +
   drivers/usb/gadget/uvc_queue.c |  537 ++-
   drivers/usb/gadget/uvc_queue.h |   25 +--
   drivers/usb/gadget/uvc_v4l2.c  |   27 +--
   drivers/usb/gadget/uvc_video.c |   18 +-
   5 files changed, 189 insertions(+), 419 deletions(-)

[snip]

  diff --git a/drivers/usb/gadget/uvc_queue.c
  b/drivers/usb/gadget/uvc_queue.c index 104ae9c..bd20fab 100644
  --- a/drivers/usb/gadget/uvc_queue.c
  +++ b/drivers/usb/gadget/uvc_queue.c

[snip]

  -static int uvc_queue_waiton(struct uvc_buffer *buf, int
  nonblocking)
  +static int uvc_queue_buffer(struct uvc_video_queue *queue,
  +   struct v4l2_buffer *buf)
  
   {
  
  -   if (nonblocking) {
  -   return (buf-state != UVC_BUF_STATE_QUEUED 
  -   buf-state != UVC_BUF_STATE_ACTIVE)
  -   ? 0 : -EAGAIN;
  -   }
  +   int ret;
  
  -   return wait_event_interruptible(buf-wait,
  -   buf-state != UVC_BUF_STATE_QUEUED 
  -   buf-state != UVC_BUF_STATE_ACTIVE);
  +   mutex_lock(queue-mutex);
  +   ret = vb2_qbuf(queue-queue, buf);
  +   mutex_unlock(queue-mutex);
  +
 
 How is the UVC_QUEUE_PAUSED handling supposed to be handled here?
 
 I see that this patch lost this hunk from uvc_queue_buffer():
 ret |= (queue-flags  uvc_queue_paused) != 0;
 queue-flags = ~UVC_QUEUE_PAUSED;

Good catch. This needs to be handled. The PAUSED flag needs to be set
with the irqlock held, this could be done in uvc_buffer_queue(). The
return value needs to be computed when setting the flag, so it would
need to be stored in the queue structure and read here. Adding a new
UVC_QUEUE_PUMP flag should do but will require taking the irqlock
again to read and clear that flag here. A new field is another
possible solution.
   
   the handling of UVC_QUEUE_PAUSED is currently implemented like this:
   
   ret = (queue-flags  UVC_QUEUE_PAUSED) != 0
   queue-flags = ~UVC_QUEUE_PAUSED;
   
   which is wrong as it overwrites the return value of vb2_qbuf
   which will lead to an stalled connection if the return value
   would be negative and got overwritten to 1.
  
  Oops, indeed.
  
   What do you mean with the extra flag UVC_QUEUE_PUMP. I would like
   to implement a fixup patch, but need more information how to
   correctly handle the extra return value here.
  
  Would the following patch fix the issue ?
 
 Yes, i came up with a similar patch. But i think there is more involved
 for a proper flag handling among the different state transitions.

There might be more, but I think the patch below is a good first fix. I'll 
hapilly review better fixes of course :-)

Regarding the UVC_QUEUE_PUMP flag 

USB 3 to SATA ASM1042 dies under I/O load

[Stephan Diestelhorst]

Hi,
  I am using a salvaged (from an external Toshiba spinning disk) SATA
- USB 3 adaptor with a VLI701-04 chip behind a ASMedia Technology Inc.
ASM1042 SuperSpeed USB Host Controller (ExpressCard slot).

I have attached a Samsung sereis 840 SSD and whenever I dd some data
onto the disk, the drive disconnects and then reconnects as a
different /dev/sd*.  Running 3.9 kernel (also happened with an older
one).  I know that I should not reuse that controller for such high
bandwidth operation, but maybe there is a tweak (using USB 2 works,
but I was hoping to get more than 30 MB/s from this thing ;-) to make
it work?

Many thanks for pointers!

Stephan

lspci -vv

05:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
Host Controller (prog-if 30 [XHCI])
Subsystem: Device 174c:2104
Physical Slot: 3
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at f1f0 (64-bit, non-prefetchable) [size=32K]
Capabilities: access denied
Kernel driver in use: xhci_hcd

lsusb -vv
Bus 010 Device 005: ID 0480:a009 Toshiba America Info. Systems, Inc.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 9
  idVendor   0x0480 Toshiba America Info. Systems, Inc.
  idProduct  0xa009
  bcdDevice   37.10
  iManufacturer   1 TOSHIBA
  iProduct2 External USB 3.0
  iSerial 3 290118E5
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   44
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  224mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  14
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  14
Binary Object Store Descriptor:
  bLength 5
  bDescriptorType15
  wTotalLength   22
  bNumDeviceCaps  2
  USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType16
bDevCapabilityType  2
bmAttributes   0x0002
  Link Power Management (LPM) Supported
  SuperSpeed USB Device Capability:
bLength10
bDescriptorType16
bDevCapabilityType  3
bmAttributes 0x00
  Latency Tolerance Messages (LTM) Supported
wSpeedsSupported   0x000c
  Device can operate at High Speed (480Mbps)
  Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport   2
  Lowest fully-functional device speed is High Speed (480Mbps)
bU1DevExitLat  10 micro seconds
bU2DevExitLat2047 micro seconds
Device Status: 0x
  (Bus Powered)
...
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 3
  bMaxPacketSize0 9
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0003 3.0 root hub
  bcdDevice3.09
  iManufacturer   3 Linux 3.9.0-custom xhci_hcd
  iProduct2 xHCI Host Controller
  iSerial 1 :05:00.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   31
bNumInterfaces  1
bConfigurationValue 1
  

Re: [PATCH] USB: remove remaining instances of USB_SUSPEND

[Alan Stern]

On Wed, 1 May 2013, Linus Torvalds wrote:

 On Wed, May 1, 2013 at 9:13 AM, Alan Stern st...@rowland.harvard.edu wrote:
 
  This patch (as1677) removes the remaining instances of that symbol.
 
 Btw, what are these as ID's, and what does the noise buy us?
 
 Doing a
 
   git log | egrep -w 'as[0-9]{3,}'
 
 shows that this has been going on forever, but it still doesn't make
 any *sense*. It adds nothing worthwhile. In fact, doing
 
   git log | grep 'This patch ('
 
 shows that you're pretty the only one doing it, but there's *one*
 other one jidong xiao: jx001. I really don't see the advantage of
 having this kind of random noise in the kernel logs.

I put those indexes in the patch descriptions to help with my own file
organization.  Without them, the patch files are just a big mess of
stuff with more or less arbitrary names.  The indexes have no meaning
to anybody else.

Originally I put the indexes in the email subject lines.  Greg didn't 
like this, so at his request I moved them into the patch descriptions.

I suppose they could be moved below the tear line, so that they
wouldn't show up in the final commits but only in the email messages.  
That would retain most of their utility for me without bothering anyone
else.

Jidong Xiao put that label in his patch because he was imitating me.

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 v2 net-next] net/usb: new driver for RTL8152

[Greg KH]

On Fri, May 03, 2013 at 03:48:07AM +0800, Hayes Wang wrote:
 +#define PATENTS  This product is covered by one or more of the 
  \
 + following patents:\n \
 + \t\tUS6,570,884, US6,115,776, and US6,327,625.\n

Interesting, you are aware of the issues involved with patents and GPLv2
code, right?  Do you have a pointer to the GPLv2 patent release that is
now required, or does your company now release all of the needed rights
for these patents to be able to be used by everyone?

thanks,

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

Re: xhci_hcd 0000:11:00.0: HW died, polling stopped.

[Alan Stern]

On Wed, 1 May 2013, Martin Mokrejs wrote:

  That's not how drivers work in Linux.  They don't unbind all by 
  themselves; they wait until the bus-level code tells them to unbind.
  xhci-hcd is not alone in this respect; all the drivers behave this way.
 
 I don't believe that. From my tests only the USB3 express card suffered
 the problem unlike firewire_ohci and sata_sil24 -based cards.

That's not necessarily the same thing.

 Do you remember the thread https://lkml.org/lkml/2012/4/16/566
 ... where about 60 sec timeout was needed to have usb working again?

No.

 I think I saw meanwhile other talking about 30 sec delay but I believe this
 would all be easier if xhci_hcd did unbind itself from a dead device.
 
 I am naively thinking that PCI has no way to detect a card was hot unplugged
 if e.g. hotplug was completely left out of a kernel .config or when 
 acpiphp/pciehp
 don't work, for whatever reason. But, xhci_hcd has the unique advantage that 
 it
 does polling and it know the device is dead. Probably same applies to 
 uhci/ehci.
 I just don't believe if an upper level realizes a problem why it could not
 take an action.

These drivers _do_ take action when they realize their controller is
dead.  But it's not their job to recognize when the controller has been 
removed or when they should unbind, and they don't try to do it.

 Other drivers probably don't do polling, by design, so they are in another
 situation.
 
  
  So what can be done so that the user does not have to run 
 
  echo 1  /sys/bus/pci/devices/:11:00.0/remove
 
  manually? Couldn't xhci_hcd detect somehow that the device is dead or 
  ejected?
  
  It could detect that the device is dead.  In fact, it probably detects 
  that now.  But even if it could tell that the device had been ejected, 
  it would not unbind itself.
  
  What can be done is to fix the PCIe core code so that it correctly
  realizes when an eject takes place.
 
 I believe once that will be fixed as I found that pciehp is broken
 in its action by pcie_aspm=off whereas it works when pcie_aspm=native.
 That in turn points to bad ASPM L0/L1 handling and seems similar to issues
 others had with PCIe LnkCtl on iwlwifi. That is somehow related to those
 OSC_ trickeries in acpi. Finally, seems other hit ASPM issues with Dell
 Vostro laptops. :( This will all hopefully get fixed. But I want usb
 fix as well. ;-)

When the PCI and ACPI layers are fixed, USB will automatically work
correctly too.

We don't work around problems in one driver by papering over them in 
another driver.  Instead, we fix the original driver.

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 GADGET] Add a couple kernel-doc lines to prevent warnings.

[Robert P. J. Day]

No functional change.

Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca

---

  feel free to tweak explanation if you want something more expansive

diff --git a/drivers/usb/gadget/f_ecm.c b/drivers/usb/gadget/f_ecm.c
index d893d69..abf8a31 100644
--- a/drivers/usb/gadget/f_ecm.c
+++ b/drivers/usb/gadget/f_ecm.c
@@ -816,6 +816,7 @@ ecm_unbind(struct usb_configuration *c, struct usb_function 
*f)
  * @c: the configuration to support the network link
  * @ethaddr: a buffer in which the ethernet address of the host side
  * side of the link was recorded
+ * @dev: eth_dev structure
  * Context: single threaded during gadget setup
  *
  * Returns zero on success, else negative errno.
diff --git a/drivers/usb/gadget/f_subset.c b/drivers/usb/gadget/f_subset.c
index 185d6f5..7be04b3 100644
--- a/drivers/usb/gadget/f_subset.c
+++ b/drivers/usb/gadget/f_subset.c
@@ -373,6 +373,7 @@ geth_unbind(struct usb_configuration *c, struct 
usb_function *f)
  * @c: the configuration to support the network link
  * @ethaddr: a buffer in which the ethernet address of the host side
  * side of the link was recorded
+ * @dev: eth_dev structure
  * Context: single threaded during gadget setup
  *
  * Returns zero on success, else negative errno.

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[PATCH][USB GADGET] Correct typo supperspeed to superspeed.

[Robert P. J. Day]

Tidy up kernel-doc content for USB GADGET. No functional change.

Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca

---

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c454a88..f1b0dca 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -563,9 +563,8 @@ static inline int gadget_is_dualspeed(struct usb_gadget *g)
 }

 /**
- * gadget_is_superspeed() - return true if the hardware handles
- * supperspeed
- * @g: controller that might support supper speed
+ * gadget_is_superspeed() - return true if the hardware handles superspeed
+ * @g: controller that might support superspeed
  */
 static inline int gadget_is_superspeed(struct usb_gadget *g)
 {

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

--
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] ARM: OMAP-USB: Fix possible memory leak

[Alexander Shiyan]

Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
 arch/arm/mach-omap2/usb-host.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index aa27d7f..8d17a0d 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
char *dev_supply,
supplies-dev_name = dev_id;
 
reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
-   if (!reg_data)
+   if (!reg_data) {
+   kfree(supplies);
return -ENOMEM;
+   }
 
reg_data-constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
reg_data-consumer_supplies = supplies;
@@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
char *dev_supply,
 
config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
GFP_KERNEL);
-   if (!config)
+   if (!config) {
+   kfree(supplies);
+   kfree(reg_data);
return -ENOMEM;
+   }
 
config-supply_name = name;
config-gpio = gpio;
@@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
char *dev_supply,
 
/* create a regulator device */
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
-   if (!pdev)
+   if (!pdev) {
+   kfree(supplies);
+   kfree(reg_data);
+   kfree(config);
return -ENOMEM;
+   }
 
pdev-id = PLATFORM_DEVID_AUTO;
pdev-name = reg_name;
pdev-dev.platform_data = config;
 
ret = platform_device_register(pdev);
-   if (ret)
+   if (ret) {
pr_err(%s: Failed registering regulator %s for %s\n,
__func__, name, dev_id);
+   kfree(supplies);
+   kfree(reg_data);
+   kfree(config);
+   }
 
return ret;
 }
-- 
1.8.1.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 1/2] staging: dwc2: when dma is disabled, clear dev-dma_mask

[Matthijs Kooijman]

Hi Paul ( Greg),

On Thu, May 02, 2013 at 01:23:42AM +, Paul Zimmerman wrote:
  From: Paul Zimmerman
  Sent: Monday, April 29, 2013 6:27 PM
  
   From: Matthijs Kooijman [mailto:matth...@stdin.nl]
   Sent: Monday, April 29, 2013 7:33 AM
  
 } else {
   - dma_set_mask(hsotg-dev, 0);
   + hsotg-dev-dma_mask = NULL;
 dma_set_coherent_mask(hsotg-dev, 0);
 }
  
  I see a problem after applying this patch. If I insert the driver
  modules with dwc2_module_params.dma_enable = 0, remove the modules,
  then insert them again with dwc2_module_params.dma_enable = 1, then
  the DMA does not get enabled. I see the message dma_mask not set,
  disabling DMA from the other patch. So setting the
  hsotg-dev-dma_mask pointer to NULL seems to be irreversible.
  
  It seems like this shouldn't happen. I think hsotg-dev should get
  deleted when the module is removed, and recreated when it is inserted
  again. But maybe I just don't understand the device model.
 
 Can you try the additional patch below on top of your original patch?
 This fixes the problem for me with the PCI driver, but I want to make
 sure it works for the platform device as well.

I tried your patch, but to I don't quite like it. It seems ugly to me to
have to save the dma_mask value and restore it on the module unload.

I'd say this points out that perhaps modifying the dma_mask variable
isn't the right way to tell the usb core that we don't want to be using
DMA. Instead, it seems the below alternative patch is more elegant by
simply setting hcd-self.uses_dma to 0 if we're not using dma (even
though a DMA mask is set up). If the USB core would be using the
uses_dma value during initialization already, this could create a
problem, but currently it is only used when submitting an urb, so this
should be ok.

Greg, is it ok for a HCD to modify hcd-self.uses_dma like this?

Gr.

Matthijs

diff --git a/drivers/staging/dwc2/hcd.c b/drivers/staging/dwc2/hcd.c
index d9a2055..18a91de 100644
--- a/drivers/staging/dwc2/hcd.c
+++ b/drivers/staging/dwc2/hcd.c
@@ -2766,6 +2766,9 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
if (!hcd)
goto error1;
 
+   if (hsotg-core_params-dma_enable = 0)
+   hcd-self.uses_dma = 0;
+
hcd-has_tt = 1;
 
spin_lock_init(hsotg-lock);

--
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] ARM: OMAP-USB: Fix possible memory leak

[Nishanth Menon]

On 20:03-20130502, Alexander Shiyan wrote:
 
 Signed-off-by: Alexander Shiyan shc_w...@mail.ru
 ---
  arch/arm/mach-omap2/usb-host.c | 21 +
  1 file changed, 17 insertions(+), 4 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
 index aa27d7f..8d17a0d 100644
 --- a/arch/arm/mach-omap2/usb-host.c
 +++ b/arch/arm/mach-omap2/usb-host.c
 @@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
 char *dev_supply,
   supplies-dev_name = dev_id;
  
   reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
 - if (!reg_data)
 + if (!reg_data) {
 + kfree(supplies);
   return -ENOMEM;
 + }
  
   reg_data-constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
   reg_data-consumer_supplies = supplies;
 @@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
 char *dev_supply,
  
   config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
   GFP_KERNEL);
 - if (!config)
 + if (!config) {
 + kfree(supplies);
 + kfree(reg_data);
   return -ENOMEM;
 + }
  
   config-supply_name = name;
   config-gpio = gpio;
 @@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char 
 *dev_id, char *dev_supply,
  
   /* create a regulator device */
   pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
 - if (!pdev)
 + if (!pdev) {
 + kfree(supplies);
 + kfree(reg_data);
 + kfree(config);
   return -ENOMEM;
 + }
  
   pdev-id = PLATFORM_DEVID_AUTO;
   pdev-name = reg_name;
   pdev-dev.platform_data = config;
  
   ret = platform_device_register(pdev);
 - if (ret)
 + if (ret) {
   pr_err(%s: Failed registering regulator %s for %s\n,
   __func__, name, dev_id);
 + kfree(supplies);
 + kfree(reg_data);
 + kfree(config);
 + }

Might be better to switch to devm_XXX managed functions?
  
   return ret;
  }
 -- 
 1.8.1.5
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Regards,
Nishanth Menon
--
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: USB 3 to SATA ASM1042 dies under I/O load

[Martin Mokrejs]

Hi Stefan,
  I can only tell you that I had success with ASM1051 on the drive side
(SilverStone Treasure TS04) against both NEC uPD720200 (rev. 3) controller
and TI controller on the computer side. But ASM1051 does not propagate
S.M.A.R.T. values back from the drive.
  Once I had a bad firmware in ASM2105 in SilverStone Treasure TS04B.
That one I returned.
  I am happy with 4 pcs of Manhattan Superspeed USB to SATA adapter
giving me each 150MB/s, working with 2.7TiB Seagate SV35 and Barracuda drives
despite the fact the retail box claims the adapter support 48-bit addressing
up to 2TB drives only. gdisk shows the drives report 512B sectors while should
be physically 4kB sector drives. I am handling files of up to 250GB
and shuffling data between 5 such drives. When things work on my laptop
through one 2-port XHCI TexasInstruments-based controller, 1 eSATA port of
SandyBridge and 2-port XHCI NEC-based express card I can read/write between
all the drives (including writes to /dev/null) to total 2.5Gbps as shown by
vmstat. From each single SATAIII drive I can get stably 140-150MBps with 5
drives I could not saturate the system throughput (well, just reads and writes
to /dev/null as I said).

  A chase for working USB3 to SATA converters might take you to
http://forums.whirlpool.net.au/archive/1558885 and from there to
https://docs.google.com/spreadsheet/ccc?key=0AqniL4H-VGJSdEJPZTNjbFlEWlFEbU5adnFYRFRxeFE

  I have added some items to the table and also am attaching my old benchmarks.



  Maybe check if your express card works quickly enough? Maybe play with tehse
kernel command line pci=option,option2,... parameters (from 
kernel-parameters.txt
file):


pcie_bus_tune_off   Disable PCIe MPS (Max Payload Size)
tuning and use the BIOS-configured MPS defaults.
pcie_bus_safe   Set every device's MPS to the largest value
supported by all devices below the root complex.
pcie_bus_perf   Set device MPS to the largest allowable MPS
based on its parent bus. Also set MRRS (Max
Read Request Size) to the largest supported
value (no larger than the MPS that the device
or bus can support) for best performance.
pcie_bus_peer2peer  Set every device's MPS to 128B, which
every device is guaranteed to support. This
configuration allows peer-to-peer DMA between
any pair of devices, possibly at the cost of
reduced performance.  This also guarantees
that hot-added devices will work.

Martin

Stephan Diestelhorst wrote:
 Hi,
   I am using a salvaged (from an external Toshiba spinning disk) SATA
 - USB 3 adaptor with a VLI701-04 chip behind a ASMedia Technology Inc.
 ASM1042 SuperSpeed USB Host Controller (ExpressCard slot).
 
 I have attached a Samsung sereis 840 SSD and whenever I dd some data
 onto the disk, the drive disconnects and then reconnects as a
 different /dev/sd*.  Running 3.9 kernel (also happened with an older
 one).  I know that I should not reuse that controller for such high
 bandwidth operation, but maybe there is a tweak (using USB 2 works,
 but I was hoping to get more than 30 MB/s from this thing ;-) to make
 it work?
 
 Many thanks for pointers!
 
 Stephan
 
 lspci -vv
 
 05:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB
 Host Controller (prog-if 30 [XHCI])
 Subsystem: Device 174c:2104
 Physical Slot: 3
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
 ParErr- Stepping- SERR+ FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 19
 Region 0: Memory at f1f0 (64-bit, non-prefetchable) [size=32K]
 Capabilities: access denied
 Kernel driver in use: xhci_hcd
 
 lsusb -vv
 Bus 010 Device 005: ID 0480:a009 Toshiba America Info. Systems, Inc.
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   3.00
   bDeviceClass0 (Defined at Interface level)
   bDeviceSubClass 0
   bDeviceProtocol 0
   bMaxPacketSize0 9
   idVendor   0x0480 Toshiba America Info. Systems, Inc.
   idProduct  0xa009
   bcdDevice   37.10
   iManufacturer   1 TOSHIBA
   iProduct2 External USB 3.0
   iSerial 3 290118E5
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength   44
 bNumInterfaces  1
 bConfigurationValue 1
 iConfiguration  

Re[2]: [PATCH] ARM: OMAP-USB: Fix possible memory leak

[Alexander Shiyan]

 On 20:03-20130502, Alexander Shiyan wrote:
  
  Signed-off-by: Alexander Shiyan shc_w...@mail.ru
  ---
   arch/arm/mach-omap2/usb-host.c | 21 +
   1 file changed, 17 insertions(+), 4 deletions(-)
  
  diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
  index aa27d7f..8d17a0d 100644
  --- a/arch/arm/mach-omap2/usb-host.c
  +++ b/arch/arm/mach-omap2/usb-host.c
  @@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char 
  *dev_id, char *dev_supply,
  supplies-dev_name = dev_id;
   
  reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
  -   if (!reg_data)
  +   if (!reg_data) {
  +   kfree(supplies);
  return -ENOMEM;
  +   }
   
  reg_data-constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
  reg_data-consumer_supplies = supplies;
  @@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char 
  *dev_id, char *dev_supply,
   
  config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
  GFP_KERNEL);
  -   if (!config)
  +   if (!config) {
  +   kfree(supplies);
  +   kfree(reg_data);
  return -ENOMEM;
  +   }
   
  config-supply_name = name;
  config-gpio = gpio;
  @@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char 
  *dev_id, char *dev_supply,
   
  /* create a regulator device */
  pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
  -   if (!pdev)
  +   if (!pdev) {
  +   kfree(supplies);
  +   kfree(reg_data);
  +   kfree(config);
  return -ENOMEM;
  +   }
   
  pdev-id = PLATFORM_DEVID_AUTO;
  pdev-name = reg_name;
  pdev-dev.platform_data = config;
   
  ret = platform_device_register(pdev);
  -   if (ret)
  +   if (ret) {
  pr_err(%s: Failed registering regulator %s for %s\n,
  __func__, name, dev_id);
  +   kfree(supplies);
  +   kfree(reg_data);
  +   kfree(config);
  +   }
 
 Might be better to switch to devm_XXX managed functions?

If anyone can rewrite driver to use devm_xx, it would have been better.
I'm not going to redo the patch yet, let it be so, I just showed a point
for OMAP-developers.
Thanks.

---

Re: [PATCH] ARM: OMAP-USB: Fix possible memory leak

[Felipe Balbi]

Hi,

On Thu, May 02, 2013 at 08:28:44PM +0400, Alexander Shiyan wrote:
  On 20:03-20130502, Alexander Shiyan wrote:
   
   Signed-off-by: Alexander Shiyan shc_w...@mail.ru
   ---
arch/arm/mach-omap2/usb-host.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
   
   diff --git a/arch/arm/mach-omap2/usb-host.c 
   b/arch/arm/mach-omap2/usb-host.c
   index aa27d7f..8d17a0d 100644
   --- a/arch/arm/mach-omap2/usb-host.c
   +++ b/arch/arm/mach-omap2/usb-host.c
   @@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char 
   *dev_id, char *dev_supply,
 supplies-dev_name = dev_id;

 reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
   - if (!reg_data)
   + if (!reg_data) {
   + kfree(supplies);
 return -ENOMEM;
   + }

 reg_data-constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
 reg_data-consumer_supplies = supplies;
   @@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char 
   *dev_id, char *dev_supply,

 config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
 GFP_KERNEL);
   - if (!config)
   + if (!config) {
   + kfree(supplies);
   + kfree(reg_data);
 return -ENOMEM;
   + }

 config-supply_name = name;
 config-gpio = gpio;
   @@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char 
   *dev_id, char *dev_supply,

 /* create a regulator device */
 pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
   - if (!pdev)
   + if (!pdev) {
   + kfree(supplies);
   + kfree(reg_data);
   + kfree(config);
 return -ENOMEM;
   + }

 pdev-id = PLATFORM_DEVID_AUTO;
 pdev-name = reg_name;
 pdev-dev.platform_data = config;

 ret = platform_device_register(pdev);
   - if (ret)
   + if (ret) {
 pr_err(%s: Failed registering regulator %s for %s\n,
 __func__, name, dev_id);
   + kfree(supplies);
   + kfree(reg_data);
   + kfree(config);
   + }
  
  Might be better to switch to devm_XXX managed functions?

I don't think it makes sense since the platform_device hasn't been
registered yet.

Still, patch can be improved with proper goto labels instead of
sprinkling different kfree() calls in every single error branch.

 If anyone can rewrite driver to use devm_xx, it would have been better.
 I'm not going to redo the patch yet, let it be so, I just showed a point
 for OMAP-developers.

fair enough.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 net-next] net/usb: new driver for RTL8152

[David Miller]

From: Greg KH gre...@linuxfoundation.org
Date: Thu, 2 May 2013 07:12:39 -0700

 On Fri, May 03, 2013 at 03:48:07AM +0800, Hayes Wang wrote:
 +#define PATENTS This product is covered by one or more of the 
  \
 +following patents:\n \
 +\t\tUS6,570,884, US6,115,776, and US6,327,625.\n
 
 Interesting, you are aware of the issues involved with patents and GPLv2
 code, right?  Do you have a pointer to the GPLv2 patent release that is
 now required, or does your company now release all of the needed rights
 for these patents to be able to be used by everyone?

There is no way I'm applying a patch that adds notices like this to the
kernel log.
--
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

Sans Digital TR4U+B USB3 controller not working in kernel 3.8, 3.9

[Aaron RIekenberg]

I have an AMD E-350 PC with this USB3 controller on the motherboard

03:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller
(rev 04)

I also have a Sans Digital TR4U+B 4-disk enclosure that I'm attempting to
connect to the USB3 ports.


Running Ubuntu 12.04.2 with kernel 3.5.0-27-generic things work fine.


I'm trying to upgrade to Ubuntu 13.04, which by default has kernel
3.8.0-19-generic.  With this kernel I get a Timeout while waiting for
address device command when I plug in the Sans Digital device, and no
drives are detected.  I'm not using any sort of USB hub - I'm plugging the
device directly into the onboard USB 3 port.


Thinking perhaps this is a bug in 3.8 or in Ubuntu's version of it, I
installed a vanilla 3.9 kernel.  With this kernel I also get the same
behavior as with 3.8.0-19-generic.  See below for output from dmesg.


Is this a known issue?  Is there more data I can gather to help resolve this?


Output from dmesg when Sans Digital TR4U+B is connected with vanilla 3.9 kernel:

[   63.647143] usb 8-2: new high-speed USB device number 2 using xhci_hcd
[   68.647310] xhci_hcd :03:00.0: Timeout while waiting for address
device command
[   80.940800] xhci_hcd :03:00.0: Stopped the command ring failed, maybe
the host is dead
[   80.984622] xhci_hcd :03:00.0: Host not halted after 16000 microseconds.
[   80.984626] xhci_hcd :03:00.0: Abort command ring failed
[   80.989475] xhci_hcd :03:00.0: HC died; cleaning up
[   80.991692] [sched_delayed] sched: RT throttling activated
[   86.195900] xhci_hcd :03:00.0: Timeout while waiting for address
device command
[   86.195918] xhci_hcd :03:00.0: Abort the command ring, but the xHCI
is dead.
[   86.399901] usb 8-2: device not accepting address 2, error -108
[   86.406529] hub 8-0:1.0: cannot disable port 2 (err = -19)
[   91.412079] xhci_hcd :03:00.0: Timeout while waiting for a slot
[   91.412096] xhci_hcd :03:00.0: Abort the command ring, but the xHCI
is dead.
[   91.412131] hub 8-0:1.0: cannot reset port 2 (err = -19)
[   91.418283] hub 8-0:1.0: cannot disable port 2 (err = -19)
[   91.424422] xHCI xhci_free_dev called with unaddressed device
[   96.424261] xhci_hcd :03:00.0: Timeout while waiting for a slot
[   96.424277] xhci_hcd :03:00.0: Abort the command ring, but the xHCI
is dead.
[   96.424310] hub 8-0:1.0: cannot reset port 2 (err = -19)
[   96.430494] hub 8-0:1.0: cannot disable port 2 (err = -19)
[   96.436569] xHCI xhci_free_dev called with unaddressed device
[  101.436420] xhci_hcd :03:00.0: Timeout while waiting for a slot
[  101.436435] xhci_hcd :03:00.0: Abort the command ring, but the xHCI
is dead.
[  101.436468] hub 8-0:1.0: cannot reset port 2 (err = -19)
[  101.442532] hub 8-0:1.0: cannot disable port 2 (err = -19)
[  101.448565] xHCI xhci_free_dev called with unaddressed device
[  101.448582] hub 8-0:1.0: unable to enumerate USB device on port 2
[  101.451624] hub 8-0:1.0: cannot disable port 2 (err = -19)


--
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: use devm_ioremap_resource()

[Paul Zimmerman]

 From: Matthijs Kooijman [mailto:matth...@stdin.nl]
 Sent: Thursday, May 02, 2013 4:22 AM
 
 On Thu, May 02, 2013 at 01:23:17PM +0200, Laurent Navet wrote:
  Replace a call to deprecated devm_request_and_ioremap by 
  devm_ioremap_resource.
 
  Found with coccicheck and this semantic patch:
   scripts/coccinelle/api/devm_request_and_ioremap.cocci.
 
  Signed-off-by: Laurent Navet laurent.na...@gmail.com
  ---
   drivers/staging/dwc2/pci.c |6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)
 
 Patch looks good, I had a bit-for-bit identical patch in my queue here
 as well :-)
 
 Reviewed-by: Matthijs Kooijman matth...@stdin.nl

Acked-by: Paul Zimmerman pa...@synopsys.com

--
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/1] usb: gadget/uvc: Add support to allocate UVC payload and header as SG elements

[Bhupesh SHARMA]

Hi Laurent,

On 5/1/2013 3:53 AM, Laurent Pinchart wrote:

Hi Bhupesh,

On Wednesday 01 May 2013 01:08:23 Bhupesh SHARMA wrote:

On 4/29/2013 8:08 PM, Laurent Pinchart wrote:

On Wednesday 17 April 2013 09:44:25 Bhupesh Sharma wrote:

This patch adds the support in UVC webcam gadget to allocate UVC header
and payload as Scatter-Gather elements which can be used on a SG-capable
UDC controller.

A module parameter has been introduced for the same. One can set the
module parameter 'sg_mode' to 1 to turn on this feature (by default this
feature is turned-off).

This ensures that we don't require a memcpy from CPU side to append UVC
header in front of the UVC payload atleast for SG capable UDC contollers.

Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
Note that to ease review and integration of this patch, I have rebased it
on the following patch already circulated for review last week:

[PATCH 1/1] usb: gadget/uvc: Add support for Bulk endpoint to be used as

   Video Streaming ep

http://www.mail-archive.com/linux-usb@vger.kernel.org/msg19546.html

The above patch was rebased on Laurent's UVC gadget git tree available
here (head uvc-gadget):
git://linuxtv.org/pinchartl/uvcvideo.git

This will allow the patches to be pulled into Felipe's repo in one go
after review and any subsequent rework (if required).

   drivers/usb/gadget/f_uvc.c |8 +++
   drivers/usb/gadget/uvc.h   |2 +
   drivers/usb/gadget/uvc_video.c |  113 -
   3 files changed, 109 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index e5953eb..ccf0253 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -50,6 +50,11 @@ module_param(bulk_streaming_ep, bool,
S_IRUGO|S_IWUSR);

   MODULE_PARM_DESC(bulk_streaming_ep, 0 (Use ISOC video streaming ep) /
   

1 (Use BULK video streaming ep));

+static bool sg_mode;
+module_param(sg_mode, bool, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(sg_mode, 0 (Don't use SG feature) / 
+   1 (Use scatterlist for SG-capable controllers));
+


Can't this be queried automatically from the UDC at runtime ?


Yes, it can be. But I believe its better to still provide a module
parameter to the UVC webcam module user as some UDCs may have flaky SG
implementations in H/W and then the user will not be able to use the
UVC gadget without using the SG feature of SG-capable UDCs.

I believe in worst-case its better to fall-back on memcpy from CPU if
the SG features in the UDC are not yet properly supported.


In that case could we default to use SG with UDCs that support it, and have a
module parameter to disable SG ?



Ok. Let me implement something on these lines and I will soon send out a V2.

Regards,
Bhupesh
--
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

Starting frames for isochronous URBs in xhci-hcd

[Alan Stern]

Sarah:

xhci_queue_isoc_tx_prepare() has a comment saying Always assume 
URB_ISO_ASAP set.  I'd like to see about fixing this, but I don't know 
where to look.  It doesn't seem as though any significant computations 
are done for the starting frame; the value always gets set to the 
current (micro)frame number.  In particular, the driver doesn't use 
HCS_IST.

Does the hardware expose the scheduling information for isochronous 
endpoints?  I couldn't find any mention of this in the xHCI spec.

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: USB 3 to SATA ASM1042 dies under I/O load

[Stephan Diestelhorst]

Martin,
On 2 May 2013 18:26, Martin Mokrejs mmokr...@fold.natur.cuni.cz wrote:
   I can only tell you that I had success with ASM1051 on the drive side
 (SilverStone Treasure TS04) against both NEC uPD720200 (rev. 3) controller
 and TI controller on the computer side. But ASM1051 does not propagate
 S.M.A.R.T. values back from the drive.
[...]
   I have added some items to the table and also am attaching my old 
 benchmarks.

Wow.  Thanks for all that material!

   Maybe check if your express card works quickly enough? Maybe play with tehse
 kernel command line pci=option,option2,... parameters (from 
 kernel-parameters.txt
 file):
[...]

Was going to try that, when I just had a revelation: electricity.
Turns out that my ExpressCard USB 3 adapter does not provide enough
power to fuel the SSD on full write load.  Attaching that extra cable
that pulls juice from one of the regular USB ports made it work.

So thanks for all that material, but this one was an oversight on my part.

Thanks and sorry for the noise!

Stephan

PS: I faintly remember that I saw a USB device is using too much
power warning on Windows.  Is there a programmatic way to detect that
and inform the user?  Or is in this case the automatic switching off
enough of a sign?  (I am quite familiar with the clicking of spinning
disks that do not get enough power, but these SSDs are surprisingly
non-verbose in that regard :)
--
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/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Vladimir Zapolskiy]

This change removes calls of uvc_function_connect()/uvc_function_disconnect()
functions from open()/close() syscalls.

This is a bugfix in g_webcam module, in some test scenarios (e.g. UDC in
suspend mode or OTG in host mode) straightforward control of D+ pull-up
might lead to system's misbehaviour.

Most probably a root cause of some reported system freezes on g_webcam
module probe [1] is related to the issue described above, for instance
if udev's v4l_id helper opens a new V4L2 device node to query device
capabilities.

Alternatively to this chage checks may be added to UDC driver's .pullup
functions, however presence of pullup controls from uvcvideo seems to
be redundant.

[1] http://kerneltrap.org/mailarchive/linux-usb/2010/12/29/6268355/thread

Vladimir Zapolskiy (2):
  usb: gadget/uvc: remove connect/disconnect calls on open/release
  usb: gadget/uvc: remove connection/disconnection routines

 drivers/usb/gadget/f_uvc.c|   24 
 drivers/usb/gadget/uvc.h  |3 ---
 drivers/usb/gadget/uvc_v4l2.c |5 -
 3 files changed, 32 deletions(-)

-- 
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/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Vladimir Zapolskiy]

This change removes redundant calls to uvc_function_connect() and
uvc_function_disconnect() on V4L2 device node open and release.

These two functions attemp to control pull-up on D+ line directly, however
such an action should be performed by an UDC iteself, and within the gadget
there is no information about current mode of the controller.

The UDC may be in suspended state, or an OTG controller may be in host mode,
therefore it seems better not to try to forcibly pull-up D+ line on open()
syscall.

Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/usb/gadget/uvc_v4l2.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
index ad48e81..e2b66e1 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
handle-device = uvc-video;
file-private_data = handle-vfh;
 
-   uvc_function_connect(uvc);
return 0;
 }
 
 static int
 uvc_v4l2_release(struct file *file)
 {
-   struct video_device *vdev = video_devdata(file);
-   struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_file_handle *handle = to_uvc_file_handle(file-private_data);
struct uvc_video *video = handle-device;
 
-   uvc_function_disconnect(uvc);
-
uvc_video_enable(video, 0);
uvc_free_buffers(video-queue);
 
-- 
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 2/2] usb: gadget/uvc: remove connection/disconnection routines

[Vladimir Zapolskiy]

The uvc_function_connect() and uvc_function_disconnect() functions are to be
removed, because there is no users of them.

Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/usb/gadget/f_uvc.c |   24 
 drivers/usb/gadget/uvc.h   |3 ---
 2 files changed, 27 deletions(-)

diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 38dcedd..bea22d1 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -375,30 +375,6 @@ uvc_function_disable(struct usb_function *f)
 }
 
 /* --
- * Connection / disconnection
- */
-
-void
-uvc_function_connect(struct uvc_device *uvc)
-{
-   struct usb_composite_dev *cdev = uvc-func.config-cdev;
-   int ret;
-
-   if ((ret = usb_function_activate(uvc-func))  0)
-   INFO(cdev, UVC connect failed with %d\n, ret);
-}
-
-void
-uvc_function_disconnect(struct uvc_device *uvc)
-{
-   struct usb_composite_dev *cdev = uvc-func.config-cdev;
-   int ret;
-
-   if ((ret = usb_function_deactivate(uvc-func))  0)
-   INFO(cdev, UVC disconnect failed with %d\n, ret);
-}
-
-/* --
  * USB probe and disconnect
  */
 
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 817e9e1..87d69c0 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -191,9 +191,6 @@ struct uvc_file_handle
 extern void uvc_function_setup_continue(struct uvc_device *uvc);
 extern void uvc_endpoint_stream(struct uvc_device *dev);
 
-extern void uvc_function_connect(struct uvc_device *uvc);
-extern void uvc_function_disconnect(struct uvc_device *uvc);
-
 #endif /* __KERNEL__ */
 
 #endif /* _UVC_GADGET_H_ */
-- 
1.7.10.4

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

Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Laurent Pinchart]

Hi Vladimir,

Thank you for the patch.

On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
 This change removes redundant calls to uvc_function_connect() and
 uvc_function_disconnect() on V4L2 device node open and release.
 
 These two functions attemp to control pull-up on D+ line directly, however
 such an action should be performed by an UDC iteself, and within the gadget
 there is no information about current mode of the controller.
 
 The UDC may be in suspended state, or an OTG controller may be in host mode,
 therefore it seems better not to try to forcibly pull-up D+ line on open()
 syscall.

OK, but we then need to fix the problem properly. The UVC gadget must not 
appear connected until an application opens the corresponding device. 
Likewise, it must disconnect from the bus when the application closes the 
device. How can this be guaranteed properly ?

 Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/usb/gadget/uvc_v4l2.c |5 -
  1 file changed, 5 deletions(-)
 
 diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
 index ad48e81..e2b66e1 100644
 --- a/drivers/usb/gadget/uvc_v4l2.c
 +++ b/drivers/usb/gadget/uvc_v4l2.c
 @@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
   handle-device = uvc-video;
   file-private_data = handle-vfh;
 
 - uvc_function_connect(uvc);
   return 0;
  }
 
  static int
  uvc_v4l2_release(struct file *file)
  {
 - struct video_device *vdev = video_devdata(file);
 - struct uvc_device *uvc = video_get_drvdata(vdev);
   struct uvc_file_handle *handle = to_uvc_file_handle(file-private_data);
   struct uvc_video *video = handle-device;
 
 - uvc_function_disconnect(uvc);
 -
   uvc_video_enable(video, 0);
   uvc_free_buffers(video-queue);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Michael Grzeschik]

On Fri, May 03, 2013 at 12:18:21AM +0200, Laurent Pinchart wrote:
 Hi Vladimir,
 
 Thank you for the patch.
 
 On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
  This change removes redundant calls to uvc_function_connect() and
  uvc_function_disconnect() on V4L2 device node open and release.
  
  These two functions attemp to control pull-up on D+ line directly, however
  such an action should be performed by an UDC iteself, and within the gadget
  there is no information about current mode of the controller.
  
  The UDC may be in suspended state, or an OTG controller may be in host mode,
  therefore it seems better not to try to forcibly pull-up D+ line on open()
  syscall.
 
 OK, but we then need to fix the problem properly. The UVC gadget must not 
 appear connected until an application opens the corresponding device. 
 Likewise, it must disconnect from the bus when the application closes the 
 device. How can this be guaranteed properly ?

I think a lot of the userspace Testapplication [¹] itself needs to
be moved into the kernel. I.e. a lot of the function uvc_events_process
needs to be handled in kernelspace. This way, the gadget would not even
depent on an userspace application to be ready for.

Thanks,
Michael

[¹]
http://git.ideasonboard.org/uvc-gadget.git



-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Vladimir Zapolskiy]

Hi Laurent,

On 05/03/13 01:18, Laurent Pinchart wrote:

Hi Vladimir,

Thank you for the patch.

On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:

This change removes redundant calls to uvc_function_connect() and
uvc_function_disconnect() on V4L2 device node open and release.

These two functions attemp to control pull-up on D+ line directly, however
such an action should be performed by an UDC iteself, and within the gadget
there is no information about current mode of the controller.

The UDC may be in suspended state, or an OTG controller may be in host mode,
therefore it seems better not to try to forcibly pull-up D+ line on open()
syscall.


OK, but we then need to fix the problem properly. The UVC gadget must not
appear connected until an application opens the corresponding device.
Likewise, it must disconnect from the bus when the application closes the
device. How can this be guaranteed properly ?


For better understanding of the issue, could you explain briefly why do you
prefer to have the gadget not connected to the bus, if device node is not
opened?


Signed-off-by: Vladimir Zapolskiyvladimir_zapols...@mentor.com
Cc: Laurent Pinchartlaurent.pinch...@ideasonboard.com
---
  drivers/usb/gadget/uvc_v4l2.c |5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
index ad48e81..e2b66e1 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
handle-device =uvc-video;
file-private_data =handle-vfh;

-   uvc_function_connect(uvc);
return 0;
  }

  static int
  uvc_v4l2_release(struct file *file)
  {
-   struct video_device *vdev = video_devdata(file);
-   struct uvc_device *uvc = video_get_drvdata(vdev);
struct uvc_file_handle *handle = to_uvc_file_handle(file-private_data);
struct uvc_video *video = handle-device;

-   uvc_function_disconnect(uvc);
-
uvc_video_enable(video, 0);
uvc_free_buffers(video-queue);



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

Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Laurent Pinchart]

Hi Vladimir,

On Friday 03 May 2013 02:00:29 Vladimir Zapolskiy wrote:
 On 05/03/13 01:18, Laurent Pinchart wrote:
  On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
  This change removes redundant calls to uvc_function_connect() and
  uvc_function_disconnect() on V4L2 device node open and release.
  
  These two functions attemp to control pull-up on D+ line directly,
  however such an action should be performed by an UDC iteself, and within
  the gadget there is no information about current mode of the controller.
  
  The UDC may be in suspended state, or an OTG controller may be in host
  mode, therefore it seems better not to try to forcibly pull-up D+ line
  on open() syscall.
  
  OK, but we then need to fix the problem properly. The UVC gadget must not
  appear connected until an application opens the corresponding device.
  Likewise, it must disconnect from the bus when the application closes the
  device. How can this be guaranteed properly ?
 
 For better understanding of the issue, could you explain briefly why do you
 prefer to have the gadget not connected to the bus, if device node is not
 opened?

As soon as the gadget will connect to the bus the device will be enumerated by 
the host and bound to a host driver that will query the device using UVC-
specific requests. The userspace application is involved in replying to those 
requests, so it needs to be bound to the device on the gadget side or the 
initialization process on the host side will fail.

  Signed-off-by: Vladimir Zapolskiyvladimir_zapols...@mentor.com
  Cc: Laurent Pinchartlaurent.pinch...@ideasonboard.com
  ---
  
drivers/usb/gadget/uvc_v4l2.c |5 -
1 file changed, 5 deletions(-)
  
  diff --git a/drivers/usb/gadget/uvc_v4l2.c
  b/drivers/usb/gadget/uvc_v4l2.c
  index ad48e81..e2b66e1 100644
  --- a/drivers/usb/gadget/uvc_v4l2.c
  +++ b/drivers/usb/gadget/uvc_v4l2.c
  @@ -132,20 +132,15 @@ uvc_v4l2_open(struct file *file)
  
 handle-device =uvc-video;
 file-private_data =handle-vfh;
  
  -  uvc_function_connect(uvc);
  
 return 0;

}

static int
uvc_v4l2_release(struct file *file)
{
  
  -  struct video_device *vdev = video_devdata(file);
  -  struct uvc_device *uvc = video_get_drvdata(vdev);
  
 struct uvc_file_handle *handle =
 to_uvc_file_handle(file-private_data);
 struct uvc_video *video = handle-device;
  
  -  uvc_function_disconnect(uvc);
  -
  
 uvc_video_enable(video, 0);
 uvc_free_buffers(video-queue);
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] ARM: OMAP-USB: Fix possible memory leak

[Russell King - ARM Linux]

On Thu, May 02, 2013 at 07:40:58PM +0300, Felipe Balbi wrote:
 Hi,
 
 On Thu, May 02, 2013 at 08:28:44PM +0400, Alexander Shiyan wrote:
   On 20:03-20130502, Alexander Shiyan wrote:

Signed-off-by: Alexander Shiyan shc_w...@mail.ru
---
 arch/arm/mach-omap2/usb-host.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/usb-host.c 
b/arch/arm/mach-omap2/usb-host.c
index aa27d7f..8d17a0d 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -570,8 +570,10 @@ static int usbhs_add_regulator(char *name, char 
*dev_id, char *dev_supply,
supplies-dev_name = dev_id;
 
reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
-   if (!reg_data)
+   if (!reg_data) {
+   kfree(supplies);
return -ENOMEM;
+   }
 
reg_data-constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
reg_data-consumer_supplies = supplies;
@@ -579,8 +581,11 @@ static int usbhs_add_regulator(char *name, char 
*dev_id, char *dev_supply,
 
config = kmemdup(hsusb_reg_config, sizeof(hsusb_reg_config),
GFP_KERNEL);
-   if (!config)
+   if (!config) {
+   kfree(supplies);
+   kfree(reg_data);
return -ENOMEM;
+   }
 
config-supply_name = name;
config-gpio = gpio;
@@ -589,17 +594,25 @@ static int usbhs_add_regulator(char *name, char 
*dev_id, char *dev_supply,
 
/* create a regulator device */
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
-   if (!pdev)
+   if (!pdev) {
+   kfree(supplies);
+   kfree(reg_data);
+   kfree(config);
return -ENOMEM;
+   }
 
pdev-id = PLATFORM_DEVID_AUTO;
pdev-name = reg_name;
pdev-dev.platform_data = config;
 
ret = platform_device_register(pdev);
-   if (ret)
+   if (ret) {
pr_err(%s: Failed registering regulator %s for %s\n,
__func__, name, dev_id);
+   kfree(supplies);
+   kfree(reg_data);
+   kfree(config);
+   }
   
   Might be better to switch to devm_XXX managed functions?
 
 I don't think it makes sense since the platform_device hasn't been
 registered yet.
 
 Still, patch can be improved with proper goto labels instead of
 sprinkling different kfree() calls in every single error branch.
 
  If anyone can rewrite driver to use devm_xx, it would have been better.
  I'm not going to redo the patch yet, let it be so, I just showed a point
  for OMAP-developers.
 
 fair enough.

Well, as long as this crap violates the driver model by using kfree() on
a device...  Devices are refcounted and must only be freed when the
refcount drops to zero.

This is exactly why we have platform_device_alloc(),
platform_device_register_full() and friends - so that people don't have to
fsck around with kzalloc themselves and get it wrong like the above does.

Would you like me to pass your details to gregkh for another one of his
public humilation exercises over basic kernel programming stuff? :)
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] usb: gadget/uvc: remove connect/disconnect calls on open/release

[Laurent Pinchart]

Hi Michael,

On Friday 03 May 2013 00:34:40 Michael Grzeschik wrote:
 On Fri, May 03, 2013 at 12:18:21AM +0200, Laurent Pinchart wrote:
  On Friday 03 May 2013 01:13:48 Vladimir Zapolskiy wrote:
   This change removes redundant calls to uvc_function_connect() and
   uvc_function_disconnect() on V4L2 device node open and release.
   
   These two functions attemp to control pull-up on D+ line directly,
   however such an action should be performed by an UDC iteself, and within
   the gadget there is no information about current mode of the controller.
   
   The UDC may be in suspended state, or an OTG controller may be in host
   mode, therefore it seems better not to try to forcibly pull-up D+ line
   on open() syscall.
  
  OK, but we then need to fix the problem properly. The UVC gadget must not
  appear connected until an application opens the corresponding device.
  Likewise, it must disconnect from the bus when the application closes the
  device. How can this be guaranteed properly ?
 
 I think a lot of the userspace Testapplication [¹] itself needs to
 be moved into the kernel. I.e. a lot of the function uvc_events_process
 needs to be handled in kernelspace. This way, the gadget would not even
 depent on an userspace application to be ready for.

I'm open to suggestions :-) What features of the userspace application do you 
think could (and should) be moved to kernelspace ? Many of them are highly 
application-specific.

-- 
Regards,

Laurent Pinchart

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

Re: Starting frames for isochronous URBs in xhci-hcd

[Sarah Sharp]

On Thu, May 02, 2013 at 04:01:32PM -0400, Alan Stern wrote:
 Sarah:
 
 xhci_queue_isoc_tx_prepare() has a comment saying Always assume 
 URB_ISO_ASAP set.  I'd like to see about fixing this, but I don't know 
 where to look.  It doesn't seem as though any significant computations 
 are done for the starting frame; the value always gets set to the 
 current (micro)frame number.  In particular, the driver doesn't use 
 HCS_IST.
 
 Does the hardware expose the scheduling information for isochronous 
 endpoints?  I couldn't find any mention of this in the xHCI spec.

That's a big can of worms.  I have a larger plan to fix some isochronous
ring performance issues, and I'd like to implement this change along
with that.

Can you wait for that change to go in?  AFAIK no in-kernel drivers don't
set URB_ISO_ASAP, so I didn't think this was an urgent change.

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

[PATCH v3 net-next] net/usb: new driver for RTL8152

[Hayes Wang]

Add new driver for supporting Realtek RTL8152 Based USB 2.0 Ethernet Adapters

Signed-off-by: Hayes Wang hayesw...@realtek.com
Cc: Realtek linux nic maintainers nic_s...@realtek.com
---
 drivers/net/usb/Kconfig |   11 +
 drivers/net/usb/Makefile|1 +
 drivers/net/usb/cdc_ether.c |   10 +
 drivers/net/usb/r8152.c | 1767 +++
 4 files changed, 1789 insertions(+)
 create mode 100644 drivers/net/usb/r8152.c

diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 7c769d8..287cc62 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -93,6 +93,17 @@ config USB_RTL8150
  To compile this driver as a module, choose M here: the
  module will be called rtl8150.
 
+config USB_RTL8152
+   tristate Realtek RTL8152 Based USB 2.0 Ethernet Adapters
+   select NET_CORE
+   select MII
+   help
+ This option adds support for Realtek RTL8152 based USB 2.0
+ 10/100 Ethernet adapters.
+
+ To compile this driver as a module, choose M here: the
+ module will be called r8152.
+
 config USB_USBNET
tristate Multi-purpose USB Networking Framework
select NET_CORE
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 119b06c..9ab5c9d 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_USB_CATC)  += catc.o
 obj-$(CONFIG_USB_KAWETH)   += kaweth.o
 obj-$(CONFIG_USB_PEGASUS)  += pegasus.o
 obj-$(CONFIG_USB_RTL8150)  += rtl8150.o
+obj-$(CONFIG_USB_RTL8152)  += r8152.o
 obj-$(CONFIG_USB_HSO)  += hso.o
 obj-$(CONFIG_USB_NET_AX8817X)  += asix.o
 asix-y := asix_devices.o asix_common.o ax88172a.o
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4ff71d6..24fbec2 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -479,6 +479,7 @@ static const struct driver_info wwan_info = {
 #define NOVATEL_VENDOR_ID  0x1410
 #define ZTE_VENDOR_ID  0x19D2
 #define DELL_VENDOR_ID 0x413C
+#define REALTEK_VENDOR_ID  0x0bda
 
 static const struct usb_device_id  products [] = {
 /*
@@ -619,6 +620,15 @@ static const struct usb_device_id  products [] = {
.driver_info = 0,
 },
 
+/* Realtek RTL8152 Based USB 2.0 Ethernet Adapters */
+#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
+{
+   USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
+   USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
+   .driver_info = 0,
+},
+#endif
+
 /*
  * WHITELIST!!!
  *
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
new file mode 100644
index 000..14e5198
--- /dev/null
+++ b/drivers/net/usb/r8152.c
@@ -0,0 +1,1767 @@
+/*
+ *  Copyright (c) 2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include linux/init.h
+#include linux/signal.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/version.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/mii.h
+#include linux/ethtool.h
+#include linux/usb.h
+#include linux/crc32.h
+#include linux/if_vlan.h
+#include linux/uaccess.h
+
+/* Version Information */
+#define DRIVER_VERSION v1.0.0 (2013/05/03)
+#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
+
+#define R8152_PHY_ID   32
+
+#define PLA_IDR0xc000
+#define PLA_RCR0xc010
+#define PLA_RMS0xc016
+#define PLA_RXFIFO_CTRL0   0xc0a0
+#define PLA_RXFIFO_CTRL1   0xc0a4
+#define PLA_RXFIFO_CTRL2   0xc0a8
+#define PLA_FMC0xc0b4
+#define PLA_CFG_WOL0xc0b6
+#define PLA_MAR0xcd00
+#define PAL_BDC_CR 0xd1a0
+#define PLA_LEDSEL 0xdd90
+#define PLA_LED_FEATURE0xdd92
+#define PLA_PHYAR  0xde00
+#define PLA_GPHY_INTR_IMR  0xe022
+#define PLA_EEE_CR 0xe040
+#define PLA_EEEP_CR0xe080
+#define PLA_MAC_PWR_CTRL   0xe0c0
+#define PLA_TCR0   0xe610
+#define PLA_TCR1   0xe612
+#define PLA_TXFIFO_CTRL0xe618
+#define PLA_RSTTELLY   0xe800
+#define PLA_CR 0xe813
+#define PLA_CRWECR 0xe81c
+#define PLA_CONFIG50xe822
+#define PLA_PHY_PWR0xe84c
+#define PLA_OOB_CTRL   0xe84f
+#define PLA_CPCR   0xe854
+#define PLA_MISC_0 0xe858
+#define PLA_MISC_1 0xe85a
+#define PLA_OCP_GPHY_BASE  0xe86c
+#define PLA_TELLYCNT   0xe890
+#define PLA_SFF_STS_7 

Re: [PATCH v3 net-next] net/usb: new driver for RTL8152

[Greg KH]

On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
 Add new driver for supporting Realtek RTL8152 Based USB 2.0 Ethernet Adapters
 
 Signed-off-by: Hayes Wang hayesw...@realtek.com
 Cc: Realtek linux nic maintainers nic_s...@realtek.com

You removed the wording I had questions about last time, does that mean
the previous wording was not correct, or that you no longer are
publicising the fact that this driver reads on some patents that you
own?

You also failed to answer my previous questions, why?

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

RE: [PATCH v3 net-next] net/usb: new driver for RTL8152

[hayeswang]

Greg KH [mailto:gre...@linuxfoundation.org] 
 Sent: Friday, May 03, 2013 10:33 AM
 To: Hayeswang
 Cc: oli...@neukum.org; net...@vger.kernel.org; 
 linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; nic_swsd
 Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
 
 On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
  Add new driver for supporting Realtek RTL8152 Based USB 2.0 
 Ethernet Adapters
  
  Signed-off-by: Hayes Wang hayesw...@realtek.com
  Cc: Realtek linux nic maintainers nic_s...@realtek.com
 
 You removed the wording I had questions about last time, does 
 that mean
 the previous wording was not correct, or that you no longer are
 publicising the fact that this driver reads on some patents that you
 own?
 
 You also failed to answer my previous questions, why?

That description is about the patent for the hw design, not for software. It
indicates that the design of the hw uses those patents from the other compnay. I
have no idea about how to deal with those patents. What should I do for sending
a patch? 

Best Regards,
Hayes

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

Re: [PATCH v3 net-next] net/usb: new driver for RTL8152

['Greg KH']

On Fri, May 03, 2013 at 11:11:47AM +0800, hayeswang wrote:
 Greg KH [mailto:gre...@linuxfoundation.org] 
  Sent: Friday, May 03, 2013 10:33 AM
  To: Hayeswang
  Cc: oli...@neukum.org; net...@vger.kernel.org; 
  linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; nic_swsd
  Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
  
  On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
   Add new driver for supporting Realtek RTL8152 Based USB 2.0 
  Ethernet Adapters
   
   Signed-off-by: Hayes Wang hayesw...@realtek.com
   Cc: Realtek linux nic maintainers nic_s...@realtek.com
  
  You removed the wording I had questions about last time, does 
  that mean
  the previous wording was not correct, or that you no longer are
  publicising the fact that this driver reads on some patents that you
  own?
  
  You also failed to answer my previous questions, why?
 
 That description is about the patent for the hw design, not for
 software. It indicates that the design of the hw uses those patents
 from the other compnay. I have no idea about how to deal with those
 patents. What should I do for sending a patch? 

That makes sense to me, removing it is correct.  It's now up to the
netdev developers to accept this, thanks for the quick response.

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

Re: [PATCH v3 net-next] net/usb: new driver for RTL8152

[David Miller]

From: 'Greg KH' gre...@linuxfoundation.org
Date: Thu, 2 May 2013 20:23:15 -0700

 On Fri, May 03, 2013 at 11:11:47AM +0800, hayeswang wrote:
 Greg KH [mailto:gre...@linuxfoundation.org] 
  Sent: Friday, May 03, 2013 10:33 AM
  To: Hayeswang
  Cc: oli...@neukum.org; net...@vger.kernel.org; 
  linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; nic_swsd
  Subject: Re: [PATCH v3 net-next] net/usb: new driver for RTL8152
  
  On Fri, May 03, 2013 at 10:01:25AM +0800, Hayes Wang wrote:
   Add new driver for supporting Realtek RTL8152 Based USB 2.0 
  Ethernet Adapters
   
   Signed-off-by: Hayes Wang hayesw...@realtek.com
   Cc: Realtek linux nic maintainers nic_s...@realtek.com
  
  You removed the wording I had questions about last time, does 
  that mean
  the previous wording was not correct, or that you no longer are
  publicising the fact that this driver reads on some patents that you
  own?
  
  You also failed to answer my previous questions, why?
 
 That description is about the patent for the hw design, not for
 software. It indicates that the design of the hw uses those patents
 from the other compnay. I have no idea about how to deal with those
 patents. What should I do for sending a patch? 
 
 That makes sense to me, removing it is correct.  It's now up to the
 netdev developers to accept this, thanks for the quick response.

I think this clears things up and that specific issue is no longer a
blocker for inclusion.

I'll let this sit on the list so that it may be reviewed on it's
technical merits.
--
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