Re: [RFC v4] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

2014-10-10 Thread Kiran Raparthy
Hi Felipe,
Thank you very much for taking time in reviewing the patch.
I will try to improve the patch as per your suggestions.
however,i have few queries which i wanted to understand from you.

On 7 October 2014 19:55, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Oct 07, 2014 at 02:45:44PM +0530, Kiran Kumar Raparthy wrote:
 diff --git a/drivers/usb/phy/otg-wakeupsource.c 
 b/drivers/usb/phy/otg-wakeupsource.c
 new file mode 100644
 index 000..00d3359
 --- /dev/null
 +++ b/drivers/usb/phy/otg-wakeupsource.c
 @@ -0,0 +1,134 @@
 +/*
 + * otg-wakeupsource.c
 + *
 + * Copyright (C) 2011 Google, Inc.
 + *
 + * This software is licensed under the terms of the GNU General Public
 + * License version 2, as published by the Free Software Foundation, and
 + * may be copied, distributed, and modified under those terms.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + */
 +
 +#include linux/kernel.h
 +#include linux/device.h
 +#include linux/module.h
 +#include linux/notifier.h
 +#include linux/pm_wakeup.h
 +#include linux/spinlock.h
 +#include linux/usb/otg.h
 +
 +static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long 
 event)
 +{
 + unsigned long irqflags;
 +
 + spin_lock_irqsave(otgws_xceiv-otgws_slock, irqflags);
 +
 + switch (event) {
 + case USB_EVENT_VBUS:

 Looks like VBUS should be temporary too.

 + case USB_EVENT_ENUMERATED:
 + __pm_stay_awake(otgws_xceiv-wsource);
 + break;
 +
 + case USB_EVENT_NONE:
 + case USB_EVENT_ID:
 + case USB_EVENT_CHARGER:
 + __pm_wakeup_event(otgws_xceiv-wsource,
 + msecs_to_jiffies(TEMPORARY_HOLD_TIME));
 + break;
 +
 + default:
 + break;
 + }
 +
 + spin_unlock_irqrestore(otgws_xceiv-otgws_slock, irqflags);
 +}
 +
 +static int otgws_otg_usb2_notifications(struct notifier_block *nb,
 + unsigned long event, void *unused)
 +{
 + static struct usb_phy *otgws_xceiv;
 +
 + otgws_xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
 +
 + if (IS_ERR(otgws_xceiv)) {
 + pr_err(%s: No OTG transceiver found\n, __func__);
 + return PTR_ERR(otgws_xceiv);
 + }
 +
 + otgws_handle_event(otgws_xceiv, event);
 +
 + return NOTIFY_OK;
 +}
 +
 +static int otgws_otg_usb3_notifications(struct notifier_block *nb,
 + unsigned long event, void *unused)
 +{
 + static struct usb_phy *otgws_xceiv;
 +
 + otgws_xceiv = usb_get_phy(USB_PHY_TYPE_USB3);
 +
 + if (IS_ERR(otgws_xceiv)) {
 + pr_err(%s: No OTG transceiver found\n, __func__);
 + return PTR_ERR(otgws_xceiv);
 + }
 +
 + otgws_handle_event(otgws_xceiv, event);
 +
 + return NOTIFY_OK;
 +}
 +
 +static int otg_wakeupsource_init(void)
 +{
 + int ret_usb2;
 + int ret_usb3;
 + char wsource_name_usb2[40];
 + char wsource_name_usb3[40];
 + static struct usb_phy *otgws_xceiv_usb2;
 + static struct usb_phy *otgws_xceiv_usb3;
 +
 + otgws_xceiv_usb2 = usb_get_phy(USB_PHY_TYPE_USB2);
 + otgws_xceiv_usb3 = usb_get_phy(USB_PHY_TYPE_USB3);
 +
 + if (IS_ERR(otgws_xceiv_usb2)  IS_ERR(otgws_xceiv_usb3)) {
 + pr_err(%s: No OTG transceiver found\n, __func__);
 + return PTR_ERR(otgws_xceiv_usb2);
 + }
 +
 + spin_lock_init(otgws_xceiv_usb2-otgws_slock);
 + spin_lock_init(otgws_xceiv_usb3-otgws_slock);
 +
 + snprintf(wsource_name_usb2, sizeof(wsource_name_usb2), vbus-%s,
 + dev_name(otgws_xceiv_usb2-dev));
 + wakeup_source_init(otgws_xceiv_usb2-wsource, wsource_name_usb2);
 +
 + snprintf(wsource_name_usb3, sizeof(wsource_name_usb3), vbus-%s,
 + dev_name(otgws_xceiv_usb3-dev));
 + wakeup_source_init(otgws_xceiv_usb3-wsource, wsource_name_usb3);
 +
 + otgws_xceiv_usb2-otgws_nb.notifier_call = 
 otgws_otg_usb2_notifications;
 + ret_usb2 = usb_register_notifier(otgws_xceiv_usb2,
 + otgws_xceiv_usb2-otgws_nb);
 +
 + otgws_xceiv_usb3-otgws_nb.notifier_call = 
 otgws_otg_usb3_notifications;
 + ret_usb3 = usb_register_notifier(otgws_xceiv_usb3,
 + otgws_xceiv_usb3-otgws_nb);
 +
 + if (ret_usb2  ret_usb3) {
 + pr_err(%s: usb_register_notifier on transceiver failed\n,
 +  __func__);
 + wakeup_source_trash(otgws_xceiv_usb2-wsource);
 + wakeup_source_trash(otgws_xceiv_usb3-wsource);
 + otgws_xceiv_usb2 = NULL;
 + otgws_xceiv_usb3 = NULL;
 + return ret_usb2 | ret_usb3;
 + }
 +
 + return 0;
 +}
 +
 +late_initcall(otg_wakeupsource_init);

 you guys are really not getting what I mean. I 

Re: [PATCH] usb: host: xhci-plat: fix suspend/resume on xhci-rcar

2014-10-10 Thread Geert Uytterhoeven
On Thu, Oct 9, 2014 at 4:14 PM, Felipe Balbi ba...@ti.com wrote:
 On Thu, Oct 09, 2014 at 01:45:47PM +0900, Yoshihiro Shimoda wrote:
 This patch fixes an issue that suspend/resume cannot work correctly
 on xhci-rcar because the xhci driver output the following log:

 xhci-hcd ee00.usb: WARN: xHC CMD_RUN timeout

 So, this patch adds to set the XHCI_SLOW_SUSPEND quirk if xhci-rcar.

 do you have erratum number confirming this is needed for your platform ?
 We really don't want to enable quirks just because they help, we need to
 be sure HW is quirky. For example, we triggered the same thing on DRA7xx
 (which uses dwc3) but after digging a little, it seems like we're having
 memory access latency issues, not a problem with XHCI.

FWIW, xhci_handshake() runs a tight loop around udelay(1) for up to 16 ms
(160 ms when the quirk is enabled --- not counting loop overhead),
which looks like an area for improvement.

As the individual udelay() calls wait for only 1 us, the __bad_udelay()
sanity check Use only for very small delays (  2 msec) doesn't kick in.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 can't detect new devices after enabling runtime PM and disabling S3 wake (bug #85701)

2014-10-10 Thread Dmitry Nezhevenko
On Wed, Oct 08, 2014 at 12:38:35PM -0400, Alan Stern wrote:
 Dmitry, this gave me another idea.  Can you test the patch below,
 _without_ the previous patch?  And post the corresponding usbmon trace
 and dmesg log?

Hi, it doesn't work. All other attempts to plug device (after first one+)
don't produce any dmesg output.

[  140.766041] xhci_hcd :00:14.0: PME# enabled
[  140.801962] xhci_hcd :00:14.0: power state changed by ACPI to D3cold
[  211.872301] xhci_hcd :00:14.0: power state changed by ACPI to D0
[  211.976315] xhci_hcd :00:14.0: PME# disabled
[  211.976332] xhci_hcd :00:14.0: enabling bus mastering
[  211.976408] xhci_hcd :00:14.0: hcd_pci_runtime_resume: 0
[  211.976415] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: -16
[  211.976450] pci_pm_runtime_suspend(): hcd_pci_runtime_suspend+0x0/0x40 
[usbcore] returns -16
[  211.976452] usb usb1: usb wakeup-resume
[  211.976465] usb usb1: usb auto-resume
[  211.976498] hub 1-0:1.0: hub_resume
[  211.976551] usb usb1-port5: status 0107 change 
[  211.976573] usb usb1-port7: status 0107 change 
[  211.976616] usb usb1-port12: status 0507 change 
[  212.080230] hub 1-0:1.0: state 7 ports 15 chg 0040 evt 
[  212.080297] usb usb1-port6: status 0100, change , 12 Mb/s
[  212.080314] hub 1-0:1.0: hub_suspend
[  212.080328] usb usb1: bus auto-suspend, wakeup 1
[  212.080410] xhci_hcd :00:14.0: hcd_pci_runtime_suspend: 0
[  212.080458] xhci_hcd :00:14.0: PME# enabled
[  212.120252] xhci_hcd :00:14.0: power state changed by ACPI to D3cold

88042830e7c0 1795043513 S Ci:1:001:0 s a3 00  0001 0004 4 
88042830e7c0 1795043534 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043538 S Ci:1:001:0 s a3 00  0002 0004 4 
88042830e7c0 1795043545 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043548 S Ci:1:001:0 s a3 00  0003 0004 4 
88042830e7c0 1795043550 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043552 S Ci:1:001:0 s a3 00  0004 0004 4 
88042830e7c0 1795043555 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043557 S Ci:1:001:0 s a3 00  0005 0004 4 
88042830e7c0 1795043560 C Ci:1:001:0 0 4 = 0701
88042830e7c0 1795043564 S Ci:1:001:0 s a3 00  0006 0004 4 
88042830e7c0 1795043572 C Ci:1:001:0 0 4 = 00010100
88042830e7c0 1795043574 S Co:1:001:0 s 23 01 0010 0006  0
88042830e7c0 1795043578 C Co:1:001:0 0 0
88042830e7c0 1795043580 S Ci:1:001:0 s a3 00  0007 0004 4 
88042830e7c0 1795043582 C Ci:1:001:0 0 4 = 0701
88042830e7c0 1795043585 S Ci:1:001:0 s a3 00  0008 0004 4 
88042830e7c0 1795043596 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043598 S Ci:1:001:0 s a3 00  0009 0004 4 
88042830e7c0 1795043601 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043603 S Ci:1:001:0 s a3 00  000a 0004 4 
88042830e7c0 1795043606 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043608 S Ci:1:001:0 s a3 00  000b 0004 4 
88042830e7c0 1795043611 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043615 S Ci:1:001:0 s a3 00  000c 0004 4 
88042830e7c0 1795043625 C Ci:1:001:0 0 4 = 0705
88042830e7c0 1795043629 S Ci:1:001:0 s a3 00  000d 0004 4 
88042830e7c0 1795043640 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043641 S Ci:1:001:0 s a3 00  000e 0004 4 
88042830e7c0 1795043644 C Ci:1:001:0 0 4 = 0001
88042830e7c0 1795043646 S Ci:1:001:0 s a3 00  000f 0004 4 
88042830e7c0 1795043649 C Ci:1:001:0 0 4 = 0001
8800ad06bac0 1795147238 S Ii:1:001:1 -115:2048 4 
880427003040 1795147287 S Ci:1:001:0 s a3 00  0006 0004 4 
880427003040 1795147312 C Ci:1:001:0 0 4 = 0001
8800ad06bac0 1795147369 C Ii:1:001:1 -2:2048 0


 
 
 Index: usb-3.17/drivers/usb/core/hub.c
 ===
 --- usb-3.17.orig/drivers/usb/core/hub.c
 +++ usb-3.17/drivers/usb/core/hub.c
 @@ -1171,7 +1171,8 @@ static void hub_activate(struct usb_hub
* check for a new connection
*/
   if (udev || (portstatus  USB_PORT_STAT_CONNECTION) ||
 - (portstatus  USB_PORT_STAT_OVERCURRENT))
 + (portstatus  USB_PORT_STAT_OVERCURRENT) ||
 + (portchange  USB_PORT_STAT_C_CONNECTION))
   set_bit(port1, hub-change_bits);
  
   } else if (portstatus  USB_PORT_STAT_ENABLE) {
 
 
 

-- 
WBR, Dmitry
--
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] usb: gadget: f_fs: add no_disconnect mode

2014-10-10 Thread Robert Baldyga
On 10/09/2014 03:57 PM, Michal Nazarewicz wrote:
 On Thu, Oct 09 2014, Robert Baldyga r.bald...@samsung.com wrote:
 Since we can compose gadgets from many functions, there is the problem
 related to gadget breakage while FunctionFS daemon being closed. FFS
 function is userspace code so there is no way to know when it will close
 files (it doesn't matter what is the reason of this situation, it can
 be daemon logic, program breakage, process kill or any other). So when
 we have another function in gadget which, for example, sends some amount
 of data, does some software update or implements some real-time 
 functionality,
 we may want to keep the gadget connected despite FFS function is no longer
 functional.

 We can't just remove one of functions from gadget since it has been
 enumerated, so the only way to keep entire gadget working is to make
 broken FFS function deactivated but still visible to host. For this
 purpose this patch introduces no_disconnect mode. It can be enabled
 by setting mount option no_disconnect=1, and results with defering
 function disconnect to the moment of reopen ep0 file or filesystem
 unmount. After closing all endpoint files, FunctionFS is set to state
 FFS_DEACTIVATED.

 When ffs-state == FFS_DEACTIVATED:
 - function is still bound and visible to host,
 - setup requests are automatically stalled,
 - transfers on other endpoints are refused,
 - epfiles, except ep0, are deleted from the filesystem,
 - opening ep0 causes the function to be closes, and then FunctionFS 
   is ready for descriptors and string write,
 - unmounting of the FunctionFS instance causes the function to be closed.

 Signed-off-by: Robert Baldyga r.bald...@samsung.com
 
 Acked-by: Michal Nazarewicz min...@mina86.com
 
 Even though I have some concerns whether the mode should be enable via
 a mount option.  Perhaps it should come from the gadget or the daemon?
 I don't have strong feelings though, so I would be fine with the code as
 is.
 

I think that setting this option by daemon isn't good idea. It's better
to have this feature transparent for ffs daemons, and allow user to
decide how the function should behave after daemon breakage/termination.
This feature makes sense only because we don't want to have entire
gadget work dependent on ffs daemon, which is userspace code and we have
no guarantee it works properly.

