Re: [PATCHv2 5/6] base: platform: name the device already during allocation

2014-08-05 Thread Heikki Krogerus 
On Mon, Jul 14, 2014 at 07:55:43AM -0700, Greg Kroah-Hartman wrote:
   diff --git a/drivers/base/platform.c b/drivers/base/platform.c
   index 9e9227e..e856bc4 100644
   --- a/drivers/base/platform.c
   +++ b/drivers/base/platform.c
   @@ -177,11 +177,45 @@ struct platform_object {
 */
void platform_device_put(struct platform_device *pdev)
{
   - if (pdev)
   - put_device(pdev-dev);
   + if (!pdev)
   + return;
   +
   + if (pdev-id_auto) {
   + ida_simple_remove(platform_devid_ida, pdev-id);
   + pdev-id = PLATFORM_DEVID_AUTO;
   + }
   +
   + put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
 
 Why would a single call to this function remove an id?  That seems
 really wrong, you should be able to call get and put on a device
 numerous times, only the last reference should cause the device to be
 cleaned up.
 
 Shouldn't this be in the release function instead?

I'll fix this.

Thanks Greg.

-- 
heikki
--
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/usb/hso: Add support for Option GTM671WFS

2014-08-05 Thread Ricardo Ribalda Delgado 
Hello Dan.

I have also been able to start/stop the gps via the gps control port
(ttyHS2) and get nmea data port through the gps port. (ttyHS1)

Please tell me if you need more tests

Regards!

root@qt5022:~# cat /sys/class/tty/*/hsotype
Diagnostic
GPS
GPS Control
Application
Control
Modem
root@qt5022:~# hso_connect up
Using /etc/conninfo.ini as connection file
Using /dev/ttyHS3 application port.
Initializing...
Trying internet ...
Connecting...
trying
Connected
Setting IP address to  10.198.XXX.115
Adding route
Done.
root@qt5022:~# ifconfig hso0
hso0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:10.198.XXX.115  P-t-P:10.198.XXX.115  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1486  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:10
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@qt5022:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=1163 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=304 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=72.5 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=60.7 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 60.790/400.296/1163.670/451.296 ms, pipe 2
root@qt5022:~# cat /dev/ttyHS1
$GPGSV,4,1,16,24271232,,,*7A
$GPGSV,4,2,16,31302928,,,*78
$GPGSV,4,3,16,26252322,,,*7B
$GPGSV,4,4,16,21201918,,,*7E
$GPGGA,,0*66
$PQXFI,,*56
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,N*53
$GPGSA,A,1,,,*1E
$GPGSV,4,1,16,04242712,,,*7F
$GPGSV,4,2,16,32313029,,,*73
$GPGSV,4,3,16,28262523,,,*71
$GPGSV,4,4,16,22212019,,,*77
$GPGGA,,0*66
$PQXFI,,*56
$GPVTG,,T,,M,,N,,K,N*2C
$GPRMC,,V,,N*53
$GPGSA,A,1,,,*1E

On Mon, Aug 4, 2014 at 8:30 PM, Dan Williams d...@redhat.com wrote:
 On Mon, 2014-08-04 at 11:20 +0200, Ricardo Ribalda Delgado wrote:
 Suggested-by: Dan Williams d...@redhat.com

 Before we apply this patch though, can you grab for the following for
 me?

 cat /sys/class/tty/*/hsotype

 and lets see if the firmware actually responds.  Also, do you get an
 'hso0' network interface as reported by ifconfig or /sbin/ip?  If you
 do, then lets do some additional verification to ensure it should be
 driven by 'hso' instead of option.

 Dan

 On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado
 ricardo.riba...@gmail.com wrote:
  After this patch:
 
  [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless
  [ 33.000452] hso 2-1.4:1.7: Not our interface
  [ 33.001849] usbcore: registered new interface driver hso
 
  root@qt5022:~# ls /dev/ttyHS*
  /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
  /dev/ttyHS5
 
  root@qt5022:~# lsusb -d 0af0: -vvv
 
  Bus 002 Device 003: ID 0af0:9200 Option
  Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass  255 Vendor Specific Class
bDeviceSubClass   255 Vendor Specific Subclass
bDeviceProtocol   255 Vendor Specific Protocol
bMaxPacketSize064
idVendor   0x0af0 Option
idProduct  0x9200
bcdDevice0.00
iManufacturer   3 Option N.V.
iProduct2 Globetrotter HSUPA Modem
iSerial 0
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength  200
  bNumInterfaces  8
  bConfigurationValue 1
  iConfiguration  1 Option Configuration
  bmAttributes 0xe0
Self Powered
Remote Wakeup
  MaxPower  100mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   2
bInterfaceClass   255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface  0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x81  EP 1 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0200  1x 512 bytes
  bInterval  32
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x01  EP 1 OUT
  bmAttributes2
Transfer Type

Re: [PATCH] xhci: Merge and Update debugging for patches from 3.6 kernel tree

2014-08-05 Thread Sam Ravnborg 
On Tue, Aug 05, 2014 at 01:55:34AM -0400, Nick Krause wrote:
 On Tue, Aug 5, 2014 at 1:45 AM, Greg KH gre...@linuxfoundation.org wrote:
  On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote:
  I am adding the fixes to the tree send for adding debugging to the kernel
  tree from a patch sent in 2013 on the the 3.6 release. The patch adds
  debugging over xhci capable debugging usb ports and needed to be updated
  into the latest rc tree. The patch was first sent in this thread,
  http://marc.info/?l=linux-usbm=135948845511047.
 
  Signed-off-by: Nicholas Krause xerofo...@gmail.com
 
 You haven't even checked my patch, our you just going to assume it's wrong?

If you spend 20 seconds reding what I quouted above you will find
bugs already.

1) No proper attribution
2) No proper description of the purpose of the patch

And considering the history of your formar patches
3) No documentation on how the patch was verified


There is no need to read the code with so many bugs in the changelog already.

Sam
--
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] xhci: Merge and Update debugging for patches from 3.6 kernel tree

2014-08-05 Thread Mateusz Guzik 
On Tue, Aug 05, 2014 at 01:55:34AM -0400, Nick Krause wrote:
 On Tue, Aug 5, 2014 at 1:45 AM, Greg KH gre...@linuxfoundation.org wrote:
  On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote:
  I am adding the fixes to the tree send for adding debugging to the kernel
  tree from a patch sent in 2013 on the the 3.6 release. The patch adds
  debugging over xhci capable debugging usb ports and needed to be updated
  into the latest rc tree. The patch was first sent in this thread,
  http://marc.info/?l=linux-usbm=135948845511047.
 
  Signed-off-by: Nicholas Krause xerofo...@gmail.com
 
  If you send one more patch, I am going to have to ask vger.kernel.org to
  ban you from their servers.  You are actively bothering people and
  causing problems and wasting time.
 
  You have been told _numerous_ times to stop, yet you refuse to listen.
  You hold the record for getting kicked out of the Eudyptula challenge in
  a matter of hours, something no one else has ever had happen.  You
  ignore lots of very valid comments and suggestions, for no good reason.
  You flail about, making mistakes that are now starting to bother users,
  which is not acceptable at all.
 
  I will not respond to any more of your emails, and ask everyone else to
  now stop as well.
 
  good bye.
 
  *plonk*
 
  greg k-h
 
 Greg,
 You haven't even checked my patch, our you just going to assume it's wrong?


I don't know this code and I'm not interested in changing that, so just I'm
just pointing out obvious problems.

1. You somehow managed to have changes like his all over the patch:
-#define TT_HS_OVERHEAD (31 + 94)
-#define TT_DMI_OVERHEAD (25 + 12)
+#define TT_HS_OVERHEAD (31  94)
+#define TT_DMI_OVERHEAD (25  12)

Clearly, this will cause compilation problems. But maybe this weird
corruption happened after you tested your patch?

2.  In the original patch there were some additions to struct xhci_hcd,
e.g. dbg_cap_reg.

Let's look at a random user:
+void xhci_teardown_dbg_cap(struct xhci_hcd *xhci, struct device *dev)
+{
+   u32 val;
+
+   xhci_dbg(xhci, xhci_teardown_dbg_cap()\n);
+   if (!xhci-dbg_cap_regs)
+   return;

xhci is a pointer to struct xhci_hcd.

Except in your patch all these additions landed in struct xhci_dbg_cap_ctx,
thus this could not possibly compile.

But what's the most important thing here is this: writing a compilable
patch is not a problem, writing a working patch is.

Forward porting, like this one, demands that you:
- understand the patch as applied to the original tree
- understand current state of the tree and how it influences the patch

As such, foward porting is typically not a task for beginners.

I can only recommend one last time you leave the kernel alone for the
time being and focus on userspace.

There. This is my last reply, have fun.

-- 
Mateusz Guzik
--
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: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Vivek Gautam 
Since we want to keep support for both older usb-phys as well as the
newer generic phys, lets first get the generic PHYs and fallback to
older USB-PHYs only when we fail to get the former.
This should fix the issue with ehci-exynos and ohci-exynos, wherein
in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
are not configured properly.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Jingoo Han jg1@samsung.com
---
 drivers/usb/host/ehci-exynos.c |   40 +-
 drivers/usb/host/ohci-exynos.c |   47 +++-
 2 files changed, 42 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index cda0a2f..2eed9a4 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -62,18 +62,6 @@ static int exynos_ehci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci-phy)) {
-   ret = PTR_ERR(exynos_ehci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ehci-otg = exynos_ehci-phy-otg;
-   }
-
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -90,15 +78,27 @@ static int exynos_ehci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
of_node_put(child);
-   if (IS_ERR(phy)) {
-   ret = PTR_ERR(phy);
-   if (ret != -ENOSYS  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   }
+   if (IS_ERR(phy))
+   /* Lets fallback to older USB-PHYs */
+   goto usb_phy_old;
exynos_ehci-phy_g[phy_number] = phy;
+   /* Make the older PHYs unavailable */
+   exynos_ehci-phy = ERR_PTR(-ENXIO);
+   }
+
+   return 0;
+
+usb_phy_old:
+   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ehci-phy)) {
+   ret = PTR_ERR(exynos_ehci-phy);
+   if (ret != -ENXIO  ret != -ENODEV) {
+   dev_err(dev, no usb2 phy configured\n);
+   return ret;
+   }
+   dev_dbg(dev, Failed to get usb2 phy\n);
+   } else {
+   exynos_ehci-otg = exynos_ehci-phy-otg;
}
 