Thanks,
Robert Baldyga

 ---

 Changelog:

 v3:
 - change option name to more descriptive and less scary,
 - fix cleaning up on unmount (call ffs_data_closed() in ffs_fs_kill_sb(),
   and ffs_data_clear() in ffs_data_closed() if ffs-opened is negative).

 v2: https://lkml.org/lkml/2014/10/7/109
 - delete epfiles, excepting ep0, when FFS is in zombie mode,
 - add description of FFS_ZOMBIE state,
 - minor cleanups.

 v1: https://lkml.org/lkml/2014/10/6/128

  drivers/usb/gadget/function/f_fs.c | 42 
 +++---
  drivers/usb/gadget/function/u_fs.h | 22 
  2 files changed, 57 insertions(+), 7 deletions(-)

 diff --git a/drivers/usb/gadget/function/f_fs.c 
 b/drivers/usb/gadget/function/f_fs.c
 index 12dbdaf..f326267 100644
 --- a/drivers/usb/gadget/function/f_fs.c
 +++ b/drivers/usb/gadget/function/f_fs.c
 @@ -606,6 +606,8 @@ static unsigned int ffs_ep0_poll(struct file *file, 
 poll_table *wait)
  }
  case FFS_CLOSING:
  break;
 +case FFS_DEACTIVATED:
 +break;
  }
  
  mutex_unlock(ffs-mutex);
 @@ -1152,6 +1154,7 @@ struct ffs_sb_fill_data {
  struct ffs_file_perms perms;
  umode_t root_mode;
  const char *dev_name;
 +bool no_disconnect;
  struct ffs_data *ffs_data;
  };
  
 @@ -1222,6 +1225,12 @@ static int ffs_fs_parse_opts(struct ffs_sb_fill_data 
 *data, char *opts)
  
  /* Interpret option */
  switch (eq - opts) {
 +case 13:
 +if (!memcmp(opts, no_disconnect, 13))
 +data-no_disconnect = !!value;
 +else
 +goto invalid;
 +break;
  case 5:
  if (!memcmp(opts, rmode, 5))
  data-root_mode  = (value  0555) | S_IFDIR;
 @@ -1286,6 +1295,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
  .gid = GLOBAL_ROOT_GID,
  },
  .root_mode = S_IFDIR | 0500,
 +.no_disconnect = false,
  };
  struct dentry *rv;
  int ret;
 @@ -1302,6 +1312,7 @@ ffs_fs_mount(struct file_system_type *t, int flags,
  if (unlikely(!ffs))
  return ERR_PTR(-ENOMEM);
  ffs-file_perms = data.perms;
 +ffs-no_disconnect = data.no_disconnect;
  
  ffs-dev_name = kstrdup(dev_name, GFP_KERNEL);
  if (unlikely(!ffs-dev_name)) {
 @@ -1333,6 +1344,7 @@ ffs_fs_kill_sb(struct super_block *sb)
  kill_litter_super(sb);
  if (sb-s_fs_info) {
  ffs_release_dev(sb-s_fs_info);
 +

[PATCH] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
Add new IDs for the Xsens Awinda Station and Awinda Dongle.

Cc: sta...@vger.kernel.org
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
 drivers/usb/serial/ftdi_sio.c | 2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index dc72b92..4969875 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -663,6 +663,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
{ USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 5937b2d..be3fffe 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -145,6 +145,8 @@
 #define XSENS_VID  0x2639
 #define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
 #define XSENS_MTW_PID  0x0200  /* Xsens MTw */
+#define XSENS_AWINDA_STATION_PID 0x0101
+#define XSENS_AWINDA_DONGLE_PID 0x0102
 #define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
 #define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
 #define XSENS_CONVERTER_2_PID  0xD38A
-- 
2.1.0

--
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: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Johan Hovold
On Fri, Oct 10, 2014 at 10:44:54AM +0200, Frans Klaver wrote:
 Add new IDs for the Xsens Awinda Station and Awinda Dongle.
 
 Cc: sta...@vger.kernel.org
 Signed-off-by: Frans Klaver frans.kla...@xsens.com
 ---
  drivers/usb/serial/ftdi_sio.c | 2 ++
  drivers/usb/serial/ftdi_sio_ids.h | 2 ++
  2 files changed, 4 insertions(+)
 
 diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
 index dc72b92..4969875 100644
 --- a/drivers/usb/serial/ftdi_sio.c
 +++ b/drivers/usb/serial/ftdi_sio.c
 @@ -663,6 +663,8 @@ static const struct usb_device_id id_table_combined[] = {
   { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
   { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
   { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
 + { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
 + { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },

Could you keep the XSENS_VID entries sorted alphabetically here?

   { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
   { USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
   { USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
 diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
 b/drivers/usb/serial/ftdi_sio_ids.h
 index 5937b2d..be3fffe 100644
 --- a/drivers/usb/serial/ftdi_sio_ids.h
 +++ b/drivers/usb/serial/ftdi_sio_ids.h
 @@ -145,6 +145,8 @@
  #define XSENS_VID0x2639
  #define XSENS_CONVERTER_PID  0xD00D  /* Xsens USB-serial converter */
  #define XSENS_MTW_PID0x0200  /* Xsens MTw */
 +#define XSENS_AWINDA_STATION_PID 0x0101
 +#define XSENS_AWINDA_DONGLE_PID 0x0102

And sorted by PID here (even though the two current entries are not, you
could reorder them as well).

I noticed that the below PIDs use the FTDI VID. Perhaps a comment or at
least a separating empty line would be appropriate.

  #define XSENS_CONVERTER_0_PID0xD388  /* Xsens USB converter */
  #define XSENS_CONVERTER_1_PID0xD389  /* Xsens Wireless Receiver */
  #define XSENS_CONVERTER_2_PID0xD38A

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] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
On Fri, Oct 10, 2014 at 11:01:17AM +0200, Johan Hovold wrote:
 On Fri, Oct 10, 2014 at 10:44:54AM +0200, Frans Klaver wrote:
  Add new IDs for the Xsens Awinda Station and Awinda Dongle.
  
  Cc: sta...@vger.kernel.org
  Signed-off-by: Frans Klaver frans.kla...@xsens.com
  ---
   drivers/usb/serial/ftdi_sio.c | 2 ++
   drivers/usb/serial/ftdi_sio_ids.h | 2 ++
   2 files changed, 4 insertions(+)
  
  diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
  index dc72b92..4969875 100644
  --- a/drivers/usb/serial/ftdi_sio.c
  +++ b/drivers/usb/serial/ftdi_sio.c
  @@ -663,6 +663,8 @@ static const struct usb_device_id id_table_combined[] = 
  {
  { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
  { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
  { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
  +   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
  +   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },
 
 Could you keep the XSENS_VID entries sorted alphabetically here?

Sure thing. Should have been obvious.

  { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
  { USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
  { USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
  diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
  b/drivers/usb/serial/ftdi_sio_ids.h
  index 5937b2d..be3fffe 100644
  --- a/drivers/usb/serial/ftdi_sio_ids.h
  +++ b/drivers/usb/serial/ftdi_sio_ids.h
  @@ -145,6 +145,8 @@
   #define XSENS_VID  0x2639
   #define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
   #define XSENS_MTW_PID  0x0200  /* Xsens MTw */
  +#define XSENS_AWINDA_STATION_PID 0x0101
  +#define XSENS_AWINDA_DONGLE_PID 0x0102
 
 And sorted by PID here (even though the two current entries are not, you
 could reorder them as well).
 
 I noticed that the below PIDs use the FTDI VID. Perhaps a comment or at
 least a separating empty line would be appropriate.
 
   #define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
   #define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
   #define XSENS_CONVERTER_2_PID  0xD38A

I'll move the new entries up. How about I throw in a separate patch that
cleans up stuff around the PID definitions? There's some alignment off
as well. That doesn't need to go into stable, I think.

Thanks,
Frans
--
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 v7 1/4] mfd: add support for Diolan DLN-2 devices

2014-10-10 Thread Johan Hovold
On Thu, Oct 09, 2014 at 11:27:12PM +0300, Octavian Purdila wrote:
 On Thu, Oct 9, 2014 at 10:44 PM, Joe Perches j...@perches.com wrote:
  On Thu, 2014-10-09 at 22:22 +0300, Octavian Purdila wrote:

  diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
  []
  +struct dln2_mod_rx_slots {
  +   /* RX slots bitmap */
  +   unsigned long bmap;
 
  Probably better as:
  DECLARE_BITMAP(bmap, DLN2_MAX_RX_SLOTS);
 
  Then a lot of ptr-bmap uses can be ptr-bmap
 
 
 Originally I was using DECLARE_BITMAP, but during the review process
 Johan suggested to use unsigned long. Now that I think about it, it
 sounds better to use DECLARE_BITMAP and of couse keep using
 find_first_bit, set_bit, etc. Johan do you see any issue with that?

No, that's fine as long as you keep the bitops.

  +struct dln2_dev {
  + struct usb_device *usb_dev;
  + struct usb_interface *interface;
  + u8 ep_in;
  + u8 ep_out;
  +
  + struct urb *rx_urb[DLN2_MAX_URBS];
  + void *rx_buf[DLN2_MAX_URBS];
  +
  + struct dln2_mod_rx_slots mod_rx_slots[DLN2_HANDLES];
  +
  + struct list_head event_cb_list;
  + spinlock_t event_cb_lock;
  +
  + bool disconnect;
  + int active_transfers;
  + wait_queue_head_t disconnect_wq;
  + spinlock_t disconnect_lock;
  +};
 
  Maybe reorder the bools and u8s to pack this a bit better?
 
 I prefer to keep it this way, it's not wasting a lot since you will
 only have a handful of these devices, and it keeps the related data
 together.

I agree.

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] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Johan Hovold
On Fri, Oct 10, 2014 at 11:12:09AM +0200, Frans Klaver wrote:
 On Fri, Oct 10, 2014 at 11:01:17AM +0200, Johan Hovold wrote:
  On Fri, Oct 10, 2014 at 10:44:54AM +0200, Frans Klaver wrote:

   diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
   b/drivers/usb/serial/ftdi_sio_ids.h
   index 5937b2d..be3fffe 100644
   --- a/drivers/usb/serial/ftdi_sio_ids.h
   +++ b/drivers/usb/serial/ftdi_sio_ids.h
   @@ -145,6 +145,8 @@
#define XSENS_VID0x2639
#define XSENS_CONVERTER_PID  0xD00D  /* Xsens USB-serial converter */
#define XSENS_MTW_PID0x0200  /* Xsens MTw */
   +#define XSENS_AWINDA_STATION_PID 0x0101
   +#define XSENS_AWINDA_DONGLE_PID 0x0102
  
  And sorted by PID here (even though the two current entries are not, you
  could reorder them as well).
  
  I noticed that the below PIDs use the FTDI VID. Perhaps a comment or at
  least a separating empty line would be appropriate.
  
#define XSENS_CONVERTER_0_PID0xD388  /* Xsens USB converter */
#define XSENS_CONVERTER_1_PID0xD389  /* Xsens Wireless Receiver */
#define XSENS_CONVERTER_2_PID0xD38A
 
 I'll move the new entries up. How about I throw in a separate patch that
 cleans up stuff around the PID definitions? There's some alignment off
 as well. That doesn't need to go into stable, I think.

As long as you keep the clean up minimal (e.g. the reorder the two
entries above and add a comment or new line, skip the alignment bit) it
can all go in one patch along with the new PIDs.

That way there'll be no conflicts when future PID-patches get backported
to stable.

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] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
On Fri, Oct 10, 2014 at 11:20:14AM +0200, Johan Hovold wrote:
 On Fri, Oct 10, 2014 at 11:12:09AM +0200, Frans Klaver wrote:
  I'll move the new entries up. How about I throw in a separate patch that
  cleans up stuff around the PID definitions? There's some alignment off
  as well. That doesn't need to go into stable, I think.
 
 As long as you keep the clean up minimal (e.g. the reorder the two
 entries above and add a comment or new line, skip the alignment bit) it
 can all go in one patch along with the new PIDs.
 
 That way there'll be no conflicts when future PID-patches get backported
 to stable.

Alright. Expect a new patch soonish.

Thanks,
Frans
--
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] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
Add new IDs for the Xsens Awinda Station and Awinda Dongle.

While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID and those using FTDI's VID.

Cc: sta...@vger.kernel.org
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
 drivers/usb/serial/ftdi_sio.c | 2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index dc72b92..e4eccb6 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -661,6 +661,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 5937b2d..b68084c 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -143,8 +143,12 @@
  * Xsens Technologies BV products (http://www.xsens.com).
  */
 #define XSENS_VID  0x2639
-#define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
+#define XSENS_AWINDA_STATION_PID 0x0101
+#define XSENS_AWINDA_DONGLE_PID 0x0102
 #define XSENS_MTW_PID  0x0200  /* Xsens MTw */
+#define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
+
+/* Xsens devices using FTDI VID */
 #define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
 #define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
 #define XSENS_CONVERTER_2_PID  0xD38A
-- 
2.1.0

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


Re: [PATCH v2] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Johan Hovold
On Fri, Oct 10, 2014 at 11:32:27AM +0200, Frans Klaver wrote:
 Add new IDs for the Xsens Awinda Station and Awinda Dongle.
 
 While at it, order the definitions by PID and add a logical separation
 between devices using Xsens' VID and those using FTDI's VID.
 
 Cc: sta...@vger.kernel.org
 Signed-off-by: Frans Klaver frans.kla...@xsens.com
 ---
  drivers/usb/serial/ftdi_sio.c | 2 ++
  drivers/usb/serial/ftdi_sio_ids.h | 6 +-
  2 files changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
 index dc72b92..e4eccb6 100644
 --- a/drivers/usb/serial/ftdi_sio.c
 +++ b/drivers/usb/serial/ftdi_sio.c
 @@ -661,6 +661,8 @@ static const struct usb_device_id id_table_combined[] = {
   { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
   { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
   { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
 + { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
 + { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },

These are still not in alphabetical order. :)

   { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
   { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
   { USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
 diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
 b/drivers/usb/serial/ftdi_sio_ids.h
 index 5937b2d..b68084c 100644
 --- a/drivers/usb/serial/ftdi_sio_ids.h
 +++ b/drivers/usb/serial/ftdi_sio_ids.h
 @@ -143,8 +143,12 @@
   * Xsens Technologies BV products (http://www.xsens.com).
   */
  #define XSENS_VID0x2639
 -#define XSENS_CONVERTER_PID  0xD00D  /* Xsens USB-serial converter */
 +#define XSENS_AWINDA_STATION_PID 0x0101
 +#define XSENS_AWINDA_DONGLE_PID 0x0102
  #define XSENS_MTW_PID0x0200  /* Xsens MTw */
 +#define XSENS_CONVERTER_PID  0xD00D  /* Xsens USB-serial converter */
 +
 +/* Xsens devices using FTDI VID */
  #define XSENS_CONVERTER_0_PID0xD388  /* Xsens USB converter */
  #define XSENS_CONVERTER_1_PID0xD389  /* Xsens Wireless Receiver */
  #define XSENS_CONVERTER_2_PID0xD38A

Looks good otherwise.

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 v2] usb: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
On Fri, Oct 10, 2014 at 11:34:43AM +0200, Johan Hovold wrote:
 On Fri, Oct 10, 2014 at 11:32:27AM +0200, Frans Klaver wrote:
  Add new IDs for the Xsens Awinda Station and Awinda Dongle.
  
  While at it, order the definitions by PID and add a logical separation
  between devices using Xsens' VID and those using FTDI's VID.
  
  Cc: sta...@vger.kernel.org
  Signed-off-by: Frans Klaver frans.kla...@xsens.com
  ---
   drivers/usb/serial/ftdi_sio.c | 2 ++
   drivers/usb/serial/ftdi_sio_ids.h | 6 +-
   2 files changed, 7 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
  index dc72b92..e4eccb6 100644
  --- a/drivers/usb/serial/ftdi_sio.c
  +++ b/drivers/usb/serial/ftdi_sio.c
  @@ -661,6 +661,8 @@ static const struct usb_device_id id_table_combined[] = 
  {
  { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
  { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
  { USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
  +   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
  +   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },
 
 These are still not in alphabetical order. :)

*goes and hides in the woods*

Frans
--
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: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Frans Klaver
Add new IDs for the Xsens Awinda Station and Awinda Dongle.

While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID and those using FTDI's VID.

Cc: sta...@vger.kernel.org
Signed-off-by: Frans Klaver frans.kla...@xsens.com
---
Third time's a charm.

 drivers/usb/serial/ftdi_sio.c | 2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index dc72b92..1f73ca3 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -661,6 +661,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_DONGLE_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 5937b2d..b68084c 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -143,8 +143,12 @@
  * Xsens Technologies BV products (http://www.xsens.com).
  */
 #define XSENS_VID  0x2639
-#define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
+#define XSENS_AWINDA_STATION_PID 0x0101
+#define XSENS_AWINDA_DONGLE_PID 0x0102
 #define XSENS_MTW_PID  0x0200  /* Xsens MTw */
+#define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
+
+/* Xsens devices using FTDI VID */
 #define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
 #define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
 #define XSENS_CONVERTER_2_PID  0xD38A
-- 
2.1.0

--
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: serial: ftdi_sio: add Awinda Station and Dongle products

2014-10-10 Thread Johan Hovold
On Fri, Oct 10, 2014 at 11:52:08AM +0200, Frans Klaver wrote:
 Add new IDs for the Xsens Awinda Station and Awinda Dongle.
 
 While at it, order the definitions by PID and add a logical separation
 between devices using Xsens' VID and those using FTDI's VID.
 
 Cc: sta...@vger.kernel.org
 Signed-off-by: Frans Klaver frans.kla...@xsens.com
 ---
 Third time's a charm.

Thanks for your persistence. :)

I'll queue it up when rc1 is out.

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


[PATCH] USB: phy: add ralink SoC driver

2014-10-10 Thread John Crispin
RT3352, RT5350 and the MT762x SoCs all have a usb phy that we need to setup.

Signed-off-by: John Crispin blo...@openwrt.org
---
 drivers/usb/phy/Kconfig  |8 ++
 drivers/usb/phy/Makefile |1 +
 drivers/usb/phy/phy-ralink.c |  192 ++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/usb/phy/phy-ralink.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e253fa0..ba0ef3a 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -215,6 +215,14 @@ config USB_RCAR_GEN2_PHY
  To compile this driver as a module, choose M here: the
  module will be called phy-rcar-gen2-usb.
 
+config USB_RALINK_PHY
+   bool Ralink USB PHY controller Driver
+   depends on MIPS  RALINK
+   select USB_PHY
+   help
+ Enable this to support ralink USB phy controller for ralink
+ SoCs.
+
 config USB_ULPI
bool Generic ULPI Transceiver Driver
depends on ARM || ARM64
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 24a9133..1bebfc5 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)  += phy-msm-usb.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
+obj-$(CONFIG_USB_RALINK_PHY)   += phy-ralink.o
 obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
 obj-$(CONFIG_USB_RCAR_GEN2_PHY)+= phy-rcar-gen2-usb.o
 obj-$(CONFIG_USB_ULPI) += phy-ulpi.o
diff --git a/drivers/usb/phy/phy-ralink.c b/drivers/usb/phy/phy-ralink.c
new file mode 100644
index 000..c54b2a8
--- /dev/null
+++ b/drivers/usb/phy/phy-ralink.c
@@ -0,0 +1,192 @@
+/*
+ * Copyright (C) 2013 John Crispin blo...@openwrt.org
+ *
+ * based on: Renesas R-Car USB phy driver
+ *
+ * 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/delay.h
+#include linux/io.h
+#include linux/usb/otg.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/module.h
+#include linux/reset.h
+
+#include asm/mach-ralink/ralink_regs.h
+
+#define RT_SYSC_REG_SYSCFG10x014
+#define RT_SYSC_REG_CLKCFG10x030
+#define RT_SYSC_REG_USB_PHY_CFG0x05c
+
+#define RT_RSTCTRL_UDEVBIT(25)
+#define RT_RSTCTRL_UHSTBIT(22)
+#define RT_SYSCFG1_USB0_HOST_MODE  BIT(10)
+
+#define MT7620_CLKCFG1_UPHY0_CLK_ENBIT(25)
+#define MT7620_CLKCFG1_UPHY1_CLK_ENBIT(22)
+#define RT_CLKCFG1_UPHY1_CLK_ENBIT(20)
+#define RT_CLKCFG1_UPHY0_CLK_ENBIT(18)
+
+#define USB_PHY_UTMI_8B60M BIT(1)
+#define UDEV_WAKEUPBIT(0)
+
+static atomic_t usb_pwr_ref = ATOMIC_INIT(0);
+static struct reset_control *rstdev;
+static struct reset_control *rsthost;
+static u32 phy_clk;
+
+static void usb_phy_enable(int state)
+{
+   if (state)
+   rt_sysc_m32(0, phy_clk, RT_SYSC_REG_CLKCFG1);
+   else
+   rt_sysc_m32(phy_clk, 0, RT_SYSC_REG_CLKCFG1);
+   mdelay(100);
+}
+
+static int usb_power_on(struct usb_phy *phy)
+{
+   if (atomic_inc_return(usb_pwr_ref) == 1) {
+   u32 t;
+
+   usb_phy_enable(1);
+
+   if (OTG_STATE_B_HOST) {
+   rt_sysc_m32(0, RT_SYSCFG1_USB0_HOST_MODE,
+   RT_SYSC_REG_SYSCFG1);
+   if (!IS_ERR(rsthost))
+   reset_control_deassert(rsthost);
+   } else {
+   rt_sysc_m32(RT_SYSCFG1_USB0_HOST_MODE, 0,
+   RT_SYSC_REG_SYSCFG1);
+   if (!IS_ERR(rstdev))
+   reset_control_deassert(rstdev);
+   }
+   mdelay(100);
+
+   t = rt_sysc_r32(RT_SYSC_REG_USB_PHY_CFG);
+   dev_info(phy-dev, remote usb device wakeup %s\n,
+   (t  UDEV_WAKEUP) ? enabled : disabled);
+   if (t  USB_PHY_UTMI_8B60M)
+   dev_info(phy-dev, UTMI 8bit 60MHz\n);
+   else
+   dev_info(phy-dev, UTMI 16bit 30MHz\n);
+   }
+
+   return 0;
+}
+
+static void usb_power_off(struct usb_phy *phy)
+{
+   if (atomic_dec_return(usb_pwr_ref) == 0) {
+   usb_phy_enable(0);
+   if (!IS_ERR(rstdev))
+   reset_control_assert(rstdev);
+   if (!IS_ERR(rsthost))
+   reset_control_assert(rsthost);
+   }
+}
+
+static int usb_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+   otg-gadget = NULL;
+   

Re: Bug 83371 - Kernel Panic on ASM1051e USB 3.0 Drive Connection

2014-10-10 Thread Mathias Nyman
On 10/10/2014 04:11 AM, Ivan Fossa Ferrari wrote:
 I have tested Kernel versions starting with 3.15.1 all the way to
 3.15.10 under both Arch and Fedora, using both NEC and Intel host
 controllers and the result is always the same.
 
 Connecting a Asmedia ASM1051e device causes a kernel panic after about
 a minute of connection.
 
 Interestingly, Asmedia ASM1053 devices do not cause this issue.
 
 I have plenty of hardware to test with, so please, let me know if
 there is any logs I can provide, or test I can do that will help
 resolve this issue.
 
 Sincerely,
 Ivan
 Plugable Technologies
 --
 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
 

I believe Hans de Goede found many UAS issues with ASM1051.
A patch to only use it in BOT mode was added to 3.17

commit a9c54caa456dccba938005f6479892b589975e6a
uas: Disable uas on ASM1051 devices

-Mathias
--
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: function: Remove redundant usb_free_all_descriptors

2014-10-10 Thread pavi1729 ivap
From 3272817673910c63682e8b91ce0efaef190a399a Mon Sep 17 00:00:00 2001
From: Pavitra pavitra1...@gmail.com
Date: Fri, 10 Oct 2014 16:05:30 +0530
Subject: [PATCH] usb: gadget: function: Remove redundant
 usb_free_all_descriptors

Removed the usb_free_all_descriptors call in *_bind functions
as this call is already present in usb_assign_descriptors.
usb_assign_descriptors is the only call where usb descriptor
allocation happens, also in case of error freeing of the
allocated memory takes place in the same call. Hence the
call in the *_bind functions are redundant.
Also the presence of usb_free_all_descriptors in the *_bind
functions might result in double-free corruption of the
allocated mmeory.

Signed-off-by: Pavitra pavitra1...@gmail.com
---
 drivers/usb/gadget/function/f_eem.c| 1 -
 drivers/usb/gadget/function/f_hid.c| 2 --
 drivers/usb/gadget/function/f_ncm.c| 1 -
 drivers/usb/gadget/function/f_phonet.c | 1 -
 drivers/usb/gadget/function/f_rndis.c  | 1 -
 drivers/usb/gadget/function/f_subset.c | 1 -
 drivers/usb/gadget/function/f_uac2.c   | 1 -
 7 files changed, 8 deletions(-)

diff --git a/drivers/usb/gadget/function/f_eem.c
b/drivers/usb/gadget/function/f_eem.c
index 4d8b236..c9e90de 100644
--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (eem-port.out_ep)
 eem-port.out_ep-driver_data = NULL;
 if (eem-port.in_ep)
diff --git a/drivers/usb/gadget/function/f_hid.c
b/drivers/usb/gadget/function/f_hid.c
index a95290a..5c67d28 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -652,8 +652,6 @@ static void hidg_unbind(struct usb_configuration
*c, struct usb_function *f)
 kfree(hidg-req-buf);
 usb_ep_free_request(hidg-in_ep, hidg-req);

-usb_free_all_descriptors(f);
-
 kfree(hidg-report_desc);
 kfree(hidg);
 }
diff --git a/drivers/usb/gadget/function/f_ncm.c
b/drivers/usb/gadget/function/f_ncm.c
index bcdc882..38a9279 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (ncm-notify_req) {
 kfree(ncm-notify_req-buf);
 usb_ep_free_request(ncm-notify, ncm-notify_req);
diff --git a/drivers/usb/gadget/function/f_phonet.c
b/drivers/usb/gadget/function/f_phonet.c
index b9cfc15..74ddcac 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -571,7 +571,6 @@ err_req:
 for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
 usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
 err:
-usb_free_all_descriptors(f);
 if (fp-out_ep)
 fp-out_ep-driver_data = NULL;
 if (fp-in_ep)
diff --git a/drivers/usb/gadget/function/f_rndis.c
b/drivers/usb/gadget/function/f_rndis.c
index ddb09dc..e257eff 100644
--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -820,7 +820,6 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
 fail:
 kfree(f-os_desc_table);
 f-os_desc_n = 0;
-usb_free_all_descriptors(f);

 if (rndis-notify_req) {
 kfree(rndis-notify_req-buf);
diff --git a/drivers/usb/gadget/function/f_subset.c
b/drivers/usb/gadget/function/f_subset.c
index 1ea8baf..e3dfa67 100644
--- a/drivers/usb/gadget/function/f_subset.c
+++ b/drivers/usb/gadget/function/f_subset.c
@@ -380,7 +380,6 @@ geth_bind(struct usb_configuration *c, struct
usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 /* we might as well release our claims on endpoints */
 if (geth-port.out_ep)
 geth-port.out_ep-driver_data = NULL;
diff --git a/drivers/usb/gadget/function/f_uac2.c
b/drivers/usb/gadget/function/f_uac2.c
index 3ed89ec..c294fb9 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -1012,7 +1012,6 @@ afunc_bind(struct usb_configuration *cfg, struct
usb_function *fn)
 err:
 kfree(agdev-uac2.p_prm.rbuf);
 kfree(agdev-uac2.c_prm.rbuf);
-usb_free_all_descriptors(fn);
 if (agdev-in_ep)
 agdev-in_ep-driver_data = NULL;
 if (agdev-out_ep)
-- 
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


[PATCH v3 1/2] usb: ehci: add port_power callback and override

2014-10-10 Thread Peter Chen
From: Michael Grzeschik m.grzesc...@pengutronix.de

The current EHCI implementation is prepared to toggle the
PORT_POWER bit to enable or disable a USB-Port. In some
cases this port power can not be toggled by the PORT_POWER
bit but instead i.e. by an external GPIO.
This patch adds a override callback for port power control,
the platform code can use it for its specific usage.

Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/host/ehci-hcd.c |   10 +-
 drivers/usb/host/ehci-hub.c |   41 +++--
 drivers/usb/host/ehci.h |3 +++
 include/linux/usb/hcd.h |3 +++
 4 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 15feaf9..b59c8fa 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -328,10 +328,15 @@ static void end_unlink_intr(struct ehci_hcd *ehci, struct 
ehci_qh *qh);
 static void ehci_turn_off_all_ports(struct ehci_hcd *ehci)
 {
int port = HCS_N_PORTS(ehci-hcs_params);
+   struct usb_hcd *hcd = ehci_to_hcd(ehci);
 
-   while (port--)
+   while (port--) {
ehci_writel(ehci, PORT_RWC_BITS,
ehci-regs-port_status[port]);
+   spin_unlock_irq(ehci-lock);
+   hcd-driver-port_power(hcd, port, false);
+   spin_lock_irq(ehci-lock);
+   }
 }
 
 /*
@@ -1216,6 +1221,7 @@ static const struct hc_driver ehci_hc_driver = {
.bus_resume =   ehci_bus_resume,
.relinquish_port =  ehci_relinquish_port,
.port_handed_over = ehci_port_handed_over,
+   .port_power =   ehci_port_power,
 
/*
 * device support
@@ -1233,6 +1239,8 @@ void ehci_init_driver(struct hc_driver *drv,
drv-hcd_priv_size += over-extra_priv_size;
if (over-reset)
drv-reset = over-reset;
+   if (over-port_power)
+   drv-port_power = over-port_power;
}
 }
 EXPORT_SYMBOL_GPL(ehci_init_driver);
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 5728829..bfb7b75 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -70,8 +70,8 @@ static void ehci_handover_companion_ports(struct ehci_hcd 
*ehci)
reg = ehci-regs-port_status[port];
status = ehci_readl(ehci, reg)  ~PORT_RWC_BITS;
if (!(status  PORT_POWER)) {
-   status |= PORT_POWER;
ehci_writel(ehci, status, reg);
+   hcd-driver-port_power(hcd, port, true);
}
}
}
@@ -952,9 +952,11 @@ int ehci_hub_control(
clear_bit(wIndex, ehci-port_c_suspend);
break;
case USB_PORT_FEAT_POWER:
-   if (HCS_PPC (ehci-hcs_params))
-   ehci_writel(ehci, temp  ~PORT_POWER,
-   status_reg);
+   if (HCS_PPC(ehci-hcs_params)) {
+   spin_unlock_irqrestore(ehci-lock, flags);
+   hcd-driver-port_power(hcd, wIndex, false);
+   spin_lock_irqsave(ehci-lock, flags);
+   }
break;
case USB_PORT_FEAT_C_CONNECTION:
ehci_writel(ehci, temp | PORT_CSC, status_reg);
@@ -1004,9 +1006,11 @@ int ehci_hub_control(
 */
if (((temp  PORT_OC) || (ehci-need_oc_pp_cycle))
 HCS_PPC(ehci-hcs_params)) {
-   ehci_writel(ehci,
-   temp  ~(PORT_RWC_BITS | PORT_POWER),
-   status_reg);
+   temp = ~PORT_RWC_BITS;
+   ehci_writel(ehci, temp, status_reg);
+   spin_unlock_irqrestore(ehci-lock, flags);
+   hcd-driver-port_power(hcd, wIndex, false);
+   spin_lock_irqsave(ehci-lock, flags);
temp = ehci_readl(ehci, status_reg);
}
}
@@ -1187,9 +1191,11 @@ int ehci_hub_control(
set_bit(wIndex, ehci-suspended_ports);
break;
case USB_PORT_FEAT_POWER:
-   if (HCS_PPC (ehci-hcs_params))
-   ehci_writel(ehci, temp | PORT_POWER,
-   status_reg);
+   if (HCS_PPC(ehci-hcs_params)) {
+   

[PATCH v3 0/2] usb: ehci: add portpower override

2014-10-10 Thread Peter Chen
Michael, Hope you are ok I have changed your patches.

Hi Alan,

At the first patch, it defines one hcd driver's API .port_power,
which is used to power on/off dedicated port, the implementation
of this API is the same which it used to replace, and the platform
can override it if necessary.

At the second patch, the chipidea host override .port_power to control
regulator during the port power control.

Michael Grzeschik (2):
  usb: ehci: add port_power callback and override
  usb: chipidea: host: add portpower override

 drivers/usb/chipidea/host.c |   69 ++-
 drivers/usb/host/ehci-hcd.c |   10 ++-
 drivers/usb/host/ehci-hub.c |   41 ++---
 drivers/usb/host/ehci.h |3 ++
 include/linux/usb/hcd.h |3 ++
 5 files changed, 94 insertions(+), 32 deletions(-)

-- 
1.7.9.5

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


[PATCH v3 2/2] usb: chipidea: host: add portpower override

2014-10-10 Thread Peter Chen
From: Michael Grzeschik m.grzesc...@pengutronix.de

This patch adds an external portpower override callback, only single
port regulator control is supported now.

Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de
Signed-off-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/host.c |   69 ++-
 1 file changed, 48 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index ebde7b6..615feb2 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -34,6 +34,46 @@
 
 static struct hc_driver __read_mostly ci_ehci_hc_driver;
 
+struct ehci_ci_priv {
+   struct regulator *reg_vbus;
+};
+
+static int ehci_ci_portpower(struct usb_hcd *hcd, int portnum, bool enable)
+{
+   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+   struct ehci_ci_priv *priv = (struct ehci_ci_priv *)ehci-priv;
+   struct device *dev = hcd-self.controller;
+   struct ci_hdrc *ci = dev_get_drvdata(dev);
+   int ret = 0;
+   int port = HCS_N_PORTS(ehci-hcs_params);
+
+   ehci_port_power(hcd, portnum, enable);
+
+   if (priv-reg_vbus  !ci_otg_is_fsm_mode(ci)) {
+   if (port  1) {
+   dev_warn(dev,
+   Not support multi-port regulator control\n);
+   return 0;
+   }
+   if (enable)
+   ret = regulator_enable(priv-reg_vbus);
+   else
+   ret = regulator_disable(priv-reg_vbus);
+   if (ret) {
+   dev_err(dev,
+   Failed to %s vbus regulator, ret=%d\n,
+   enable ? enable : disable, ret);
+   return ret;
+   }
+   }
+   return 0;
+};
+
+static const struct ehci_driver_overrides ehci_ci_overrides = {
+   .extra_priv_size = sizeof(struct ehci_ci_priv),
+   .port_power  = ehci_ci_portpower,
+};
+
 static irqreturn_t host_irq(struct ci_hdrc *ci)
 {
return usb_hcd_irq(ci-irq, ci-hcd);
@@ -43,6 +83,7 @@ static int host_start(struct ci_hdrc *ci)
 {
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
+   struct ehci_ci_priv *priv;
int ret;
 
if (usb_disabled())
@@ -68,23 +109,15 @@ static int host_start(struct ci_hdrc *ci)
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
ehci-imx28_write_fix = ci-imx28_write_fix;
 
-   /*
-* vbus is always on if host is not in OTG FSM mode,
-* otherwise should be controlled by OTG FSM
-*/
-   if (ci-platdata-reg_vbus  !ci_otg_is_fsm_mode(ci)) {
-   ret = regulator_enable(ci-platdata-reg_vbus);
-   if (ret) {
-   dev_err(ci-dev,
-   Failed to enable vbus regulator, ret=%d\n,
-   ret);
-   goto put_hcd;
-   }
-   }
+   priv = (struct ehci_ci_priv *)ehci-priv;
+   priv-reg_vbus = NULL;
+
+   if (ci-platdata-reg_vbus)
+   priv-reg_vbus = ci-platdata-reg_vbus;
 
ret = usb_add_hcd(hcd, 0, 0);
if (ret) {
-   goto disable_reg;
+   goto put_hcd;
} else {
struct usb_otg *otg = ci-transceiver-otg;
 
@@ -100,10 +133,6 @@ static int host_start(struct ci_hdrc *ci)
 
return ret;
 
-disable_reg:
-   if (ci-platdata-reg_vbus  !ci_otg_is_fsm_mode(ci))
-   regulator_disable(ci-platdata-reg_vbus);
-
 put_hcd:
usb_put_hcd(hcd);
 
@@ -117,8 +146,6 @@ static void host_stop(struct ci_hdrc *ci)
if (hcd) {
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
-   if (ci-platdata-reg_vbus  !ci_otg_is_fsm_mode(ci))
-   regulator_disable(ci-platdata-reg_vbus);
}
 }
 
@@ -146,7 +173,7 @@ int ci_hdrc_host_init(struct ci_hdrc *ci)
rdrv-name  = host;
ci-roles[CI_ROLE_HOST] = rdrv;
 
-   ehci_init_driver(ci_ehci_hc_driver, NULL);
+   ehci_init_driver(ci_ehci_hc_driver, ehci_ci_overrides);
 
return 0;
 }
-- 
1.7.9.5

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


Re: [PATCH v3] Add support for GPIOs for SMSC LAN95xx chips.

2014-10-10 Thread Bjørn Mork
Evgeny Boger bo...@contactless.ru writes:

 For LAN951x:
 GPIOs with offsets 0-7 are named GPIO3 - GPIO7,

The number of offsets does not match the number of names.



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


Re: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

2014-10-10 Thread Robert Baldyga
Hi,

On 10/10/2014 01:51 PM, pavi1729 ivap wrote:
From 3272817673910c63682e8b91ce0efaef190a399a Mon Sep 17 00:00:00 2001
 From: Pavitra pavitra1...@gmail.com
 Date: Fri, 10 Oct 2014 16:05:30 +0530
 Subject: [PATCH] usb: gadget: function: Remove redundant
  usb_free_all_descriptors
 
 Removed the usb_free_all_descriptors call in *_bind functions
 as this call is already present in usb_assign_descriptors.
 usb_assign_descriptors is the only call where usb descriptor
 allocation happens, also in case of error freeing of the
 allocated memory takes place in the same call. Hence the
 call in the *_bind functions are redundant.
 Also the presence of usb_free_all_descriptors in the *_bind
 functions might result in double-free corruption of the
 allocated mmeory.

Double-free corruption is good point in this place, but your patch
doesn't solve this problem properly. If usb_assign_descriptors() returns
without error and one of following calls fails, we need to call
usb_free_all_descriptors() in error handling code.

There should be rather two error labels: one where you goto on errors
before usb_assign_descriptors() call, and another one where you goto on
errors after it. And in second case usb_free_all_descriptors() is
called, because descriptors are already allocated and you need to free them.

I also see that in some drivers usb_assign_descriptors() is the last
call in bind() and then removing usb_free_all_descriptors() from error
handling code makes sense.

Best regards,
Robert Baldyga

 
 Signed-off-by: Pavitra pavitra1...@gmail.com
 ---
  drivers/usb/gadget/function/f_eem.c| 1 -
  drivers/usb/gadget/function/f_hid.c| 2 --
  drivers/usb/gadget/function/f_ncm.c| 1 -
  drivers/usb/gadget/function/f_phonet.c | 1 -
  drivers/usb/gadget/function/f_rndis.c  | 1 -
  drivers/usb/gadget/function/f_subset.c | 1 -
  drivers/usb/gadget/function/f_uac2.c   | 1 -
  7 files changed, 8 deletions(-)
 
 diff --git a/drivers/usb/gadget/function/f_eem.c
 b/drivers/usb/gadget/function/f_eem.c
 index 4d8b236..c9e90de 100644
 --- a/drivers/usb/gadget/function/f_eem.c
 +++ b/drivers/usb/gadget/function/f_eem.c
 @@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;
 
  fail:
 -usb_free_all_descriptors(f);
  if (eem-port.out_ep)
  eem-port.out_ep-driver_data = NULL;
  if (eem-port.in_ep)
 diff --git a/drivers/usb/gadget/function/f_hid.c
 b/drivers/usb/gadget/function/f_hid.c
 index a95290a..5c67d28 100644
 --- a/drivers/usb/gadget/function/f_hid.c
 +++ b/drivers/usb/gadget/function/f_hid.c
 @@ -652,8 +652,6 @@ static void hidg_unbind(struct usb_configuration
 *c, struct usb_function *f)
  kfree(hidg-req-buf);
  usb_ep_free_request(hidg-in_ep, hidg-req);
 
 -usb_free_all_descriptors(f);
 -
  kfree(hidg-report_desc);
  kfree(hidg);
  }
 diff --git a/drivers/usb/gadget/function/f_ncm.c
 b/drivers/usb/gadget/function/f_ncm.c
 index bcdc882..38a9279 100644
 --- a/drivers/usb/gadget/function/f_ncm.c
 +++ b/drivers/usb/gadget/function/f_ncm.c
 @@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;
 
  fail:
 -usb_free_all_descriptors(f);
  if (ncm-notify_req) {
  kfree(ncm-notify_req-buf);
  usb_ep_free_request(ncm-notify, ncm-notify_req);
 diff --git a/drivers/usb/gadget/function/f_phonet.c
 b/drivers/usb/gadget/function/f_phonet.c
 index b9cfc15..74ddcac 100644
 --- a/drivers/usb/gadget/function/f_phonet.c
 +++ b/drivers/usb/gadget/function/f_phonet.c
 @@ -571,7 +571,6 @@ err_req:
  for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
  usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
  err:
 -usb_free_all_descriptors(f);
  if (fp-out_ep)
  fp-out_ep-driver_data = NULL;
  if (fp-in_ep)
 diff --git a/drivers/usb/gadget/function/f_rndis.c
 b/drivers/usb/gadget/function/f_rndis.c
 index ddb09dc..e257eff 100644
 --- a/drivers/usb/gadget/function/f_rndis.c
 +++ b/drivers/usb/gadget/function/f_rndis.c
 @@ -820,7 +820,6 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  fail:
  kfree(f-os_desc_table);
  f-os_desc_n = 0;
 -usb_free_all_descriptors(f);
 
  if (rndis-notify_req) {
  kfree(rndis-notify_req-buf);
 diff --git a/drivers/usb/gadget/function/f_subset.c
 b/drivers/usb/gadget/function/f_subset.c
 index 1ea8baf..e3dfa67 100644
 --- a/drivers/usb/gadget/function/f_subset.c
 +++ b/drivers/usb/gadget/function/f_subset.c
 @@ -380,7 +380,6 @@ geth_bind(struct usb_configuration *c, struct
 usb_function *f)
  return 0;
 
  fail:
 -usb_free_all_descriptors(f);
  /* we might as well release our claims on endpoints */
  if (geth-port.out_ep)
  geth-port.out_ep-driver_data = NULL;
 diff --git a/drivers/usb/gadget/function/f_uac2.c
 b/drivers/usb/gadget/function/f_uac2.c
 index 3ed89ec..c294fb9 100644
 --- a/drivers/usb/gadget/function/f_uac2.c
 +++ 

Re: [PATCHv2 0/2] HID: usbhid: enable always-poll quirk for other Elan Touchscreen

2014-10-10 Thread Jiri Kosina
On Thu, 9 Oct 2014, Adel Gadllah wrote:

 This adds two devices that needs the always-poll quirk to the list.
 
 Adel Gadllah (2):
   HID: usbhid: enable always-poll quirk for Elan Touchscreen 009b
   HID: usbhid: enable always-poll quirk for Elan Touchscreen 016f

Queued to for-3.18/upstream-fixes, thanks.

-- 
Jiri Kosina
SUSE Labs
--
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: yurex: fixed sparse warning of incorrect type

2014-10-10 Thread Sudip Mukherjee
fixed sparse warning of
1) incorrect type (different address spaces)
2) incorrect type in initializer

Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
 drivers/usb/misc/yurex.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index c3a45da..343fa6f 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -410,7 +410,8 @@ static int yurex_release(struct inode *inode, struct file 
*file)
return 0;
 }
 
-static ssize_t yurex_read(struct file *file, char *buffer, size_t count, 
loff_t *ppos)
+static ssize_t yurex_read(struct file *file, char __user *buffer, size_t count,
+ loff_t *ppos)
 {
struct usb_yurex *dev;
int retval = 0;
@@ -444,7 +445,8 @@ exit:
return retval;
 }
 
-static ssize_t yurex_write(struct file *file, const char *user_buffer, size_t 
count, loff_t *ppos)
+static ssize_t yurex_write(struct file *file, const char __user *user_buffer,
+  size_t count, loff_t *ppos)
 {
struct usb_yurex *dev;
int i, set = 0, retval = 0;
-- 
1.8.1.2

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


Re: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

2014-10-10 Thread pavi1729 ivap
Rob,
   Got your point, will submit a new patch with a new error label.
Also I just found that in f_hid.c f_rndis.c and f_uac2.c do need the
freeing function.
Will clean it up and send the patch.

Thanks,
Pavitra

On Fri, Oct 10, 2014 at 6:05 PM, Robert Baldyga r.bald...@samsung.com wrote:
 Hi,

 On 10/10/2014 01:51 PM, pavi1729 ivap wrote:
From 3272817673910c63682e8b91ce0efaef190a399a Mon Sep 17 00:00:00 2001
 From: Pavitra pavitra1...@gmail.com
 Date: Fri, 10 Oct 2014 16:05:30 +0530
 Subject: [PATCH] usb: gadget: function: Remove redundant
  usb_free_all_descriptors

 Removed the usb_free_all_descriptors call in *_bind functions
 as this call is already present in usb_assign_descriptors.
 usb_assign_descriptors is the only call where usb descriptor
 allocation happens, also in case of error freeing of the
 allocated memory takes place in the same call. Hence the
 call in the *_bind functions are redundant.
 Also the presence of usb_free_all_descriptors in the *_bind
 functions might result in double-free corruption of the
 allocated mmeory.

 Double-free corruption is good point in this place, but your patch
 doesn't solve this problem properly. If usb_assign_descriptors() returns
 without error and one of following calls fails, we need to call
 usb_free_all_descriptors() in error handling code.

 There should be rather two error labels: one where you goto on errors
 before usb_assign_descriptors() call, and another one where you goto on
 errors after it. And in second case usb_free_all_descriptors() is
 called, because descriptors are already allocated and you need to free them.

 I also see that in some drivers usb_assign_descriptors() is the last
 call in bind() and then removing usb_free_all_descriptors() from error
 handling code makes sense.

 Best regards,
 Robert Baldyga


 Signed-off-by: Pavitra pavitra1...@gmail.com
 ---
  drivers/usb/gadget/function/f_eem.c| 1 -
  drivers/usb/gadget/function/f_hid.c| 2 --
  drivers/usb/gadget/function/f_ncm.c| 1 -
  drivers/usb/gadget/function/f_phonet.c | 1 -
  drivers/usb/gadget/function/f_rndis.c  | 1 -
  drivers/usb/gadget/function/f_subset.c | 1 -
  drivers/usb/gadget/function/f_uac2.c   | 1 -
  7 files changed, 8 deletions(-)

 diff --git a/drivers/usb/gadget/function/f_eem.c
 b/drivers/usb/gadget/function/f_eem.c
 index 4d8b236..c9e90de 100644
 --- a/drivers/usb/gadget/function/f_eem.c
 +++ b/drivers/usb/gadget/function/f_eem.c
 @@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (eem-port.out_ep)
  eem-port.out_ep-driver_data = NULL;
  if (eem-port.in_ep)
 diff --git a/drivers/usb/gadget/function/f_hid.c
 b/drivers/usb/gadget/function/f_hid.c
 index a95290a..5c67d28 100644
 --- a/drivers/usb/gadget/function/f_hid.c
 +++ b/drivers/usb/gadget/function/f_hid.c
 @@ -652,8 +652,6 @@ static void hidg_unbind(struct usb_configuration
 *c, struct usb_function *f)
  kfree(hidg-req-buf);
  usb_ep_free_request(hidg-in_ep, hidg-req);

 -usb_free_all_descriptors(f);
 -
  kfree(hidg-report_desc);
  kfree(hidg);
  }
 diff --git a/drivers/usb/gadget/function/f_ncm.c
 b/drivers/usb/gadget/function/f_ncm.c
 index bcdc882..38a9279 100644
 --- a/drivers/usb/gadget/function/f_ncm.c
 +++ b/drivers/usb/gadget/function/f_ncm.c
 @@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (ncm-notify_req) {
  kfree(ncm-notify_req-buf);
  usb_ep_free_request(ncm-notify, ncm-notify_req);
 diff --git a/drivers/usb/gadget/function/f_phonet.c
 b/drivers/usb/gadget/function/f_phonet.c
 index b9cfc15..74ddcac 100644
 --- a/drivers/usb/gadget/function/f_phonet.c
 +++ b/drivers/usb/gadget/function/f_phonet.c
 @@ -571,7 +571,6 @@ err_req:
  for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
  usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
  err:
 -usb_free_all_descriptors(f);
  if (fp-out_ep)
  fp-out_ep-driver_data = NULL;
  if (fp-in_ep)
 diff --git a/drivers/usb/gadget/function/f_rndis.c
 b/drivers/usb/gadget/function/f_rndis.c
 index ddb09dc..e257eff 100644
 --- a/drivers/usb/gadget/function/f_rndis.c
 +++ b/drivers/usb/gadget/function/f_rndis.c
 @@ -820,7 +820,6 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  fail:
  kfree(f-os_desc_table);
  f-os_desc_n = 0;
 -usb_free_all_descriptors(f);

  if (rndis-notify_req) {
  kfree(rndis-notify_req-buf);
 diff --git a/drivers/usb/gadget/function/f_subset.c
 b/drivers/usb/gadget/function/f_subset.c
 index 1ea8baf..e3dfa67 100644
 --- a/drivers/usb/gadget/function/f_subset.c
 +++ b/drivers/usb/gadget/function/f_subset.c
 @@ -380,7 +380,6 @@ geth_bind(struct usb_configuration *c, struct
 usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  /* we might as well 

Re: [PATCH] usb: gadget: function: Remove redundant usb_free_all_descriptors

2014-10-10 Thread pavi1729 ivap
Oh! precisely what you are saying ..

On Fri, Oct 10, 2014 at 6:21 PM, pavi1729 ivap pavitra1...@gmail.com wrote:
 Rob,
Got your point, will submit a new patch with a new error label.
 Also I just found that in f_hid.c f_rndis.c and f_uac2.c do need the
 freeing function.
 Will clean it up and send the patch.

 Thanks,
 Pavitra

 On Fri, Oct 10, 2014 at 6:05 PM, Robert Baldyga r.bald...@samsung.com wrote:
 Hi,

 On 10/10/2014 01:51 PM, pavi1729 ivap wrote:
From 3272817673910c63682e8b91ce0efaef190a399a Mon Sep 17 00:00:00 2001
 From: Pavitra pavitra1...@gmail.com
 Date: Fri, 10 Oct 2014 16:05:30 +0530
 Subject: [PATCH] usb: gadget: function: Remove redundant
  usb_free_all_descriptors

 Removed the usb_free_all_descriptors call in *_bind functions
 as this call is already present in usb_assign_descriptors.
 usb_assign_descriptors is the only call where usb descriptor
 allocation happens, also in case of error freeing of the
 allocated memory takes place in the same call. Hence the
 call in the *_bind functions are redundant.
 Also the presence of usb_free_all_descriptors in the *_bind
 functions might result in double-free corruption of the
 allocated mmeory.

 Double-free corruption is good point in this place, but your patch
 doesn't solve this problem properly. If usb_assign_descriptors() returns
 without error and one of following calls fails, we need to call
 usb_free_all_descriptors() in error handling code.

 There should be rather two error labels: one where you goto on errors
 before usb_assign_descriptors() call, and another one where you goto on
 errors after it. And in second case usb_free_all_descriptors() is
 called, because descriptors are already allocated and you need to free them.

 I also see that in some drivers usb_assign_descriptors() is the last
 call in bind() and then removing usb_free_all_descriptors() from error
 handling code makes sense.

 Best regards,
 Robert Baldyga


 Signed-off-by: Pavitra pavitra1...@gmail.com
 ---
  drivers/usb/gadget/function/f_eem.c| 1 -
  drivers/usb/gadget/function/f_hid.c| 2 --
  drivers/usb/gadget/function/f_ncm.c| 1 -
  drivers/usb/gadget/function/f_phonet.c | 1 -
  drivers/usb/gadget/function/f_rndis.c  | 1 -
  drivers/usb/gadget/function/f_subset.c | 1 -
  drivers/usb/gadget/function/f_uac2.c   | 1 -
  7 files changed, 8 deletions(-)

 diff --git a/drivers/usb/gadget/function/f_eem.c
 b/drivers/usb/gadget/function/f_eem.c
 index 4d8b236..c9e90de 100644
 --- a/drivers/usb/gadget/function/f_eem.c
 +++ b/drivers/usb/gadget/function/f_eem.c
 @@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (eem-port.out_ep)
  eem-port.out_ep-driver_data = NULL;
  if (eem-port.in_ep)
 diff --git a/drivers/usb/gadget/function/f_hid.c
 b/drivers/usb/gadget/function/f_hid.c
 index a95290a..5c67d28 100644
 --- a/drivers/usb/gadget/function/f_hid.c
 +++ b/drivers/usb/gadget/function/f_hid.c
 @@ -652,8 +652,6 @@ static void hidg_unbind(struct usb_configuration
 *c, struct usb_function *f)
  kfree(hidg-req-buf);
  usb_ep_free_request(hidg-in_ep, hidg-req);

 -usb_free_all_descriptors(f);
 -
  kfree(hidg-report_desc);
  kfree(hidg);
  }
 diff --git a/drivers/usb/gadget/function/f_ncm.c
 b/drivers/usb/gadget/function/f_ncm.c
 index bcdc882..38a9279 100644
 --- a/drivers/usb/gadget/function/f_ncm.c
 +++ b/drivers/usb/gadget/function/f_ncm.c
 @@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
 struct usb_function *f)
  return 0;

  fail:
 -usb_free_all_descriptors(f);
  if (ncm-notify_req) {
  kfree(ncm-notify_req-buf);
  usb_ep_free_request(ncm-notify, ncm-notify_req);
 diff --git a/drivers/usb/gadget/function/f_phonet.c
 b/drivers/usb/gadget/function/f_phonet.c
 index b9cfc15..74ddcac 100644
 --- a/drivers/usb/gadget/function/f_phonet.c
 +++ b/drivers/usb/gadget/function/f_phonet.c
 @@ -571,7 +571,6 @@ err_req:
  for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
  usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
  err:
 -usb_free_all_descriptors(f);
  if (fp-out_ep)
  fp-out_ep-driver_data = NULL;
  if (fp-in_ep)
 diff --git a/drivers/usb/gadget/function/f_rndis.c
 b/drivers/usb/gadget/function/f_rndis.c
 index ddb09dc..e257eff 100644
 --- a/drivers/usb/gadget/function/f_rndis.c
 +++ b/drivers/usb/gadget/function/f_rndis.c
 @@ -820,7 +820,6 @@ rndis_bind(struct usb_configuration *c, struct
 usb_function *f)
  fail:
  kfree(f-os_desc_table);
  f-os_desc_n = 0;
 -usb_free_all_descriptors(f);

  if (rndis-notify_req) {
  kfree(rndis-notify_req-buf);
 diff --git a/drivers/usb/gadget/function/f_subset.c
 b/drivers/usb/gadget/function/f_subset.c
 index 1ea8baf..e3dfa67 100644
 --- a/drivers/usb/gadget/function/f_subset.c
 +++ b/drivers/usb/gadget/function/f_subset.c
 @@ -380,7 +380,6 @@ geth_bind(struct 

[PATCH] Update default usb-storage delay_use value in kernel-parameters.txt

2014-10-10 Thread Mark Knibbs
Hi,

Back in 2010 the default usb-storage delay_use time was reduced from 5 to 1
second (commit a4a47bc03fe520e95e0c4212bf97c86545fb14f9), but
kernel-parameters.txt wasn't updated to reflect that.

Signed-off-by: Mark Knibbs ma...@clara.co.uk

---
diff -upN linux-3.17/Documentation/kernel-parameters.txt.orig 
linux-3.17/Documentation/kernel-parameters.txt
--- linux-3.17/Documentation/kernel-parameters.txt.orig 2014-10-05 
20:23:04.0 +0100
+++ linux-3.17/Documentation/kernel-parameters.txt  2014-10-10 
13:51:16.0 +0100
@@ -3502,7 +3502,7 @@ bytes respectively. Such letter suffixes
 
usb-storage.delay_use=
[UMS] The delay in seconds before a new device is
-   scanned for Logical Units (default 5).
+   scanned for Logical Units (default 1).
 
usb-storage.quirks=
[UMS] A list of quirks entries to supplement or
--
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: function: Remove redundant usb_free_all_descriptors

2014-10-10 Thread pavi1729 ivap
From: Pavitra pavitra1...@gmail.com
Date: Fri, 10 Oct 2014 16:05:30 +0530
Subject: [PATCH] usb: gadget: function: Remove redundant
 usb_free_all_descriptors

Removed the usb_free_all_descriptors call in *_bind functions
as this call is already present in usb_assign_descriptors.
usb_assign_descriptors is the only call where usb descriptor
allocation happens, also in case of error freeing of the
allocated memory takes place in the same call. Hence the
call in the *_bind functions are redundant.
Also the presence of usb_free_all_descriptors in the *_bind
functions might result in double-free corruption of the
allocated mmeory.

Signed-off-by: Pavitra pavitra1...@gmail.com
---
 drivers/usb/gadget/function/f_eem.c|  1 -
 drivers/usb/gadget/function/f_hid.c|  7 +++
 drivers/usb/gadget/function/f_ncm.c|  1 -
 drivers/usb/gadget/function/f_phonet.c |  1 -
 drivers/usb/gadget/function/f_rndis.c  |  5 +++--
 drivers/usb/gadget/function/f_subset.c |  1 -
 drivers/usb/gadget/function/f_uac2.c   | 10 ++
 7 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/function/f_eem.c
b/drivers/usb/gadget/function/f_eem.c
index 4d8b236..c9e90de 100644
--- a/drivers/usb/gadget/function/f_eem.c
+++ b/drivers/usb/gadget/function/f_eem.c
@@ -325,7 +325,6 @@ static int eem_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (eem-port.out_ep)
 eem-port.out_ep-driver_data = NULL;
 if (eem-port.in_ep)
diff --git a/drivers/usb/gadget/function/f_hid.c
b/drivers/usb/gadget/function/f_hid.c
index a95290a..df4f390 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -621,12 +621,14 @@ static int __init hidg_bind(struct
usb_configuration *c, struct usb_function *f)
 dev = MKDEV(major, hidg-minor);
 status = cdev_add(hidg-cdev, dev, 1);
 if (status)
-goto fail;
+goto err;

 device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor);

 return 0;

+err:
+usb_free_all_descriptors(f);
 fail:
 ERROR(f-config-cdev, hidg_bind FAILED\n);
 if (hidg-req != NULL) {
@@ -635,7 +637,6 @@ fail:
 usb_ep_free_request(hidg-in_ep, hidg-req);
 }

-usb_free_all_descriptors(f);
 return status;
 }

@@ -652,8 +653,6 @@ static void hidg_unbind(struct usb_configuration
*c, struct usb_function *f)
 kfree(hidg-req-buf);
 usb_ep_free_request(hidg-in_ep, hidg-req);

-usb_free_all_descriptors(f);
-
 kfree(hidg-report_desc);
 kfree(hidg);
 }
diff --git a/drivers/usb/gadget/function/f_ncm.c
b/drivers/usb/gadget/function/f_ncm.c
index bcdc882..38a9279 100644
--- a/drivers/usb/gadget/function/f_ncm.c
+++ b/drivers/usb/gadget/function/f_ncm.c
@@ -1453,7 +1453,6 @@ static int ncm_bind(struct usb_configuration *c,
struct usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 if (ncm-notify_req) {
 kfree(ncm-notify_req-buf);
 usb_ep_free_request(ncm-notify, ncm-notify_req);
diff --git a/drivers/usb/gadget/function/f_phonet.c
b/drivers/usb/gadget/function/f_phonet.c
index b9cfc15..74ddcac 100644
--- a/drivers/usb/gadget/function/f_phonet.c
+++ b/drivers/usb/gadget/function/f_phonet.c
@@ -571,7 +571,6 @@ err_req:
 for (i = 0; i  phonet_rxq_size  fp-out_reqv[i]; i++)
 usb_ep_free_request(fp-out_ep, fp-out_reqv[i]);
 err:
-usb_free_all_descriptors(f);
 if (fp-out_ep)
 fp-out_ep-driver_data = NULL;
 if (fp-in_ep)
diff --git a/drivers/usb/gadget/function/f_rndis.c
b/drivers/usb/gadget/function/f_rndis.c
index ddb09dc..dae8c4b 100644
--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -803,7 +803,7 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
 if (rndis-manufacturer  rndis-vendorID 
 rndis_set_param_vendor(rndis-config, rndis-vendorID,
rndis-manufacturer))
-goto fail;
+goto err;

 /* NOTE:  all that is done without knowing or caring about
  * the network link ... which is unavailable to this code
@@ -817,10 +817,11 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
 rndis-notify-name);
 return 0;

+err:
+usb_free_all_descriptors(f);
 fail:
 kfree(f-os_desc_table);
 f-os_desc_n = 0;
-usb_free_all_descriptors(f);

 if (rndis-notify_req) {
 kfree(rndis-notify_req-buf);
diff --git a/drivers/usb/gadget/function/f_subset.c
b/drivers/usb/gadget/function/f_subset.c
index 1ea8baf..e3dfa67 100644
--- a/drivers/usb/gadget/function/f_subset.c
+++ b/drivers/usb/gadget/function/f_subset.c
@@ -380,7 +380,6 @@ geth_bind(struct usb_configuration *c, struct
usb_function *f)
 return 0;

 fail:
-usb_free_all_descriptors(f);
 /* we might as well release our claims on endpoints */
 if (geth-port.out_ep)
 geth-port.out_ep-driver_data = NULL;
diff --git 

[PATCH] usb: dwc2: gadget: sparse warning of context imbalance

2014-10-10 Thread Sudip Mukherjee
sparse was giving the following warning:
warning: context imbalance in 's3c_hsotg_ep_enable' 
- different lock contexts for basic block

we were returning ENOMEM while still holding the spinlock.
The sparse warning was fixed by releasing the spinlock before return.

Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
 drivers/usb/dwc2/gadget.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7b5856f..046e90d 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2561,8 +2561,10 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
hs_ep-fifo_size = val;
break;
}
-   if (i == 8)
+   if (i == 8) {
+   spin_unlock_irqrestore(hsotg-lock, flags);
return -ENOMEM;
+   }
}
 
/* for non control endpoints, set PID to D0 */
-- 
1.8.1.2

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


Re: [PATCH] u_serial.c - Force destroy tty_port in gserial_free_port

2014-10-10 Thread Peter Hurley
On 10/10/2014 12:05 AM, Andre Wolokita wrote:
 
 
 On 10/10/14 00:47, Peter Hurley wrote:
 Hi Andre,

 On 10/08/2014 11:54 PM, Andre Wolokita wrote:
 On 09/10/14 14:38, Greg KH wrote:
 On Thu, Oct 09, 2014 at 02:08:04PM +1100, Andre Wolokita wrote:
 On 09/10/14 13:56, Greg KH wrote:
 On Thu, Oct 09, 2014 at 11:23:59AM +1100, Andre Wolokita wrote:
 Issuing a modprobe -r g_serial command to the target
 over the gadget serial communications line causes
 modprobe to enter uninterruptable sleep, leaving the
 system in an unstable state.

 The associated tty_port.count won't drop to 0 because
 the command is issued over the very line being removed.

 Destroying the tty_port will ensure that resources are
 freed and modprobe will not hang.

 Signed-off-by: Andre Wolokita andre.wolok...@analog.com
 ---
  drivers/usb/gadget/function/u_serial.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/usb/gadget/function/u_serial.c 
 b/drivers/usb/gadget/function/u_serial.c
 index ad0aca8..db631c4 100644
 --- a/drivers/usb/gadget/function/u_serial.c
 +++ b/drivers/usb/gadget/function/u_serial.c
 @@ -1074,10 +1074,10 @@ static int gs_closed(struct gs_port *port)
  static void gserial_free_port(struct gs_port *port)
  {
 tasklet_kill(port-push);
 +   tty_port_destroy(port-port);
 /* wait for old opens to finish */
 wait_event(port-port.close_wait, gs_closed(port));

 Isn't this now a use-after-free issue?


 Are you referring to the subsequent call to wait event() on gs_closed()?

 Yes.

 Testing the use-case with this patch applied seemed to work without any 
 issues. The ttyGS0 reference in /dev/ is gone after running modprobe -r
 but I'm just a newbie, so I could be doing sometime horrible here.

 Hm, I dug into the tty core, it should be ok, but it just seems really
 odd, and bad-form to be doing something with port-port after calling a
 destroy function with it, don't you agree?

 I do. The call to wait_event() can be removed as we no longer care whether
 gs_closed(port) is returning true - if it even can, having destroyed the
 tty_port.

 Neither the patch nor the idea that this wait_event() is unnecessary is
 correct (within the current design of u_serial).

 tty_port_destroy() frees the input processing buffers, which may be in use
 right at this moment, if a port is still in use by its tty. Since whatever
 was using those buffers doesn't know this has happened, it may still be 
 writing
 to that memory, which may now be reallocated to some other kernel subsystem, 
 like
 file cache buffers.

 The wait_event() tries to ensure that the port destruction can't take place
 while the port is still in use, so when it's hung there, it's preventing bad
 things from happening.

 There is no way to simply 'force' the port to no longer be in use, since a
 userspace process can maintain an open file indefinitely.

 There are a couple of possible solutions though:

 In gserial_free_line(), hangup the tty associated with the port. You can
 look at usb_serial_disconnect() for how to do that properly. This doesn't
 guarantee that the userspace process will close the tty, but most programs
 will close the file on end-of-file read (which is what hangup will cause).
 
 I tried adding the adding the same tty_vhangup(tty) and tty_kref_put(tty) 
 logic that usb serial has
 but the problem still occurs.

That's because g_serial has no hangup() method; ports aren't going to
close themselves.

 It doesn't look like making the wait_event() interruptible is possible
 (or desirable).

 The ideal solution would be for u_serial to reference count its gs_ports;
 that's what usb serial does for its usb_serial_port. Then gserial_free_line()
 becomes a 'disconnect', and the actual cleanup happens later. The key
 implementation details are:
 1. The tty core helps keep reference counting simple by calling the tty
 driver's install() and cleanup() methods; install() for the first open() and
 cleanup() when the tty is being released. usb serial does this with
 usb_serial_port_get_by_minor() from serial_install() and usb_serial_put() in
 serial_cleanup() and usb_serial_disconnect().
 2. a flag (like usb serial's '-disconnected') to prevent continued port
 allocation after 'disconnect'.

 The key concept is that although the tty and port still exist, neither
 does anything useful after the disconnect.

 And u_serial.c should really be ported to using tty_port which takes care of
 stuff like parallel opens and closes without looping and other stuff like
 the port-openclose flag.

 FWIW, the tty_unregister_device() does not need to be after 
 gserial_free_port()
 because existing ttys maintain a device reference count which prevents the
 underlying tty device from being released.
 
 To be honest with you, I am in way over my head at the moment. I'll continue
 working on this problem but I can't guarantee it'll be fixed any time soon.

Maybe you should reconsider if this use-case is really worth 

Re: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Felipe Balbi
On Thu, Oct 09, 2014 at 04:07:15PM -0500, Felipe Balbi wrote:
 Hi,
 
 On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
  On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
   On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
alright, it's pretty deterministic however. Always on the same test, no
matter which USB controller, no matter if backing store is RAM or MMC.

Those two undefined instructions on the disassembly caught my attention,
perhaps I'm facing a GCC bug ?
   
   The undefined instructions are just ARM's BUG() implementation.
   
   But did you see the question I asked you yesterday in your other thread?
   http://www.spinics.net/lists/arm-kernel/msg368634.html
  
  hmm, completely missed that, sorry. I'm using 4.8.2, will try something
  else.
 
 seems to be working fine now, thanks. I'll leave test running overnight
 just in case.

yup, ran over night without any problems.

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] USB: phy: add ralink SoC driver

2014-10-10 Thread Felipe Balbi
On Fri, Oct 10, 2014 at 12:20:01PM +0200, John Crispin wrote:
 RT3352, RT5350 and the MT762x SoCs all have a usb phy that we need to setup.
 
 Signed-off-by: John Crispin blo...@openwrt.org

new PHY drivers only on drivers/phy ;-)

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL

2014-10-10 Thread Felipe Balbi
Hi,

On Fri, Oct 10, 2014 at 05:25:34PM +0800, Huang Rui wrote:
   I enabled dwc3 and gadget debug/verbose configuration, the whole testing 
   dmesg
  
  oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
  A9 :-)
  
 
 Yes, maybe have two reasons:
 1) The input clock is much slower than SOC's.
 2) I used high speed mode.

right, i'm running at highspeed too.

 Because of the timing issue on FPGA, bulk write transfer would get
 stuck when use more than 1MB (can pass on small file write) on super
 speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

These shouldn't fail. I'll leave testusb running tonight.

   Do you want to see the whole testing dmesg, with which debug level
   enablement?
  
  This is good for me, thank you.
 
 The test log with booting is attached. Please review.

will do.

  ps: FYI, I left my board running overnight the same test. It has been
  pretty stable so far.
  
 
 High speed mode is stable in my FPGA board, but super speed is not
 at current.

weird. Got any logs ? If you want to share logs I can probably help you
debugging that.

-- 
balbi


signature.asc
Description: Digital signature


hso. hso_serial_close oops.

2014-10-10 Thread Christian Melki

I'm using a ppc 8347 with a normal 3.16.1 kernel.
The software opens the driver tty in question and then sets it as stdin, 
stdout for chat-program and pppd.
When I yank the modem while running, the software detects this and tries 
to close the open socket with a kernel crash as a result.


Unable to handle kernel paging request for unknown fault
Faulting instruction address: 0xc03a4420
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT ASP8347E
Modules linked in:
CPU: 0 PID: 1536 Comm: pppd Not tainted 3.16.1 #1
task: c31272e0 ti: c39e8000 task.ti: c39e8000
NIP: c03a4420 LR: c020752c CTR: c02074e0
REGS: c39e9d40 TRAP: 0600   Not tainted  (3.16.1)
MSR: 9032 EE,ME,IR,DR,RI  CR: 24004224  XER: 2000
DAR: 004d DSISR: 
GPR00:  c39e9df0 c31272e0 004d c3235460  c39c1934 

GPR08:   c39c1964 c39c1800 24004228 10047610 1004 
1003f6ec
GPR16: 1003f6b4 1003f618 1003f6b0 1003f6bc 1003f700 1003f7b4 c39e9edc 
1003f6c8
GPR24: 1003f6dc c03bd1a8 0004 c03bd2b4  c3235460  
c38cca00

NIP [c03a4420] mutex_lock+0x0/0x1c
LR [c020752c] hso_serial_close+0x4c/0x11c
Call Trace:
[c39e9df0] [c3235460] 0xc3235460 (unreliable)
[c39e9e00] [c0188944] tty_release+0x134/0x560
[c39e9e90] [c00a1968] __fput+0x94/0x214
[c39e9eb0] [c0032854] task_work_run+0xcc/0xf4
[c39e9ed0] [c0019108] do_exit+0x208/0x874
[c39e9f20] [c00198c0] do_group_exit+0x44/0xd8
[c39e9f30] [c0019968] __wake_up_parent+0x0/0x34
[c39e9f40] [c000e60c] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfebd4cc
LR = 0xff79a98
Instruction dump:
409e0014 801f003c 70090004 41820008 4bffe6ad 80010034 bb410018 38210030
7c0803a6 4e800020 4bffe695 4bc4 7c001828 3000 7c00192d 40a2fff4
---[ end trace bfebaf22f6f5795a ]---

Fixing recursive fault but reboot is needed!

I have simulated the same error with a simple userland program without 
using pppd.



#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include stdlib.h

int
main(int argc, char *argv[]) {
int fd;
fd = open(argv[1], O_RDWR);
sleep(atoi(argv[2]));
close(fd);

return 0;
}

If I yank the modem while the program is sleeping, I get exactly the 
same kernel error as with pppd.
I have looked at the hso.c (hso_serial_close) driver but can't figure it 
out. The structs might not be intact at that time, but those are tty 
structs.. Im not sure what is going on. I tried to check the integrity 
of the structs but still get a crash. The tty layer is a mystery to me.


regards,
Christian
--
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: hso. hso_serial_close oops.

2014-10-10 Thread Peter Hurley
[ +Jan Dumon, netdev ]

Forwarding oops report to maintainer.

On 10/10/2014 10:02 AM, Christian Melki wrote:
 I'm using a ppc 8347 with a normal 3.16.1 kernel.
 The software opens the driver tty in question and then sets it as stdin, 
 stdout for chat-program and pppd.
 When I yank the modem while running, the software detects this and tries to 
 close the open socket with a kernel crash as a result.
 
 Unable to handle kernel paging request for unknown fault
 Faulting instruction address: 0xc03a4420
 Oops: Kernel access of bad area, sig: 11 [#1]
 PREEMPT ASP8347E
 Modules linked in:
 CPU: 0 PID: 1536 Comm: pppd Not tainted 3.16.1 #1
 task: c31272e0 ti: c39e8000 task.ti: c39e8000
 NIP: c03a4420 LR: c020752c CTR: c02074e0
 REGS: c39e9d40 TRAP: 0600   Not tainted  (3.16.1)
 MSR: 9032 EE,ME,IR,DR,RI  CR: 24004224  XER: 2000
 DAR: 004d DSISR: 
 GPR00:  c39e9df0 c31272e0 004d c3235460  c39c1934 
 GPR08:   c39c1964 c39c1800 24004228 10047610 1004 1003f6ec
 GPR16: 1003f6b4 1003f618 1003f6b0 1003f6bc 1003f700 1003f7b4 c39e9edc 1003f6c8
 GPR24: 1003f6dc c03bd1a8 0004 c03bd2b4  c3235460  c38cca00
 NIP [c03a4420] mutex_lock+0x0/0x1c
 LR [c020752c] hso_serial_close+0x4c/0x11c
 Call Trace:
 [c39e9df0] [c3235460] 0xc3235460 (unreliable)
 [c39e9e00] [c0188944] tty_release+0x134/0x560
 [c39e9e90] [c00a1968] __fput+0x94/0x214
 [c39e9eb0] [c0032854] task_work_run+0xcc/0xf4
 [c39e9ed0] [c0019108] do_exit+0x208/0x874
 [c39e9f20] [c00198c0] do_group_exit+0x44/0xd8
 [c39e9f30] [c0019968] __wake_up_parent+0x0/0x34
 [c39e9f40] [c000e60c] ret_from_syscall+0x0/0x38
 --- Exception: c01 at 0xfebd4cc
 LR = 0xff79a98
 Instruction dump:
 409e0014 801f003c 70090004 41820008 4bffe6ad 80010034 bb410018 38210030
 7c0803a6 4e800020 4bffe695 4bc4 7c001828 3000 7c00192d 40a2fff4
 ---[ end trace bfebaf22f6f5795a ]---
 
 Fixing recursive fault but reboot is needed!
 
 I have simulated the same error with a simple userland program without using 
 pppd.
 
 
 #include sys/types.h
 #include sys/stat.h
 #include fcntl.h
 #include unistd.h
 #include stdlib.h
 
 int
 main(int argc, char *argv[]) {
 int fd;
 fd = open(argv[1], O_RDWR);
 sleep(atoi(argv[2]));
 close(fd);
 
 return 0;
 }
 
 If I yank the modem while the program is sleeping, I get exactly the same 
 kernel error as with pppd.
 I have looked at the hso.c (hso_serial_close) driver but can't figure it out. 
 The structs might not be intact at that time, but those are tty structs.. Im 
 not sure what is going on. I tried to check the integrity of the structs but 
 still get a crash. The tty layer is a mystery to me.
 
 regards,
 Christian

--
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 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller

2014-10-10 Thread Muthu Mani
 -Original Message-
 From: Lee Jones [mailto:lee.jo...@linaro.org]
 Sent: Thursday, October 09, 2014 1:10 PM
 To: Muthu Mani
 Cc: Samuel Ortiz; Wolfram Sang; Linus Walleij; Alexandre Courbot;
 gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
 g...@vger.kernel.org; linux-usb@vger.kernel.org; linux-
 ker...@vger.kernel.org; Rajaram Regupathy; Johan Hovold
 Subject: Re: [PATCH v3 1/3] mfd: add support for Cypress CYUSBS234 USB
 Serial Bridge controller
 
 On Mon, 06 Oct 2014, Muthu Mani wrote:
 
  Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor
  CYUSBS234 USB-Serial Bridge controller.
 
  Details about the device can be found at:
  http://www.cypress.com/?rID=84126
 
  Signed-off-by: Muthu Mani m...@cypress.com
  Signed-off-by: Rajaram Regupathy r...@cypress.com
  ---
  Changes since v2:
  * Used auto mfd id to support multiple devices
  * Cleaned up the code
 
  Changes since v1:
  * Identified different serial interface and loaded correct cell driver
  * Formed a mfd id to support multiple devices
  * Removed unused platform device
 
   drivers/mfd/Kconfig   |  12 +++
   drivers/mfd/Makefile  |   1 +
   drivers/mfd/cyusbs23x.c   | 167
 ++
   include/linux/mfd/cyusbs23x.h |  62 
   4 files changed, 242 insertions(+)
   create mode 100644 drivers/mfd/cyusbs23x.c
   create mode 100644 include/linux/mfd/cyusbs23x.h
 
  diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
  index de5abf2..a31e9e3 100644
  --- a/drivers/mfd/Kconfig
  +++ b/drivers/mfd/Kconfig
  @@ -116,6 +116,18 @@ config MFD_ASIC3
  This driver supports the ASIC3 multifunction chip found on many
  PDAs (mainly iPAQ and HTC based ones)
 
  +config MFD_CYUSBS23X
  +tristate Cypress CYUSBS23x USB Serial Bridge controller
 
 White space issue here.

Thanks for reviewing!
Sure, will fix other files as well.

 
  + select MFD_CORE
  + depends on USB
  + default n
  + help
  +   Say yes here if you want support for Cypress Semiconductor
  +   CYUSBS23x USB-Serial Bridge controller.
  +
  +   This driver can also be built as a module. If so, the module will be
  +   called cyusbs23x.
  +
   config PMIC_DA903X
bool Dialog Semiconductor DA9030/DA9034 PMIC Support
depends on I2C=y
  diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
  index f001487..fc5bcd1 100644
  --- a/drivers/mfd/Makefile
  +++ b/drivers/mfd/Makefile
  @@ -151,6 +151,7 @@ si476x-core-y := si476x-cmd.o si476x-prop.o si476x-
 i2c.o
   obj-$(CONFIG_MFD_SI476X_CORE)+= si476x-core.o
 
   obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
  +obj-$(CONFIG_MFD_CYUSBS23X) += cyusbs23x.o
   obj-$(CONFIG_MFD_OMAP_USB_HOST)  += omap-usb-host.o omap-
 usb-tll.o
   obj-$(CONFIG_MFD_PM8921_CORE)+= pm8921-core.o ssbi.o
   obj-$(CONFIG_TPS65911_COMPARATOR)+= tps65911-comparator.o
  diff --git a/drivers/mfd/cyusbs23x.c b/drivers/mfd/cyusbs23x.c
  new file mode 100644
  index 000..c70ea40
  --- /dev/null
  +++ b/drivers/mfd/cyusbs23x.c
  @@ -0,0 +1,167 @@
  +/*
  + * Cypress USB-Serial Bridge Controller USB adapter driver
  + *
  + * Copyright (c) 2014 Cypress Semiconductor Corporation.
  + *
  + * Author:
  + *   Muthu Mani m...@cypress.com
  + *
  + * Additional contributors include:
  + *   Rajaram Regupathy r...@cypress.com
  + *
  + * 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 is core MFD driver for Cypress Semiconductor CYUSBS234 USB-
 Serial
  + * Bridge controller. CYUSBS234 offers a single channel serial interface
  + * (I2C/SPI/UART). It can be configured to enable either of I2C, SPI, UART
  + * interfaces. The GPIOs are also available to access.
  + * Details about the device can be found at:
  + *http://www.cypress.com/?rID=84126
  + *
  + * Separate cell drivers are available for I2C and GPIO. SPI and UART are
 not
  + * supported yet. All GPIOs are exposed for get operation. However, only
  + * unused GPIOs can be set.
  + */
  +
  +#include linux/kernel.h
  +#include linux/errno.h
  +#include linux/module.h
  +#include linux/slab.h
  +#include linux/types.h
  +#include linux/mutex.h
  +
 
 This '\n' is superfluous, please remove it.
 
  +#include linux/mfd/core.h
  +#include linux/mfd/cyusbs23x.h
  +
  +#include linux/usb.h
  +
  +static const struct usb_device_id cyusbs23x_usb_table[] = {
  + { USB_DEVICE(0x04b4, 0x0004) },   /* Cypress Semiconductor */
  + { }   /* Terminating entry */
 
 This comment is not required, please remove it.
 
  +};
  +
  +MODULE_DEVICE_TABLE(usb, cyusbs23x_usb_table);
  +
  +static const struct mfd_cell cyusbs23x_i2c_devs[] = {
  + {
  + .name = cyusbs23x-i2c,
  + },
  + {
  + .name = 

Re: Displaylink Attached Display Adapater and Monitor Not Recognized

2014-10-10 Thread Alan Stern
On Thu, 9 Oct 2014, Dennis Gesker wrote:

 I did see that note and link but it was an to a pretty old thread. I
 figured something must have happend on this since then. There seem to
 be quite a few products with these displaylink chip sets in them.
 
 If its really just a bad product as as far as linux goes could you
 recommend other USB to Dual Monitor product that is supported?

I have no idea.  Judging by what the MAINTAINERS file says, you should 
try asking Bernie Thompson ber...@plugable.com on the 
linux-fb...@vger.kernel.org mailing list.  He's the maintainer 
responsible for the udl driver.

 [3.628131] usb 4-2.3: new SuperSpeed USB device number 3 using xhci_hcd
 [3.643446] usb 4-2.3: New USB device found, idVendor=17e9, idProduct=4318
 [3.643448] usb 4-2.3: New USB device strings: Mfr=1, Product=2,
 SerialNumber=3
 [3.643449] usb 4-2.3: Product: Dell USB 3.0 Dock
 [3.643450] usb 4-2.3: Manufacturer: DisplayLink
 [3.643451] usb 4-2.3: SerialNumber: 30929893

 [5.105640] usb 4-2.3: parse_audio_format_rates_v2(): unable to
 retrieve number of sample rates (clock 10)
 [5.105790] usb 4-2.3: parse_audio_format_rates_v2(): unable to
 retrieve number of sample rates (clock 10)

 [5.113739] usb 4-2.3: Warning! Unlikely big volume range (=511),
 cval-res is probably wrong.
 [5.113741] usb 4-2.3: [14] FU [Digital In Playback Volume] ch = 6,
 val = -8176/0/16
 [5.115121] usb 4-2.3: Warning! Unlikely big volume range (=511),
 cval-res is probably wrong.
 [5.115123] usb 4-2.3: [11] FU [Dell USB Audio Capture Volume] ch =
 2, val = -8176/0/16
 [5.116196] usbcore: registered new interface driver snd-usb-audio
 [5.117073] cdc_ether 4-2.3:1.5 eth1: register 'cdc_ether' at
 usb-:00:14.0-2.3, CDC Ethernet Device, 00:24:9b:0b:60:24

These error messages suggest that the udl driver isn't going to work 
with your device.

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] usb: chipidea: add portpower override for host and use it

2014-10-10 Thread Alan Stern
On Fri, 10 Oct 2014, Laurent Pinchart wrote:

 Hi Alan,
 
 On Thursday 09 October 2014 12:51:34 Alan Stern wrote:
  On Thu, 9 Oct 2014, Michael Grzeschik wrote:
   This patch adds an hub_control override to toggle the PORT_POWER
   by the registered regulator. That is needed when an external
   GPIO is used instead of the default PORT_POWER bit.
  
  I don't think this is such a good approach.  There are places in
  ehci-hcd where port power is toggled directly, without going through
  ehci_hub_control().  For example, see ehci_turn_off_all_ports().
  
  You should do what I recommended earlier: Add routines to ehci-hcd
  specifically for turning port power on or off, and then use those
  routines every place the power setting gets changed.  Then those
  routines can call a platform-specific override, if needed.
 
 Should that be done for OHCI as well, to keep the two implementations 
 coherent 
 ?

Yes, it should.

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 v3 1/2] usb: ehci: add port_power callback and override

2014-10-10 Thread Alan Stern
On Fri, 10 Oct 2014, Peter Chen wrote:

 @@ -1216,6 +1221,7 @@ static const struct hc_driver ehci_hc_driver = {
   .bus_resume =   ehci_bus_resume,
   .relinquish_port =  ehci_relinquish_port,
   .port_handed_over = ehci_port_handed_over,
 + .port_power =   ehci_port_power,
  
   /*
* device support
 @@ -1233,6 +1239,8 @@ void ehci_init_driver(struct hc_driver *drv,
   drv-hcd_priv_size += over-extra_priv_size;
   if (over-reset)
   drv-reset = over-reset;
 + if (over-port_power)
 + drv-port_power = over-port_power;

 +int ehci_port_power(struct usb_hcd *hcd, int portnum, bool enable)
 +{
 + struct ehci_hcd *ehci = hcd_to_ehci(hcd);

You might as well pass ehci as the first argument instead of hcd.

 + u32 __iomem *status_reg = ehci-regs-port_status[portnum];
 + u32 status = ehci_readl(ehci, status_reg);
 +
 + if (enable)
 + ehci_writel(ehci, status | PORT_POWER, status_reg);
 + else
 + ehci_writel(ehci, status  ~PORT_POWER, status_reg);

These writes are wrong.  You have to turn off the RWC bits before 
writing anything to the status register; otherwise you will 
accidentally turn off some bit that should remain on.

 +
 + return 0;

You missed the point of what I said earlier.  This routine should not
be a callback, because it should run every time we adjust the port
power.  Then _this_ routine should invoke the callback.

Alan Stern

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


Re: [PATCH] USB: phy: add ralink SoC driver

2014-10-10 Thread John Crispin

On 10/10/2014 15:58, Felipe Balbi wrote:
 On Fri, Oct 10, 2014 at 12:20:01PM +0200, John Crispin wrote:
 RT3352, RT5350 and the MT762x SoCs all have a usb phy that we need to setup.

 Signed-off-by: John Crispin blo...@openwrt.org
 new PHY drivers only on drivers/phy ;-)

i that hope i am not the first to get it wrong. I will prepare/send a
fixed version.

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


Re: [PATCH] usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC

2014-10-10 Thread Felipe Balbi
Hi,

On Thu, Oct 09, 2014 at 09:00:16AM -0700, Ashwini Pahuja wrote:
 - This patch adds a UDC driver for Broadcom's USB3.0 device controller 
 IP(BDC).
 
 - The driver was written using the Felipe's USB tree as a baseline from:
 git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 
 - The driver is tested on FPGA-PCIe based platform using various gadget 
 drivers such as zero, mass storage, ether(rndis), hid, audio and also with 
 tools such as USB3CV, USB2CV and Link layer compliance.
 
 - There are 0 warnings reported by checkpatch.pl
 
 Signed-off-by: Ashwini Pahuja ashwini.li...@gmail.com
 ---
  drivers/usb/gadget/udc/Kconfig|2 +
  drivers/usb/gadget/udc/Makefile   |1 +
  drivers/usb/gadget/udc/bdc/Kconfig|   21 +
  drivers/usb/gadget/udc/bdc/Makefile   |3 +
  drivers/usb/gadget/udc/bdc/bdc.h  |  598 ++
  drivers/usb/gadget/udc/bdc/bdc_cmd.c  |  352 ++
  drivers/usb/gadget/udc/bdc/bdc_core.c |  618 ++
  drivers/usb/gadget/udc/bdc/bdc_dbg.c  |  222 
  drivers/usb/gadget/udc/bdc/bdc_dbg.h  |   26 +
  drivers/usb/gadget/udc/bdc/bdc_ep.c   | 2041 
 +
  drivers/usb/gadget/udc/bdc/bdc_pci.c  |  138 +++
  drivers/usb/gadget/udc/bdc/bdc_udc.c  |  577 ++
  12 files changed, 4599 insertions(+), 0 deletions(-)
  create mode 100644 drivers/usb/gadget/udc/bdc/Kconfig
  create mode 100644 drivers/usb/gadget/udc/bdc/Makefile
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc.h
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_cmd.c
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_core.c
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.c
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_dbg.h
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_ep.c
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_pci.c
  create mode 100644 drivers/usb/gadget/udc/bdc/bdc_udc.c
 
 diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
 index 3ea287b..7af6540 100644
 --- a/drivers/usb/gadget/udc/Kconfig
 +++ b/drivers/usb/gadget/udc/Kconfig
 @@ -241,6 +241,8 @@ config USB_M66592
  dynamically linked module called m66592_udc and force all
  gadget drivers to also be dynamically linked.
  
 +source drivers/usb/gadget/udc/bdc/Kconfig
 +
  #
  # Controllers available only in discrete form (and all PCI controllers)
  #
 diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
 index a7f4491..fba2049 100644
 --- a/drivers/usb/gadget/udc/Makefile
 +++ b/drivers/usb/gadget/udc/Makefile
 @@ -30,3 +30,4 @@ obj-$(CONFIG_USB_FOTG210_UDC)   += fotg210-udc.o
  obj-$(CONFIG_USB_MV_U3D) += mv_u3d_core.o
  obj-$(CONFIG_USB_GR_UDC) += gr_udc.o
  obj-$(CONFIG_USB_GADGET_XILINX)  += udc-xilinx.o
 +obj-$(CONFIG_USB_BDC_UDC)+= bdc/
 diff --git a/drivers/usb/gadget/udc/bdc/Kconfig 
 b/drivers/usb/gadget/udc/bdc/Kconfig
 new file mode 100644
 index 000..37d0be7
 --- /dev/null
 +++ b/drivers/usb/gadget/udc/bdc/Kconfig
 @@ -0,0 +1,21 @@
 +config USB_BDC_UDC
 + tristate Broadcom USB3.0 device controller IP driver(BDC)
 + depends on USB_GADGET

depends on HAS_DMA too

 +
 + help
 + BDC is Broadcom's USB3.0 device controller IP. If your SOC has a BDC IP
 + then select this driver.
 +
 + Say y here to link the driver statically, or m to build a 
 dynamically
 + linked module called bdc.
 +
 +if USB_BDC_UDC
 +
 +comment Platform Support
 +config   USB_BDC_PCI
 + tristate BDC support for PCIe based platforms
 + depends on PCI
 + default USB_BDC_UDC
 + help
 + Enable support for platforms which have BDC connected through 
 PCIe, such as Lego3 FPGA platform.
 +endif
 diff --git a/drivers/usb/gadget/udc/bdc/Makefile 
 b/drivers/usb/gadget/udc/bdc/Makefile
 new file mode 100644
 index 000..66383d3
 --- /dev/null
 +++ b/drivers/usb/gadget/udc/bdc/Makefile
 @@ -0,0 +1,3 @@
 +obj-$(CONFIG_USB_BDC_UDC)+= bdc.o
 +bdc-y:= bdc_core.o bdc_cmd.o bdc_ep.o bdc_udc.o bdc_dbg.o
 +obj-$(CONFIG_USB_BDC_PCI)+= bdc_pci.o
 diff --git a/drivers/usb/gadget/udc/bdc/bdc.h 
 b/drivers/usb/gadget/udc/bdc/bdc.h
 new file mode 100644
 index 000..886ff1c
 --- /dev/null
 +++ b/drivers/usb/gadget/udc/bdc/bdc.h
 @@ -0,0 +1,598 @@
 +/*
 + * bdc.h - header for the BRCM BDC USB3.0 device controller
 + *
 + * Copyright (C) 2014 Broadcom Corporation
 + *
 + * Author: Ashwini Pahuja
 + *
 + * This program is free software; you can redistribute it and/or modify it
 + * under the terms of the GNU General Public License as published by the
 + * Free Software Foundation; either version 2 of the License, or (at your
 + * option) any later version.
 + *
 + */
 +
 +#ifndef  __LINUX_BDC_H__
 +#define  __LINUX_BDC_H__
 +
 +#include linux/kernel.h
 +#include linux/usb.h
 +#include linux/device.h
 +#include linux/spinlock.h
 +#include linux/list.h
 +#include linux/dma-mapping.h
 +#include linux/mm.h
 +#include 

Re: [PATCH] USB: phy: add ralink SoC driver

2014-10-10 Thread Felipe Balbi
On Fri, Oct 10, 2014 at 05:01:48PM +0200, John Crispin wrote:
 
 On 10/10/2014 15:58, Felipe Balbi wrote:
  On Fri, Oct 10, 2014 at 12:20:01PM +0200, John Crispin wrote:
  RT3352, RT5350 and the MT762x SoCs all have a usb phy that we need to 
  setup.
 
  Signed-off-by: John Crispin blo...@openwrt.org
  new PHY drivers only on drivers/phy ;-)
 
 i that hope i am not the first to get it wrong. I will prepare/send a
 fixed version.

of course not, happens all the time :-) We're still transitioning things
over.

Thanks

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC v4] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode

2014-10-10 Thread Felipe Balbi
Hi,

On Fri, Oct 10, 2014 at 11:37:31AM +0530, Kiran Raparthy wrote:
 Hi Felipe,
 Thank you very much for taking time in reviewing the patch.
 I will try to improve the patch as per your suggestions.
 however,i have few queries which i wanted to understand from you.

sure thing.

 On 7 October 2014 19:55, Felipe Balbi ba...@ti.com wrote:
  +static int otg_wakeupsource_init(void)
  +{
  + int ret_usb2;
  + int ret_usb3;
  + char wsource_name_usb2[40];
  + char wsource_name_usb3[40];
  + static struct usb_phy *otgws_xceiv_usb2;
  + static struct usb_phy *otgws_xceiv_usb3;
  +
  + otgws_xceiv_usb2 = usb_get_phy(USB_PHY_TYPE_USB2);
  + otgws_xceiv_usb3 = usb_get_phy(USB_PHY_TYPE_USB3);
  +
  + if (IS_ERR(otgws_xceiv_usb2)  IS_ERR(otgws_xceiv_usb3)) {
  + pr_err(%s: No OTG transceiver found\n, __func__);
  + return PTR_ERR(otgws_xceiv_usb2);
  + }
  +
  + spin_lock_init(otgws_xceiv_usb2-otgws_slock);
  + spin_lock_init(otgws_xceiv_usb3-otgws_slock);
  +
  + snprintf(wsource_name_usb2, sizeof(wsource_name_usb2), vbus-%s,
  + dev_name(otgws_xceiv_usb2-dev));
  + wakeup_source_init(otgws_xceiv_usb2-wsource, wsource_name_usb2);
  +
  + snprintf(wsource_name_usb3, sizeof(wsource_name_usb3), vbus-%s,
  + dev_name(otgws_xceiv_usb3-dev));
  + wakeup_source_init(otgws_xceiv_usb3-wsource, wsource_name_usb3);
  +
  + otgws_xceiv_usb2-otgws_nb.notifier_call = 
  otgws_otg_usb2_notifications;
  + ret_usb2 = usb_register_notifier(otgws_xceiv_usb2,
  + otgws_xceiv_usb2-otgws_nb);
  +
  + otgws_xceiv_usb3-otgws_nb.notifier_call = 
  otgws_otg_usb3_notifications;
  + ret_usb3 = usb_register_notifier(otgws_xceiv_usb3,
  + otgws_xceiv_usb3-otgws_nb);
  +
  + if (ret_usb2  ret_usb3) {
  + pr_err(%s: usb_register_notifier on transceiver failed\n,
  +  __func__);
  + wakeup_source_trash(otgws_xceiv_usb2-wsource);
  + wakeup_source_trash(otgws_xceiv_usb3-wsource);
  + otgws_xceiv_usb2 = NULL;
  + otgws_xceiv_usb3 = NULL;
  + return ret_usb2 | ret_usb3;
  + }
  +
  + return 0;
  +}
  +
  +late_initcall(otg_wakeupsource_init);
 
  you guys are really not getting what I mean. I asked for this to be
  built into the core itself. This means that you shouldn't need to use
  notifications nor should you need to call usb_get_phy(). You're part of
  the PHY framework.
 
  All this late_initcall() nonsense should go.
 
  This code won't even work if we have more than one phy of the same type
  (AM437x SoC, for example, has up to 4 instances of dwc3, so that's 4
  USB2 PHYs), because you can't grab the PHY you want.
 
 Apologies,I am new to usb sub system,so i missed this point before i
 posted my patch,Thanks for the information.

np.

  What you need is to:
 
  1) make PHY notifiers generic (move all of that phy-core.c)
 From the above points,you mentioned that if we built it into core,we
 shouldn't need to use notifications
 and your first point here says that make phy notifiers generic in phy-core.c
 can you help me understanding it better so that there wont be any
 understanding gap.

yeah, notifiers should go but if you really must use them, then at least
make all of that generic ;-)

  2) introduce usb_phy_set_event(phy, event) (which just sets the even to a
  phy-event member for now)
  3) make all PHY drivers use usb_phy_set_event()
  4) add the following to usb_phy_set_event()
 
  switch (event) {
  case USB_EVENT_ENUMERATED:
  pm_stay_awake(otgws_xceiv-wsource);
  break;
 
  case USB_EVENT_NONE:
  case USB_EVENT_VBUS:
  case USB_EVENT_ID:
  case USB_EVENT_CHARGER:
  pm_wakeup_event(otgws_xceiv-wsource,
  msecs_to_jiffies(TEMPORARY_HOLD_TIME));
  break;
 
  default:
  break;
  }
 
 Once the phy drivers receives per-PHY event notification(if we use
 notifier,else for any event) we can call usb_phy_set_event from phy
 driver to hold the wakeup source.
 Please correct me if my understanding is incorrect.

yeah. In fact, you can call usb_phy_set_event() directly from PHY's IRQ
handler.

 I have gone through some phy drivers in drivers/phy,since the each
 driver implementation is different from others, i didn't get the best
 place in  PHY driver
 where we can trigger(use phy-core functionality) per-PHY notifier
 registration. any pointers here?

registration ? probe(), they all have probe() functions. Now to figure
out where to call usb_phy_set_event(). That's something completely
different, and that's where the core of this change is :-)

For PHYs which have IRQ lines, easy: just call usb_phy_set_event() from
IRQ handler. For those who don't, then it's a 

Re: [PATCH] usb: musb: musb_dsps: fix NULL pointer in suspend

2014-10-10 Thread Felipe Balbi
On Thu, Oct 09, 2014 at 10:25:20AM +0530, George Cherian wrote:
 
 On 10/08/2014 11:59 PM, Sebastian Andrzej Siewior wrote:
 So testing managed to configure musb in DMA mode but not load the
 matching cppi41 driver for DMA. This results in
 
 |musb-hdrc musb-hdrc.0.auto: Failed to request rx1.
 |musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
 |platform musb-hdrc.0.auto: Driver musb-hdrc requests probe deferral
 
 which is okay. Once the driver is loaded we re-try probing and
 everyone is happy. Until then if you try suspend say
  echo mem  /sys/power/state
 then you go boom
 
 |Unable to handle kernel NULL pointer dereference at virtual address 03a4
 |pgd = cf50c000
 |[03a4] *pgd=8f6a3831, *pte=, *ppte=
 |Internal error: Oops: 17 [#1] ARM
 |PC is at dsps_suspend+0x18/0x9c [musb_dsps]
 |LR is at dsps_suspend+0x18/0x9c [musb_dsps]
 |pc : [bf08e268] lr : [bf08e268] psr: a013
 |sp : cbd97e00 ip : c0af4394 fp : 
 |r10: c0831d90 r9 : 0002 r8 : cf6da410
 |r7 : c03ba4dc r6 : bf08f224 r5 :  r4 : cbc5fcd0
 |r3 : bf08e250 r2 : bf08f264 r1 : cf6da410 r0 : 
 |[bf08e268] (dsps_suspend [musb_dsps]) from [c03ba508] 
 (platform_pm_suspend+0x2c/0x54)
 |Code: e1a04000 e9900041 e2800010 eb4caa8e (e59053a4)
 
 because platform_get_drvdata(glue-musb) returns a NULL pointer as long as 
 the
 device is not fully probed.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 Tested-by: George Cherian george.cher...@ti.com

Care to rebase on testing/next ? It doesn't apply:

checking file drivers/usb/musb/musb_dsps.c
Hunk #1 FAILED at 868.
Hunk #2 succeeded at 887 (offset 1 line).
1 out of 2 hunks FAILED

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH v3 1/3] mfd: add support for Cypress CYUSBS234 USB Serial Bridge controller

2014-10-10 Thread Lee Jones
  -Original Message-
  From: Lee Jones [mailto:lee.jo...@linaro.org]
  Sent: Thursday, October 09, 2014 1:10 PM
  To: Muthu Mani
  Cc: Samuel Ortiz; Wolfram Sang; Linus Walleij; Alexandre Courbot;
  gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
  g...@vger.kernel.org; linux-usb@vger.kernel.org; linux-
  ker...@vger.kernel.org; Rajaram Regupathy; Johan Hovold
  Subject: Re: [PATCH v3 1/3] mfd: add support for Cypress CYUSBS234 USB
  Serial Bridge controller

Why is this in here?

   + cyusbs-usb_dev = usb_get_dev(interface_to_usbdev(interface));
  
  Can you do this last?  Then you can remove the 'error' error path.
 
 mfd_add_devices would utlimately invoke the cell drivers' probe before 
 returning and cell drivers use usb_dev in their probe.
 So, leaving it as such.

Can you move it down to just about mfd_add_devices() then.  That way
can you at least return directly in the other error paths.

[...]

   +MODULE_AUTHOR(Rajaram Regupathy r...@cypress.com);
   +MODULE_AUTHOR(Muthu Mani m...@cypress.com);
   +MODULE_DESCRIPTION(Cypress CYUSBS23x mfd core driver);
  
  s/mfd/MFD/
 
 Is there a typo?

Yes mfd should be MFD, as I sed (spelt this way on purpose).

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Russell King - ARM Linux
On Fri, Oct 10, 2014 at 12:47:06AM +0300, Aaro Koskinen wrote:
 Hi,
 
 On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
What GCC version are you using?

4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
find_get_entry() crashes with 0x involved smell a lot like the
earlier reports from kernels build with those compilers:

https://lkml.org/lkml/2014/6/25/456
https://lkml.org/lkml/2014/6/30/375
https://lkml.org/lkml/2014/6/30/660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
https://lkml.org/lkml/2014/5/9/330
 
 Is it possible to blacklist those GCC versions on ARM somehow as it
 seems people are still using them?
 
 This bug also ruined a file system on one of my boxes last year
 (see e.g. http://marc.info/?l=linux-arm-kernelm=139033442527244w=2).

Given that, why the fsck (pun intended) did you not shout a little louder
about getting it blacklisted.  Looking at your marc.info URL, there's
very little information there which hints at filesystem corruption, and
it's a thread of only *one* message according to marc.info.

Even _if_ I did read the message you point to above, that on its own did
not hint at filesystem corruption.

So, would you please mind passing on further details about this,
specifically which function in the ext4 code is affected, so it can
be properly written up.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Russell King - ARM Linux
On Fri, Oct 10, 2014 at 08:57:43AM -0500, Felipe Balbi wrote:
 On Thu, Oct 09, 2014 at 04:07:15PM -0500, Felipe Balbi wrote:
  Hi,
  
  On Thu, Oct 09, 2014 at 03:46:37PM -0500, Felipe Balbi wrote:
   On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
On Thu, Oct 09, 2014 at 11:26:56AM -0500, Felipe Balbi wrote:
 alright, it's pretty deterministic however. Always on the same test, 
 no
 matter which USB controller, no matter if backing store is RAM or MMC.
 
 Those two undefined instructions on the disassembly caught my 
 attention,
 perhaps I'm facing a GCC bug ?

The undefined instructions are just ARM's BUG() implementation.

But did you see the question I asked you yesterday in your other thread?
http://www.spinics.net/lists/arm-kernel/msg368634.html
   
   hmm, completely missed that, sorry. I'm using 4.8.2, will try something
   else.
  
  seems to be working fine now, thanks. I'll leave test running overnight
  just in case.
 
 yup, ran over night without any problems.

Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
it seems that this has been known about for some time.)

We can blacklist these GCC versions quite easily.  We already have GCC
3.3 blacklisted, and it's trivial to add others.  I would want to include
some proper details about the bug, just like the other existing entries
we already have in asm-offsets.c, where we name the functions that the
compiler is known to break where appropriate.

However, I'm rather annoyed that there are people here who have known
for some time that GCC 4.8.1 and GCC 4.8.2 _can_ lead to filesystem
corruption, and have sat on their backsides doing nothing about getting
it blacklisted for something like a year.

When people talk about the ARM community being dysfunctional... well,
this kind of irresponsible behaviour just gives them more fodder to
throw at us.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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: dwc2: add a call to device_reset_optional()

2014-10-10 Thread John Crispin
We need this for dwc2 to work on older ralink SoC like the rt3052.

Signed-off-by: John Crispin blo...@openwrt.org
---
 drivers/usb/dwc2/hcd.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 4d918ed..8b5f966 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -47,6 +47,7 @@
 #include linux/io.h
 #include linux/slab.h
 #include linux/usb.h
+#include linux/reset.h
 
 #include linux/usb/hcd.h
 #include linux/usb/ch11.h
@@ -2764,6 +2765,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq,
 
dev_dbg(hsotg-dev, DWC OTG HCD INIT\n);
 
+   /* reset the device if a reset controller is present */
+   retval = device_reset_optional(hsotg-dev);
+   if (retval  retval != -ENOSYS)
+   return retval;
+
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
 
-- 
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 0/8] Equivalent of g_hid with configfs

2014-10-10 Thread Andrzej Pietrasiewicz
This series aims at integrating configfs into uvc, the way
it has been done for acm, ncm, ecm, eem, ecm subset, rndis, obex, phonet,
mass_storage, FunctionFS, loopback, sourcesink, uac1, uac2 and uvc.

The hid function driver needs some data from userspace, which cannot
be known in advance, so it must be passed somehow to the kernel.

So far passing this data has been done in a rather tricky way:
another (proablby out-of-tree) kernel module is required to provide
fake platform device(s), for which the g_hid happens to be
a platform driver. The platform devices contain in their platform_data
the data to be passed to the hid function, and during platform drivers's
probe the data is passed.

With configfs passing of the said data is straightforward: there is
a report_desc attribute in hid function's directory, to which the
data is just written.

Rebased onto Felipe's testing/next.

Since Felipe has closed his tree for 3.18, this is meant for 3.19.

BACKWARD COMPATIBILITY
==

Please note that the old g_hid.ko is still available and works.


USING THE NEW GADGET
==

Please refer to this post:

http://www.spinics.net/lists/linux-usb/msg76388.html

for general information from Sebastian on how to use configfs-based
gadgets (*).

With configfs the procedure is as follows, compared to the information
mentioned above (*):

instead of mkdir functions/acm.ttyS1 do

mkdir functions/hid.instance name

e.g. mkdir functions/hid.usb0.

In the hid.usb0 directory there will be the following attributes:

protocol- HID protocol to use
report_desc - data to be used in HID reports, except data
passed with /dev/hidgX
report_length   - HID report length
subclass- HID subclass to use

For a keyboard protocol and subclass are 1, report_length is 8,
while the report_desc is:

$ hd my_report_desc
  05 01 09 06 a1 01 05 07  19 e0 29 e7 15 00 25 01  |..)...%.|
0010  75 01 95 08 81 02 95 01  75 08 81 03 95 05 75 01  |u...u.u.|
0020  05 08 19 01 29 05 91 02  95 01 75 03 91 03 95 06  |).u.|
0030  75 08 15 00 25 65 05 07  19 00 29 65 81 00 c0 |u...%e)e...|
003f

Such a sequence of bytes can be stored to the attribute with echo:

$ echo -ne \\x05\\x01\\x09\\x06\\xa1.

Below is a script which creates a hid gadget:

$ modprobe libcomposite
$ mount none cfg -t configfs
$ mkdir cfg/usb_gadget/g1
$ cd cfg/usb_gadget/g1
$ mkdir configs/c.1
$ mkdir functions/hid.usb0
$ echo 1  functions/hid.usb0/protocol
$ echo 1  functions/hid.usb0/subclass
$ echo 8  functions/hid.usb0/report_length
$ cat my_report_desc  functions/hid.usb0/report_desc
$ mkdir strings/0x409
$ mkdir configs/c.1/strings/0x409
$ echo 0xa4ac  idProduct
$ echo 0x0525  idVendor
$ echo serial  strings/0x409/serialnumber
$ echo manufacturer  strings/0x409/manufacturer
$ echo HID Gadget  strings/0x409/product
$ echo Conf 1  configs/c.1/strings/0x409/configuration
$ echo 120  configs/c.1/MaxPower
$ ln -s functions/hid.usb0 configs/c.1
$ echo 1248.hsotg  UDC

TESTING THE FUNCTION


gadget)
- create the gadget
- connect the gadget to a host, preferably not the one used
to control the gadget
- run a program which writes to /dev/hidgN, e.g.
a userspace program found in Documentation/usb/gadget_hid.txt:

$ ./hid_gadget_test /dev/hidg0 keyboard

host)
- observe the keystrokes from the gadget

Andrzej Pietrasiewicz (8):
  usb: gadget: f_hid: check return value of class_create
  usb: gadget: f_hid: check return value of device_create
  usb: gadget: hid: mirror init operations in module cleanup
  usb: gadget: f_hid: convert to new function interface with backward
compatibility
  usb: gadget: hid: convert to new interface of f_hid
  usb: gadget: f_hid: remove compatibility layer
  usb: gadget: f_hid: use usb_gstrings_attach
  usb: gadget: hid: add configfs support

 Documentation/ABI/testing/configfs-usb-gadget-hid |  11 +
 Documentation/usb/gadget_hid.txt  |   7 +
 drivers/usb/gadget/Kconfig|  13 +
 drivers/usb/gadget/function/Makefile  |   2 +
 drivers/usb/gadget/function/f_hid.c   | 360 ++
 drivers/usb/gadget/function/u_hid.h   |  42 +++
 drivers/usb/gadget/legacy/Kconfig |   1 +
 drivers/usb/gadget/legacy/hid.c   |  79 +++--
 8 files changed, 428 insertions(+), 87 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-hid
 create mode 100644 drivers/usb/gadget/function/u_hid.h

-- 
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 6/8] usb: gadget: f_hid: remove compatibility layer

2014-10-10 Thread Andrzej Pietrasiewicz
There are no old function interface users left, so remove it.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/function/f_hid.c | 73 -
 1 file changed, 73 deletions(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 9ba340d..55d4e7c 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -28,10 +28,8 @@
 
 static int major, minors;
 static struct class *hidg_class;
-#ifndef USBF_HID_INCLUDED
 static DEFINE_IDA(hidg_ida);
 static DEFINE_MUTEX(hidg_ida_lock); /* protects access to hidg_ida */
-#endif
 
 /*-*/
 /*HID gadget struct*/
@@ -683,75 +681,6 @@ fail:
return status;
 }
 
-#ifdef USBF_HID_INCLUDED
-static void hidg_unbind(struct usb_configuration *c, struct usb_function *f)
-{
-   struct f_hidg *hidg = func_to_hidg(f);
-
-   device_destroy(hidg_class, MKDEV(major, hidg-minor));
-   cdev_del(hidg-cdev);
-
-   /* disable/free request and end point */
-   usb_ep_disable(hidg-in_ep);
-   usb_ep_dequeue(hidg-in_ep, hidg-req);
-   kfree(hidg-req-buf);
-   usb_ep_free_request(hidg-in_ep, hidg-req);
-
-   usb_free_all_descriptors(f);
-
-   kfree(hidg-report_desc);
-   kfree(hidg);
-}
-
-/*-*/
-/* usb_configuration   */
-int __init hidg_bind_config(struct usb_configuration *c,
-   struct hidg_func_descriptor *fdesc, int index)
-{
-   struct f_hidg *hidg;
-   int status;
-
-   if (index = minors)
-   return -ENOENT;
-
-   /* allocate and initialize one new instance */
-   hidg = kzalloc(sizeof *hidg, GFP_KERNEL);
-   if (!hidg)
-   return -ENOMEM;
-
-   hidg-minor = index;
-   hidg-bInterfaceSubClass = fdesc-subclass;
-   hidg-bInterfaceProtocol = fdesc-protocol;
-   hidg-report_length = fdesc-report_length;
-   hidg-report_desc_length = fdesc-report_desc_length;
-   hidg-report_desc = kmemdup(fdesc-report_desc,
-   fdesc-report_desc_length,
-   GFP_KERNEL);
-   if (!hidg-report_desc) {
-   kfree(hidg);
-   return -ENOMEM;
-   }
-
-   hidg-func.name= hid;
-   hidg-func.strings = ct_func_strings;
-   hidg-func.bind= hidg_bind;
-   hidg-func.unbind  = hidg_unbind;
-   hidg-func.set_alt = hidg_set_alt;
-   hidg-func.disable = hidg_disable;
-   hidg-func.setup   = hidg_setup;
-
-   /* this could me made configurable at some point */
-   hidg-qlen = 4;
-
-   status = usb_add_function(c, hidg-func);
-   if (status)
-   kfree(hidg);
-
-   return status;
-}
-
-#else
-
 static inline int hidg_get_minor(void)
 {
int ret;
@@ -894,8 +823,6 @@ DECLARE_USB_FUNCTION_INIT(hid, hidg_alloc_inst, hidg_alloc);
 MODULE_LICENSE(GPL);
 MODULE_AUTHOR(Fabien Chouteau);
 
-#endif
-
 int ghid_setup(struct usb_gadget *g, int count)
 {
int status;
-- 
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 7/8] usb: gadget: f_hid: use usb_gstrings_attach

2014-10-10 Thread Andrzej Pietrasiewicz
Before configfs is integrated the usb_gstrings_attach() interface
must be used.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/function/f_hid.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 55d4e7c..8c0096f 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -582,18 +582,17 @@ static int hidg_bind(struct usb_configuration *c, struct 
usb_function *f)
 {
struct usb_ep   *ep;
struct f_hidg   *hidg = func_to_hidg(f);
+   struct usb_string   *us;
struct device   *device;
int status;
dev_t   dev;
 
/* maybe allocate device-global string IDs, and patch descriptors */
-   if (ct_func_string_defs[CT_FUNC_HID_IDX].id == 0) {
-   status = usb_string_id(c-cdev);
-   if (status  0)
-   return status;
-   ct_func_string_defs[CT_FUNC_HID_IDX].id = status;
-   hidg_interface_desc.iInterface = status;
-   }
+   us = usb_gstrings_attach(c-cdev, ct_func_strings,
+ARRAY_SIZE(ct_func_string_defs));
+   if (IS_ERR(us))
+   return PTR_ERR(us);
+   hidg_interface_desc.iInterface = us[CT_FUNC_HID_IDX].id;
 
/* allocate instance-specific interface IDs, and patch descriptors */
status = usb_interface_id(c, f);
@@ -805,7 +804,6 @@ struct usb_function *hidg_alloc(struct 
usb_function_instance *fi)
}
 
hidg-func.name= hid;
-   hidg-func.strings = ct_func_strings;
hidg-func.bind= hidg_bind;
hidg-func.unbind  = hidg_unbind;
hidg-func.set_alt = hidg_set_alt;
-- 
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 4/8] usb: gadget: f_hid: convert to new function interface with backward compatibility

2014-10-10 Thread Andrzej Pietrasiewicz
Converting hid to the new function interface requires converting
the USB hid's function code and its users.

This patch converts the f_hid.c to the new function interface.

The file can now be compiled into a separate usb_f_hid.ko module.

The old function interface is provided by means of a preprocessor
conditional directives. After all users are converted, the old interface
can be removed.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/Kconfig   |   3 +
 drivers/usb/gadget/function/Makefile |   2 +
 drivers/usb/gadget/function/f_hid.c  | 218 ++-
 drivers/usb/gadget/function/u_hid.h  |  35 ++
 drivers/usb/gadget/legacy/hid.c  |   1 +
 5 files changed, 227 insertions(+), 32 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_hid.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index c4880fc..e48f7c0 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -190,6 +190,9 @@ config USB_F_UAC2
 config USB_F_UVC
tristate
 
+config USB_F_HID
+   tristate
+
 choice
tristate USB Gadget Drivers
default USB_ETH
diff --git a/drivers/usb/gadget/function/Makefile 
b/drivers/usb/gadget/function/Makefile
index 90701aa..1ef2359 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -38,3 +38,5 @@ usb_f_uac2-y  := f_uac2.o
 obj-$(CONFIG_USB_F_UAC2)   += usb_f_uac2.o
 usb_f_uvc-y:= f_uvc.o uvc_queue.o uvc_v4l2.o uvc_video.o
 obj-$(CONFIG_USB_F_UVC)+= usb_f_uvc.o
+usb_f_hid-y:= f_hid.o
+obj-$(CONFIG_USB_F_HID)+= usb_f_hid.o
diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 434bce8..9ba340d 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -12,6 +12,7 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/hid.h
+#include linux/idr.h
 #include linux/cdev.h
 #include linux/mutex.h
 #include linux/poll.h
@@ -21,9 +22,16 @@
 #include linux/usb/g_hid.h
 
 #include u_f.h
+#include u_hid.h
+
+#define HIDG_MINORS4
 
 static int major, minors;
 static struct class *hidg_class;
+#ifndef USBF_HID_INCLUDED
+static DEFINE_IDA(hidg_ida);
+static DEFINE_MUTEX(hidg_ida_lock); /* protects access to hidg_ida */
+#endif
 
 /*-*/
 /*HID gadget struct*/
@@ -161,6 +169,26 @@ static struct usb_descriptor_header *hidg_fs_descriptors[] 
= {
 };
 
 /*-*/
+/* Strings */
+
+#define CT_FUNC_HID_IDX0
+
+static struct usb_string ct_func_string_defs[] = {
+   [CT_FUNC_HID_IDX].s = HID Interface,
+   {}, /* end of list */
+};
+
+static struct usb_gadget_strings ct_func_string_table = {
+   .language   = 0x0409,   /* en-US */
+   .strings= ct_func_string_defs,
+};
+
+static struct usb_gadget_strings *ct_func_strings[] = {
+   ct_func_string_table,
+   NULL,
+};
+
+/*-*/
 /*  Char Device*/
 
 static ssize_t f_hidg_read(struct file *file, char __user *buffer,
@@ -552,7 +580,7 @@ const struct file_operations f_hidg_fops = {
.llseek = noop_llseek,
 };
 
-static int __init hidg_bind(struct usb_configuration *c, struct usb_function 
*f)
+static int hidg_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct usb_ep   *ep;
struct f_hidg   *hidg = func_to_hidg(f);
@@ -560,6 +588,15 @@ static int __init hidg_bind(struct usb_configuration *c, 
struct usb_function *f)
int status;
dev_t   dev;
 
+   /* maybe allocate device-global string IDs, and patch descriptors */
+   if (ct_func_string_defs[CT_FUNC_HID_IDX].id == 0) {
+   status = usb_string_id(c-cdev);
+   if (status  0)
+   return status;
+   ct_func_string_defs[CT_FUNC_HID_IDX].id = status;
+   hidg_interface_desc.iInterface = status;
+   }
+
/* allocate instance-specific interface IDs, and patch descriptors */
status = usb_interface_id(c, f);
if (status  0)
@@ -646,6 +683,7 @@ fail:
return status;
 }
 
+#ifdef USBF_HID_INCLUDED
 static void hidg_unbind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_hidg *hidg = func_to_hidg(f);
@@ -666,28 +704,7 @@ static void hidg_unbind(struct usb_configuration *c, 
struct usb_function *f)
 }
 
 /*-*/
-/* 

[PATCH 2/8] usb: gadget: f_hid: check return value of device_create

2014-10-10 Thread Andrzej Pietrasiewicz
device_create() might fail, so check its return value and react
appropriately.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/function/f_hid.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 25021df..434bce8 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -556,6 +556,7 @@ static int __init hidg_bind(struct usb_configuration *c, 
struct usb_function *f)
 {
struct usb_ep   *ep;
struct f_hidg   *hidg = func_to_hidg(f);
+   struct device   *device;
int status;
dev_t   dev;
 
@@ -623,10 +624,16 @@ static int __init hidg_bind(struct usb_configuration *c, 
struct usb_function *f)
if (status)
goto fail;
 
-   device_create(hidg_class, NULL, dev, NULL, %s%d, hidg, hidg-minor);
+   device = device_create(hidg_class, NULL, dev, NULL,
+  %s%d, hidg, hidg-minor);
+   if (IS_ERR(device)) {
+   status = PTR_ERR(device);
+   goto del;
+   }
 
return 0;
-
+del:
+   cdev_del(hidg-cdev);
 fail:
ERROR(f-config-cdev, hidg_bind FAILED\n);
if (hidg-req != NULL) {
-- 
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 3/8] usb: gadget: hid: mirror init operations in module cleanup

2014-10-10 Thread Andrzej Pietrasiewicz
So far platform driver has been unregistered first,
so just after that the usb composite is still available,
but there is no hid data any more.

Reverse the order so that first the usb composite becomes
unavailable and second the hid data goes away.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/legacy/hid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 778613e..fba80a2 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -260,7 +260,7 @@ module_init(hidg_init);
 
 static void __exit hidg_cleanup(void)
 {
-   platform_driver_unregister(hidg_plat_driver);
usb_composite_unregister(hidg_driver);
+   platform_driver_unregister(hidg_plat_driver);
 }
 module_exit(hidg_cleanup);
-- 
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 5/8] usb: gadget: hid: convert to new interface of f_hid

2014-10-10 Thread Andrzej Pietrasiewicz
Use the new f_hid interface in order for the old to be removed.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/legacy/Kconfig |  1 +
 drivers/usb/gadget/legacy/hid.c   | 78 +++
 2 files changed, 56 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/gadget/legacy/Kconfig 
b/drivers/usb/gadget/legacy/Kconfig
index 24392d2..af99550 100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -419,6 +419,7 @@ endif # TTY
 config USB_G_HID
tristate HID Gadget
select USB_LIBCOMPOSITE
+   select USB_F_HID
help
  The HID gadget driver provides generic emulation of USB
  Human Interface Devices (HID).
diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 26cb4ea..633fe7e 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -17,11 +17,14 @@
 #include linux/list.h
 #include linux/module.h
 #include linux/usb/composite.h
+#include linux/usb/g_hid.h
 
 #include gadget_chips.h
 #define DRIVER_DESCHID Gadget
 #define DRIVER_VERSION 2010/03/16
 
+#include u_hid.h
+
 /*-*/
 
 #define HIDG_VENDOR_NUM0x0525  /* XXX NetChip */
@@ -29,18 +32,9 @@
 
 /*-*/
 
-/*
- * kbuild is not very cooperative with respect to linking separately
- * compiled library objects into one module.  So for now we won't use
- * separate compilation ... ensuring init/exit sections work to shrink
- * the runtime footprint, and giving us at least some parts of what
- * a gcc --combine ... part1.c part2.c part3.c ...  build would.
- */
-#define USBF_HID_INCLUDED
-#include f_hid.c
-
-
 struct hidg_func_node {
+   struct usb_function_instance *fi;
+   struct usb_function *f;
struct list_head node;
struct hidg_func_descriptor *func;
 };
@@ -114,8 +108,8 @@ static struct usb_gadget_strings *dev_strings[] = {
 
 static int __init do_config(struct usb_configuration *c)
 {
-   struct hidg_func_node *e;
-   int func = 0, status = 0;
+   struct hidg_func_node *e, *n;
+   int status = 0;
 
if (gadget_is_otg(c-cdev-gadget)) {
c-descriptors = otg_desc;
@@ -123,11 +117,24 @@ static int __init do_config(struct usb_configuration *c)
}
 
list_for_each_entry(e, hidg_func_list, node) {
-   status = hidg_bind_config(c, e-func, func++);
-   if (status)
-   break;
+   e-f = usb_get_function(e-fi);
+   if (IS_ERR(e-f))
+   goto put;
+   status = usb_add_function(c, e-f);
+   if (status  0) {
+   usb_put_function(e-f);
+   goto put;
+   }
}
 
+   return 0;
+put:
+   list_for_each_entry(n, hidg_func_list, node) {
+   if (n == e)
+   break;
+   usb_remove_function(c, n-f);
+   usb_put_function(n-f);
+   }
return status;
 }
 
@@ -144,6 +151,8 @@ static int __init hid_bind(struct usb_composite_dev *cdev)
 {
struct usb_gadget *gadget = cdev-gadget;
struct list_head *tmp;
+   struct hidg_func_node *n, *m;
+   struct f_hid_opts *hid_opts;
int status, funcs = 0;
 
list_for_each(tmp, hidg_func_list)
@@ -152,10 +161,20 @@ static int __init hid_bind(struct usb_composite_dev *cdev)
if (!funcs)
return -ENODEV;
 
-   /* set up HID */
-   status = ghid_setup(cdev-gadget, funcs);
-   if (status  0)
-   return status;
+   list_for_each_entry(n, hidg_func_list, node) {
+   n-fi = usb_get_function_instance(hid);
+   if (IS_ERR(n-fi)) {
+   status = PTR_ERR(n-fi);
+   goto put;
+   }
+   hid_opts = container_of(n-fi, struct f_hid_opts, func_inst);
+   hid_opts-subclass = n-func-subclass;
+   hid_opts-protocol = n-func-protocol;
+   hid_opts-report_length = n-func-report_length;
+   hid_opts-report_desc_length = n-func-report_desc_length;
+   hid_opts-report_desc = n-func-report_desc;
+   }
+
 
/* Allocate string descriptor numbers ... note that string
 * contents can be overridden by the composite_dev glue.
@@ -163,24 +182,37 @@ static int __init hid_bind(struct usb_composite_dev *cdev)
 
status = usb_string_ids_tab(cdev, strings_dev);
if (status  0)
-   return status;
+   goto put;
device_desc.iManufacturer = strings_dev[USB_GADGET_MANUFACTURER_IDX].id;
device_desc.iProduct = strings_dev[USB_GADGET_PRODUCT_IDX].id;
 
/* register our configuration */
status = 

[PATCH 1/8] usb: gadget: f_hid: check return value of class_create

2014-10-10 Thread Andrzej Pietrasiewicz
class_create() might fail, so check its return value and react
appropriately.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 drivers/usb/gadget/function/f_hid.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index a95290a..25021df 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -741,6 +741,10 @@ int __init ghid_setup(struct usb_gadget *g, int count)
dev_t dev;
 
hidg_class = class_create(THIS_MODULE, hidg);
+   if (IS_ERR(hidg_class)) {
+   hidg_class = NULL;
+   return PTR_ERR(hidg_class);
+   }
 
status = alloc_chrdev_region(dev, 0, count, hidg);
if (!status) {
-- 
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 8/8] usb: gadget: hid: add configfs support

2014-10-10 Thread Andrzej Pietrasiewicz
Make the hid function available for gadgets composed with configfs.

Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
---
 Documentation/ABI/testing/configfs-usb-gadget-hid |  11 ++
 Documentation/usb/gadget_hid.txt  |   7 ++
 drivers/usb/gadget/Kconfig|  10 ++
 drivers/usb/gadget/function/f_hid.c   | 144 +-
 drivers/usb/gadget/function/u_hid.h   |   7 ++
 5 files changed, 178 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-hid

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-hid 
b/Documentation/ABI/testing/configfs-usb-gadget-hid
new file mode 100644
index 000..f12e00e
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-hid
@@ -0,0 +1,11 @@
+What:  /config/usb-gadget/gadget/functions/hid.name
+Date:  Nov 2014
+KernelVersion: 3.19
+Description:
+   The attributes:
+
+   protocol- HID protocol to use
+   report_desc - blob corresponding to HID report descriptors
+   except the data passed through /dev/hidgN
+   report_length   - HID report length
+   subclass- HID device subclass to use
diff --git a/Documentation/usb/gadget_hid.txt b/Documentation/usb/gadget_hid.txt
index 12696c2..7a0fb8e 100644
--- a/Documentation/usb/gadget_hid.txt
+++ b/Documentation/usb/gadget_hid.txt
@@ -74,6 +74,13 @@ static struct platform_device my_hid = {
You can add as many HID functions as you want, only limited by
the amount of interrupt endpoints your gadget driver supports.
 
+Configuration with configfs
+
+   Instead of adding fake platform devices and drivers in order to pass
+   some data to the kernel, if HID is a part of a gadget composed with
+   configfs the hidg_func_descriptor.report_desc is passed to the kernel
+   by writing the appropriate stream of bytes to a configfs attribute.
+
 Send and receive HID reports
 
HID reports can be sent/received using read/write on the
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index e48f7c0..2f9a1bc 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -365,6 +365,16 @@ config USB_CONFIGFS_F_FS
  implemented in kernel space (for instance Ethernet, serial or
  mass storage) and other are implemented in user space.
 
+config USB_CONFIGFS_F_HID
+   boolean HID function
+   select USB_LIBCOMPOSITE
+   select USB_F_HID
+   help
+ The HID function driver provides generic emulation of USB
+ Human Interface Devices (HID).
+
+ For more information, see Documentation/usb/gadget_hid.txt.
+
 source drivers/usb/gadget/legacy/Kconfig
 
 endchoice
diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 8c0096f..5821ad7 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -689,6 +689,136 @@ static inline int hidg_get_minor(void)
return ret;
 }
 
+static inline struct f_hid_opts *to_f_hid_opts(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct f_hid_opts,
+   func_inst.group);
+}
+
+CONFIGFS_ATTR_STRUCT(f_hid_opts);
+CONFIGFS_ATTR_OPS(f_hid_opts);
+
+static void hid_attr_release(struct config_item *item)
+{
+   struct f_hid_opts *opts = to_f_hid_opts(item);
+
+   usb_put_function_instance(opts-func_inst);
+}
+
+static struct configfs_item_operations hidg_item_ops = {
+   .release= hid_attr_release,
+   .show_attribute = f_hid_opts_attr_show,
+   .store_attribute = f_hid_opts_attr_store,
+};
+
+#define F_HID_OPT(name, prec, limit)   \
+static ssize_t f_hid_opts_##name##_show(struct f_hid_opts *opts, char *page)\
+{  \
+   int result; \
+   \
+   mutex_lock(opts-lock);\
+   result = sprintf(page, %d\n, opts-name); \
+   mutex_unlock(opts-lock);  \
+   \
+   return result;  \
+}  \
+   \
+static ssize_t f_hid_opts_##name##_store(struct f_hid_opts *opts,  \
+const char *page, size_t len)  \
+{  \
+   int ret;\
+   u##prec num;

xHCI bug

2014-10-10 Thread Felipe Balbi
Hi Mathias,

I seem to be able to rather easily kill xHCI by just running
test.sh/testusb with a USB2 device attached to it (I used my AM437x
Starter Kit for the test).

I noticed that after not too long, all tests started failing (see below)
but using ehci, it works just fine (afaicr).

Here's a snippet of the hang, but it has been running for a while and
before testusb I ran over 24 hours of MSC testing, also passed full
USB20CV and USB30CV with g_mass_storage and g_zero (and most other
gadget drivers too):

[874685.176903] usbtest 1-7:3.0: Linux gadget zero
[874685.176906] usbtest 1-7:3.0: high-speed {control in/out bulk-in bulk-out} 
tests (+alt)
[874703.140258] usbtest 1-7:3.0: TEST 9:  ch9 (subset) control tests, 5000 times
[874723.716857] usbtest 1-7:3.0: TEST 10:  queue 32 control calls, 5000 times
[874743.773236] usbtest 1-7:3.0: TEST 14:  15000 ep0out, 1..256 vary 1
[874748.774291] usbtest 1-7:3.0: ctrl_out write failed, code -110, count 0
[874754.297205] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874759.819703] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874765.341962] usbtest 1-7:3.0: set altsetting to 0 failed, -110
[874765.863127] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874766.383337] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874766.903526] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874767.423750] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874767.943965] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874768.464174] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874768.988078] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874769.376451] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874769.896675] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874770.416920] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874770.937170] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874771.306870] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874771.829525] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874772.349723] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874772.870041] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874773.363080] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874773.866381] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874774.386594] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874774.910836] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874775.431062] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874775.951018] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874776.347478] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874776.867690] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874777.387859] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874777.911980] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874778.432250] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874778.952692] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874779.472784] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.008646] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.528880] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874780.925468] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874781.297533] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874781.817776] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874782.341828] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874782.862237] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874783.382444] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874783.902684] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874784.430835] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874784.954964] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874785.475225] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874785.999464] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874786.519801] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874787.039882] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874787.560232] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874788.080327] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874788.600517] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874789.120687] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874789.641042] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874790.161156] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874790.680681] xhci_hcd :00:14.0: URB transfer length is wrong, xHC issue? 
req. len = 0, act. len = 4294967288
[874790.680707] usbtest 1-7:3.0: TEST 1:  write 2048 bytes 5000 times
[874800.683902] usb 1-7: test1 failed, iterations left 4999, status -110 (not 0)
[874801.205807] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874801.726028] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874802.246264] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874802.770493] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874803.290302] usbtest 1-7:3.0: set altsetting to 0 failed, -71
[874803.810881] usbtest 1-7:3.0: set altsetting to 0 

Re: xHCI bug

2014-10-10 Thread Felipe Balbi
Hi again,

On Fri, Oct 10, 2014 at 01:47:55PM -0500, Felipe Balbi wrote:
 I seem to be able to rather easily kill xHCI by just running
 test.sh/testusb with a USB2 device attached to it (I used my AM437x
 Starter Kit for the test).

I think Tony mentioned taht it's also pretty easy to break xHCI by
trying to cold flash an old N900

-- 
balbi


signature.asc
Description: Digital signature


Re: xHCI bug

2014-10-10 Thread Tony Lindgren
* Felipe Balbi ba...@ti.com [141010 11:51]:
 Hi again,
 
 On Fri, Oct 10, 2014 at 01:47:55PM -0500, Felipe Balbi wrote:
  I seem to be able to rather easily kill xHCI by just running
  test.sh/testusb with a USB2 device attached to it (I used my AM437x
  Starter Kit for the test).
 
 I think Tony mentioned taht it's also pretty easy to break xHCI by
 trying to cold flash an old N900

Heh yeah. After upgrading my build box, I noticed few things.
The new mobo came with xchi, and the following broke:

1. My old printer MFC-7820N no longer worked for scanning

2. Trying to cold flash any omap3 boards over USB stopped working
   for most of the time

3. Back-ups to a USB drive occasionally started failing