return ret;
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a72ab8f..7c48e3f 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -51,27 +51,12 @@ static int exynos_ohci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci-phy)) {
-   ret = PTR_ERR(exynos_ohci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ohci-otg = exynos_ohci-phy-otg;
-   }
-
/*
 * Getting generic phy:
 * We are keeping both types of phys as a part of transiting OHCI
 * to generic phy framework, so as to maintain backward compatibilty
-* with old DTB.
-* If there are existing devices using DTB files built from them,
-* to remove the support for old bindings in this driver,
-* we need to make sure that such devices have their DTBs
-* updated to ones built from new DTS.
+* with old DTB too.
+* We fallback to older USB-PHYs when we fail to get generic PHYs.
 */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
@@ -89,15 +74,27 @@ static int exynos_ohci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
of_node_put(child);
-   if (IS_ERR(phy)) {
-   ret = PTR_ERR(phy);
-   if (ret != -ENOSYS  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-

Re: [PATCH v3 0/2] staging: dwc2: add microframe scheduler

2014-08-05 Thread Nick Hudson 

On 07/22/14 22:22, Nick Hudson wrote:

On 07/22/14 18:46, Paul Zimmerman wrote:


The nak_frame handling would have added some benefit, but wouldn't 
handle all

cases.

I'm seeing problems with devices NAKing to the point of confusing 
dwc2 completely,
so I'd like to investigate a NAK holdoff scheme that's acceptable 
for dwc2.  I
suspect the best thing to do here is to add a nak_count field to 
dwc2_qh (or maybe
dwc2_qtd) and increment in dwc2_hc_nak_intr.  If the count exceeds a 
threshold

then it would call

dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_NAK);

and go around again.

I assume the NAK count would need resetting everywhere 
qtd-error_count is reset.


How does this sound?

Sounds good to me. BTW, can you give me a pointer to one of the devices
that gives excessive NAKs? I would like to buy one for the lab here to
test with.



I'm seeing problems with a d-link dwcl-g122 wifi dongle that someone 
sent me.


The attached patch helps with my d-link dwl-g122 - it's adapted from the 
raspberry pi dwc_otg driver.


I'm not sure the NYET/NAK/ACK/other case and would happily remove it.

I assume the scheduler is doing something that is confusing the core 
with this particular device. The error recovery is still valid I think.


Nick
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 47b9eb5..5de7b58 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -1890,12 +1890,21 @@ static void dwc2_hc_chhltd_intr_dma(struct dwc2_hsotg 
*hsotg,
hcint 0x%08x, intsts 0x%08x\n,
chan-hcint,
readl(hsotg-regs + GINTSTS));
+   goto error;
}
}
} else {
dev_info(hsotg-dev,
 NYET/NAK/ACK/other in non-error case, 0x%08x\n,
 chan-hcint);
+error:
+
+   /* Failthrough: use 3-strikes rule */
+   qtd-error_count++;
+   dwc2_update_urb_state_abn(hsotg, chan, chnum, qtd-urb,
+ qtd, DWC2_HC_XFER_XACT_ERR);
+   dwc2_hcd_save_data_toggle(hsotg, chan, chnum, qtd);
+   dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_XACT_ERR);
}
 }

[PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Vivek Gautam 
Since we want to keep support for both older usb-phys as well as the
newer generic phys, lets first get the generic PHYs and fallback to
older USB-PHYs only when we fail to get the former.
This should fix the issue with ehci-exynos and ohci-exynos, wherein
in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
are not configured properly.

Reported-by: Sachin Kamat sachin.ka...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Jingoo Han jg1@samsung.com
---

Based on 'usb-next' branch.
Resending it after adding 'Reported-by' tag.

 drivers/usb/host/ehci-exynos.c |   40 +-
 drivers/usb/host/ohci-exynos.c |   47 +++-
 2 files changed, 42 insertions(+), 45 deletions(-)

diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index cda0a2f..2eed9a4 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -62,18 +62,6 @@ static int exynos_ehci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ehci-phy)) {
-   ret = PTR_ERR(exynos_ehci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ehci-otg = exynos_ehci-phy-otg;
-   }
-
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
if (ret) {
@@ -90,15 +78,27 @@ static int exynos_ehci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
of_node_put(child);
-   if (IS_ERR(phy)) {
-   ret = PTR_ERR(phy);
-   if (ret != -ENOSYS  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   }
+   if (IS_ERR(phy))
+   /* Lets fallback to older USB-PHYs */
+   goto usb_phy_old;
exynos_ehci-phy_g[phy_number] = phy;
+   /* Make the older PHYs unavailable */
+   exynos_ehci-phy = ERR_PTR(-ENXIO);
+   }
+
+   return 0;
+
+usb_phy_old:
+   exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ehci-phy)) {
+   ret = PTR_ERR(exynos_ehci-phy);
+   if (ret != -ENXIO  ret != -ENODEV) {
+   dev_err(dev, no usb2 phy configured\n);
+   return ret;
+   }
+   dev_dbg(dev, Failed to get usb2 phy\n);
+   } else {
+   exynos_ehci-otg = exynos_ehci-phy-otg;
}
 
return ret;
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a72ab8f..7c48e3f 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -51,27 +51,12 @@ static int exynos_ohci_get_phy(struct device *dev,
int phy_number;
int ret = 0;
 
-   exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(exynos_ohci-phy)) {
-   ret = PTR_ERR(exynos_ohci-phy);
-   if (ret != -ENXIO  ret != -ENODEV) {
-   dev_err(dev, no usb2 phy configured\n);
-   return ret;
-   }
-   dev_dbg(dev, Failed to get usb2 phy\n);
-   } else {
-   exynos_ohci-otg = exynos_ohci-phy-otg;
-   }
-
/*
 * Getting generic phy:
 * We are keeping both types of phys as a part of transiting OHCI
 * to generic phy framework, so as to maintain backward compatibilty
-* with old DTB.
-* If there are existing devices using DTB files built from them,
-* to remove the support for old bindings in this driver,
-* we need to make sure that such devices have their DTBs
-* updated to ones built from new DTS.
+* with old DTB too.
+* We fallback to older USB-PHYs when we fail to get generic PHYs.
 */