4. After disabling xhci in the BIOS, things were still flakey
   with ehci

5. I ended up installing a usb2.0 ehci pcie card to fix things

Regards,

Tony
--
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: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Aaro Koskinen
On Fri, Oct 10, 2014 at 05:18:35PM +0100, Russell King - ARM Linux wrote:
 On Fri, Oct 10, 2014 at 12:47:06AM +0300, Aaro Koskinen wrote:
  On Thu, Oct 09, 2014 at 10:41:01PM +0200, Rabin Vincent wrote:
 What GCC version are you using?
 
 4.8.1 and 4.8.2 are known to miscompile the ARM kernel and these
 find_get_entry() crashes with 0x involved smell a lot like the
 earlier reports from kernels build with those compilers:
 
 https://lkml.org/lkml/2014/6/25/456
 https://lkml.org/lkml/2014/6/30/375
 https://lkml.org/lkml/2014/6/30/660
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
 https://lkml.org/lkml/2014/5/9/330
  
  Is it possible to blacklist those GCC versions on ARM somehow as it
  seems people are still using them?
  
  This bug also ruined a file system on one of my boxes last year
  (see e.g. http://marc.info/?l=linux-arm-kernelm=139033442527244w=2).
 
 Given that, why the fsck (pun intended) did you not shout a little louder
 about getting it blacklisted.  Looking at your marc.info URL, there's
 very little information there which hints at filesystem corruption, and
 it's a thread of only *one* message according to marc.info.
 
 Even _if_ I did read the message you point to above, that on its own did
 not hint at filesystem corruption.
 
 So, would you please mind passing on further details about this,
 specifically which function in the ext4 code is affected, so it can
 be properly written up.

I have not done any proper deeper analysis. After I first mailed about
the issue I just downgraded GCC and pretty much forgot about it until
an engineer from some commercial Linux vendor replied privately months
later and kindly pointed me the needed GCC fix (which I then shared
in the reply). Then I just moved on using a newer GCC with no issues.
Obviously this was not a widespread problem since no one else
reported the same.

Today I again booted a kernel compiled with GCC 4.8.2 and still was able
reproduce the issue, and I think below shows that at least ext3 can
easily end up in inconsistent state using these compiler versions:

0) Run the bad kernel:

~ # dmesg|grep GCC
[0.00] Linux version 3.17.0-mvebu-los_9755+ (aaro@cooljazz) (gcc 
version 4.8.2 (GCC) ) #1 Fri Oct 10 21:05:20 EEST 2014

1) Start with small ext3 (writeback) fs with gcc tarball:

/mnt/test # ls -l
total 84092
-rw-r--r--1 root root  85999682 Apr 24 21:52 gcc-4.8.2.tar.bz2
drwx--2 root root 16384 Oct 10 10:33 lost+found
/mnt/test # df -h .
FilesystemSize  Used Available Use% Mounted on
/dev/sdc1 3.8G 90.2M  3.5G   2% /mnt/test

2) Extract, delete  crash:

/mnt/test # tar xjf gcc-4.8.2.tar.bz2
/mnt/test # rm -rf gcc-4.8.2
rm: can't remove 'gcc-4.8.2/libgfortran/generated': Directory not empty
rm: can't remove 'gcc-4.8.2/libgfortran': Directory not empty
rm: can't remove 
'gcc-4.8.2/gcc/testsuite/gcc.dg/compat/struct-by-value-18a_y.c': No such file 
or directory
rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg/compat': Directory not empty
rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg/tree-ssa': Directory not empty
rm: can't remove 'gcc-4.8.2/gcc/testsuite/gcc.dg': Directory not empty
rm: can't remove 
'gcc-4.8.2/gcc/testsuite/gfortran.dg/result_default_init_1.f90': No such file 
or directory
rm: can't remove 'gcc-4.8.2/gcc/testsuite/gfortran.dg': Directory not empty
[  960.864433] Unable to handle kernel paging request at virtual address 