for_each_available_child_of_node(dev-of_node, child) {
ret = of_property_read_u32(child, reg, phy_number);
@@ -89,15 +74,27 @@ static int exynos_ohci_get_phy(struct device *dev,
 
phy = devm_of_phy_get(dev, child, NULL);
of_node_put(child);
-   if (IS_ERR(phy)) {
-   ret = PTR_ERR(phy);
-   if (ret != -ENOSYS  ret != -ENODEV) {
-

Re: [PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Jingoo Han 
On Tuesday, August 05, 2014 7:39 PM, Vivek Gautam wrote:
 
 Since we want to keep support for both older usb-phys as well as the
 newer generic phys, lets first get the generic PHYs and fallback to
 older USB-PHYs only when we fail to get the former.
 This should fix the issue with ehci-exynos and ohci-exynos, wherein
 in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
 the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
 are not configured properly.
 
 Reported-by: Sachin Kamat sachin.ka...@samsung.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: Jingoo Han jg1@samsung.com

Acked-by: Jingoo Han jg1@samsung.com

Right, we would get the generic PHYs first, then get the older
usb-phys. Then, the older one will be removed from the kernel.
Thank you.

Best regards,
Jingoo Han

 ---
 
 Based on 'usb-next' branch.
 Resending it after adding 'Reported-by' tag.
 
  drivers/usb/host/ehci-exynos.c |   40 +-
  drivers/usb/host/ohci-exynos.c |   47 
 +++-
  2 files changed, 42 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index cda0a2f..2eed9a4 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -62,18 +62,6 @@ static int exynos_ehci_get_phy(struct device *dev,
   int phy_number;
   int ret = 0;
 
 - exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
 - if (IS_ERR(exynos_ehci-phy)) {
 - ret = PTR_ERR(exynos_ehci-phy);
 - if (ret != -ENXIO  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ehci-otg = exynos_ehci-phy-otg;
 - }
 -
   for_each_available_child_of_node(dev-of_node, child) {
   ret = of_property_read_u32(child, reg, phy_number);
   if (ret) {
 @@ -90,15 +78,27 @@ static int exynos_ehci_get_phy(struct device *dev,
 
   phy = devm_of_phy_get(dev, child, NULL);
   of_node_put(child);
 - if (IS_ERR(phy)) {
 - ret = PTR_ERR(phy);
 - if (ret != -ENOSYS  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - }
 + if (IS_ERR(phy))
 + /* Lets fallback to older USB-PHYs */
 + goto usb_phy_old;
   exynos_ehci-phy_g[phy_number] = phy;
 + /* Make the older PHYs unavailable */
 + exynos_ehci-phy = ERR_PTR(-ENXIO);
 + }
 +
 + return 0;
 +
 +usb_phy_old:
 + exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
 + if (IS_ERR(exynos_ehci-phy)) {
 + ret = PTR_ERR(exynos_ehci-phy);
 + if (ret != -ENXIO  ret != -ENODEV) {
 + dev_err(dev, no usb2 phy configured\n);
 + return ret;
 + }
 + dev_dbg(dev, Failed to get usb2 phy\n);
 + } else {
 + exynos_ehci-otg = exynos_ehci-phy-otg;
   }
 
   return ret;
 diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
 index a72ab8f..7c48e3f 100644
 --- a/drivers/usb/host/ohci-exynos.c
 +++ b/drivers/usb/host/ohci-exynos.c
 @@ -51,27 +51,12 @@ static int exynos_ohci_get_phy(struct device *dev,
   int phy_number;
   int ret = 0;
 
 - exynos_ohci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
 - if (IS_ERR(exynos_ohci-phy)) {
 - ret = PTR_ERR(exynos_ohci-phy);
 - if (ret != -ENXIO  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ohci-otg = exynos_ohci-phy-otg;
 - }
 -
   /*
* Getting generic phy:
* We are keeping both types of phys as a part of transiting OHCI
* to generic phy framework, so as to maintain backward compatibilty
 -  * with old DTB.
 -  * If there are existing devices using DTB files built from them,
 -  * to remove the support for old bindings in this driver,
 -  * we need to make sure that such devices have their DTBs
 -  * updated to ones built from new DTS.
 +  * with old DTB too.
 +  * We fallback to older USB-PHYs when we fail to get generic PHYs.
*/
   for_each_available_child_of_node(dev-of_node, child) {
   ret = of_property_read_u32(child, reg, phy_number);
 @@ -89,15 +74,27 @@ static int exynos_ohci_get_phy(struct device *dev,
 
   phy = devm_of_phy_get(dev,

Re: [PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Sachin Kamat 
Hi Vivek,

On Tue, Aug 5, 2014 at 4:09 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
 Since we want to keep support for both older usb-phys as well as the
 newer generic phys, lets first get the generic PHYs and fallback to
 older USB-PHYs only when we fail to get the former.
 This should fix the issue with ehci-exynos and ohci-exynos, wherein
 in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
 the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
 are not configured properly.

 Reported-by: Sachin Kamat sachin.ka...@samsung.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: Jingoo Han jg1@samsung.com

Tested this patch on Exynos5250 based Arndale and Snow boards.
Fixes the said issue. Thanks.

Tested-by: Sachin Kamat sachin.ka...@samsung.com

-- 
Regards,
Sachin.
--
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 RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Vivek Gautam 

Hi Jingoo,


On Tuesday, August 05, 2014 4:28 PM, Jingoo Han wrote:

On Tuesday, August 05, 2014 7:39 PM, Vivek Gautam wrote:


Since we want to keep support for both older usb-phys as well as the
newer generic phys, lets first get the generic PHYs and fallback to
older USB-PHYs only when we fail to get the former.
This should fix the issue with ehci-exynos and ohci-exynos, wherein
in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
are not configured properly.

Reported-by: Sachin Kamat sachin.ka...@samsung.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Jingoo Han jg1@samsung.com


Acked-by: Jingoo Han jg1@samsung.com

Right, we would get the generic PHYs first, then get the older
usb-phys. Then, the older one will be removed from the kernel.


Right, I have a set of patches to remove the older phy support for Exynos 
SoC series,

keeping the support for S3C64XX, which I shall send soon.

[snip]

Thanks
Vivek Gautam 


--
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: isp1362: Use devm_ioremap_resource

2014-08-05 Thread Tobias Klauser 
Use devm_ioremap_resource to simplify error handling in the probe
function and to get rid of some boilerplate in the remove function.

Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
 drivers/usb/host/isp1362-hcd.c | 103 ++---
 1 file changed, 25 insertions(+), 78 deletions(-)

diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
index 875bcfd..4bb3798 100644
--- a/drivers/usb/host/isp1362-hcd.c
+++ b/drivers/usb/host/isp1362-hcd.c
@@ -2616,30 +2616,10 @@ static int isp1362_remove(struct platform_device *pdev)
 {
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct isp1362_hcd *isp1362_hcd = hcd_to_isp1362_hcd(hcd);
-   struct resource *res;
 
remove_debug_file(isp1362_hcd);
DBG(0, %s: Removing HCD\n, __func__);
usb_remove_hcd(hcd);
-
-   DBG(0, %s: Unmapping data_reg @ %p\n, __func__,
-   isp1362_hcd-data_reg);
-   iounmap(isp1362_hcd-data_reg);
-
-   DBG(0, %s: Unmapping addr_reg @ %p\n, __func__,
-   isp1362_hcd-addr_reg);
-   iounmap(isp1362_hcd-addr_reg);
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   DBG(0, %s: release mem_region: %08lx\n, __func__, (long unsigned 
int)res-start);
-   if (res)
-   release_mem_region(res-start, resource_size(res));
-
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   DBG(0, %s: release mem_region: %08lx\n, __func__, (long unsigned 
int)res-start);
-   if (res)
-   release_mem_region(res-start, resource_size(res));
-
DBG(0, %s: put_hcd\n, __func__);
usb_put_hcd(hcd);
DBG(0, %s: Done\n, __func__);
@@ -2651,12 +2631,11 @@ static int isp1362_probe(struct platform_device *pdev)
 {
struct usb_hcd *hcd;
struct isp1362_hcd *isp1362_hcd;
-   struct resource *addr, *data;
+   struct resource *addr, *data, *irq_res;
void __iomem *addr_reg;
void __iomem *data_reg;
int irq;
int retval = 0;
-   struct resource *irq_res;
unsigned int irq_flags = 0;
 
if (usb_disabled())
@@ -2667,52 +2646,35 @@ static int isp1362_probe(struct platform_device *pdev)
 * specific platform_data.  we don't probe for IRQs, and do only
 * minimal sanity checking.
 */
-   if (pdev-num_resources  3) {
-   retval = -ENODEV;
-   goto err1;
-   }
-
-   data = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   addr = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!addr || !data || !irq_res) {
-   retval = -ENODEV;
-   goto err1;
-   }
-   irq = irq_res-start;
+   if (pdev-num_resources  3)
+   return -ENODEV;
 
if (pdev-dev.dma_mask) {
DBG(1, won't do DMA);
-   retval = -ENODEV;
-   goto err1;
+   return -ENODEV;
}
 
-   if (!request_mem_region(addr-start, resource_size(addr), hcd_name)) {
-   retval = -EBUSY;
-   goto err1;
-   }
-   addr_reg = ioremap(addr-start, resource_size(addr));
-   if (addr_reg == NULL) {
-   retval = -ENOMEM;
-   goto err2;
-   }
+   irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!irq_res)
+   return -ENODEV;
 
-   if (!request_mem_region(data-start, resource_size(data), hcd_name)) {
-   retval = -EBUSY;
-   goto err3;
-   }
-   data_reg = ioremap(data-start, resource_size(data));
-   if (data_reg == NULL) {
-   retval = -ENOMEM;
-   goto err4;
-   }
+   irq = irq_res-start;
+
+   addr = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   addr_reg = devm_ioremap_resource(pdev-dev, addr);
+   if (IS_ERR(addr_reg))
+   return PTR_ERR(addr_reg);
+
+   data = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   data_reg = devm_ioremap_resource(pdev-dev, data);
+   if (IS_ERR(data_reg))
+   return PTR_ERR(data_reg);
 
/* allocate and initialize hcd */
hcd = usb_create_hcd(isp1362_hc_driver, pdev-dev, 
dev_name(pdev-dev));
-   if (!hcd) {
-   retval = -ENOMEM;
-   goto err5;
-   }
+   if (!hcd)
+   return -ENOMEM;
+
hcd-rsrc_start = data-start;
isp1362_hcd = hcd_to_isp1362_hcd(hcd);
isp1362_hcd-data_reg = data_reg;
@@ -2729,7 +2691,7 @@ static int isp1362_probe(struct platform_device *pdev)
if (!isp1362_hcd-board-delay) {
dev_err(hcd-self.controller, No platform delay function 
given\n);
retval = -ENODEV;
-   goto err6;
+   goto err;
}
 #endif
 
@@ -2744,32 +2706,17 @@ static int isp1362_probe(struct platform_device *pdev)
 
retval =

Re: [RESEND PATCH v3 2/4] usb: musb: Bugfix of_node assignment

2014-08-05 Thread Sebastian Andrzej Siewior 
On 08/04/2014 12:13 PM, Markus Pargmann wrote:

 In the long term I would suggest to move the DT probe over to the musb
 core code and we wouldn't need the node assignment anymore…

 [0] http://www.spinics.net/lists/linux-usb/msg94701.html
 
 Really old thread but I just noticed that this solution does not work
 for automatically parsed properties like 'default' pinctrl. I added
 'default' pinctrl settings for the musb device node. They are
 automatically setup by the driver core infrastracture as expected.
 
 The problem is that the 'default' pincontrol settings will be applied
 again for the musb-hdrc because they are extracted from the of_ndoe
 data. This fails because they are already claimed by the 'musb-dsps'
 driver. musb-hdrc continues probing, but there is a big error message
 that it failed:
 
 [1.181912] pinctrl-single 44e10800.pinmux: pin 44e10a20.0 already 
 requested by 47401c00.usb; cannot clai
 m for musb-hdrc.1.auto
 [1.194053] pinctrl-single 44e10800.pinmux: pin-136 (musb-hdrc.1.auto) 
 status -22
 [1.201930] pinctrl-single 44e10800.pinmux: could not request pin 136 
 (44e10a20.0) from group pinmux_usb1
 _pins  on device pinctrl-single
 [1.214790] musb-hdrc musb-hdrc.1.auto: Error applying setting, reverse 
 things back
 
 Any ideas how to solve it for mainline?

Just what I said last time and I hope Felipe has the same opinion:
Teach musb-hdrc DT. Which means ti,musb-am33xx would be listed for
for musb-hdrc itself and we would lose that child device. The
additional ops that we have would be passed via the data field next to
the id.

 Best regards,
 
 Markus

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

Re: 3.14.12 and USB option_instat_callback with 3G DONGLE

2014-08-05 Thread Johan Hovold 
On Tue, Aug 05, 2014 at 02:30:31PM +1000, ress...@ausics.net wrote:
 On 2014-08-05 00:10, Johan Hovold wrote:

  I'll queue this up for v3.17-rc.
  
 
 Awesome, any chance of it finding its way into 3.14.x since it's a LT 
 release?

Yes, it's marked for stable and should show up there within a few weeks
(a little longer than usual due to the merge window).

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

Re: Resend Re: [PATCH v6] usb:serial:pl2303: add GPIOs interface on PL2303

2014-08-05 Thread Johan Hovold 
On Tue, Aug 05, 2014 at 01:15:36AM +0800, Wang YanQing wrote:
 I change my system recently, and sendmail has trouble
 to send mails to kernel mail list, so I resend it 
 with my old system.

I got all three.

 Ok, before I send out next version, I still has some
 vague places, see below:
   
 On Mon, Aug 04, 2014 at 04:00:32PM +0200, Johan Hovold wrote:
   +config USB_SERIAL_PL2303_GPIO
   + bool USB Prolific 2303 Single Port GPIOs support
   + depends on USB_SERIAL_PL2303  GPIOLIB
   + ---help---
   +   Say Y here if you want to use the GPIOs on PL2303 USB Serial single 
   port
   +   adapter from Prolific.
   +
   +   It supports 2 GPIOs on PL2303HX currently,
   +   if unsure, say N.
  
  You can drop the unsure bit (or at least split it into two sentences).
 
 I don't understand here, what is your meaning?
 I add if unsure, say N to make checkpatch.pl happy,
 it seems like checkpatch.pl want at least two lines here.

If you just added it to make checkpatch happy, then you should
definitely remove it. It adds no value (and is not grammatically correct
as it stands as one sentence).

If you want you could extend the description and mention that these
GPIOs are only accessible on some serial-converters and that only two
out of four are currently supported, for example.

  I noticed that setting direction to output and setting the gpio high has
  no effect on the read-back value (i.e. I still read back 0) for my
  pl2303hx (note that my device has no easily accessible gpios so I
  haven't verified the actual state of the output pin).
  
  What happens on your system? Is the read-back value still 0, even when
  the GPIO output is actually high? Should we return the cached value in
  this case?
 
 If i set direction to output, then I could control gpio high and low
 by set 1 or 0, and the read-back value is 1 or 0 according to high and
 low(I test high and low by oscillscope)
 
 I test it with my pl2303hx with only two gpios.

 Could you use usbmon to see whether the traffic is right according
 to comment in struct pl2303_gpio?

The traffic appears correct judging from the debug output (which I
trust). Output-enable is reflected in register 0x81, but the value
isn't.

What is the lsusb -v output for your device?

   + spriv-gpio-index = 0x00;
   + spriv-gpio-serial = serial;
   +
   + mutex_lock(gpiochip_lock);
   + minor = idr_alloc(gpiochip_minor, serial, 0, 0, GFP_KERNEL);
   + if (minor  0) {
   + mutex_unlock(gpiochip_lock);
   + ret = minor;
   + goto ERROR1;
   + }
   + spriv-gpio-minor = minor;
   + mutex_unlock(gpiochip_lock);
   +
   + label = kasprintf(GFP_KERNEL, pl2303-gpio%d,
   +   spriv-gpio-minor);
   + if (label == NULL) {
   + ret = -ENOMEM;
   + goto ERROR2;
   + }
  
  The id allocation and label generation is just overkill (if anything,
  you'd want the generated name to include the interface name rather
  than some new random number).
  
  But as we can always find the parent device via sysfs, simply set the
  label to pl2303.
 I don't understand here, I want to fix we can't distinguish
 multi pl2303 gpios in kernel space, not userspace by different
 label name when there are more than one pl2303.

Ok, but why do you want to fix that? What is the use case? When would
you want to use such an unreliable (can go away anytime and hard to
match to a specific device) gpio chip for anything from within the
kernel (except possibly from the driver itself)?

 I find usb-serial use idr_alloc to manage minor, so I use it,
 I hope the label's name looks like below:
 pl2303-gpio0, pl2303-gpio1.

Yes, the usb-serial port minors are actually needed. (And you cannot
rely on them as they haven't been allocated yet when you initialise the
gpio chip).

 Because gpiolib could use label to find out specified gpio chio,
 then we could distinguish them by standard gpio interface, after
 acquire pl2303 gpio by different label name, we could test their
 parent device to make sure whether right one or not, and release
 it when not.

That just seems backwards. If there's a valid use case, we should have a
generic way to iterate over any gpio chips of the parent device instead.  

 With different label names, we could predict their name depend on
 fix usb bus scanning order in a fix hardare environment, then we could
 acquire right pl2303 gpio chip by pl2303-gpio0, pl2303-gpio1.

This will never be fully predictable. Userspace can always find the
right gpio based on chip serial number or similar, however.

I suggest you just set the label to pl2303 until we have a valid
use-case that requires something more elaborate.

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

Re: [PATCH RESEND] usb: ehci/ohci-exynos: Fix PHY getting sequence

2014-08-05 Thread Alan Stern 
On Tue, 5 Aug 2014, Vivek Gautam wrote:

 Since we want to keep support for both older usb-phys as well as the
 newer generic phys, lets first get the generic PHYs and fallback to
 older USB-PHYs only when we fail to get the former.
 This should fix the issue with ehci-exynos and ohci-exynos, wherein
 in the absence of SAMSUNG_USB2PHY config symbol, we end up getting
 the NOP_USB_XCEIV phy when the same is enabled. And thus the PHYs
 are not configured properly.
 
 Reported-by: Sachin Kamat sachin.ka...@samsung.com
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: Jingoo Han jg1@samsung.com
 ---
 
 Based on 'usb-next' branch.
 Resending it after adding 'Reported-by' tag.
 
  drivers/usb/host/ehci-exynos.c |   40 +-
  drivers/usb/host/ohci-exynos.c |   47 
 +++-
  2 files changed, 42 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
 index cda0a2f..2eed9a4 100644
 --- a/drivers/usb/host/ehci-exynos.c
 +++ b/drivers/usb/host/ehci-exynos.c
 @@ -62,18 +62,6 @@ static int exynos_ehci_get_phy(struct device *dev,
   int phy_number;
   int ret = 0;
  
 - exynos_ehci-phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
 - if (IS_ERR(exynos_ehci-phy)) {
 - ret = PTR_ERR(exynos_ehci-phy);
 - if (ret != -ENXIO  ret != -ENODEV) {
 - dev_err(dev, no usb2 phy configured\n);
 - return ret;
 - }
 - dev_dbg(dev, Failed to get usb2 phy\n);
 - } else {
 - exynos_ehci-otg = exynos_ehci-phy-otg;
 - }
 -
   for_each_available_child_of_node(dev-of_node, child) {
   ret = of_property_read_u32(child, reg, phy_number);
   if (ret) {
 @@ -90,15 +78,27 @@ static int exynos_ehci_get_phy(struct device *dev,

What about the code that you skipped here?  Suppose the 
of_property_read_32() call returns an error.  Do you then want to abort 
the whole thing, or should you go on to try the old usb_phy?

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] net/usb/hso: Add support for Option GTM671WFS

2014-08-05 Thread Dan Williams 
On Tue, 2014-08-05 at 08:59 +0200, Ricardo Ribalda Delgado wrote:
 Hello Dan.
 
 I have also been able to start/stop the gps via the gps control port
 (ttyHS2) and get nmea data port through the gps port. (ttyHS1)
 
 Please tell me if you need more tests

No, this looks good enough.  Because (a) 'hsotype' is valid for the
ports and (b) we get the hso0 net device and (c) you can get an IP
address on that interface, then this device should definitely be driven
by 'hso' and not option.  I'll ack the hso patch.

Dan


 Regards!
 
 root@qt5022:~# cat /sys/class/tty/*/hsotype
 Diagnostic
 GPS
 GPS Control
 Application
 Control
 Modem
 root@qt5022:~# hso_connect up
 Using /etc/conninfo.ini as connection file
 Using /dev/ttyHS3 application port.
 Initializing...
 Trying internet ...
 Connecting...
 trying
 Connected
 Setting IP address to  10.198.XXX.115
 Adding route
 Done.
 root@qt5022:~# ifconfig hso0
 hso0  Link encap:UNSPEC  HWaddr
 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
   inet addr:10.198.XXX.115  P-t-P:10.198.XXX.115  Mask:255.255.255.255
   UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1486  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:10
   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 
 root@qt5022:~# ping 8.8.8.8
 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=1163 ms
 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=304 ms
 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=72.5 ms
 64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=60.7 ms
 ^C
 --- 8.8.8.8 ping statistics ---
 4 packets transmitted, 4 received, 0% packet loss, time 3003ms
 rtt min/avg/max/mdev = 60.790/400.296/1163.670/451.296 ms, pipe 2
 root@qt5022:~# cat /dev/ttyHS1
 $GPGSV,4,1,16,24271232,,,*7A
 $GPGSV,4,2,16,31302928,,,*78
 $GPGSV,4,3,16,26252322,,,*7B
 $GPGSV,4,4,16,21201918,,,*7E
 $GPGGA,,0*66
 $PQXFI,,*56
 $GPVTG,,T,,M,,N,,K,N*2C
 $GPRMC,,V,,N*53
 $GPGSA,A,1,,,*1E
 $GPGSV,4,1,16,04242712,,,*7F
 $GPGSV,4,2,16,32313029,,,*73
 $GPGSV,4,3,16,28262523,,,*71
 $GPGSV,4,4,16,22212019,,,*77
 $GPGGA,,0*66
 $PQXFI,,*56
 $GPVTG,,T,,M,,N,,K,N*2C
 $GPRMC,,V,,N*53
 $GPGSA,A,1,,,*1E
 
 On Mon, Aug 4, 2014 at 8:30 PM, Dan Williams d...@redhat.com wrote:
  On Mon, 2014-08-04 at 11:20 +0200, Ricardo Ribalda Delgado wrote:
  Suggested-by: Dan Williams d...@redhat.com
 
  Before we apply this patch though, can you grab for the following for
  me?
 
  cat /sys/class/tty/*/hsotype
 
  and lets see if the firmware actually responds.  Also, do you get an
  'hso0' network interface as reported by ifconfig or /sbin/ip?  If you
  do, then lets do some additional verification to ensure it should be
  driven by 'hso' instead of option.
 
  Dan
 
  On Mon, Aug 4, 2014 at 11:11 AM, Ricardo Ribalda Delgado
  ricardo.riba...@gmail.com wrote:
   After this patch:
  
   [ 32.985530] hso: drivers/net/usb/hso.c: Option Wireless
   [ 33.000452] hso 2-1.4:1.7: Not our interface
   [ 33.001849] usbcore: registered new interface driver hso
  
   root@qt5022:~# ls /dev/ttyHS*
   /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
   /dev/ttyHS5
  
   root@qt5022:~# lsusb -d 0af0: -vvv
  
   Bus 002 Device 003: ID 0af0:9200 Option
   Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass  255 Vendor Specific Class
 bDeviceSubClass   255 Vendor Specific Subclass
 bDeviceProtocol   255 Vendor Specific Protocol
 bMaxPacketSize064
 idVendor   0x0af0 Option
 idProduct  0x9200
 bcdDevice0.00
 iManufacturer   3 Option N.V.
 iProduct2 Globetrotter HSUPA Modem
 iSerial 0
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength  200
   bNumInterfaces  8
   bConfigurationValue 1
   iConfiguration  1 Option Configuration
   bmAttributes 0xe0
 Self Powered
 Remote Wakeup
   MaxPower  100mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   2
 bInterfaceClass   255 Vendor Specific Class
 bInterfaceSubClass255 Vendor Specific Subclass
 bInterfaceProtocol255 Vendor Specific Protocol
 iInterface  0
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1

Re: [PATCH] net/usb/hso: Add support for Option GTM671WFS

2014-08-05 Thread Dan Williams 
On Mon, 2014-08-04 at 11:11 +0200, Ricardo Ribalda Delgado wrote:
 After this patch:
 
 [   32.985530] hso: drivers/net/usb/hso.c: Option Wireless
 [   33.000452] hso 2-1.4:1.7: Not our interface
 [   33.001849] usbcore: registered new interface driver hso
 
 root@qt5022:~# ls /dev/ttyHS*
 /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
 /dev/ttyHS5

Acked-by: Dan Williams d...@redhat.com

 root@qt5022:~# lsusb -d 0af0: -vvv
 
 Bus 002 Device 003: ID 0af0:9200 Option
 Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  255 Vendor Specific Class
   bDeviceSubClass   255 Vendor Specific Subclass
   bDeviceProtocol   255 Vendor Specific Protocol
   bMaxPacketSize064
   idVendor   0x0af0 Option
   idProduct  0x9200
   bcdDevice0.00
   iManufacturer   3 Option N.V.
   iProduct2 Globetrotter HSUPA Modem
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  200
 bNumInterfaces  8
 bConfigurationValue 1
 iConfiguration  1 Option Configuration
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  100mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x01  EP 1 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber1
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x82  EP 2 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x02  EP 2 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber2
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   255 Vendor Specific Class
   bInterfaceSubClass255 Vendor Specific Subclass
   bInterfaceProtocol255 Vendor Specific Protocol
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x83  EP 3 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x03  EP 3 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0200  1x 512 bytes
 bInterval  32
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber3

Re: [PATCH] serial/option: Add support for Option GTM671WFS

2014-08-05 Thread Dan Williams 
On Mon, 2014-08-04 at 11:12 +0200, Ricardo Ribalda Delgado wrote:
 Hello Dan
 
 
  Are you 100% sure these don't go into the 'hso' driver?  'option' is
  used for mostly older Option devices (like 5+ years old).  I tried to
  find information about this module, and the closest I could come for
  0af0:9200 was:
 
  http://trac.gateworks.com/wiki/3g
 
  which indicates they might be 'hso' instead.  Can you give that a try?

Follow-up note: this device should indeed be driven by 'hso' (not
option) and Ricardo has submitted a patch for that to netdev@.

Dan

 With all the hso_ids configuration I get the following error message:
 
 [  553.501693] hso: drivers/net/usb/hso.c: Option Wireless
 [  553.524898] hso 2-1.4:1.7: Not our interface
 
 and depending on the mode I get 3, 4 or 6 ttySH interfaces
 
 But, if we ignore this, the device can connect to the internet with
 hso_connect.sh. I have already post a patch using the hso driver.
 
 The device could also connect with option.ko... Do you think that
 there could be other devices wrongly handled with option ?
 
 Ricardo
 --
 To unsubscribe from this list: send the line unsubscribe linux-usb in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

Re: [PATCH] xhci: Merge and Update debugging for patches from 3.6 kernel tree

2014-08-05 Thread Nick Krause 
On Tue, Aug 5, 2014 at 3:27 AM, Mateusz Guzik mgu...@redhat.com wrote:
 On Tue, Aug 05, 2014 at 01:55:34AM -0400, Nick Krause wrote:
 On Tue, Aug 5, 2014 at 1:45 AM, Greg KH gre...@linuxfoundation.org wrote:
  On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote:
  I am adding the fixes to the tree send for adding debugging to the kernel
  tree from a patch sent in 2013 on the the 3.6 release. The patch adds
  debugging over xhci capable debugging usb ports and needed to be updated
  into the latest rc tree. The patch was first sent in this thread,
  http://marc.info/?l=linux-usbm=135948845511047.
 
  Signed-off-by: Nicholas Krause xerofo...@gmail.com
 
  If you send one more patch, I am going to have to ask vger.kernel.org to
  ban you from their servers.  You are actively bothering people and
  causing problems and wasting time.
 
  You have been told _numerous_ times to stop, yet you refuse to listen.
  You hold the record for getting kicked out of the Eudyptula challenge in
  a matter of hours, something no one else has ever had happen.  You
  ignore lots of very valid comments and suggestions, for no good reason.
  You flail about, making mistakes that are now starting to bother users,
  which is not acceptable at all.
 
  I will not respond to any more of your emails, and ask everyone else to
  now stop as well.
 
  good bye.
 
  *plonk*
 
  greg k-h

 Greg,
 You haven't even checked my patch, our you just going to assume it's wrong?


 I don't know this code and I'm not interested in changing that, so just I'm
 just pointing out obvious problems.

 1. You somehow managed to have changes like his all over the patch:
 -#define TT_HS_OVERHEAD (31 + 94)
 -#define TT_DMI_OVERHEAD (25 + 12)
 +#define TT_HS_OVERHEAD (31  94)
 +#define TT_DMI_OVERHEAD (25  12)

 Clearly, this will cause compilation problems. But maybe this weird
 corruption happened after you tested your patch?

 2.  In the original patch there were some additions to struct xhci_hcd,
 e.g. dbg_cap_reg.

 Let's look at a random user:
 +void xhci_teardown_dbg_cap(struct xhci_hcd *xhci, struct device *dev)
 +{
 +   u32 val;
 +
 +   xhci_dbg(xhci, xhci_teardown_dbg_cap()\n);
 +   if (!xhci-dbg_cap_regs)
 +   return;

 xhci is a pointer to struct xhci_hcd.

 Except in your patch all these additions landed in struct xhci_dbg_cap_ctx,
 thus this could not possibly compile.

 But what's the most important thing here is this: writing a compilable
 patch is not a problem, writing a working patch is.

 Forward porting, like this one, demands that you:
 - understand the patch as applied to the original tree
 - understand current state of the tree and how it influences the patch

 As such, foward porting is typically not a task for beginners.

 I can only recommend one last time you leave the kernel alone for the
 time being and focus on userspace.

 There. This is my last reply, have fun.

 --
 Mateusz Guzik
 Matueuz ,
I am going to not send any more patches for now at least. I am
going to just read the lkml.
Regards Nick
--
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 0/2] staging: dwc2: add microframe scheduler

2014-08-05 Thread Paul Zimmerman 
 From: Nick Hudson [mailto:sk...@netbsd.org]
 Sent: Tuesday, August 05, 2014 1:57 AM
 
 On 07/22/14 22:22, Nick Hudson wrote:
  On 07/22/14 18:46, Paul Zimmerman wrote:
 
  The nak_frame handling would have added some benefit, but wouldn't
  handle all
  cases.
 
  I'm seeing problems with devices NAKing to the point of confusing
  dwc2 completely,
  so I'd like to investigate a NAK holdoff scheme that's acceptable
  for dwc2.  I
  suspect the best thing to do here is to add a nak_count field to
  dwc2_qh (or maybe
  dwc2_qtd) and increment in dwc2_hc_nak_intr.  If the count exceeds a
  threshold
  then it would call
 
  dwc2_halt_channel(hsotg, chan, qtd, DWC2_HC_XFER_NAK);
 
  and go around again.
 
  I assume the NAK count would need resetting everywhere
  qtd-error_count is reset.
 
  How does this sound?
  Sounds good to me. BTW, can you give me a pointer to one of the devices
  that gives excessive NAKs? I would like to buy one for the lab here to
  test with.
 
 
  I'm seeing problems with a d-link dwcl-g122 wifi dongle that someone
  sent me.
 
 The attached patch helps with my d-link dwl-g122 - it's adapted from the
 raspberry pi dwc_otg driver.
 
 I'm not sure the NYET/NAK/ACK/other case and would happily remove it.
 
 I assume the scheduler is doing something that is confusing the core
 with this particular device. The error recovery is still valid I think.

Hi Nick,

If this is done in the Raspberry Pi kernel, then it's probably fine,
since those guys know more about the DWC2 core than anyone, I think.

One thing: For Linux, we are required to have a Signed-off-by line on
all patches. May I add your Signed-off-by to this patch?

Also, in future, please include the patch inline instead of as an
attachment. That's the standard practice on the Linux lists, it
causes less problems with funky mailers and such. Thanks.

-- 
Paul

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

Re: [RESEND PATCH] xhci-rcar: add firmware for R-Car H2/M2 USB 3.0 host controller

2014-08-05 Thread Kyle McMartin 
On Thu, Jul 10, 2014 at 10:41:55AM +0900, Yoshihiro Shimoda wrote:
 This patch adds a firmware for the USB 3.0 host controller of Renesas
 R-Car H2 and M2 SoCs.
 
 Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com

applied, thanks!

--kyle
--
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/usb/hso: Add support for Option GTM671WFS

2014-08-05 Thread David Miller 
From: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
Date: Mon,  4 Aug 2014 11:11:49 +0200

 After this patch:
 
 [   32.985530] hso: drivers/net/usb/hso.c: Option Wireless
 [   33.000452] hso 2-1.4:1.7: Not our interface
 [   33.001849] usbcore: registered new interface driver hso
 
 root@qt5022:~# ls /dev/ttyHS*
 /dev/ttyHS0  /dev/ttyHS1  /dev/ttyHS2  /dev/ttyHS3  /dev/ttyHS4
 /dev/ttyHS5
 
 root@qt5022:~# lsusb -d 0af0: -vvv
 ...
 Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com

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

RE: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting

2014-08-05 Thread Paul Zimmerman 
 From: Kever Yang [mailto:kever.y...@rock-chips.com]
 Sent: Monday, August 04, 2014 6:46 PM
 
 On 08/05/2014 12:34 AM, Doug Anderson wrote:
 
  Normally I'd say that you should have added Paul's Acked-by since
  you fixed his nit and he told you to include his Acked-by when his nit
  was fixed, but...
 There are some more changes than Paul's suggestion, so I'm not sure
 if Paul need more review to give me the Acked-by, I get it now.

Yes, you did the right thing by leaving off my ack (although you should
have mentioned the additional changes in your email).

  diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
  index 27d2c9b..738bec2 100644
  --- a/drivers/usb/dwc2/core.c
  +++ b/drivers/usb/dwc2/core.c
  @@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
   u32 greset;
   int count = 0;
  +   u32 gusbcfg;
 
   dev_vdbg(hsotg-dev, %s()\n, __func__);
 
  @@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
   }
   } while (greset  GRSTCTL_CSFTRST);
 
  +   if (hsotg-dr_mode == USB_DR_MODE_HOST) {
  +   gusbcfg = readl(hsotg-regs + GUSBCFG);
  +   gusbcfg = ~GUSBCFG_FORCEDEVMODE;
  +   gusbcfg |= GUSBCFG_FORCEHOSTMODE;
  +   writel(gusbcfg, hsotg-regs + GUSBCFG);
  +   } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
  +   gusbcfg = readl(hsotg-regs + GUSBCFG);
  +   gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
  +   gusbcfg |= GUSBCFG_FORCEDEVMODE;
  +   writel(gusbcfg, hsotg-regs + GUSBCFG);
  +   } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
  +   gusbcfg = readl(hsotg-regs + GUSBCFG);
  +   gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
  +   gusbcfg = ~GUSBCFG_FORCEDEVMODE;
  +   writel(gusbcfg, hsotg-regs + GUSBCFG);
  +   }
  +
   /*
* NOTE: This long sleep is _very_ important, otherwise the core 
  will
* not stay in host mode after a connector ID change!
  diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
  index 1efd10c..52a4fd2 100644
  --- a/drivers/usb/dwc2/core.h
  +++ b/drivers/usb/dwc2/core.h
  @@ -501,6 +501,10 @@ struct dwc2_hw_params {
 *  a_peripheral and b_device=b_host) this may not 
  match
 *  the core, but allows the software to determine
 *  transitions
  + * @dr_mode:Requested mode of operation, one of following:
  + *  - USB_DR_MODE_PERIPHERAL
  + *  - USB_DR_MODE_HOST
  + *  - USB_DR_MODE_OTG
 * @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
 *  transfer are in process of being queued
 * @srp_success:Stores status of SRP request in the case of a FS 
  PHY
  @@ -592,6 +596,7 @@ struct dwc2_hsotg {
   /** Params to actually use */
   struct dwc2_core_params *core_params;
   enum usb_otg_state op_state;
  +   enum usb_dr_mode dr_mode;
 
   unsigned int queuing_high_bandwidth:1;
   unsigned int srp_success:1;
  diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
  index a10e7a3..4d2c738 100644
  --- a/drivers/usb/dwc2/platform.c
  +++ b/drivers/usb/dwc2/platform.c
  @@ -42,6 +42,8 @@
#include linux/of_device.h
#include linux/platform_device.h
 
  +#include linux/usb/of.h
  +
#include core.h
#include hcd.h
 
  @@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device 
  *dev)
   dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
   (unsigned long)res-start, hsotg-regs);
 
  +   hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
  +
  +   if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
  +   hsotg-dr_mode = USB_DR_MODE_HOST;
  +   else if (IS_ENABLED(CONFIG_USB_DWC2_GADGET))
  +   hsotg-dr_mode = USB_DR_MODE_PERIPHERAL;
  +
  +   if (hsotg-dr_mode == USB_DR_MODE_UNKNOWN)
  +   hsotg-dr_mode = USB_DR_MODE_OTG;
  +
  Please remove this whole chunk.  Specifically:
 
  * CONFIG_USB_DWC2_GADGET is not a config option and is nowhere in any
  KConfig files.
 This should be USB_DWC2_PERIPHERAL, and I just copy it wrong from dwc3.
 
  * CONFIG_USB_DWC2_HOST claims in Kconfig that we'll be in host only
  mode, but I don't think that's right.  The only way you'll get any
  host functionality is if CONFIG_USB_DWC2_HOST is defined, so we'd need
  that defined even for OTG mode.
 Yeap, I add the chunk above because I'm confused by Host only mode for
 CONFIG_USB_DWC2_HOST in Kconfig. If it's the Host only mode, I should
 add the dr_mode for it to make sure the controller works in host mode.
 
 Maybe dwc2 is refer to the Kconfig in dwc3 for there is a choice from
 one of Host only mode, Gadget only mode and Dual Role mode,
 which means the role is

Re: [RESEND PATCH v3 2/4] usb: musb: Bugfix of_node assignment

2014-08-05 Thread Felipe Balbi 
On Tue, Aug 05, 2014 at 02:33:25PM +0200, Sebastian Andrzej Siewior wrote:
 On 08/04/2014 12:13 PM, Markus Pargmann wrote:
 
  In the long term I would suggest to move the DT probe over to the musb
  core code and we wouldn't need the node assignment anymore…
 
  [0] http://www.spinics.net/lists/linux-usb/msg94701.html
  
  Really old thread but I just noticed that this solution does not work
  for automatically parsed properties like 'default' pinctrl. I added
  'default' pinctrl settings for the musb device node. They are
  automatically setup by the driver core infrastracture as expected.
  
  The problem is that the 'default' pincontrol settings will be applied
  again for the musb-hdrc because they are extracted from the of_ndoe
  data. This fails because they are already claimed by the 'musb-dsps'
  driver. musb-hdrc continues probing, but there is a big error message
  that it failed:
  
  [1.181912] pinctrl-single 44e10800.pinmux: pin 44e10a20.0 already 
  requested by 47401c00.usb; cannot clai
  m for musb-hdrc.1.auto
  [1.194053] pinctrl-single 44e10800.pinmux: pin-136 (musb-hdrc.1.auto) 
  status -22
  [1.201930] pinctrl-single 44e10800.pinmux: could not request pin 136 
  (44e10a20.0) from group pinmux_usb1
  _pins  on device pinctrl-single
  [1.214790] musb-hdrc musb-hdrc.1.auto: Error applying setting, reverse 
  things back
  
  Any ideas how to solve it for mainline?
 
 Just what I said last time and I hope Felipe has the same opinion:
 Teach musb-hdrc DT. Which means ti,musb-am33xx would be listed for
 for musb-hdrc itself and we would lose that child device. The
 additional ops that we have would be passed via the data field next to
 the id.

sounds good to me.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH net-next 1/1] net: reduce USB network driver config options.

2014-08-05 Thread Francois Romieu 
From: Francois Romieu rom...@fr.zoreil.com

USB network drivers are already handled in drivers/net/usb/Kconfig.
Let's save the maintenance burden of dependencies in drivers/net/Makefile.

The newly introduced USB_NET_DRIVERS umbrella config option defaults
to 'y' so as to minimize the changes of behavior.

Signed-off-by: Francois Romieu rom...@fr.zoreil.com
---
 drivers/net/Makefile|  9 +
 drivers/net/usb/Kconfig | 13 -
 2 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index fa49d45..61aefdd 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -61,14 +61,7 @@ obj-$(CONFIG_VMXNET3) += vmxnet3/
 obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o
 obj-$(CONFIG_XEN_NETDEV_BACKEND) += xen-netback/
 
-obj-$(CONFIG_USB_CATC)  += usb/
-obj-$(CONFIG_USB_KAWETH)+= usb/
-obj-$(CONFIG_USB_PEGASUS)   += usb/
-obj-$(CONFIG_USB_RTL8150)   += usb/
-obj-$(CONFIG_USB_HSO)  += usb/
-obj-$(CONFIG_USB_USBNET)+= usb/
-obj-$(CONFIG_USB_IPHETH)+= usb/
-obj-$(CONFIG_USB_CDC_PHONET)   += usb/
+obj-$(CONFIG_USB_NET_DRIVERS) += usb/
 
 obj-$(CONFIG_HYPERV_NET) += hyperv/
 obj-$(CONFIG_NTB_NETDEV) += ntb_netdev.o
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 7e7269f..9f194a0 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -1,12 +1,16 @@
 #
 # USB Network devices configuration
 #
-comment Networking support is needed for USB Network Adapter support
-   depends on USB  !NET
+comment Host-side USB support is needed for USB Network Adapter support
+   depends on !USB  NET
 
-menu USB Network Adapters
+menuconfig USB_NET_DRIVERS
+   bool USB Network Adapters
+   default y
depends on USB  NET
 
+if USB_NET_DRIVERS
+
 config USB_CATC
tristate USB CATC NetMate-based Ethernet device support
select CRC32
@@ -568,5 +572,4 @@ config USB_VL600
 
  http://ubuntuforums.org/showpost.php?p=10589647postcount=17
 
-
-endmenu
+endif # USB_NET_DRIVERS
-- 
1.9.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

Re: [PATCH net-next 1/1] net: reduce USB network driver config options.

2014-08-05 Thread David Miller 
From: Francois Romieu rom...@fr.zoreil.com
Date: Tue, 5 Aug 2014 23:10:52 +0200

 From: Francois Romieu rom...@fr.zoreil.com
 
 USB network drivers are already handled in drivers/net/usb/Kconfig.
 Let's save the maintenance burden of dependencies in drivers/net/Makefile.
 
 The newly introduced USB_NET_DRIVERS umbrella config option defaults
 to 'y' so as to minimize the changes of behavior.
 
 Signed-off-by: Francois Romieu rom...@fr.zoreil.com

Looks great, applied, thanks!
--
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: Register u-blox FW2770 and FW2760 modems with Option USB serial driver

2014-08-05 Thread Brennan Ashton 
Both devices have the same VID and PID.

This patch has been tested on both of these modem versions.

Signed-off-by: Brennan Ashton bash...@brennanashton.com
---
 drivers/usb/serial/option.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a968894..b398ab7 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -494,6 +494,10 @@ static void option_instat_callback(struct urb *urb);
 #define INOVIA_VENDOR_ID   0x20a6
 #define INOVIA_SEW858  0x1105
 
+/* u-blox */
+#define UBLOX_VENDOR_ID0x15eb
+#define UBLOX_PRODUCT_FW2770   0x0001
+
 /* some devices interfaces need special handling due to a number of reasons */
 enum option_blacklist_reason {
OPTION_BLACKLIST_NONE = 0,
@@ -1724,6 +1728,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /* 
D-Link DWM-156/C1 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
+   { USB_DEVICE(UBLOX_VENDOR_ID, UBLOX_PRODUCT_FW2770) },
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);
-- 
1.9.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 v4 0/2] Patches to add dr_mode for dwc2

2014-08-05 Thread Kever Yang 
These two patches enable the dr_mode for the dwc2 usb
controller.  These are split from the patch series adding
rk3288 dwc2 support.

Changes in v4:
- From Doug's suggestion:
 -- remove dr_mode init from Kconfig code
 -- change the commit meesage

Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
- add dr_mode init from Kconfig

Changes in v2:
- Split out dr_mode and rk3288 bindings.
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG

Kever Yang (2):
  Documentation: dt-bindings: add dt binding info for dwc2 dr_mode
  usb: dwc2: add 'mode' which based on Kconfig select or dts setting

 Documentation/devicetree/bindings/usb/dwc2.txt |  2 ++
 drivers/usb/dwc2/core.c| 18 ++
 drivers/usb/dwc2/core.h|  5 +
 drivers/usb/dwc2/platform.c|  4 
 4 files changed, 29 insertions(+)

-- 
1.9.1

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

[PATCH v4 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting

2014-08-05 Thread Kever Yang 
According to the dr_mode, the otg controller can work as
device role and host role. Some boards always want to use host mode
and some other boards want to use gadget mode. We use the dts setting
to set dwc2's mode, rather than fixing it to whatever hardware says.

Signed-off-by: Kever Yang kever.y...@rock-chips.com
Acked-by: Paul Zimmerman pa...@synopsys.com
---

Changes in v4:
- From Doug's suggestion:
 -- remove dr_mode init from Kconfig code
 -- change the commit meesage

Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
change the commit message
- add dr_mode init from Kconfig

Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG

 drivers/usb/dwc2/core.c | 18 ++
 drivers/usb/dwc2/core.h |  5 +
 drivers/usb/dwc2/platform.c |  4 
 3 files changed, 27 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 {
u32 greset;
int count = 0;
+   u32 gusbcfg;
 
dev_vdbg(hsotg-dev, %s()\n, __func__);
 
@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (greset  GRSTCTL_CSFTRST);
 
+   if (hsotg-dr_mode == USB_DR_MODE_HOST) {
+   gusbcfg = readl(hsotg-regs + GUSBCFG);
+   gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+   gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+   writel(gusbcfg, hsotg-regs + GUSBCFG);
+   } else if (hsotg-dr_mode == USB_DR_MODE_PERIPHERAL) {
+   gusbcfg = readl(hsotg-regs + GUSBCFG);
+   gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+   gusbcfg |= GUSBCFG_FORCEDEVMODE;
+   writel(gusbcfg, hsotg-regs + GUSBCFG);
+   } else if (hsotg-dr_mode == USB_DR_MODE_OTG) {
+   gusbcfg = readl(hsotg-regs + GUSBCFG);
+   gusbcfg = ~GUSBCFG_FORCEHOSTMODE;
+   gusbcfg = ~GUSBCFG_FORCEDEVMODE;
+   writel(gusbcfg, hsotg-regs + GUSBCFG);
+   }
+
/*
 * NOTE: This long sleep is _very_ important, otherwise the core will
 * not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
  *  a_peripheral and b_device=b_host) this may not match
  *  the core, but allows the software to determine
  *  transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ *  - USB_DR_MODE_PERIPHERAL
+ *  - USB_DR_MODE_HOST
+ *  - USB_DR_MODE_OTG
  * @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
  *  transfer are in process of being queued
  * @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
/** Params to actually use */
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
+   enum usb_dr_mode dr_mode;
 
unsigned int queuing_high_bandwidth:1;
unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..5f0c4bb 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
 #include linux/of_device.h
 #include linux/platform_device.h
 
+#include linux/usb/of.h
+
 #include core.h
 #include hcd.h
 
@@ -171,6 +173,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
dev_dbg(dev-dev, mapped PA %08lx to VA %p\n,
(unsigned long)res-start, hsotg-regs);
 
+   hsotg-dr_mode = of_usb_get_dr_mode(dev-dev.of_node);
+
retval = dwc2_hcd_init(hsotg, irq, params);
if (retval)
return retval;
-- 
1.9.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 12/15] usb: musb: ux500: fix decimal printf format specifiers prefixed with 0x

2014-08-05 Thread Hans Wennborg 
The prefix suggests the number should be printed in hex, so use
the %x specifier to do that.

Found by using regex suggested by Joe Perches.

Signed-off-by: Hans Wennborg h...@hanshq.net
---
 drivers/usb/musb/ux500_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index 9aad00f..221faed 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -96,7 +96,7 @@ static bool ux500_configure_channel(struct dma_channel 
*channel,
struct musb *musb = ux500_channel-controller-private_data;
 
dev_dbg(musb-controller,
-   packet_sz=%d, mode=%d, dma_addr=0x%llu, len=%d is_tx=%d\n,
+   packet_sz=%d, mode=%d, dma_addr=0x%llx, len=%d is_tx=%d\n,
packet_sz, mode, (unsigned long long) dma_addr,
len, ux500_channel-is_tx);
 
-- 
2.0.0.526.g5318336

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

Re: [PATCH] USB: Register u-blox FW2770 and FW2760 modems with Option USB serial driver

2014-08-05 Thread Lars Melin 

On 2014-08-06 07:20, Brennan Ashton wrote:

Both devices have the same VID and PID.

This patch has been tested on both of these modem versions.

Signed-off-by: Brennan Ashton bash...@brennanashton.com
---
  drivers/usb/serial/option.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index a968894..b398ab7 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -494,6 +494,10 @@ static void option_instat_callback(struct urb *urb);
  #define INOVIA_VENDOR_ID  0x20a6
  #define INOVIA_SEW858 0x1105
  
+/* u-blox */

+#define UBLOX_VENDOR_ID0x15eb
+#define UBLOX_PRODUCT_FW2770   0x0001

.
The owner of the VID is VIA Telecom, China who also has manufactured the 
chip in this dongle.

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

Re: [PATCH] USB: Register u-blox FW2770 and FW2760 modems with Option USB serial driver

2014-08-05 Thread Brennan Ashton 
On 8/5/14, Lars Melin lars...@gmail.com wrote:
 On 2014-08-06 07:20, Brennan Ashton wrote:
 Both devices have the same VID and PID.

 This patch has been tested on both of these modem versions.

 Signed-off-by: Brennan Ashton bash...@brennanashton.com
 ---
   drivers/usb/serial/option.c | 5 +
   1 file changed, 5 insertions(+)

 diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
 index a968894..b398ab7 100644
 --- a/drivers/usb/serial/option.c
 +++ b/drivers/usb/serial/option.c
 @@ -494,6 +494,10 @@ static void option_instat_callback(struct urb *urb);
   #define INOVIA_VENDOR_ID   0x20a6
   #define INOVIA_SEW858  0x1105

 +/* u-blox */
 +#define UBLOX_VENDOR_ID 0x15eb
 +#define UBLOX_PRODUCT_FW27700x0001
 .
 The owner of the VID is VIA Telecom, China who also has manufactured the
 chip in this dongle.

I will update the patch to reflect the low level chipset which is CDS7
from Via Telecom

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