[  960.930597] pgd = df6e
[  960.990849] [] *pgd=1fffd831, *pte=, *ppte=
[  961.056512] Internal error: Oops: 1 [#1] ARM
[  961.120063] Modules linked in:
[  961.180974] CPU: 0 PID: 684 Comm: rm Not tainted 3.17.0-mvebu-los_9755+ #1
[  961.247146] task: df447b00 ti: df4de000 task.ti: df4de000
[  961.311524] PC is at find_get_entry+0x28/0x84
[  961.375037] LR is at radix_tree_lookup_slot+0x1c/0x2c
[  961.439061] pc : [c006e418]lr : [c018392c]psr: a013
[  961.439061] sp : df4dfc68  ip :   fp : df4dfc7c
[  961.570018] r10: 0001  r9 : c04e3253  r8 : df020b60
[  961.634596] r7 : 0009001a  r6 :   r5 : 0009001a  r4 : df020c90
[  961.700070] r3 :   r2 :   r1 : 0009001a  r0 : 
[  961.764437] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  961.830518] Control: 0005317f  Table: 1f6e  DAC: 0015
[  961.895866] Process rm (pid: 684, stack limit = 0xdf4de1c0)
[  961.960597] Stack: (0xdf4dfc68 to 0xdf4e)
[  962.022968] fc60:   0001 df020c8c df4dfcb4 df4dfc80 
c006eef68 c006e400
[  962.091214] fc80: c00d4e80 c00d4764 1000 0009001a   
df0200b60 df020b60
[  962.159490] fca0: df020bd8 df04e4d8 df4dfd04 df4dfcb8 c00d34c0 c006ef44 
0 df4dfcc8
[  962.226940] fcc0: c00d4e80 c00d4764 1000 0001 df4dfd84 dd1c73f0 
000900306 
[  962.295558] fce0: 00090068   df020b60 df04e4d8 0181 

Re: Displaylink Attached Display Adapater and Monitor Not Recognized

2014-10-10 Thread poma

https://lkml.org/lkml/2013/7/23/121

--
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: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Nathan Lynch
On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
 
 Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
 it seems that this has been known about for some time.)

Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x  3
are affected, as well as 4.9.0.

 We can blacklist these GCC versions quite easily.  We already have GCC
 3.3 blacklisted, and it's trivial to add others.  I would want to include
 some proper details about the bug, just like the other existing entries
 we already have in asm-offsets.c, where we name the functions that the
 compiler is known to break where appropriate.

Before blacklisting anything, it's worth considering that simple version
checks would break existing pre-4.8.3 compilers that have been patched
for PR58854.  It looks like Yocto and Buildroot issued releases with
patched 4.8.2 compilers well before the (fixed) 4.8.3 release.  I think
the most we can reasonably do without breaking some correctly-behaving
toolchains is to emit a warning.

Hopefully nobody's still using gcc 4.8 from the Linaro 2013.11 toolchain
release -- since it's a 4.8.3 prerelease from before the fix was
committed you'll get GCC_VERSION == 40803 but still generate bad code.

 However, I'm rather annoyed that there are people here who have known
 for some time that GCC 4.8.1 and GCC 4.8.2 _can_ lead to filesystem
 corruption, and have sat on their backsides doing nothing about getting
 it blacklisted for something like a year.

Mea culpa, although I hadn't drawn the connection to FS corruption
reports until now.  I have known about the issue for some time, but
figured the prevalence of the fix in downstream projects largely
mitigated the issue.

--
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 1/2] usb: ehci: add port_power callback and override

2014-10-10 Thread Peter Chen
On Fri, Oct 10, 2014 at 10:31:24AM -0400, Alan Stern wrote:
 On Fri, 10 Oct 2014, Peter Chen wrote:
 
  @@ -1216,6 +1221,7 @@ static const struct hc_driver ehci_hc_driver = {
  .bus_resume =   ehci_bus_resume,
  .relinquish_port =  ehci_relinquish_port,
  .port_handed_over = ehci_port_handed_over,
  +   .port_power =   ehci_port_power,
   
  /*
   * device support
  @@ -1233,6 +1239,8 @@ void ehci_init_driver(struct hc_driver *drv,
  drv-hcd_priv_size += over-extra_priv_size;
  if (over-reset)
  drv-reset = over-reset;
  +   if (over-port_power)
  +   drv-port_power = over-port_power;
 
  +int ehci_port_power(struct usb_hcd *hcd, int portnum, bool enable)
  +{
  +   struct ehci_hcd *ehci = hcd_to_ehci(hcd);
 
 You might as well pass ehci as the first argument instead of hcd.
 
  +   u32 __iomem *status_reg = ehci-regs-port_status[portnum];
  +   u32 status = ehci_readl(ehci, status_reg);
  +
  +   if (enable)
  +   ehci_writel(ehci, status | PORT_POWER, status_reg);
  +   else
  +   ehci_writel(ehci, status  ~PORT_POWER, status_reg);
 
 These writes are wrong.  You have to turn off the RWC bits before 
 writing anything to the status register; otherwise you will 
 accidentally turn off some bit that should remain on.
 

Yes, I see the code at ehci-hub.c do like this.
Can I know the reason why these port changed bits written (cleared)
will cause other bits be turned off?

  +
  +   return 0;
 
 You missed the point of what I said earlier.  This routine should not
 be a callback, because it should run every time we adjust the port
 power.  Then _this_ routine should invoke the callback.
 

Would you please explain the benefit for your suggestion?

If that, ehci_port_power would be an additional API to control
port power, and we also need hc_driver callback to define the
original port power control way like ehci_port_power in my patch.
Why we can't invoke the callback every time when we want to adjust
the port power?

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


Re: RCU bug with v3.17-rc3 ?

2014-10-10 Thread Peter Chen
On Fri, Oct 10, 2014 at 08:44:33PM -0500, Nathan Lynch wrote:
 On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
  
  Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
  it seems that this has been known about for some time.)
 
 Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x  3
 are affected, as well as 4.9.0.
 
  We can blacklist these GCC versions quite easily.  We already have GCC
  3.3 blacklisted, and it's trivial to add others.  I would want to include
  some proper details about the bug, just like the other existing entries
  we already have in asm-offsets.c, where we name the functions that the
  compiler is known to break where appropriate.
 
 Before blacklisting anything, it's worth considering that simple version
 checks would break existing pre-4.8.3 compilers that have been patched
 for PR58854.  It looks like Yocto and Buildroot issued releases with
 patched 4.8.2 compilers well before the (fixed) 4.8.3 release.  I think
 the most we can reasonably do without breaking some correctly-behaving
 toolchains is to emit a warning.

Yocto has PR58854 problem patch.

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/gcc/gcc-4.8/0048-PR58854_fix_arm_apcs_epilogue.patch?h=daisy

 
 Hopefully nobody's still using gcc 4.8 from the Linaro 2013.11 toolchain
 release -- since it's a 4.8.3 prerelease from before the fix was
 committed you'll get GCC_VERSION == 40803 but still generate bad code.
 
  However, I'm rather annoyed that there are people here who have known
  for some time that GCC 4.8.1 and GCC 4.8.2 _can_ lead to filesystem
  corruption, and have sat on their backsides doing nothing about getting
  it blacklisted for something like a year.
 
 Mea culpa, although I hadn't drawn the connection to FS corruption
 reports until now.  I have known about the issue for some time, but
 figured the prevalence of the fix in downstream projects largely
 mitigated the issue.
 
 --
 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

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


[PATCH 2/2] USB: ohci-platform: Expose no_big_frame_no and num_ports in DT

2014-10-10 Thread Kevin Cernekee
These quirks are currently set through platform_data; allow DT-based SoCs
to use them too.

Signed-off-by: Kevin Cernekee cerne...@gmail.com
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 ++
 drivers/usb/host/ohci-platform.c   | 6 ++
 2 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index b968a1a..19233b7 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -9,6 +9,8 @@ Optional properties:
 - big-endian-regs : boolean, set this for hcds with big-endian registers
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+- no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
 - phy-names : usb
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 4369299..6fb03f8 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -175,6 +175,12 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev-dev.of_node, big-endian))
ohci-flags |= OHCI_QUIRK_BE_MMIO | OHCI_QUIRK_BE_DESC;
 
+   if (of_property_read_bool(dev-dev.of_node, no-big-frame-no))
+   ohci-flags |= OHCI_QUIRK_FRAME_NO;
+
+   of_property_read_u32(dev-dev.of_node, num-ports,
+ohci-num_ports);
+
priv-phy = devm_phy_get(dev-dev, usb);
if (IS_ERR(priv-phy)) {
err = PTR_ERR(priv-phy);
-- 
2.1.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 1/2] USB: OHCI: Eliminate platform-specific test in ohci.h

2014-10-10 Thread Kevin Cernekee
OHCI_QUIRK_FRAME_NO is currently set under either of the following
conditions:

1) If a ppc-of-ohci DT node indicates a compatible string of
fsl,mpc5200-ohci or mpc5200-ohci

2) If usb_ohci_pdata-no_big_frame_no is set

For #1, the affected platforms already enable CONFIG_PPC_MPC52xx.
For #2, there are currently no in-tree users.

So we can safely remove the #ifdef, and thereby allow OHCI_QUIRK_FRAME_NO
to be used by other (non-PPC) platforms that have the same property.
bcm63xx and bcm3384 are two such users.

Signed-off-by: Kevin Cernekee cerne...@gmail.com
---
 drivers/usb/host/ohci.h | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/ohci.h b/drivers/usb/host/ohci.h
index 59f4245..bc46228 100644
--- a/drivers/usb/host/ohci.h
+++ b/drivers/usb/host/ohci.h
@@ -647,23 +647,22 @@ static inline u32 hc32_to_cpup (const struct ohci_hcd 
*ohci, const __hc32 *x)
 
 /*-*/
 
-/* HCCA frame number is 16 bits, but is accessed as 32 bits since not all
- * hardware handles 16 bit reads.  That creates a different confusion on
- * some big-endian SOC implementations.  Same thing happens with PSW access.
+/*
+ * The HCCA frame number is 16 bits, but is accessed as 32 bits since not all
+ * hardware handles 16 bit reads.  Depending on the SoC implementation, the
+ * frame number can wind up in either bits [31:16] (default) or
+ * [15:0] (OHCI_QUIRK_FRAME_NO) on big endian hosts.
+ *
+ * Somewhat similarly, the 16-bit PSW fields in a transfer descriptor are
+ * reordered on BE.
  */
 
-#ifdef CONFIG_PPC_MPC52xx
-#define big_endian_frame_no_quirk(ohci)(ohci-flags  
OHCI_QUIRK_FRAME_NO)
-#else
-#define big_endian_frame_no_quirk(ohci)0
-#endif
-
 static inline u16 ohci_frame_no(const struct ohci_hcd *ohci)
 {
u32 tmp;
if (big_endian_desc(ohci)) {
tmp = be32_to_cpup((__force __be32 *)ohci-hcca-frame_no);
-   if (!big_endian_frame_no_quirk(ohci))
+   if (!(ohci-flags  OHCI_QUIRK_FRAME_NO))
tmp = 16;
} else
tmp = le32_to_cpup((__force __le32 *)ohci-hcca-frame_no);
-- 
2.1.1

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


Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL

2014-10-10 Thread Huang Rui
On Fri, Oct 10, 2014 at 09:04:15AM -0500, Felipe Balbi wrote:
 Hi,
 
 On Fri, Oct 10, 2014 at 05:25:34PM +0800, Huang Rui wrote:
I enabled dwc3 and gadget debug/verbose configuration, the whole 
testing dmesg
   
   oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
   A9 :-)
   
  
  Yes, maybe have two reasons:
  1) The input clock is much slower than SOC's.
  2) I used high speed mode.
 
 right, i'm running at highspeed too.
 
  Because of the timing issue on FPGA, bulk write transfer would get
  stuck when use more than 1MB (can pass on small file write) on super
  speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)
 
 These shouldn't fail. I'll leave testusb running tonight.
 
Do you want to see the whole testing dmesg, with which debug level
enablement?
   
   This is good for me, thank you.
  
  The test log with booting is attached. Please review.
 
 will do.
 
   ps: FYI, I left my board running overnight the same test. It has been
   pretty stable so far.
   
  
  High speed mode is stable in my FPGA board, but super speed is not
  at current.
 
 weird. Got any logs ? If you want to share logs I can probably help you
 debugging that.
 

Sure. Below is my controller as super speed mode on gadget zero test 1 (bulk
write). Test 9/10 can be passed and device is able to enumerated, so control
transfer should be OK.

Bus 007 Device 004: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB Gadget 
Zero

root@hr-bak:/home/ray/usb# ./testusb.sh 1
unknown speed   /dev/bus/usb/007/0040
/dev/bus/usb/007/004 test 1 -- 110 (Connection timed out)

Host:
[ 8793.096303] usb 7-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 8793.119876] usb 7-1: New USB device found, idVendor=0525, idProduct=a4a0
[ 8793.120109] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8793.120352] usb 7-1: Product: Gadget Zero
[ 8793.120493] usb 7-1: Manufacturer: Linux 3.17.0-rc5-dwc3-upstream+ with 
dwc3-gadget
[ 8793.120751] usb 7-1: SerialNumber: 0123456789.0123456789.0123456789
[ 8793.489749] usbtest 7-1:3.0: Linux gadget zero
[ 8793.489933] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} 
tests (+alt)
[ 8793.490246] usbcore: registered new interface driver usbtest
[ 8815.325781] usbcore: deregistering interface driver usbtest
[ 8819.760443] usbtest 7-1:3.0: Linux gadget zero
[ 8819.760621] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} 
tests (+alt)
[ 8819.760921] usbcore: registered new interface driver usbtest
[ 8891.317350] usbtest 7-1:3.0: TEST 1:  write 512 bytes 20 times
[ 8901.316770] usb 7-1: test1 failed, iterations left 19, status -110 (not 0)

Device:
[ 7872.401865] udc dwc3.0.auto: registering UDC driver [zero]
[ 7872.420057] zero gadget: adding 'source/sink'/88002e593e00 to config 
'source/sink'/a01ad000
[ 7872.420072] zero gadget: super speed source/sink: IN/ep1in, OUT/ep1out, 
ISO-IN/ep2in, ISO-OUT/ep2out, INT-IN/ep3in, INT-OUT/ep3out
[ 7872.420076] zero gadget: adding 'loopback'/88002e593000 to config 
'loopback'/a01ad0e0
[ 7872.420081] zero gadget: super speed loopback: IN/ep1in, OUT/ep1out
[ 7872.420086] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[ 7872.420089] zero gadget: zero ready
[ 7872.661926] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
8/8 === 0
[ 7872.662505] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
18/18 === 0
[ 7872.663039] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
5/5 === 0
[ 7872.663655] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
22/22 === 0
[ 7872.664261] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
9/9 === 0
[ 7872.664890] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
140/140 === 0
[ 7872.665924] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
9/9 === 0
[ 7872.666493] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
44/44 === 0
[ 7872.667596] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
4/4 === 0
[ 7872.668135] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
24/24 === 0
[ 7872.668933] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
98/98 === 0
[ 7872.669501] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
66/66 === 0
[ 7872.671680] zero gadget: super-speed config #3: source/sink
[ 7872.671766] zero gadget: source/sink enabled, alt intf 0
[ 7872.671898] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
0/0 === 0
[ 7872.672400] dwc3 dwc3.0.auto: request 880186d91180 from ep0out completed 
42/42 === 0
[ 7970.768261] dwc3 dwc3.0.auto: request 88018778eb40 from ep1in completed 
0/512 === -108
[ 7970.768277] dwc3 dwc3.0.auto: request 88018778e600 from ep1out completed 
0/512 === -108
[ 7970.768349] zero gadget: source/sink enabled, alt intf 0
[ 7970.768517] dwc3 dwc3.0.auto: request 880186d91180 from 

Re: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL

2014-10-10 Thread Huang Rui
On Sat, Oct 11, 2014 at 01:14:44PM +0800, Huang Rui wrote:
 On Fri, Oct 10, 2014 at 09:04:15AM -0500, Felipe Balbi wrote:
  Hi,
  
  On Fri, Oct 10, 2014 at 05:25:34PM +0800, Huang Rui wrote:
 I enabled dwc3 and gadget debug/verbose configuration, the whole 
 testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

   
   Yes, maybe have two reasons:
   1) The input clock is much slower than SOC's.
   2) I used high speed mode.
  
  right, i'm running at highspeed too.
  
   Because of the timing issue on FPGA, bulk write transfer would get
   stuck when use more than 1MB (can pass on small file write) on super
   speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)
  
  These shouldn't fail. I'll leave testusb running tonight.
  
 Do you want to see the whole testing dmesg, with which debug level
 enablement?

This is good for me, thank you.
   
   The test log with booting is attached. Please review.
  
  will do.
  
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

   
   High speed mode is stable in my FPGA board, but super speed is not
   at current.
  
  weird. Got any logs ? If you want to share logs I can probably help you
  debugging that.
  
 
 Sure. Below is my controller as super speed mode on gadget zero test 1 (bulk
 write). Test 9/10 can be passed and device is able to enumerated, so control
 transfer should be OK.
 
 Bus 007 Device 004: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB Gadget 
 Zero
 
 root@hr-bak:/home/ray/usb# ./testusb.sh 1
 unknown speed   /dev/bus/usb/007/0040
 /dev/bus/usb/007/004 test 1 -- 110 (Connection timed out)
 
 Host:
 [ 8793.096303] usb 7-1: new SuperSpeed USB device number 4 using xhci_hcd
 [ 8793.119876] usb 7-1: New USB device found, idVendor=0525, idProduct=a4a0
 [ 8793.120109] usb 7-1: New USB device strings: Mfr=1, Product=2, 
 SerialNumber=3
 [ 8793.120352] usb 7-1: Product: Gadget Zero
 [ 8793.120493] usb 7-1: Manufacturer: Linux 3.17.0-rc5-dwc3-upstream+ with 
 dwc3-gadget
 [ 8793.120751] usb 7-1: SerialNumber: 0123456789.0123456789.0123456789
 [ 8793.489749] usbtest 7-1:3.0: Linux gadget zero
 [ 8793.489933] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} 
 tests (+alt)
 [ 8793.490246] usbcore: registered new interface driver usbtest
 [ 8815.325781] usbcore: deregistering interface driver usbtest
 [ 8819.760443] usbtest 7-1:3.0: Linux gadget zero
 [ 8819.760621] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} 
 tests (+alt)
 [ 8819.760921] usbcore: registered new interface driver usbtest
 [ 8891.317350] usbtest 7-1:3.0: TEST 1:  write 512 bytes 20 times
 [ 8901.316770] usb 7-1: test1 failed, iterations left 19, status -110 (not 0)
 
 Device:
 [ 7872.401865] udc dwc3.0.auto: registering UDC driver [zero]
 [ 7872.420057] zero gadget: adding 'source/sink'/88002e593e00 to config 
 'source/sink'/a01ad000
 [ 7872.420072] zero gadget: super speed source/sink: IN/ep1in, OUT/ep1out, 
 ISO-IN/ep2in, ISO-OUT/ep2out, INT-IN/ep3in, INT-OUT/ep3out
 [ 7872.420076] zero gadget: adding 'loopback'/88002e593000 to config 
 'loopback'/a01ad0e0
 [ 7872.420081] zero gadget: super speed loopback: IN/ep1in, OUT/ep1out
 [ 7872.420086] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
 [ 7872.420089] zero gadget: zero ready
 [ 7872.661926] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 8/8 === 0
 [ 7872.662505] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 18/18 === 0
 [ 7872.663039] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 5/5 === 0
 [ 7872.663655] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 22/22 === 0
 [ 7872.664261] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 9/9 === 0
 [ 7872.664890] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 140/140 === 0
 [ 7872.665924] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 9/9 === 0
 [ 7872.666493] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 44/44 === 0
 [ 7872.667596] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 4/4 === 0
 [ 7872.668135] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 24/24 === 0
 [ 7872.668933] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 98/98 === 0
 [ 7872.669501] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 66/66 === 0
 [ 7872.671680] zero gadget: super-speed config #3: source/sink
 [ 7872.671766] zero gadget: source/sink enabled, alt intf 0
 [ 7872.671898] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 0/0 === 0
 [ 7872.672400] dwc3 dwc3.0.auto: request 880186d91180 from ep0out 
 completed 42/42 === 0
 [ 7970.768261] dwc3 dwc3.0.auto: request 88018778eb40 from ep1in 
 completed 0/512 === -108
 [ 7970.768277] dwc3 dwc3.0.auto: request