[RFC][PATCH] fs: configfs: programmatically create config groups

[Andrzej Pietrasiewicz]

In some parts of the kernel (e.g. planned configfs integration into usb
gadget) there is a need to programmatically create config groups
(directories) but it would be preferable to disallow creating them by
the user. This is more or less what default_groups used to be for.
But e.g. in the mass storage gadget, after storing the number of
luns (logical units) into some configfs attribute, the corresponding lun#
directories should be created, their number is not known up front so
default_groups are no good for this.

Example:

$ echo 3 > /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2

to be created. Yet

$ mkdir /cfg//mass_storage/

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?

Andrzej Pietrasiewicz (1):
  fs: configfs: allow other kernel parts to programmatically create
config groups

 fs/configfs/dir.c|5 +++--
 include/linux/configfs.h |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

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

[RFC][PATCH] fs: configfs: allow other kernel parts to programmatically create config groups

[Andrzej Pietrasiewicz]

Signed-off-by: Andrzej Pietrasiewicz 
Signed-off-by: Kyungmin Park 
---
 fs/configfs/dir.c|5 +++--
 include/linux/configfs.h |2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index 7414ae2..42608dc 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -656,7 +656,7 @@ static void detach_groups(struct config_group *group)
  * We could, perhaps, tweak our parent's ->mkdir for a minute and
  * try using vfs_mkdir.  Just a thought.
  */
-static int create_default_group(struct config_group *parent_group,
+int create_group(struct config_group *parent_group,
struct config_group *group)
 {
int ret;
@@ -690,6 +690,7 @@ static int create_default_group(struct config_group 
*parent_group,
 
return ret;
 }
+EXPORT_SYMBOL(create_group);
 
 static int populate_groups(struct config_group *group)
 {
@@ -701,7 +702,7 @@ static int populate_groups(struct config_group *group)
for (i = 0; group->default_groups[i]; i++) {
new_group = group->default_groups[i];
 
-   ret = create_default_group(group, new_group);
+   ret = create_group(group, new_group);
if (ret) {
detach_groups(group);
break;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 34025df..8bf295f 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -252,6 +252,8 @@ static inline struct configfs_subsystem 
*to_configfs_subsystem(struct config_gro
 int configfs_register_subsystem(struct configfs_subsystem *subsys);
 void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
 
+int create_group(struct config_group *parent_group, struct config_group 
*group);
+
 /* These functions can sleep and can alloc with GFP_KERNEL */
 /* WARNING: These cannot be called underneath configfs callbacks!! */
 int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item 
*target);
-- 
1.7.0.4

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

Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Felipe Balbi]

Hi,

On Fri, Nov 23, 2012 at 11:27:34AM -0500, Alan Stern wrote:
> On Fri, 23 Nov 2012, Felipe Balbi wrote:
> 
> > > And maybe the same sort of scheme could be used for clocks, although I 
> > > don't know how to do it in a generic way that will work on all 
> > > platforms.
> > 
> > perhaps making use of pm_clk_add() and letting PM layer do the rest for
> > us ? If that doesn't work then it means PM layer's clk handling could be
> > improved, I suppose.
> 
> Is the clock framework sufficiently generic at this point that it can
> be used by core code (like the PM layer)?

It already is :-) See drivers/base/power/clock_ops.c

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v3 1/7] Revert "USB: chipidea: add vbus detect for udc"

[Peter Chen]

vbus register is at otgsc, and vbus detect does not belong
to device function. Revert this patch, and will move
vbus detect function to drivers/usb/chipidea/udc.c

This reverts commit 8c4fc031954b4eb72daf13d3c907a985a3eee208.

Signed-off-by: Peter Chen 
---
Changes for v3:
Add Signed-off-by: Peter Chen 

 drivers/usb/chipidea/ci.h  |1 -
 drivers/usb/chipidea/udc.c |   39 +--
 2 files changed, 1 insertions(+), 39 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index e25d126..d738603 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -139,7 +139,6 @@ struct ci13xxx {
enum ci_rolerole;
boolis_otg;
struct work_struct  work;
-   struct work_struct  vbus_work;
struct workqueue_struct *wq;
 
struct dma_pool *qh_pool;
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 2f45bba..d214448 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -305,18 +305,6 @@ static u32 hw_test_and_clear_intr_active(struct ci13xxx 
*ci)
return reg;
 }
 
-static void hw_enable_vbus_intr(struct ci13xxx *ci)
-{
-   hw_write(ci, OP_OTGSC, OTGSC_AVVIS, OTGSC_AVVIS);
-   hw_write(ci, OP_OTGSC, OTGSC_AVVIE, OTGSC_AVVIE);
-   queue_work(ci->wq, &ci->vbus_work);
-}
-
-static void hw_disable_vbus_intr(struct ci13xxx *ci)
-{
-   hw_write(ci, OP_OTGSC, OTGSC_AVVIE, 0);
-}
-
 /**
  * hw_test_and_clear_setup_guard: test & clear setup guard (execute without
  *interruption)
@@ -383,16 +371,6 @@ static int hw_usb_reset(struct ci13xxx *ci)
return 0;
 }
 
-static void vbus_work(struct work_struct *work)
-{
-   struct ci13xxx *ci = container_of(work, struct ci13xxx, vbus_work);
-
-   if (hw_read(ci, OP_OTGSC, OTGSC_AVV))
-   usb_gadget_vbus_connect(&ci->gadget);
-   else
-   usb_gadget_vbus_disconnect(&ci->gadget);
-}
-
 /**
  * UTIL block
  */
@@ -1392,7 +1370,6 @@ static int ci13xxx_vbus_session(struct usb_gadget 
*_gadget, int is_active)
if (is_active) {
pm_runtime_get_sync(&_gadget->dev);
hw_device_reset(ci, USBMODE_CM_DC);
-   hw_enable_vbus_intr(ci);
hw_device_state(ci, ci->ep0out->qh.dma);
} else {
hw_device_state(ci, 0);
@@ -1567,10 +1544,8 @@ static int ci13xxx_start(struct usb_gadget *gadget,
pm_runtime_get_sync(&ci->gadget.dev);
if (ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) {
if (ci->vbus_active) {
-   if (ci->platdata->flags & CI13XXX_REGS_SHARED) {
+   if (ci->platdata->flags & CI13XXX_REGS_SHARED)
hw_device_reset(ci, USBMODE_CM_DC);
-   hw_enable_vbus_intr(ci);
-   }
} else {
pm_runtime_put_sync(&ci->gadget.dev);
goto done;
@@ -1676,13 +1651,6 @@ static irqreturn_t udc_irq(struct ci13xxx *ci)
} else {
retval = IRQ_NONE;
}
-
-   intr = hw_read(ci, OP_OTGSC, ~0);
-   hw_write(ci, OP_OTGSC, ~0, intr);
-
-   if (intr & (OTGSC_AVVIE & OTGSC_AVVIS))
-   queue_work(ci->wq, &ci->vbus_work);
-
spin_unlock(&ci->lock);
 
return retval;
@@ -1758,7 +1726,6 @@ static int udc_start(struct ci13xxx *ci)
retval = hw_device_reset(ci, USBMODE_CM_DC);
if (retval)
goto put_transceiver;
-   hw_enable_vbus_intr(ci);
}
 
retval = device_register(&ci->gadget.dev);
@@ -1821,9 +1788,6 @@ static void udc_stop(struct ci13xxx *ci)
if (ci == NULL)
return;
 
-   hw_disable_vbus_intr(ci);
-   cancel_work_sync(&ci->vbus_work);
-
usb_del_gadget_udc(&ci->gadget);
 
destroy_eps(ci);
@@ -1864,7 +1828,6 @@ int ci_hdrc_gadget_init(struct ci13xxx *ci)
rdrv->irq   = udc_irq;
rdrv->name  = "gadget";
ci->roles[CI_ROLE_GADGET] = rdrv;
-   INIT_WORK(&ci->vbus_work, vbus_work);
 
return 0;
 }
-- 
1.7.0.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 v3 2/7] usb: chipidea: add otg file

[Peter Chen]

Implement struct usb_otg, In that way, calling otg_set_peripheral
will not be failed at udc.c.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/Makefile |2 +-
 drivers/usb/chipidea/ci.h |2 +
 drivers/usb/chipidea/otg.c|   60 +
 drivers/usb/chipidea/otg.h|6 
 4 files changed, 69 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index d92ca32..11f513c 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -2,7 +2,7 @@ ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
 
-ci_hdrc-y  := core.o
+ci_hdrc-y  := core.o otg.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)   += debug.o
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index d738603..8702871 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -129,6 +129,7 @@ struct hw_bank {
  * @vbus_active: is VBUS active
  * @transceiver: pointer to USB PHY, if any
  * @hcd: pointer to usb_hcd for ehci host driver
+ * @otg: for otg support
  */
 struct ci13xxx {
struct device   *dev;
@@ -164,6 +165,7 @@ struct ci13xxx {
boolglobal_phy;
struct usb_phy  *transceiver;
struct usb_hcd  *hcd;
+   struct usb_otg  otg;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci13xxx *ci)
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
new file mode 100644
index 000..7dea3b3
--- /dev/null
+++ b/drivers/usb/chipidea/otg.c
@@ -0,0 +1,60 @@
+/*
+ * otg.c - ChipIdea USB IP core OTG driver
+ *
+ * Copyright (C) 2012 Freescale Semiconductor, Inc.
+ *
+ * Author: Peter Chen
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ci.h"
+#include "udc.h"
+#include "bits.h"
+#include "host.h"
+#include "debug.h"
+
+static int ci_otg_set_peripheral(struct usb_otg *otg,
+   struct usb_gadget *periph)
+{
+   otg->gadget = periph;
+
+   return 0;
+}
+
+static int ci_otg_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
+   otg->host = host;
+
+   return 0;
+}
+
+/**
+ * ci_hdrc_otg_init - initialize device related bits
+ * ci: the controller
+ *
+ * This function create otg struct, if the device can switch between
+ * device and host.
+ */
+int ci_hdrc_otg_init(struct ci13xxx *ci)
+{
+   /* Useless at current */
+   ci->otg.set_peripheral = ci_otg_set_peripheral;
+   ci->otg.set_host = ci_otg_set_host;
+   if (!IS_ERR_OR_NULL(ci->transceiver))
+   ci->transceiver->otg = &ci->otg;
+
+   return 0;
+}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
new file mode 100644
index 000..b4c6b3e
--- /dev/null
+++ b/drivers/usb/chipidea/otg.h
@@ -0,0 +1,6 @@
+#ifndef __DRIVERS_USB_CHIPIDEA_OTG_H
+#define __DRIVERS_USB_CHIPIDEA_OTG_H
+
+int ci_hdrc_otg_init(struct ci13xxx *ci);
+
+#endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
-- 
1.7.0.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 v3 0/7] Add fully tested id switch and vbus connect detect support for Chipidea

[Peter Chen]

Changes for v3 mainly for 1/7, 3/7, 4/7, 7/7, see individual
patch commit for detail.

This patchset adds fully tested otg id switch function and
vbus connect/disconnect detection for chipidea driver.
The mainly design of id/vbus handling follows msm otg driver.
I hope the msm usb maintainer can have a look of this patchset,
and give some comments, and move the whole msm usb driver to
chipidea framework if possible in the future.

This patchset is fully tested at i.mx6Q saberlite board.

There is github repo for my chipdiea work:
https://github.com/hzpeterchen/linux-usb.git
branch: master

Peter Chen (7):
  Revert "USB: chipidea: add vbus detect for udc"
  usb: chipidea: add otg file
  usb: chipidea: add otg id switch and vbus connect/disconnect detect
  usb: chipidea: consolidate ci_role_driver's API for both roles
  usb: chipidea: udc: add pullup/pulldown dp at hw_device_state
  usb: chipidea: udc: retire the flag CI13_PULLUP_ON_VBUS
  usb: chipidea: imx: add internal vbus regulator control

 drivers/usb/chipidea/Makefile  |2 +-
 drivers/usb/chipidea/bits.h|   10 ++
 drivers/usb/chipidea/ci.h  |   29 +-
 drivers/usb/chipidea/ci13xxx_imx.c |   81 
 drivers/usb/chipidea/ci13xxx_msm.c |1 -
 drivers/usb/chipidea/core.c|  189 +++
 drivers/usb/chipidea/host.c|2 +
 drivers/usb/chipidea/otg.c |   61 
 drivers/usb/chipidea/otg.h |6 +
 drivers/usb/chipidea/udc.c |   90 +++--
 include/linux/usb/chipidea.h   |1 -
 11 files changed, 371 insertions(+), 101 deletions(-)
 create mode 100644 drivers/usb/chipidea/otg.c
 create mode 100644 drivers/usb/chipidea/otg.h


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

[PATCH v3 5/7] usb: chipidea: udc: add pullup/pulldown dp at hw_device_state

[Peter Chen]

- During the connect/disconnect host, we need to pullup
and pulldown dp
- Make sure the dp is not pullup until the vbus is on when
flag CI13XXX_PULLUP_ON_VBUS is set
- Using hw_device_state when set run/stop bit

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/udc.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index ae4755c..f27507f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -90,8 +90,10 @@ static int hw_device_state(struct ci13xxx *ci, u32 dma)
/* interrupt, error, port change, reset, sleep/suspend */
hw_write(ci, OP_USBINTR, ~0,
 USBi_UI|USBi_UEI|USBi_PCI|USBi_URI|USBi_SLI);
+   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
} else {
hw_write(ci, OP_USBINTR, ~0, 0);
+   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
}
return 0;
 }
@@ -1423,10 +1425,14 @@ static int ci13xxx_pullup(struct usb_gadget *_gadget, 
int is_on)
 {
struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
 
+   if ((ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) &&
+   !ci->vbus_active)
+   return -ENOTSUPP;
+
if (is_on)
-   hw_write(ci, OP_USBCMD, USBCMD_RS, USBCMD_RS);
+   hw_device_state(ci, ci->ep0out->qh.dma);
else
-   hw_write(ci, OP_USBCMD, USBCMD_RS, 0);
+   hw_device_state(ci, 0);
 
return 0;
 }
-- 
1.7.0.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 v3 4/7] usb: chipidea: consolidate ci_role_driver's API for both roles

[Peter Chen]

- Create init/destroy API for probe and remove
- start/stop API are only used otg id switch process
- Create the gadget at ci_hdrc_probe if the gadget is supported
at that port, the main purpose for this is to avoid gadget module
load fail at init.rc

Signed-off-by: Peter Chen 
---
Changes for v3:
- Create init/destroy API for probe and remove
- start/stop API are only used otg id switch process

 drivers/usb/chipidea/ci.h   |   19 ++-
 drivers/usb/chipidea/core.c |   75 +--
 drivers/usb/chipidea/host.c |2 +
 drivers/usb/chipidea/udc.c  |   22 +++-
 4 files changed, 76 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 12665fa..bc9e4e1 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -67,14 +67,18 @@ enum ci_role {
 
 /**
  * struct ci_role_driver - host/gadget role driver
- * start: start this role
- * stop: stop this role
+ * init: init this role (used at module probe)
+ * start: start this role (used at id switch)
+ * stop: stop this role (used at id switch)
+ * destroy: destroy this role (used at module remove)
  * irq: irq handler for this role
  * name: role name string (host/gadget)
  */
 struct ci_role_driver {
+   int (*init)(struct ci13xxx *);
int (*start)(struct ci13xxx *);
void(*stop)(struct ci13xxx *);
+   void(*destroy)(struct ci13xxx *);
irqreturn_t (*irq)(struct ci13xxx *);
const char  *name;
 };
@@ -207,6 +211,17 @@ static inline void ci_role_stop(struct ci13xxx *ci)
ci->roles[role]->stop(ci);
 }
 
+static inline void ci_role_destroy(struct ci13xxx *ci)
+{
+   enum ci_role role = ci->role;
+
+   if (role == CI_ROLE_END)
+   return;
+
+   ci->role = CI_ROLE_END;
+
+   ci->roles[role]->destroy(ci);
+}
 /**
  * REGISTERS
  */
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index e0392fa..f0d3691 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -307,27 +307,16 @@ static void ci_handle_id_switch(struct ci13xxx *ci)
ci_role(ci)->name, ci->roles[role]->name);
 
/* 1. Finish the current role */
-   if (ci->role == CI_ROLE_GADGET) {
-   usb_gadget_vbus_disconnect(&ci->gadget);
-   /* host doesn't care B_SESSION_VALID event */
-   hw_write(ci, OP_OTGSC, OTGSC_BSVIE, ~OTGSC_BSVIE);
-   hw_write(ci, OP_OTGSC, OTGSC_BSVIS, OTGSC_BSVIS);
-   ci->role = CI_ROLE_END;
-   /* reset controller */
-   hw_device_reset(ci, USBMODE_CM_IDLE);
-   } else if (ci->role == CI_ROLE_HOST) {
-   ci_role_stop(ci);
-   /* reset controller */
-   hw_device_reset(ci, USBMODE_CM_IDLE);
-   }
+   ci_role_stop(ci);
+   hw_device_reset(ci, USBMODE_CM_IDLE);
 
/* 2. Turn on/off vbus according to coming role */
-   if (ci_otg_role(ci) == CI_ROLE_GADGET) {
+   if (role == CI_ROLE_GADGET) {
otg_set_vbus(&ci->otg, false);
/* wait vbus lower than OTGSC_BSV */
hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
CI_VBUS_STABLE_TIMEOUT);
-   } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
+   } else if (role == CI_ROLE_HOST) {
otg_set_vbus(&ci->otg, true);
/* wait vbus higher than OTGSC_AVV */
hw_wait_reg(ci, OP_OTGSC, OTGSC_AVV, OTGSC_AVV,
@@ -335,13 +324,7 @@ static void ci_handle_id_switch(struct ci13xxx *ci)
}
 
/* 3. Begin the new role */
-   if (ci_otg_role(ci) == CI_ROLE_GADGET) {
-   ci->role = role;
-   hw_write(ci, OP_OTGSC, OTGSC_BSVIS, OTGSC_BSVIS);
-   hw_write(ci, OP_OTGSC, OTGSC_BSVIE, OTGSC_BSVIE);
-   } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
-   ci_role_start(ci, role);
-   }
+   ci_role_start(ci, role);
}
 }
 
@@ -584,7 +567,7 @@ static int __devinit ci_hdrc_probe(struct platform_device 
*pdev)
 
ret = ci_hdrc_gadget_init(ci);
if (ret)
-   dev_info(dev, "doesn't support gadget\n");
+   dev_info(dev, "doesn't support gadget, ret=%d\n", ret);
 
if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
dev_err(dev, "no supported roles\n");
@@ -608,23 +591,39 @@ static int __devinit ci_hdrc_probe(

[PATCH v3 6/7] usb: chipidea: udc: retire the flag CI13_PULLUP_ON_VBUS

[Peter Chen]

(change CI13XXX to CI13 to avoid junk email check)
Now, we have handled vbus session in core driver when the
vbus interrupt occurs, so our pullup operations are all
according to vbus.
Of cource, the software can still call .pullup when device connects
to host if it wants to connect/disconnect with host.

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/ci13xxx_imx.c |1 -
 drivers/usb/chipidea/ci13xxx_msm.c |1 -
 drivers/usb/chipidea/udc.c |   23 ---
 include/linux/usb/chipidea.h   |1 -
 4 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
b/drivers/usb/chipidea/ci13xxx_imx.c
index 0f5ca4b..86671a3 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -88,7 +88,6 @@ EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
 static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata  = {
.name   = "ci13xxx_imx",
.flags  = CI13XXX_REQUIRE_TRANSCEIVER |
- CI13XXX_PULLUP_ON_VBUS |
  CI13XXX_DISABLE_STREAMING,
.capoffset  = DEF_CAPOFFSET,
 };
diff --git a/drivers/usb/chipidea/ci13xxx_msm.c 
b/drivers/usb/chipidea/ci13xxx_msm.c
index b01feb3..cf74b62 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -49,7 +49,6 @@ static struct ci13xxx_platform_data ci13xxx_msm_platdata = {
.name   = "ci13xxx_msm",
.flags  = CI13XXX_REGS_SHARED |
  CI13XXX_REQUIRE_TRANSCEIVER |
- CI13XXX_PULLUP_ON_VBUS |
  CI13XXX_DISABLE_STREAMING,
 
.notify_event   = ci13xxx_msm_notify_event,
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index f27507f..f4796c1 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1359,9 +1359,6 @@ static int ci13xxx_vbus_session(struct usb_gadget 
*_gadget, int is_active)
unsigned long flags;
int gadget_ready = 0;
 
-   if (!(ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS))
-   return -EOPNOTSUPP;
-
spin_lock_irqsave(&ci->lock, flags);
ci->vbus_active = is_active;
if (ci->driver)
@@ -1425,8 +1422,7 @@ static int ci13xxx_pullup(struct usb_gadget *_gadget, int 
is_on)
 {
struct ci13xxx *ci = container_of(_gadget, struct ci13xxx, gadget);
 
-   if ((ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) &&
-   !ci->vbus_active)
+   if (!ci->vbus_active)
return -ENOTSUPP;
 
if (is_on)
@@ -1550,14 +1546,12 @@ static int ci13xxx_start(struct usb_gadget *gadget,
 
ci->driver = driver;
pm_runtime_get_sync(&ci->gadget.dev);
-   if (ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) {
-   if (ci->vbus_active) {
-   if (ci->platdata->flags & CI13XXX_REGS_SHARED)
-   hw_device_reset(ci, USBMODE_CM_DC);
-   } else {
-   pm_runtime_put_sync(&ci->gadget.dev);
-   goto done;
-   }
+   if (ci->vbus_active) {
+   if (ci->platdata->flags & CI13XXX_REGS_SHARED)
+   hw_device_reset(ci, USBMODE_CM_DC);
+   } else {
+   pm_runtime_put_sync(&ci->gadget.dev);
+   goto done;
}
 
retval = hw_device_state(ci, ci->ep0out->qh.dma);
@@ -1580,8 +1574,7 @@ static int ci13xxx_stop(struct usb_gadget *gadget,
 
spin_lock_irqsave(&ci->lock, flags);
 
-   if (!(ci->platdata->flags & CI13XXX_PULLUP_ON_VBUS) ||
-   ci->vbus_active) {
+   if (ci->vbus_active) {
hw_device_state(ci, 0);
if (ci->platdata->notify_event)
ci->platdata->notify_event(ci,
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 544825d..37821b3 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -17,7 +17,6 @@ struct ci13xxx_platform_data {
unsigned longflags;
 #define CI13XXX_REGS_SHAREDBIT(0)
 #define CI13XXX_REQUIRE_TRANSCEIVERBIT(1)
-#define CI13XXX_PULLUP_ON_VBUS BIT(2)
 #define CI13XXX_DISABLE_STREAMING  BIT(3)
 
 #define CI13XXX_CONTROLLER_RESET_EVENT 0
-- 
1.7.0.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 v3 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect

[Peter Chen]

The main design flow is the same with msm otg driver, that is the id and
vbus interrupt are handled at core driver, others are handled by
individual drivers.

- At former design, when switch usb role from device->host, it will call
udc_stop, it will remove the gadget driver, so when switch role
from host->device, it can't add gadget driver any more.
At new design, when role switch occurs, the gadget just calls
usb_gadget_vbus_disconnect/usb_gadget_vbus_connect as well as
reset controller, it will not free any device/gadget structure

- Add vbus connect and disconnect to core interrupt handler, it can
notify udc driver by calling usb_gadget_vbus_disconnect
/usb_gadget_vbus_connect.

Signed-off-by: Peter Chen 
---
Changes for v3:
- Add prefix CI_ for ID and B_SESS_VALID
- Use new API hw_wait_reg which is alexander sugguested to wait vbus
voltage stable

 drivers/usb/chipidea/bits.h |   10 +++
 drivers/usb/chipidea/ci.h   |5 +
 drivers/usb/chipidea/core.c |  182 ++
 drivers/usb/chipidea/otg.c  |1 +
 drivers/usb/chipidea/udc.c  |2 +
 5 files changed, 182 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 050de85..ba9c6ef 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -65,11 +65,21 @@
 #define OTGSC_ASVIS  BIT(18)
 #define OTGSC_BSVIS  BIT(19)
 #define OTGSC_BSEIS  BIT(20)
+#define OTGSC_1MSIS  BIT(21)
+#define OTGSC_DPIS   BIT(22)
 #define OTGSC_IDIE   BIT(24)
 #define OTGSC_AVVIE  BIT(25)
 #define OTGSC_ASVIE  BIT(26)
 #define OTGSC_BSVIE  BIT(27)
 #define OTGSC_BSEIE  BIT(28)
+#define OTGSC_1MSIE  BIT(29)
+#define OTGSC_DPIE   BIT(30)
+#define OTGSC_INT_EN_BITS  (OTGSC_IDIE | OTGSC_AVVIE | OTGSC_ASVIE \
+   | OTGSC_BSVIE | OTGSC_BSEIE | OTGSC_1MSIE \
+   | OTGSC_DPIE)
+#define OTGSC_INT_STATUS_BITS  (OTGSC_IDIS | OTGSC_AVVIS | OTGSC_ASVIS \
+   | OTGSC_BSVIS | OTGSC_BSEIS | OTGSC_1MSIS \
+   | OTGSC_DPIS)
 
 /* USBMODE */
 #define USBMODE_CM(0x03UL <<  0)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 8702871..12665fa 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -130,6 +130,7 @@ struct hw_bank {
  * @transceiver: pointer to USB PHY, if any
  * @hcd: pointer to usb_hcd for ehci host driver
  * @otg: for otg support
+ * @events: events for otg, and handled at ci_role_work
  */
 struct ci13xxx {
struct device   *dev;
@@ -140,6 +141,7 @@ struct ci13xxx {
enum ci_rolerole;
boolis_otg;
struct work_struct  work;
+   struct delayed_work dwork;
struct workqueue_struct *wq;
 
struct dma_pool *qh_pool;
@@ -166,6 +168,9 @@ struct ci13xxx {
struct usb_phy  *transceiver;
struct usb_hcd  *hcd;
struct usb_otg  otg;
+#define CI_ID  0
+#define CI_B_SESS_VALID1
+   unsigned long events;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci13xxx *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index f69d029..e0392fa 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -73,6 +73,7 @@
 #include "bits.h"
 #include "host.h"
 #include "debug.h"
+#include "otg.h"
 
 /* Controller register map */
 static uintptr_t ci_regs_nolpm[] = {
@@ -265,24 +266,124 @@ static enum ci_role ci_otg_role(struct ci13xxx *ci)
 }
 
 /**
- * ci_role_work - perform role changing based on ID pin
- * @work: work struct
+ * hw_wait_reg: wait the register value
+ *
+ * Sometimes, it needs to wait register value before going on.
+ * Eg, when switch to device mode, the vbus value should be lower
+ * than OTGSC_BSV before connects to host.
+ *
+ * @ci: the controller
+ * @reg: register index
+ * @mask: mast bit
+ * @value: the bit value to wait
+ * @timeout: timeout to indicate an error
+ *
+ * This function returns an error code if timeout
  */
-static void ci_role_work(struct work_struct *work)
+static int hw_wait_reg(struct ci13xxx *ci, enum ci13xxx_regs reg, u32 mask,
+   u32 value, unsigned long timeout)
+{
+   unsigned long elapse = jiffies + timeout;
+
+   while (hw_read(ci, reg, mask) != value) {
+   if (time_after(jiffies, elapse)) {
+   dev_err(ci->dev, "timeout waiting for %08x in %d\n",
+   mask, reg);
+   return -ETIMEDOUT;
+   }
+   msleep(20);
+   }
+
+   return 0;
+}
+
+#define CI_VBUS_STABLE_TIMEOUT 500
+static void ci_handle_id_switch(struct ci13xxx *ci)
 {
-   struct ci13xxx *c

[PATCH v3 7/7] usb: chipidea: imx: add internal vbus regulator control

[Peter Chen]

- For host, the vbus should always be on.
- For otg, the vbus is off defaultly, the vbus needs to be
turned on/off when usb role switches.

Signed-off-by: Peter Chen 
---
Changes for v3:
- Add return value check for regulator_enable/regulator_disable
- typo error

 drivers/usb/chipidea/ci.h  |6 ++-
 drivers/usb/chipidea/ci13xxx_imx.c |   80 
 2 files changed, 66 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index bc9e4e1..9528f6a 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -135,6 +135,7 @@ struct hw_bank {
  * @hcd: pointer to usb_hcd for ehci host driver
  * @otg: for otg support
  * @events: events for otg, and handled at ci_role_work
+ * @reg_vbus: used to control internal vbus regulator
  */
 struct ci13xxx {
struct device   *dev;
@@ -171,10 +172,11 @@ struct ci13xxx {
boolglobal_phy;
struct usb_phy  *transceiver;
struct usb_hcd  *hcd;
-   struct usb_otg  otg;
+   struct usb_otg  otg;
 #define CI_ID  0
 #define CI_B_SESS_VALID1
-   unsigned long events;
+   unsigned long   events;
+   struct regulator*reg_vbus;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci13xxx *ci)
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
b/drivers/usb/chipidea/ci13xxx_imx.c
index 86671a3..b50cfd7 100644
--- a/drivers/usb/chipidea/ci13xxx_imx.c
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -88,14 +88,47 @@ EXPORT_SYMBOL_GPL(usbmisc_get_init_data);
 static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata  = {
.name   = "ci13xxx_imx",
.flags  = CI13XXX_REQUIRE_TRANSCEIVER |
- CI13XXX_DISABLE_STREAMING,
+ CI13XXX_DISABLE_STREAMING |
+ CI13XXX_REGS_SHARED,
.capoffset  = DEF_CAPOFFSET,
 };
 
+static int ci13xxx_otg_set_vbus(struct usb_otg *otg, bool enabled)
+{
+   struct ci13xxx  *ci = container_of(otg, struct ci13xxx, otg);
+   struct regulator *reg_vbus = ci->reg_vbus;
+   int ret;
+
+   WARN_ON(!reg_vbus);
+
+   if (reg_vbus) {
+   if (enabled) {
+   ret = regulator_enable(reg_vbus);
+   if (ret) {
+   dev_err(ci->dev,
+   "Failed to enable vbus regulator, ret=%d\n",
+   ret);
+   return ret;
+   }
+   } else {
+   ret = regulator_disable(reg_vbus);
+   if (ret) {
+   dev_err(ci->dev,
+   "Failed to disable vbus regulator, ret=%d\n",
+   ret);
+   return ret;
+   }
+   }
+   }
+
+   return 0;
+}
+
 static int __devinit ci13xxx_imx_probe(struct platform_device *pdev)
 {
struct ci13xxx_imx_data *data;
struct platform_device *plat_ci, *phy_pdev;
+   struct ci13xxx  *ci;
struct device_node *phy_np;
struct resource *res;
struct regulator *reg_vbus;
@@ -152,20 +185,11 @@ static int __devinit ci13xxx_imx_probe(struct 
platform_device *pdev)
}
}
 
-   /* we only support host now, so enable vbus here */
reg_vbus = devm_regulator_get(&pdev->dev, "vbus");
-   if (!IS_ERR(reg_vbus)) {
-   ret = regulator_enable(reg_vbus);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "Failed to enable vbus regulator, err=%d\n",
-   ret);
-   goto put_np;
-   }
+   if (!IS_ERR(reg_vbus))
data->reg_vbus = reg_vbus;
-   } else {
+   else
reg_vbus = NULL;
-   }
 
ci13xxx_imx_platdata.phy = data->phy;
 
@@ -175,7 +199,7 @@ static int __devinit ci13xxx_imx_probe(struct 
platform_device *pdev)
if (!pdev->dev.dma_mask) {
ret = -ENOMEM;
dev_err(&pdev->dev, "Failed to alloc dma_mask!\n");
-   goto err;
+   goto put_np;
}
*pdev->dev.dma_mask = DMA_BIT_MASK(32);
dma_set_coherent_mask(&pdev->dev, *pdev->dev.dma_mask);
@@ -186,7 +210,7 @@ static int __devinit ci13xxx_imx_probe(struct 
platform_device *pdev)
if (ret) {
dev_err(&pdev->dev,
"usbmisc init failed, ret=%d\n", ret);
-   goto err;
+   goto put_np;
}
}
 
@

Re: [PATCH 2/9] usb: chipidea: ci13xxx_imx: add 2nd and 3rd clock to support imx5x and newer

[Peter Chen]

On Wed, Nov 14, 2012 at 05:19:03PM +0100, Michael Grzeschik wrote:
> This patch adds support for a second and third clock to the chipidea driver. 
> On
> modern freescale ARM cores like the imx51, imx53 and imx6q three clocks 
> ("ahb",
> "ipg" and "per") must be enabled in order to access the USB core.
> 
> In the original driver, the clock was requested without specifying the
> connection id, further all mainline ARM archs with support for the chipidea
> core (imx23, imx28) register their USB clock without a connection id.
> 
> This patch first renames the existing clk variable to clk_ahb. The connection
> id "ahb" is added to the devm_clk_get() call. Then the clocks "ipg" and "per"
> are requested. As all archs don't specify a connection id, all clk_get return
> the same clock. This ensures compatibility to existing USB support and adds
> support for imx5x at the same time.
> 
> This patch has been tested on imx28 and on imx53 with seperate "ahb", "ipg"
> and "per" clocks.
mx23, mx28, and mx6q has the same usb clock sources and different with
mxc (mx5x, mx3x).

I am not sure which method is better:
- Add dummy clock at clock.c
- Add platform information(id_table or something similar) at driver.

Add dummy clock may confuse some users, for example, mx6q has no
"per" and "ipg" clock at all.
> 
> Signed-off-by: Michael Grzeschik 
> Signed-off-by: Marc Kleine-Budde 
> ---
>  drivers/usb/chipidea/ci13xxx_imx.c |   54 
> ++--
>  1 file changed, 45 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
> b/drivers/usb/chipidea/ci13xxx_imx.c
> index 935de97..570aedf 100644
> --- a/drivers/usb/chipidea/ci13xxx_imx.c
> +++ b/drivers/usb/chipidea/ci13xxx_imx.c
> @@ -32,7 +32,9 @@ struct ci13xxx_imx_data {
>   struct device_node *phy_np;
>   struct usb_phy *phy;
>   struct platform_device *ci_pdev;
> - struct clk *clk;
> + struct clk *clk_ahb;
> + struct clk *clk_ipg;
> + struct clk *clk_per;
>   struct regulator *reg_vbus;
>  };
>  
> @@ -144,20 +146,48 @@ static int __devinit ci13xxx_imx_probe(struct 
> platform_device *pdev)
>   dev_warn(&pdev->dev, "pinctrl get/select failed, err=%ld\n",
>   PTR_ERR(pinctrl));
>  
> - data->clk = devm_clk_get(&pdev->dev, NULL);
> - if (IS_ERR(data->clk)) {
> + data->clk_ahb = devm_clk_get(&pdev->dev, "ahb");
> + if (IS_ERR(data->clk_ahb)) {
>   dev_err(&pdev->dev,
> - "Failed to get clock, err=%ld\n", PTR_ERR(data->clk));
> - return PTR_ERR(data->clk);
> + "Failed to get ahb clock, err=%ld\n", 
> PTR_ERR(data->clk_ahb));
> + return PTR_ERR(data->clk_ahb);
>   }
>  
> - ret = clk_prepare_enable(data->clk);
> + data->clk_ipg = devm_clk_get(&pdev->dev, "ipg");
> + if (IS_ERR(data->clk_ipg)) {
> + dev_err(&pdev->dev,
> + "Failed to get ipg clock, err=%ld\n", 
> PTR_ERR(data->clk_ipg));
> + return PTR_ERR(data->clk_ipg);
> + }
> +
> + data->clk_per = devm_clk_get(&pdev->dev, "per");
> + if (IS_ERR(data->clk_per)) {
> + dev_err(&pdev->dev,
> + "Failed to get per clock, err=%ld\n", 
> PTR_ERR(data->clk_per));
> + return PTR_ERR(data->clk_per);
> + }
> +
> + ret = clk_prepare_enable(data->clk_ahb);
>   if (ret) {
>   dev_err(&pdev->dev,
> - "Failed to prepare or enable clock, err=%d\n", ret);
> + "Failed to prepare or enable ahb clock, err=%d\n", ret);
>   return ret;
>   }
>  
> + ret = clk_prepare_enable(data->clk_ipg);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "Failed to prepare or enable ipg clock, err=%d\n", ret);
> + goto err_ipg_failed;
> + }
> +
> + ret = clk_prepare_enable(data->clk_per);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "Failed to prepare or enable per clock, err=%d\n", ret);
> + goto err_per_failed;
> + }
> +
>   phy_np = of_parse_phandle(pdev->dev.of_node, "fsl,usbphy", 0);
>   if (phy_np) {
>   data->phy_np = phy_np;
> @@ -246,7 +276,11 @@ static int __devinit ci13xxx_imx_probe(struct 
> platform_device *pdev)
>  put_np:
>   if (phy_np)
>   of_node_put(phy_np);
> - clk_disable_unprepare(data->clk);
> + clk_disable_unprepare(data->clk_per);
> +err_per_failed:
> + clk_disable_unprepare(data->clk_ipg);
> +err_ipg_failed:
> + clk_disable_unprepare(data->clk_ahb);
>  
>   return ret;
>  }
> @@ -268,7 +302,9 @@ static int __devexit ci13xxx_imx_remove(struct 
> platform_device *pdev)
>  
>   of_node_put(data->phy_np);
>  
> - clk_disable_unprepare(data->clk);
> + clk_disable_unprepare(data->clk_per);
> + clk_disable_unprepare(data->clk_ipg);
> + clk_disable_unprepare(data->clk_ah

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Takashi Iwai]

At Sun, 25 Nov 2012 23:01:27 +0100,
Clemens Ladisch wrote:
> 
> Jonathan Nieder wrote:
> > Some USB MIDI keyboards fail to operate after a USB autosuspend.
> 
> Make that *all* USB MIDI devices with input ports.
> 
> This is not a bug in the device, but one of the many bugs introduced
> with the autosuspend code in .
> 
> That patch does not handle input at all, i.e., when the driver wants to
> read from the device, it just doesn't take it out of suspend mode.
> 
> > A workaround is to disable USB autosuspend for these devices by
> > putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
> > /etc/laptop-mode/conf.d/usb-autosuspend.conf.  In the spirit of commit
> > 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
> > reset the device on resume so this workaround is not needed any more.
> 
> It is not feasible to add the IDs of all USB MIDI devices.
> 
> I'm working on a fix that adds proper power management for input ports,
> but this requires the driver to be reorganized a little ...

Doesn't a simple patch like below work?
(It even reduces more lines! :)


Takashi

---
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index eeefbce..2e0fabc 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -148,7 +148,6 @@ struct snd_usb_midi_out_endpoint {
struct snd_usb_midi_out_endpoint* ep;
struct snd_rawmidi_substream *substream;
int active;
-   bool autopm_reference;
uint8_t cable;  /* cable number << 4 */
uint8_t state;
 #define STATE_UNKNOWN  0
@@ -1033,29 +1032,35 @@ static void update_roland_altsetting(struct 
snd_usb_midi* umidi)
snd_usbmidi_input_start(&umidi->list);
 }
 
-static void substream_open(struct snd_rawmidi_substream *substream, int open)
+static int substream_open(struct snd_rawmidi_substream *substream, int open)
 {
struct snd_usb_midi* umidi = substream->rmidi->private_data;
struct snd_kcontrol *ctl;
+   int err = 0;
 
mutex_lock(&umidi->mutex);
-   if (open) {
-   if (umidi->opened++ == 0 && umidi->roland_load_ctl) {
+   if (open && umidi->opened++ == 0) {
+   err = usb_autopm_get_interface(umidi->iface);
+   if (err == -EACCES)
+   err = 0;
+   if (!err && umidi->roland_load_ctl) {
ctl = umidi->roland_load_ctl;
ctl->vd[0].access |= SNDRV_CTL_ELEM_ACCESS_INACTIVE;
snd_ctl_notify(umidi->card,
   SNDRV_CTL_EVENT_MASK_INFO, &ctl->id);
update_roland_altsetting(umidi);
}
-   } else {
-   if (--umidi->opened == 0 && umidi->roland_load_ctl) {
+   } else if (!open && --umidi->opened == 0) {
+   if (umidi->roland_load_ctl) {
ctl = umidi->roland_load_ctl;
ctl->vd[0].access &= ~SNDRV_CTL_ELEM_ACCESS_INACTIVE;
snd_ctl_notify(umidi->card,
   SNDRV_CTL_EVENT_MASK_INFO, &ctl->id);
}
+   usb_autopm_put_interface(umidi->iface);
}
mutex_unlock(&umidi->mutex);
+   return err;
 }
 
 static int snd_usbmidi_output_open(struct snd_rawmidi_substream *substream)
@@ -1076,25 +1081,17 @@ static int snd_usbmidi_output_open(struct 
snd_rawmidi_substream *substream)
snd_BUG();
return -ENXIO;
}
-   err = usb_autopm_get_interface(umidi->iface);
-   port->autopm_reference = err >= 0;
-   if (err < 0 && err != -EACCES)
-   return -EIO;
+   err = substream_open(substream, 1);
+   if (err < 0)
+   return err;
substream->runtime->private_data = port;
port->state = STATE_UNKNOWN;
-   substream_open(substream, 1);
return 0;
 }
 
 static int snd_usbmidi_output_close(struct snd_rawmidi_substream *substream)
 {
-   struct snd_usb_midi* umidi = substream->rmidi->private_data;
-   struct usbmidi_out_port *port = substream->runtime->private_data;
-
-   substream_open(substream, 0);
-   if (port->autopm_reference)
-   usb_autopm_put_interface(umidi->iface);
-   return 0;
+   return substream_open(substream, 0);
 }
 
 static void snd_usbmidi_output_trigger(struct snd_rawmidi_substream 
*substream, int up)
@@ -1147,14 +1144,12 @@ static void snd_usbmidi_output_drain(struct 
snd_rawmidi_substream *substream)
 
 static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
 {
-   substream_open(substream, 1);
-   return 0;
+   return substream_open(substream, 1);
 }
 
 static int snd_usbmidi_input_close(struct snd_rawmidi_substream *substream)
 {
-   substream_open(substream, 0);
-   return 0;
+   return substream_open(substream, 0);
 }
 
 static 

cdc-acm and remote wakeup

[Daniele Palmas]

Hello,

I'm using the modem Telit HE910 with cdc-acm driver.

I've found that after a suspend and resume of the operating system
(e.g. pm-suspend), the modem does not answer anymore.

Collecting logs with an usb sniffer, it seems that, unlike the Windows
driver, the host does not send the packet SET_FEATURE DEVICE_REMOTE
WAKEUP, needed by the modem.

I've added few lines of code (in the acm_suspend function) for sending
this packet and now things work.

According to the USB 2.0 specs it seems to me that this feature should
be always requested when suspending a device, so probably the driver
behavior is not correct.

Does cdc-acm really not support this feature or am I missing some
configuration parameters that enable the sending of this request?

Thanks,
Daniele
--
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 4/9] usb: chipidea: ci13xxx-imx: add "dr_mode" property to device tree bindings

[Peter Chen]

On Fri, Nov 16, 2012 at 01:53:09PM +0200, Alexander Shishkin wrote:
> Michael Grzeschik  writes:
> 
> > From: Marc Kleine-Budde 
> >
> > Its necessary to limit a hostonly soc to its single role, since
> > debugging has shown that reading on the "CAP_DCCPARAMS" register inside
> > a host-only port, what ci_hdrc_gadget_init does, can lead to an
> > instable behaviour of the IC.
> 
> Probably typos: should be "it's" and "unstable".
> 
> [snip]
> 
> > --- a/drivers/usb/chipidea/ci13xxx_imx.c
> > +++ b/drivers/usb/chipidea/ci13xxx_imx.c
> > @@ -237,6 +237,8 @@ static int __devinit ci13xxx_imx_probe(struct 
> > platform_device *pdev)
> > }
> > }
> >  
> > +   ci13xxx_get_dr_mode(pdev->dev.of_node, pdata);
> > +
> > plat_ci = ci13xxx_add_device(&pdev->dev,
> > pdev->resource, pdev->num_resources,
> > pdata);
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index b50b77a..3e3e159 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -63,6 +63,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -521,6 +522,23 @@ void ci13xxx_remove_device(struct platform_device 
> > *pdev)
> >  }
> >  EXPORT_SYMBOL_GPL(ci13xxx_remove_device);
> >  
> > +void ci13xxx_get_dr_mode(struct device_node *of_node, struct 
> > ci13xxx_platform_data *pdata)
> > +{
> > +   const unsigned char *dr_mode;
> > +
> > +   dr_mode = of_get_property(of_node, "dr_mode", NULL);
> > +   if (!dr_mode)
> > +   return;
> > +
> > +   if (!strcmp(dr_mode, "host"))
> > +   pdata->flags |= CI13XXX_DR_MODE_HOST;
> > +   else if (!strcmp(dr_mode, "peripheral"))
> > +   pdata->flags |= CI13XXX_DR_MODE_PERIPHERAL;
> > +   else if (!strcmp(dr_mode, "otg"))
> > +   pdata->flags |= CI13XXX_DR_MODE_HOST | 
> > CI13XXX_DR_MODE_PERIPHERAL;
> > +}
> > +EXPORT_SYMBOL_GPL(ci13xxx_get_dr_mode);
> > +
> 
> I'd prefer this function to live in ci13xxx_imx, since that's where it's
> used and it doesn't really need anything from core.c anyway. Or maybe it
> would make sense to make it even more generic (for other devitetree
> users), since you're saying that other drivers are using this already.
> 
> Looks good to me otherwise.

I think it supplies a way that the platform can override the usb role,
only freescale uses it, but also other platforms may use it. It is a
generic feature, other chipidea users may need it.

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

Re: [PATCH 5/9] usb: add phy connection by phy-mode

[Peter Chen]

On Wed, Nov 14, 2012 at 05:19:06PM +0100, Michael Grzeschik wrote:
> This patch makes it possible to set the connection of the usbphy to the
> soc. It is derived from the oftree bindings for the ethernetphy and adds
> similar helperfunctions.
> 
> Signed-off-by: Michael Grzeschik 
> Signed-off-by: Marc Kleine-Budde 
> ---
>  drivers/of/Kconfig|4 
>  drivers/of/Makefile   |1 +
>  drivers/of/of_usbphy.c|   49 
> +
>  include/linux/of_usbphy.h |   15 ++
>  include/linux/usb/phy.h   |8 
>  5 files changed, 77 insertions(+)
>  create mode 100644 drivers/of/of_usbphy.c
>  create mode 100644 include/linux/of_usbphy.h
> 
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index dfba3e6..28f99fb 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -67,6 +67,10 @@ config OF_MDIO
>   help
> OpenFirmware MDIO bus (Ethernet PHY) accessors
>  
> +config OF_USBPHY
> + depends on USB
> + def_bool y
> +
>  config OF_PCI
>   def_tristate PCI
>   depends on PCI
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index e027f44..fdcaf51 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_OF_IRQ)+= irq.o
>  obj-$(CONFIG_OF_DEVICE) += device.o platform.o
>  obj-$(CONFIG_OF_I2C) += of_i2c.o
>  obj-$(CONFIG_OF_NET) += of_net.o
> +obj-$(CONFIG_OF_USBPHY)  += of_usbphy.o
>  obj-$(CONFIG_OF_SELFTEST) += selftest.o
>  obj-$(CONFIG_OF_MDIO)+= of_mdio.o
>  obj-$(CONFIG_OF_PCI) += of_pci.o
> diff --git a/drivers/of/of_usbphy.c b/drivers/of/of_usbphy.c
> new file mode 100644
> index 000..2e71f7b
> --- /dev/null
> +++ b/drivers/of/of_usbphy.c
> @@ -0,0 +1,49 @@
> +/*
> + * OF helpers for network devices.
> + *
> + * This file is released under the GPLv2
> + *
> + * Initially copied out of drivers/of/of_net.c
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * It maps 'enum usb_phy_interface' found in include/linux/usb/phy.h
> + * into the device tree binding of 'phy-mode', so that USB
> + * device driver can get phy interface from device tree.
> + */
> +static const char *usbphy_modes[] = {
> + [USBPHY_INTERFACE_MODE_NA]  = "",
> + [USBPHY_INTERFACE_MODE_UTMI]= "utmi",
> + [USBPHY_INTERFACE_MODE_UTMIW]   = "utmiw",
> + [USBPHY_INTERFACE_MODE_ULPI]= "ulpi",
> + [USBPHY_INTERFACE_MODE_SERIAL]  = "fsls",
"fsls"? or should be "serial"?
> +};
> +

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: autodetect USB MTP device characteristics without libusb_open()

[Bjørn Mork]

Linus Walleij  writes:

> /* Check if device responds to control message 1 or if there is an error 
> */
> cmd = buf[16];
> ret = libusb_control_transfer (devh,
>  LIBUSB_ENDPOINT_IN | LIBUSB_RECIPIENT_DEVICE | 
> LIBUSB_REQUEST_TYPE_VENDOR,
>  cmd,
>  0,
>  4,
>  buf,
>  sizeof(buf),
>  USB_TIMEOUT_DEFAULT);
>
> // Dump it, if requested
> if (dumpfile != NULL && ret > 0) {
>   fprintf(dumpfile, "Microsoft device response to control message
> 1, CMD 0x%02x:\n", cmd);
>   data_dump_ascii(dumpfile, buf, ret, 16);
> }
>
> /* If this is true, the device either isn't MTP or there was an error */
> if (ret <= 0x15) {
>   /* TODO: If there was an error, flag it and let the user know somehow */
>   /* if(ret == -1) {} */
>   libusb_close(devh);
>   return 0;
> }
>
> /* Check if device is MTP or if it is something like a USB Mass Storage
>device with Janus DRM support */
> if ((buf[0x12] != 'M') || (buf[0x13] != 'T') || (buf[0x14] != 'P')) {
>   libusb_close(devh);
>   return 0;
> }
>
> /* After this point we are probably dealing with an MTP device */

Not really relevant to this discussion, but this parsing is too simple
and will fail to detect composite devices with MTP functions unless the
MTP function is listed first in the Microsoft pseudo-descriptor.

You should really verify the header and look through *all* returned
function sections.

It's not clear from this, but I do hope you parse the MTP function
interface number later in the code?


>> It would mean that Linux systems must start keeping track of every
>> device that a system has seen. It's atrocious.
>>
>> But I don't think there's another way. Of course, it could be part of
>> a non-core package, so that only when the MTP software is installed
>> will there be some database.
>
> This is how it works today. The probing comes with libmtp,
> which also provide the udev rules and thus notify userspace
> that listen to the udev events.

I don't think that keeping track of all possible MTP devices a system
has seen would be that extra-ordinary.  My Debian system has a few such
examples already:
 - /lib/udev/write_cd_rules creates persistent cdrom names by writing a
   rule to /etc/udev/rules.d/70-persistent-cd.rules for every CD device
   seen
 - /lib/udev/write_net_rules creates persistent network device names by
   writing a rule to /etc/udev/rules.d/70-persistent-net.rules for every 

So following the same pattern, the MTP tools could let the probe write 
new dynamic rules which (by setting enviroment variables):
 1) prevents further probing of the same device
 2) sets a MTP supported flag on all MTP interfaces (note: NOT DEVICE).

This would make the probing a one time per device affair, which might
let you ignore crashing devices (since it will only happen once) and
it will let you point the MTP tools directly to the interfaces
supporting MTP.

Note that this will work with devices with configurable PTP or MTP
support, because they are made to work with Windows which also does the
above. Such devices will therefore typically switch device IDs when
switching modes, although they could just have used unique interface
numbers I guess.


>> For most (I'm not sure I dare say all) other devices, it would add no
>> value on Linux.
>
> I fully agree ... well, Microsoft actually intended the device
> descriptor to be used also for things like WiFi and Bluetooth
> but it seems they never did that.

Luckily the USB-IF have standardized proper descriptors for those
devices.

It's too bad they didn't have the power or guts to prevent Microsoft
from creating their parallell universe.  Which was created solely as an
attempt to prevent other OSes from using USB devices. It would have been
in the USB-IFs best interest to strike that down before it had a chance
to be implemented by anyone.

If you dont' believe me, then let me quote from Microsofts own
documentation of the "Extended Compat ID OS Feature Descriptor":

  The Microsoft OS Descriptor Specification and any accompanying
  materials (the “Specification”) provided by Microsoft is for your
  personal use only, and may be used solely for the purpose of
  implementing the Microsoft OS Descriptor set to interface with (i) a
  Microsoft OS Descriptor enabled operating system or (ii) other systems
  authorized by Microsoft to retrieve and use this information. THE
  SPECIFICATION (OR ANY OF ITS CONTENTS) MAY NOT BE COPIED OR
  DISTRIBUTED.

It's not even like they try to hide their agenda.  They just document
their evil intent like that...

Luckily, AFAICS, Linux qualifies as "a Microsoft OS Descriptor enabled
operating system", as it is perfectly able to use Microsoft OS
Descriptors :-)

But IANAL, and you may want to consider your local legal advisor before
t

Re: [PATCH 2/9] usb: chipidea: ci13xxx_imx: add 2nd and 3rd clock to support imx5x and newer

[Sascha Hauer]

On Mon, Nov 26, 2012 at 05:29:31PM +0800, Peter Chen wrote:
> On Wed, Nov 14, 2012 at 05:19:03PM +0100, Michael Grzeschik wrote:
> > This patch adds support for a second and third clock to the chipidea 
> > driver. On
> > modern freescale ARM cores like the imx51, imx53 and imx6q three clocks 
> > ("ahb",
> > "ipg" and "per") must be enabled in order to access the USB core.
> > 
> > In the original driver, the clock was requested without specifying the
> > connection id, further all mainline ARM archs with support for the chipidea
> > core (imx23, imx28) register their USB clock without a connection id.
> > 
> > This patch first renames the existing clk variable to clk_ahb. The 
> > connection
> > id "ahb" is added to the devm_clk_get() call. Then the clocks "ipg" and 
> > "per"
> > are requested. As all archs don't specify a connection id, all clk_get 
> > return
> > the same clock. This ensures compatibility to existing USB support and adds
> > support for imx5x at the same time.
> > 
> > This patch has been tested on imx28 and on imx53 with seperate "ahb", "ipg"
> > and "per" clocks.
> mx23, mx28, and mx6q has the same usb clock sources and different with
> mxc (mx5x, mx3x).
> 
> I am not sure which method is better:
> - Add dummy clock at clock.c
> - Add platform information(id_table or something similar) at driver.
> 
> Add dummy clock may confuse some users, for example, mx6q has no
> "per" and "ipg" clock at all.

The general idea is: The USB core has different input clocks. The driver
has to be provided with these input clocks. When i.MX6 does not have
these clocks, it only means that this SoC has no software controllable
gates for these clocks, thus they are not documented. Still this SoC
has these clocks.
This way we can describe the differences between the SoC purely on SoC
level without bothering the driver.
You might want to ask your hardware guys to get more information what
input clocks the USB core actually has, there actually is a lot of
guesswork in it due to missing/inconsistent/confusing documentation.

Sascha


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

Re: cdc-acm and remote wakeup

[Oliver Neukum]

On Monday 26 November 2012 10:42:48 Daniele Palmas wrote:
> Hello,
> 
> I'm using the modem Telit HE910 with cdc-acm driver.
> 
> I've found that after a suspend and resume of the operating system
> (e.g. pm-suspend), the modem does not answer anymore.
> 
> Collecting logs with an usb sniffer, it seems that, unlike the Windows
> driver, the host does not send the packet SET_FEATURE DEVICE_REMOTE
> WAKEUP, needed by the modem.

This is a new quirk.

> I've added few lines of code (in the acm_suspend function) for sending
> this packet and now things work.

acm_suspend is definitely not the place to put this, even if it fixes
your particular usage.

> According to the USB 2.0 specs it seems to me that this feature should
> be always requested when suspending a device, so probably the driver
> behavior is not correct.

Hm. Which part of the spec do you base this on?

> Does cdc-acm really not support this feature or am I missing some
> configuration parameters that enable the sending of this request?

For a modem this feature makes relatively little sense. I've never
seen a modem that doesn't hang up when you suspend it.

Regards
Oliver

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

Re: Problem with OHCI on OMAP4430

[Mohan V]

Alan,

On Tue, Oct 30, 2012 at 9:34 PM, Alan Stern  wrote:
> On Tue, 30 Oct 2012, Mohan V wrote:
>
>> >> >> Device not getting detected when 
>> >> >> connected---
>> >> >>
>> >> >> / # [  135.621002] usbhs_wakeup: Enabling clocks
>> >> >> [  135.625762] usbhs_runtime_resume:++
>> >> >> [  135.630371] usbhs_runtime_resume:--
>> >> >> [  135.638183] USB IO PAD Wakeup event triggered##
>> >> >> [  135.644958] usbhs_runtime_suspend:++
>> >> >> [  135.649749] usbhs_runtime_suspend:-
>> >> >
>> >> > It appears that ohci_irq() didn't run.  Did
>> >> > ohci_finish_controller_resume() get called?
>> >> >
>> >> This function is not used in ohci-omap3.c and is used only in ohci-omap.c.
>> >> Is it necessary to call this function?
>> >
>> > It is necessary if the driver supports suspend/resume.  As far as I can
>> > tell, the ohci-omap3 driver does not have this support (at least, not
>> > in the 3.6 kernel) whereas the ohci-omap driver does.
>> >
>> > What driver produced the "usbhs_runtime_suspend" and
>> > "usbhs_runtime_resume" messages above?  (No such messages are present
>> > in ohci-omap3.c.)  Apparently that driver _does_ support
>> > suspend/resume.
>> >
>> This driver is USBHS core driver for OMAP EHCI and OHCI
>> (drivers/mfd/omap-usb-host.c)
>
> Okay.  I don't understand why the usbhs_runtime_suspend routine ever
> got called.  Since ohci-omap3 never allows the OHCI controller to be
> suspended, the parent platform device should never get suspended
> either.
>
Sorry for the delay in confirmation. In the android kernel, it seems
that somehow the OHCI interrupts are not
propagated to ARM interrupt controller.
So, reading one of the OHCI registers in usbhs_runtime_resume() seems
to resolve the issue.

Thanks,
Mohan

> What do the various files in the /sys/devices/.../ohci-omap3.0/power
> directory show?  What about the corresponding files in the power
> subdirectory of the parent 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: cdc-acm and remote wakeup

[Daniele Palmas]

Hello Oliver,

2012/11/26 Oliver Neukum :
> On Monday 26 November 2012 10:42:48 Daniele Palmas wrote:
>> Hello,
>>
>> I'm using the modem Telit HE910 with cdc-acm driver.
>>
>> I've found that after a suspend and resume of the operating system
>> (e.g. pm-suspend), the modem does not answer anymore.
>>
>> Collecting logs with an usb sniffer, it seems that, unlike the Windows
>> driver, the host does not send the packet SET_FEATURE DEVICE_REMOTE
>> WAKEUP, needed by the modem.
>
> This is a new quirk.
>

Ok.

>> I've added few lines of code (in the acm_suspend function) for sending
>> this packet and now things work.
>
> acm_suspend is definitely not the place to put this, even if it fixes
> your particular usage.
>

Ok. Do you have any hint for adding the code in the proper place?

>> According to the USB 2.0 specs it seems to me that this feature should
>> be always requested when suspending a device, so probably the driver
>> behavior is not correct.
>
> Hm. Which part of the spec do you base this on?
>

The doc is "Universal Serial Bus Specification" revision 2.0 paragraph
10.5.4.5, if I am not misunderstanding the topic.

Here

http://msdn.microsoft.com/en-us/library/windows/hardware/ff537628%28v=vs.85%29.aspx

there is an interpretation coming from Microsoft

"In USB terminology, a USB device is enabled for remote wakeup when
its DEVICE_REMOTE_WAKEUP feature is set. The USB specification
specifies that host software must set the remote wakeup feature on a
device "only just prior" to putting the device to sleep."

>> Does cdc-acm really not support this feature or am I missing some
>> configuration parameters that enable the sending of this request?
>
> For a modem this feature makes relatively little sense. I've never
> seen a modem that doesn't hang up when you suspend it.

Maybe I have to explain better my scenario:

Modem is registered to the network. Host suspended, I want my device
to wake up the host when it receives, for example, a call or an sms.

This doesn't happen if the driver doesn't send the
DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
is bricked.

I understand that probably there are problems in the firmware of the
modem (because it should not brick), but I'm trying to find a
workaround to have things working.

>
> Regards
> Oliver
>

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

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Clemens Ladisch]

Takashi Iwai wrote:> At Sun, 25 Nov 2012 23:01:27 +0100,
> Clemens Ladisch wrote:
>>
>> Jonathan Nieder wrote:
>>> Some USB MIDI keyboards fail to operate after a USB autosuspend.
>>
>> Make that *all* USB MIDI devices with input ports.
>>
>> This is not a bug in the device, but one of the many bugs introduced
>> with the autosuspend code in .
>>
>> That patch does not handle input at all, i.e., when the driver wants to
>> read from the device, it just doesn't take it out of suspend mode.
>>
>>> A workaround is to disable USB autosuspend for these devices by
>>> putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
>>> /etc/laptop-mode/conf.d/usb-autosuspend.conf.  In the spirit of commit
>>> 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
>>> reset the device on resume so this workaround is not needed any more.
>>
>> It is not feasible to add the IDs of all USB MIDI devices.
>>
>> I'm working on a fix that adds proper power management for input ports,
>> but this requires the driver to be reorganized a little ...
>
> Doesn't a simple patch like below work?

> +static int substream_open(struct snd_rawmidi_substream *substream, int open)
>  {
> + if (open && umidi->opened++ == 0) {
> + err = usb_autopm_get_interface(umidi->iface);
>
>  static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
>  {
> + return substream_open(substream, 1);

No, because the input URBs are submitted before the userspace device is
opened.  (And usb_autopm_get_interface() cannot be called from the USB
probe callback.)


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

[RFC PATCH 0/5] Device Paths introduced and applied to generic hub and panda

[Andy Green]

NB this is against usb-next at 3.7-rc6

The following series introduces "wildcard device paths" as discussed recently;
in particular the wildcard idea is from Alan Stern.

First the API is introduced for generating, comparing and registering
the wildcard device paths.  I put them in drivers/base for now but if
that seems wrong it's easy to move.  They are a default n CONFIG_ option.

Then I remove the ehci-omap existing regulator support completely.

Third I add optional regulator support to the usb generic hub.  This uses
wildcard device path APIs to look for a regulator that matches the hub.
Again the support is optional on a default n CONFIG_ option.  If the
regulator is found, then it is enabled for the lifetime of the matching
logical hub object.

Board support for OMAP4 Panda is added which provides regulators with the
correct wildcard name to match the ehci-omap.0 root hub object.  The
wildcard name is registered so it will be used as a literal on any matching
generated device path.

Lastly there's a config delta on omap2plus_defconfig which enables EHCI,
which is otherwise disabled by default.

The end result is that the SMSC HUB+ETH chip is off by default at boot, and
is powered cleanly for the lifecycle of the ehci-hcd root hub object.

Comments welcome, this is my first attempt at turning the discussion of the
last few days into an implementation, it is working here well on Panda ES.

-Andy

---

Andy Green (5):
  drivers : introduce device_path api
  usb: omap ehci: remove all regulator control from ehci omap
  usb: hub: add device_path regulator control to generic hub
  omap4: panda: add smsc95xx regulator and reset dependent on root hub
  config omap2plus add ehci bits


 arch/arm/configs/omap2plus_defconfig   |   42 +++
 arch/arm/mach-omap2/Kconfig|1 
 arch/arm/mach-omap2/board-omap4panda.c |   90 +---
 drivers/base/Kconfig   |6 +
 drivers/base/Makefile  |2 
 drivers/base/core.c|2 
 drivers/base/path.c|  181 
 drivers/usb/core/Kconfig   |   10 ++
 drivers/usb/core/hub.c |   26 -
 drivers/usb/host/ehci-omap.c   |   33 --
 include/linux/device.h |   12 ++
 11 files changed, 327 insertions(+), 78 deletions(-)
 create mode 100644 drivers/base/path.c

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

[RFC PATCH 1/5] drivers : introduce device_path api

[Andy Green]

This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.

>From a struct device * you can generate a string like

 /platform/usbhs_omap/ehci-omap.0/usb1/1-1

which enapsulates the path of the device's connection to the board.

These can be used to match up other assets, for example struct regulators,
that have been registed elsewhere with a device instance that is probed
asynchronously from the other board assets.

If your device is on a bus, as it probably is, the device path will feature
redundant bus indexes that do not contain information about the connectivity.

For example if more than one driver can generate devices on the same bus,
then the ordering of device probing will change the path, despite the
connectivity remains the same.

For that reason, to get a deterministic path for matching, wildcards are
allowed.  If your target device has the path

 /platform/usbhs_omap/ehci-omap.0/usb1/1-1

generated, in the asset you wish to match with it you can instead use

/platform/usbhs_omap/ehci-omap.0/usb*/*-1

in order to only leave the useful, invariant parts of the path to match
against.

To avoid having to adapt every kind of "search by string" api to also use
the wildcards, the api takes the approach you can register your wildcard,
and if a matching path is generated for a device, the wildcard itself is
handed back as the device path instead.

So if your board code or a (not yet done) DT binding registers this wildcard

 /platform/usbhs_omap/ehci-omap.0/usb*

and the usb hub driver asks to generate its device path

device_path_generate(dev, name, sizeof name);

that is actually

 /platform/usbhs_omap/ehci-omap.0/usb1

then what will be returned is

 /platform/usbhs_omap/ehci-omap.0/usb*

providing the same literal string for ehci-omap.0 hub no matter how many\
usb buses have been registered before.

This wildcard string can then be matched to regulators or other string-
searchable assets intended for the device on that hardware path.

Signed-off-by: Andy Green 
---
 drivers/base/Kconfig   |6 ++
 drivers/base/Makefile  |2 +
 drivers/base/core.c|2 +
 drivers/base/path.c|  181 
 include/linux/device.h |   12 +++
 5 files changed, 203 insertions(+)
 create mode 100644 drivers/base/path.c

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index b34b5cd..3324a55 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -282,4 +282,10 @@ config CMA_AREAS
 
 endif
 
+config DEVICEPATH
+   bool "Device path api"
+   default n
+   help
+ Include dynamicly probed path matching API
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..b8d5723 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -22,5 +22,7 @@ obj-$(CONFIG_SYS_HYPERVISOR) += hypervisor.o
 obj-$(CONFIG_REGMAP)   += regmap/
 obj-$(CONFIG_SOC_BUS) += soc.o
 
+obj-$(CONFIG_DEVICEPATH) += path.o
+
 ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
 
diff --git a/drivers/base/core.c b/drivers/base/core.c
index abea76c..cc0ba02 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1368,6 +1368,8 @@ int __init devices_init(void)
if (!sysfs_dev_char_kobj)
goto char_kobj_err;
 
+   device_path_init();
+
return 0;
 
  char_kobj_err:
diff --git a/drivers/base/path.c b/drivers/base/path.c
new file mode 100644
index 000..384e792
--- /dev/null
+++ b/drivers/base/path.c
@@ -0,0 +1,181 @@
+/*
+ * drivers/base/path.c - device_path apis for matching dynamic / variable
+ *  device paths on buses like usb / mmc to wildcard constants from
+ *  platform or DT
+ *
+ * Copyright (c) 2012 Linaro, LTD
+ * Author: Andy Green 
+ *
+ * This file is released under the GPLv2
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct device_path {
+   char *path;
+   struct list_head list;
+};
+
+struct device_path list;
+DEFINE_MUTEX(lock);
+
+static int device_path_compare_wildcard(const char *awc, const char *b)
+{
+   while (*awc && *b) {
+   if (*awc == '*') {
+   awc++;
+   /* wildcard disallowed from extening past / */
+   while (*b && *b != *awc && *b != '/')
+   b++;
+   }
+   if (*awc != *b)
+   return -ENOENT;
+   if (!*awc)
+   return 0;
+   awc++;
+   b++;
+   }
+
+   if (!*awc && !*b)
+   return 0;
+
+   return -ENOENT;
+}
+
+static const char *device_path_find_wildcard(const char *device_path)
+{
+   struct device_path *dp;
+
+   mutex_lock(&lock);
+   list_for_each_entry(dp, &list.list, list) {
+   if (device_path_compare_wildcard(dp->path, device_path) == 0) {
+   mutex_unlock(&lock);
+  

[RFC PATCH 2/5] usb: omap ehci: remove all regulator control from ehci omap

[Andy Green]

This series migrates it to the hub driver as suggested by
Felipe Balbi.

Signed-off-by: Andy Green 
---
 drivers/usb/host/ehci-omap.c |   33 -
 1 file changed, 33 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 44e7d0f..2292544 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -40,7 +40,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -149,19 +148,6 @@ static int omap_ehci_init(struct usb_hcd *hcd)
return rc;
 }
 
-static void disable_put_regulator(
-   struct ehci_hcd_omap_platform_data *pdata)
-{
-   int i;
-
-   for (i = 0 ; i < OMAP3_HS_USB_PORTS ; i++) {
-   if (pdata->regulator[i]) {
-   regulator_disable(pdata->regulator[i]);
-   regulator_put(pdata->regulator[i]);
-   }
-   }
-}
-
 /* configure so an HC device and id are always provided */
 /* always called with process context; sleeping is OK */
 
@@ -223,23 +209,6 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
hcd->rsrc_len = resource_size(res);
hcd->regs = regs;
 
-   /* get ehci regulator and enable */
-   for (i = 0 ; i < OMAP3_HS_USB_PORTS ; i++) {
-   if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY) {
-   pdata->regulator[i] = NULL;
-   continue;
-   }
-   snprintf(supply, sizeof(supply), "hsusb%d", i);
-   pdata->regulator[i] = regulator_get(dev, supply);
-   if (IS_ERR(pdata->regulator[i])) {
-   pdata->regulator[i] = NULL;
-   dev_dbg(dev,
-   "failed to get ehci port%d regulator\n", i);
-   } else {
-   regulator_enable(pdata->regulator[i]);
-   }
-   }
-
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
@@ -265,7 +234,6 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
return 0;
 
 err_pm_runtime:
-   disable_put_regulator(pdata);
pm_runtime_put_sync(dev);
usb_put_hcd(hcd);
 
@@ -290,7 +258,6 @@ static int ehci_hcd_omap_remove(struct platform_device 
*pdev)
struct ehci_hcd_omap_platform_data *pdata   = dev->platform_data;
 
usb_remove_hcd(hcd);
-   disable_put_regulator(dev->platform_data);
iounmap(hcd->regs);
usb_put_hcd(hcd);
 

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

[RFC PATCH 3/5] usb: hub: add device_path regulator control to generic hub

[Andy Green]

This adds the config option to associate a regulator with each hub,
when the hub on a specific, interesting device path appears, then
the regular is powered while the logical hub exists.

Signed-off-by: Andy Green 
---
 drivers/usb/core/Kconfig |   10 ++
 drivers/usb/core/hub.c   |   26 +-
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
index f70c1a1..4a91eb1 100644
--- a/drivers/usb/core/Kconfig
+++ b/drivers/usb/core/Kconfig
@@ -95,3 +95,13 @@ config USB_OTG_BLACKLIST_HUB
  and software costs by not supporting external hubs.  So
  are "Embedded Hosts" that don't offer OTG support.
 
+config USB_HUB_DEVICE_PATH_REGULATOR
+   bool "Support generic regulators at hubs"
+   select DEVICEPATH
+   depends on USB
+   default n
+   help
+ Allows you to use the device_path APIs to associate kernel regulators
+ with dynamically probed USB hubs, so the regulators are enabled
+ as the appropriate hub instance gets created and disabled as it
+ is destroyed.
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a815fd2..49ebb5e 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -54,7 +55,9 @@ struct usb_hub {
struct usb_device   *hdev;
struct kref kref;
struct urb  *urb;   /* for interrupt polling pipe */
-
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+   struct regulator*regulator; /* optional power control */
+#endif
/* buffer for urb ... with extra space in case of babble */
char(*buffer)[8];
union {
@@ -1594,6 +1597,12 @@ static void hub_disconnect(struct usb_interface *intf)
if (hub->hdev->speed == USB_SPEED_HIGH)
highspeed_hubs--;
 
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+   if (hub->regulator && !IS_ERR(hub->regulator)) {
+   regulator_disable(hub->regulator);
+   regulator_put(hub->regulator);
+   }
+#endif
usb_free_urb(hub->urb);
kfree(hub->ports);
kfree(hub->descriptor);
@@ -1609,6 +1618,9 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+   char *dev_path;
+#endif
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1692,6 +1704,18 @@ descriptor_error:
return -ENOMEM;
}
 
+#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR
+   /* if a regulator is associated on our device_path, use it */
+   dev_path = kmalloc(MAX_DEV_PATH_SIZE, GFP_KERNEL);
+   if (!device_path_generate(&hdev->dev, dev_path, MAX_DEV_PATH_SIZE)) {
+   dev_info(&hdev->dev, "device_path: %s\n", dev_path);
+   hub->regulator = regulator_get(&hdev->dev, dev_path);
+   if (!IS_ERR(hub->regulator))
+   regulator_enable(hub->regulator);
+   }
+   kfree(dev_path);
+#endif
+
kref_init(&hub->kref);
INIT_LIST_HEAD(&hub->event_list);
hub->intfdev = &intf->dev;

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

[RFC PATCH 4/5] omap4: panda: add smsc95xx regulator and reset dependent on root hub

[Andy Green]

This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.

Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.

This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted.  When the module is removed, it's depowered
again.

Signed-off-by: Andy Green 
---
 arch/arm/mach-omap2/Kconfig|1 
 arch/arm/mach-omap2/board-omap4panda.c |   90 +---
 2 files changed, 72 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index d669e22..5105109 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -368,6 +368,7 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+   select USB_HUB_DEVICE_PATH_REGULATOR
 
 config OMAP3_EMU
bool "OMAP3 debugging peripherals"
diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..b032b6b 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -154,11 +154,6 @@ static const struct usbhs_omap_board_data usbhs_bdata 
__initconst = {
.reset_gpio_port[2]  = -EINVAL
 };
 
-static struct gpio panda_ehci_gpios[] __initdata = {
-   { GPIO_HUB_POWER,   GPIOF_OUT_INIT_LOW,  "hub_power"  },
-   { GPIO_HUB_NRESET,  GPIOF_OUT_INIT_LOW,  "hub_nreset" },
-};
-
 static void __init omap4_ehci_init(void)
 {
int ret;
@@ -173,23 +168,76 @@ static void __init omap4_ehci_init(void)
clk_set_rate(phy_ref_clk, 1920);
clk_prepare_enable(phy_ref_clk);
 
-   /* disable the power to the usb hub prior to init and reset phy+hub */
-   ret = gpio_request_array(panda_ehci_gpios,
-ARRAY_SIZE(panda_ehci_gpios));
-   if (ret) {
-   pr_err("Unable to initialize EHCI power/reset\n");
-   return;
-   }
+   usbhs_init(&usbhs_bdata);
+}
 
-   gpio_export(GPIO_HUB_POWER, 0);
-   gpio_export(GPIO_HUB_NRESET, 0);
-   gpio_set_value(GPIO_HUB_NRESET, 1);
+/*
+ * hub_nreset also resets the ULPI PHY and is required after powering SMSC chip
+ * ULPI PHY is always powered... need to do reset once for both once
+ * hub_power enables a 3.3V regulator for (hub + eth) chip
+ * however there's no point having ULPI PHY in use alone
+ * since it's only connected to the (hub + eth) chip
+ */
 
-   usbhs_init(&usbhs_bdata);
+static struct regulator_init_data panda_hub = {
+   .constraints = {
+   .name = "vhub",
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+};
 
-   /* enable power to hub */
-   gpio_set_value(GPIO_HUB_POWER, 1);
-}
+static struct fixed_voltage_config panda_vhub = {
+   .supply_name = "vhub",
+   .microvolts = 330,
+   .gpio = GPIO_HUB_POWER,
+   .startup_delay = 7, /* 70msec */
+   .enable_high = 1,
+   .enabled_at_boot = 0,
+   .init_data = &panda_hub,
+};
+
+static struct platform_device omap_vhub_device = {
+   .name   = "reg-fixed-voltage",
+   .id = 2,
+   .dev = {
+   .platform_data = &panda_vhub,
+   },
+};
+
+static struct regulator_init_data panda_ulpireset = {
+   /*
+* idea is that when operating ulpireset, regulator api will make
+* sure that the hub+eth chip is powered, since it's the "parent"
+*/
+   .supply_regulator = "vhub", /* we are a child of vhub */
+   .constraints = {
+   /*
+* this magic string associates us with ehci-omap.0 root hub
+* when the root hub logical device is up, we will power
+* and reset [ ULPI PHY + [ HUB + ETH ] ]
+*/
+   .name = "/platform/usbhs_omap/ehci-omap.0/usb*",
+   .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+   },
+};
+
+static struct fixed_voltage_config panda_vulpireset = {
+   .supply_name = "/platform/usbhs_omap/ehci-omap.0/usb*",
+   .microvolts = 330,
+   .gpio = GPIO_HUB_NRESET,
+   .startup_delay = 7, /* 70msec */
+   .enable_high = 1,
+   .enabled_at_boot = 0,
+   .init_data = &panda_ulpireset,
+};
+
+static struct platform_device omap_vulpireset_device = {
+   .name   = "reg-fixed-voltage",
+   .id = 3,
+   .dev = {
+   .platform_data = &panda_vulpireset,
+   },
+};
 
 static struct omap_musb_board_data musb_board_data = {
.interface_type = MUSB_INTERFACE_UTMI,
@@ -503,7 +551,11 @@ static void __init omap4_panda_init(void)
omap4_panda_init_rev();
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(p

[RFC PATCH 5/5] config omap2plus add ehci bits

[Andy Green]

omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.

Signed-off-by: Andy Green 
---
 arch/arm/configs/omap2plus_defconfig |   42 ++
 1 file changed, 17 insertions(+), 25 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index 6230304..2f858a3 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -1,14 +1,14 @@
 CONFIG_EXPERIMENTAL=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
 CONFIG_LOG_BUF_SHIFT=16
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_EXPERT=y
-# CONFIG_SYSCTL_SYSCALL is not set
-CONFIG_KALLSYMS_EXTRA_PASS=y
 CONFIG_SLAB=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
@@ -20,16 +20,15 @@ CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
 CONFIG_ARCH_OMAP=y
 CONFIG_OMAP_RESET_CLOCKS=y
 CONFIG_OMAP_MUX_DEBUG=y
+CONFIG_SOC_OMAP5=y
 CONFIG_ARM_THUMBEE=y
 CONFIG_ARM_ERRATA_411920=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=2
-CONFIG_LEDS=y
 CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_CMDLINE="root=/dev/mmcblk0p2 rootwait console=ttyO2,115200"
@@ -87,22 +86,21 @@ CONFIG_SCSI_MULTI_LUN=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_MD=y
 CONFIG_NETDEVICES=y
-CONFIG_SMSC_PHY=y
-CONFIG_NET_ETHERNET=y
-CONFIG_SMC91X=y
-CONFIG_SMSC911X=y
 CONFIG_KS8851=y
 CONFIG_KS8851_MLL=y
-CONFIG_LIBERTAS=m
-CONFIG_LIBERTAS_USB=m
-CONFIG_LIBERTAS_SDIO=m
-CONFIG_LIBERTAS_DEBUG=y
+CONFIG_SMC91X=y
+CONFIG_SMSC911X=y
+CONFIG_SMSC_PHY=y
 CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_NET_SMSC95XX=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
 CONFIG_USB_KC2190=y
+CONFIG_LIBERTAS=m
+CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_SDIO=m
+CONFIG_LIBERTAS_DEBUG=y
 CONFIG_INPUT_JOYDEV=y
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
@@ -132,14 +130,13 @@ CONFIG_POWER_SUPPLY=y
 CONFIG_WATCHDOG=y
 CONFIG_OMAP_WATCHDOG=y
 CONFIG_TWL4030_WATCHDOG=y
-CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_REGULATOR_TWL4030=y
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
 CONFIG_FB_TILEBLITTING=y
-CONFIG_FB_OMAP_LCD_VGA=y
 CONFIG_OMAP2_DSS=m
 CONFIG_OMAP2_DSS_RFBI=y
 CONFIG_OMAP2_DSS_SDI=y
@@ -154,7 +151,6 @@ CONFIG_PANEL_ACX565AKM=m
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_PLATFORM=y
-CONFIG_DISPLAY_SUPPORT=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
 CONFIG_FONTS=y
@@ -174,13 +170,15 @@ CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m
 CONFIG_USB=y
 CONFIG_USB_DEBUG=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
-CONFIG_USB_DEVICEFS=y
 CONFIG_USB_SUSPEND=y
 CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
+CONFIG_USB_EHCI_HCD_PLATFORM=m
 CONFIG_USB_WDM=y
 CONFIG_USB_STORAGE=y
-CONFIG_USB_LIBUSUAL=y
 CONFIG_USB_TEST=y
+CONFIG_OMAP_USB2=m
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
@@ -214,23 +212,18 @@ CONFIG_JFFS2_RUBIN=y
 CONFIG_UBIFS_FS=y
 CONFIG_CRAMFS=y
 CONFIG_NFS_FS=y
-CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
 CONFIG_NFS_V4=y
 CONFIG_ROOT_NFS=y
-CONFIG_PARTITION_ADVANCED=y
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
-CONFIG_DEBUG_KERNEL=y
 CONFIG_SCHEDSTATS=y
 CONFIG_TIMER_STATS=y
 CONFIG_PROVE_LOCKING=y
-CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_INFO=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
 CONFIG_SECURITY=y
 CONFIG_CRYPTO_MICHAEL_MIC=y
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
@@ -239,4 +232,3 @@ CONFIG_CRC_T10DIF=y
 CONFIG_CRC_ITU_T=y
 CONFIG_CRC7=y
 CONFIG_LIBCRC32C=y
-CONFIG_SOC_OMAP5=y

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

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Takashi Iwai]

At Mon, 26 Nov 2012 13:35:31 +0100,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:> At Sun, 25 Nov 2012 23:01:27 +0100,
> > Clemens Ladisch wrote:
> >>
> >> Jonathan Nieder wrote:
> >>> Some USB MIDI keyboards fail to operate after a USB autosuspend.
> >>
> >> Make that *all* USB MIDI devices with input ports.
> >>
> >> This is not a bug in the device, but one of the many bugs introduced
> >> with the autosuspend code in .
> >>
> >> That patch does not handle input at all, i.e., when the driver wants to
> >> read from the device, it just doesn't take it out of suspend mode.
> >>
> >>> A workaround is to disable USB autosuspend for these devices by
> >>> putting AUTOSUSPEND_USBID_BLACKLIST="0763:2027" (resp. 0763:019b) in
> >>> /etc/laptop-mode/conf.d/usb-autosuspend.conf.  In the spirit of commit
> >>> 166cb70e97bd ("usb: add USB_QUIRK_RESET_RESUME for M-Audio 88es"),
> >>> reset the device on resume so this workaround is not needed any more.
> >>
> >> It is not feasible to add the IDs of all USB MIDI devices.
> >>
> >> I'm working on a fix that adds proper power management for input ports,
> >> but this requires the driver to be reorganized a little ...
> >
> > Doesn't a simple patch like below work?
> 
> > +static int substream_open(struct snd_rawmidi_substream *substream, int 
> > open)
> >  {
> > +   if (open && umidi->opened++ == 0) {
> > +   err = usb_autopm_get_interface(umidi->iface);
> >
> >  static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
> >  {
> > +   return substream_open(substream, 1);
> 
> No, because the input URBs are submitted before the userspace device is
> opened.  (And usb_autopm_get_interface() cannot be called from the USB
> probe callback.)

Ah, right.  What's the reason of submitting input urbs for the all
time from the beginning?  For loopback?

If it has to be running, the easiest fix would be the patch like
below.  This will turn off the autopm essentially, but better than
breakage.


Takashi

---
diff --git a/sound/usb/midi.c b/sound/usb/midi.c
index eeefbce..66acccb 100644
--- a/sound/usb/midi.c
+++ b/sound/usb/midi.c
@@ -175,6 +175,7 @@ struct snd_usb_midi_in_endpoint {
u8 seen_f5;
u8 error_resubmit;
int current_port;
+   bool autopm_reference;
 };
 
 static void snd_usbmidi_do_output(struct snd_usb_midi_out_endpoint* ep);
@@ -2065,6 +2066,8 @@ void snd_usbmidi_input_stop(struct list_head* p)
if (ep->in)
for (j = 0; j < INPUT_URBS; ++j)
usb_kill_urb(ep->in->urbs[j]);
+   if (ep->autopm_reference)
+   usb_autopm_put_interface(umidi->iface);
}
 }
 
@@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct 
snd_usb_midi_in_endpoint* ep)
 
if (!ep)
return;
+   ep->autopm_reference =
+   usb_autopm_get_interface(ep->umidi->iface) >= 0;
for (i = 0; i < INPUT_URBS; ++i) {
struct urb* urb = ep->urbs[i];
urb->dev = ep->umidi->dev;
--
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] fs: configfs: programmatically create config groups

[Michal Nazarewicz]

On Mon, Nov 26 2012, Andrzej Pietrasiewicz  wrote:
> In some parts of the kernel (e.g. planned configfs integration into usb
> gadget) there is a need to programmatically create config groups
> (directories) but it would be preferable to disallow creating them by
> the user. This is more or less what default_groups used to be for.
> But e.g. in the mass storage gadget, after storing the number of
> luns (logical units) into some configfs attribute, the corresponding lun#
> directories should be created, their number is not known up front so
> default_groups are no good for this.
>
> Example:
>
> $ echo 3 > /cfg//mass_storage/luns
>
> causes
>
> /cfg/../mass_storage/lun0
> /cfg/../mass_storage/lun1
> /cfg/../mass_storage/lun2
>
> to be created. Yet
>
> $ mkdir /cfg//mass_storage/
>
> should not be allowed.
>
> With create_group exported it is very easily achieved: make_group and 
> make_item
> are set to NULL in mass_storage's config_group, yet the kernel can
> create_groups at will.

I think the above description should be part of the commit message. :)

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpWFkUxt36iS.pgp
Description: PGP signature

Re: [PATCH] Patch for clearing PRC bit in PORTSC register at the time of XHCI driver insertion

[Bhavik Kothari]

Hi Greg & Sarah,

Would please tell us, what should be approach now?

If possible, Sarah, would you please give us the Patch to clear all bits
in xhci_reset()?


Thanks,
Bhavik Kothari


> On Mon, Nov 19, 2012 at 6:59 PM, Bhavik Kothari
>  > wrote:
> 
> Hi Sarah,
> 
> Please find answers as aligned,
> 
> On Fri, Nov 16, 2012 at 11:36 PM, Sarah Sharp
>  > wrote:
> 
> On Fri, Nov 16, 2012 at 10:19:01AM -0500, Alan Stern wrote:
> > On Thu, 15 Nov 2012, Greg KH wrote:
> >
> > > On Wed, Nov 07, 2012 at 06:36:46PM +0530, Bhavik Kothari wrote:
> > > > Hi Greg,
> > > >
> > > > Our host controller sets PRC and CSC bits at the time of
> initialization
> > > > even though no USB device is attached. At the time of
> initialization,
> > > > hub_probe() gets called and in-turn it calls hub_activate().
> > > > hub_activate() clears the CSC bit, but PRC bit does not
> get cleared (in
> > > > linux 3.6.1). hub_events() has functionality to clear the
> PRC bit, but
> > > > initially there is no events from HUB, so hub_events() may
> not clear the
> > > > PRC bit. Due to this behavior, when we try to insert a USB
> device,
> > > > interrupt does not generate (because, earlier, PRC bit was
> set and not
> > > > cleared) and USB device does not get enumerated.
> 
> Does your host controller wait until the port reset is complete
> (and the
> PRC or BH reset change bits are set) before clearing CMD_RESET?
> 
>  
> No, our Host controller does not wait till PRC or BH bit gets set.
> However, these bits need to be clear to get an event from the root
> hub port. 
> 
>  
> 
> > > > Below Patch allows to clear PRC bit in hub_activate()
> function. So,
> > > > above issue gets resolved.
> > > >
> > > > This patch is currently against a linux 3.6.1 kernel, for
> the x86
> > > > architecture.
> > >
> > > The USB code works on all architectures :)
> > >
> > > > Let me know in case of any concern.
> > >
> > > So why do this on all host controllers?  Why not just clear
> the bit for
> > > your devices based on a device id or some other identifier?
>  What
> > > happens if you clear this on a different manufacturer's device?
> >
> > This bit should never be set at this time, regardless of the
> > manufacturer.  It's okay to clear it always.
> >
> > A question remains as to whether more should be done in
> xhci-hcd for
> > controllers that start out in similar weird states.
> 
> All xHCI host controllers are supposed to issue a port reset on
> a host
> controller reset.  The xHCI driver issues a host reset as part of
> initialization.
> 
> As Alan said, I don't think this belongs in hub_activate.
>  External USB
> 3.0 hubs don't automatically reset their ports as part of a hub
> reset,
> so they should not have their port reset bits set.  We shouldn't put
> code that is specific for the xHCI roothub in hub_activate.
>  Instead, we
> should clear these bits in xhci_reset.
> 
> Note that this patch is not complete.  A hot reset can migrate
> to a warm
> reset, which would cause the BH reset change bit to be set as
> well as
> the port reset change bit.  xhci_reset needs to clear both bits.
> 
> 
> hub_activate() has handling to clear the BH bit too.
> 
> 
> > > Also, I would like to get an ack from Alan on this before I
> accept it.
> >
> > The patch is okay with me.  But we should get Sarah's opinion too.
> >
> > Acked-by: Alan Stern  >
> 
> Nak until this code moves to xhci_reset.
> 
> Sarah Sharp
> 
> 
> According to spec, section 4.19.1.2.3 Disconnected (initially host
> controller should be in Disconnected), "An xHC implementation may
> assert WPR or PR to reflect the associated reset operation if HCRST
> is asserted while the port is in the Disconnected state." So, if
> hub_activate() clears PR bit, then it may not create any problem.
> 
> Please let us know, what should be the proper approach to clear PR bit.
> 
> Thanks,
> Bhavik Kothari


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

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
>> Takashi Iwai wrote:
>>> Clemens Ladisch wrote:
 I'm working on a fix that adds proper power management for input ports,
 but this requires the driver to be reorganized a little ...
>>>
>>> Doesn't a simple patch like below work?
>>
>>> +static int substream_open(struct snd_rawmidi_substream *substream, int 
>>> open)
>>>  {
>>> +   if (open && umidi->opened++ == 0) {
>>> +   err = usb_autopm_get_interface(umidi->iface);
>>>
>>>  static int snd_usbmidi_input_open(struct snd_rawmidi_substream *substream)
>>>  {
>>> +   return substream_open(substream, 1);
>>
>> No, because the input URBs are submitted before the userspace device is
>> opened.
>
> Ah, right.  What's the reason of submitting input urbs for the all
> time from the beginning?  For loopback?

For not needing to count open input ports.

> If it has to be running, the easiest fix would be the patch like
> below.  This will turn off the autopm essentially, but better than
> breakage.
>
> @@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct 
> snd_usb_midi_in_endpoint* ep)
>
> + ep->autopm_reference =
> + usb_autopm_get_interface(ep->umidi->iface) >= 0;

usb_autopm_get_interface() cannot be called from the USB probe callback.


Regards,
Clemens
--
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 4/5] smsc95xx: refactor entering suspend modes

[Bjørn Mork]

[adding linux-usb to CC as this is very USB specific]

Steve Glendinning  writes:

> + smsc95xx_set_feature(dev, USB_DEVICE_REMOTE_WAKEUP);

That does look a bit strange to me.  This is a USB interface driver.
The USB device is handled by the generic "usb" USB device driver, which
will DTRT for you.  I don't think you need to set any USB device
features here.

Sorry for not commenting on this earlier It took me a while to
understand why that part surprised me.


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: cdc-acm and remote wakeup

[Oliver Neukum]

On Monday 26 November 2012 13:29:09 Daniele Palmas wrote:

> Ok. Do you have any hint for adding the code in the proper place?

First we need to define a new quirk.
 
> >> According to the USB 2.0 specs it seems to me that this feature should
> >> be always requested when suspending a device, so probably the driver
> >> behavior is not correct.
> >
> > Hm. Which part of the spec do you base this on?
> >
> 
> The doc is "Universal Serial Bus Specification" revision 2.0 paragraph
> 10.5.4.5, if I am not misunderstanding the topic.
> 
> Here
> 
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff537628%28v=vs.85%29.aspx
> 
> there is an interpretation coming from Microsoft
> 
> "In USB terminology, a USB device is enabled for remote wakeup when
> its DEVICE_REMOTE_WAKEUP feature is set. The USB specification
> specifies that host software must set the remote wakeup feature on a
> device "only just prior" to putting the device to sleep."

Well, that tells us when to set DEVICE_REMOTE_WAKEUP, if we want remote
wakeup, not whether we want it at all.

> Modem is registered to the network. Host suspended, I want my device
> to wake up the host when it receives, for example, a call or an sms.

If you want a device to wake up the system, you need to declare it
a wakeup source in sysfs.

> This doesn't happen if the driver doesn't send the
> DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
> is bricked.

That is not good.

> I understand that probably there are problems in the firmware of the
> modem (because it should not brick), but I'm trying to find a
> workaround to have things working.

I am attaching a patch to introduce a new quirk type. You need to add
your device to the list of quirky devices in drivers/usb/core/quirks.c
with the new quirk type.
You cannot solve this in the cdc-acm driver because there is an
unsolvable race if your system is suspended after the device is enumerated
but before the driver is loaded.

Would you test this?

Regards
Oliver

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 6056db7..094c3c9 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1097,7 +1097,10 @@ static int usb_suspend_device(struct usb_device *udev, pm_message_t msg)
 	if (udev->dev.driver)
 		udriver = to_usb_device_driver(udev->dev.driver);
 	else {
-		udev->do_remote_wakeup = 0;
+		if (udev->quirks & USB_QUIRK_NEEDS_REMOTE_WAKEUP)
+			udev->do_remote_wakeup = 1;
+		else
+			udev->do_remote_wakeup = 0;
 		udriver = &usb_generic_driver;
 	}
 	status = udriver->suspend(udev, msg);
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 52f944d..a5d1995 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -30,4 +30,7 @@
descriptor */
 #define USB_QUIRK_DELAY_INIT		0x0040
 
+/* device requires remote wakeup to survive suspend/resume */
+#define USB_QUIRK_NEEDS_REMOTE_WAKEUP	0x0080
+
 #endif /* __LINUX_USB_QUIRKS_H */

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Oliver Neukum]

On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:

> > If it has to be running, the easiest fix would be the patch like
> > below.  This will turn off the autopm essentially, but better than
> > breakage.
> >
> > @@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct 
> > snd_usb_midi_in_endpoint* ep)
> >
> > +   ep->autopm_reference =
> > +   usb_autopm_get_interface(ep->umidi->iface) >= 0;
> 
> usb_autopm_get_interface() cannot be called from the USB probe callback.

You can use usb_autopm_get_interface_no_resume()
During probe() the device is known to not be suspended.

Regards
Oliver

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

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Takashi Iwai]

At Mon, 26 Nov 2012 14:43:13 +0100,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > Clemens Ladisch wrote:
> >> Takashi Iwai wrote:
> >>> Clemens Ladisch wrote:
>  I'm working on a fix that adds proper power management for input ports,
>  but this requires the driver to be reorganized a little ...
> >>>
> >>> Doesn't a simple patch like below work?
> >>
> >>> +static int substream_open(struct snd_rawmidi_substream *substream, int 
> >>> open)
> >>>  {
> >>> + if (open && umidi->opened++ == 0) {
> >>> + err = usb_autopm_get_interface(umidi->iface);
> >>>
> >>>  static int snd_usbmidi_input_open(struct snd_rawmidi_substream 
> >>> *substream)
> >>>  {
> >>> + return substream_open(substream, 1);
> >>
> >> No, because the input URBs are submitted before the userspace device is
> >> opened.
> >
> > Ah, right.  What's the reason of submitting input urbs for the all
> > time from the beginning?  For loopback?
> 
> For not needing to count open input ports.

So we've spun urbs for all the time just for reducing refcount?
That's bad.

> > If it has to be running, the easiest fix would be the patch like
> > below.  This will turn off the autopm essentially, but better than
> > breakage.
> >
> > @@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct 
> > snd_usb_midi_in_endpoint* ep)
> >
> > +   ep->autopm_reference =
> > +   usb_autopm_get_interface(ep->umidi->iface) >= 0;
> 
> usb_autopm_get_interface() cannot be called from the USB probe callback.

OK, it can call no_resume version by passing an argument.

But judging from your comment above, we should fix the free wheel MIDI
input urbs at first indeed, not only for autopm but in general.


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

Re: [PATCH 01/27] usb: gadget: mv_udc: use udc_start and udc_stop functions

[Greg KH]

On Sun, Nov 25, 2012 at 11:43:14PM -0500, Chao Xie wrote:
> From: Chao Xie 
> 
> This patches converts the driver into the new style start/stop
> interface. As a result the driver no longer uses the static
> global the_conroller variable.
> 
> Signed-off-by: Chao Xie 

How come your signed-off-by address does not match your "From:" address
on the patch?  The marvell.com address should be both here, right?

Please fix that.

thanks,

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

Re: [PATCH 01/27] usb: gadget: mv_udc: use udc_start and udc_stop functions

[Felipe Balbi]

Hi,

On Mon, Nov 26, 2012 at 06:39:36AM -0800, Greg KH wrote:
> On Sun, Nov 25, 2012 at 11:43:14PM -0500, Chao Xie wrote:
> > From: Chao Xie 
> > 
> > This patches converts the driver into the new style start/stop
> > interface. As a result the driver no longer uses the static
> > global the_conroller variable.
> > 
> > Signed-off-by: Chao Xie 
> 
> How come your signed-off-by address does not match your "From:" address
> on the patch?  The marvell.com address should be both here, right?

And how come I wasn't in Cc ???

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Roger Quadros]

Felipe,

On 11/21/2012 03:39 PM, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
>> All ports have similarly named port clocks so we can
>> bunch them into a port data structure and use for loop
>> to enable/disable the clocks.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/mfd/omap-usb-host.c |  208 
>> +--
>>  1 files changed, 101 insertions(+), 107 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 23cec57..7303c41 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -76,6 +76,8 @@
>>  
>>  #define OMAP_UHH_DEBUG_CSR  (0x44)
>>  
>> +#define MAX_HS_USB_PORTS3   /* Increase this if any chip has more */
>> +
>>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
>>  #define OMAP_USBHS_REV1 0x0010  /* OMAP3 */
>>  #define OMAP_USBHS_REV2 0x50700100  /* OMAP4 */
>> @@ -87,14 +89,15 @@
>>  #define is_ehci_tll_mode(x) (x == OMAP_EHCI_PORT_MODE_TLL)
>>  #define is_ehci_hsic_mode(x)(x == OMAP_EHCI_PORT_MODE_HSIC)
>>  
>> +struct usbhs_port {
>> +struct clk  *utmi_clk;
>> +};
> 
> I rather not since this will make it a lot more difficult to use
> pm_clk_add() :-s Also, this sort of thing should be dynamically
> allocated anyway ;-)
> 

Why do you say so? The whole point of this patch is to group similarly
named clocks so that we can use a for loop and set number of ports (or
clocks) dynamically. I suppose it would be just a matter of replacing
clk_enable/disable() with pm_clk_add() later, right?

If you see patch 11, we are adding 2 HSIC related clocks to this
structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
managed using a simple for loop instead of coding each clock name by hand.

--
cheers,
-roger
--
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: Any followups concerning: cannot submit urb 0, error -22: internal error followed by USB hung tasks

[Oliver Neukum]

On Friday 23 November 2012 11:42:02 Alan Stern wrote:
> On Fri, 23 Nov 2012, Oliver Neukum wrote:
> 
> > Hi Alan,
> > 
> > did you ever recieve any feedback concerning the patch you wrote
> > the patch in the message mentioned above for? I am getting reports
> > from customers that it fixes issues with NVIDIA chipsets.
> 
> You mean the patch I posted on Oct. 9?  No, no feedback.  If people say 
> that it fixes problems, I'm willing to submit it to Greg.  Can we get 
> any Tested-by's?

Sure, it solves the problem. What is the impact on performance?
Should it be restricted to affected systems?

Regards
Oliver

Tested-by: Oliver Neukum 
--
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 5/7] usb: chipidea: usbmisc: add support for ahb, ipg and per clock

[Michael Grzeschik]

On Sun, Nov 25, 2012 at 05:18:35PM +0800, Peter Chen wrote:
> On Fri, Nov 23, 2012 at 05:20:51PM +0100, Michael Grzeschik wrote:
> > > usbphy: used to transfer data
> > > (like your per)
> > 
> > The "per" clk is a different clk than the usbphy. We have an usbphy clk
> > aswell on the mx5x. As discussed before [1], we need a solution to enable
> > the usbphy clk. The current approach is to let the nop-xceiver enable
> > this.
> > 
> > [1] http://www.spinics.net/lists/linux-usb/msg74489.html
> It does not matter which the name is, this clock is related to usb 480M or 
> its source. We use nop-xceiver is just to create struct usb_otg
> and usb_phy. Clock information can be at imx specific file like
> cil13xxx_imx.

I think the clock task needs to become a sepreate topic, apart from this
series.

> > 
> > > mx6q:
> > > - usboh3(Index 162 at DT), used to access register
> > > - usbphy(Index 182 for otg port at DT), at phy controller
> > 
> > > So, we may consider a way to consolidate both mx6q (mx28) and mxc (mx5x, 
> > > mx3x)
> > > platforms.
> > 
> > Yes, we will discuss a real clktree solution in the usbmisc driver for
> > the different cores. The first thoughts are, that the clk configuration
> > has completely to be done inside the usbmisc driver. For this, the
> > usbmisc needs to become a hard dependency for the ci13xxx_imx glue code.
> 
> For my mind, imx usb clock handling is better only at place, that is
> cil13xxx_imx. We can have imx_clk_enable and imx_clk_disable in it,
> and handling clk in imx_clk_enable using id_table or what else platform
> specific.

As already mentioned, the clock layout differs from SoC to SoC.
Therefore the usbmisc can become a mandatory instance over the
ci13xxx_imx instances in all imx cases. This controlling interface can
define the special clock setups and connection types for the underlying
usb cores.

I will send the next series without this clock handling.

Regards,
Michael

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

Re: USB audio device

[Alan Stern]

On Sat, 24 Nov 2012, Jim Passmore wrote:

> On Sat, Nov 24, 2012 at 6:08 PM, Oliver Neukum  wrote:
> >> NVIDIA Corporation MCP61 USB Controller, rev a3
> >
> > Known problematic controller:
> > http://www.mail-archive.com/linux-usb@vger.kernel.org/msg07227.html
> 
> Well, that's a heck of a thread.  Skimmed through it, and never found
> anything that I would have searched for, so thanks for replying.
> 
> Interesting description/solution.  Remembered the digital camera my
> wife uses produces similar response, so I assume it's the same
> problem.  As someone who knows nothing about hardware drivers, it's
> surprising your patch doesn't actually mention the chipset(s) or the
> device I was connecting!

The problem could potentially apply to any full-speed device.  And
there was no point in mentioning the chipset, because the person I 
mailed the patch to already knew what sort of chipset he has.

> So about the patch--
> --Still testing, or accepted?  Is there some place to follow to know
> when the patch becomes part of the standard kernel?

Until Oliver mentioned it a few days ago, I had not received any test 
reports for this patch.  The place to follow is right here, the 
linux-usb mailing list.

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: d3cold breaks my usb 3.0 port (Lenovo X220)

[Alan Stern]

On Sun, 25 Nov 2012, Andrew Lutomirski wrote:

> Here's lots of lots with debugging and notes.  Turning off runtime
> suspend isn't helping any more.  This stick still works fine on a
> non-USB3 port.
> 
> Notes from me start with ***.

...

> [   44.856520] xhci_hcd :0e:00.0: set port remote wake mask,
> actual port 0 status  = 0xe0002a0
> [   44.856546] xhci_hcd :0e:00.0: set port remote wake mask,
> actual port 1 status  = 0xe0002a0
> [   44.856555] hub 4-0:1.0: hub_suspend
> [   44.856561] usb usb4: bus auto-suspend, wakeup 1
> [   44.857631] xhci_hcd :0e:00.0: // Setting command ring address
> to 0x36807001
> [   44.857705] xhci_hcd :0e:00.0: hcd_pci_runtime_suspend: 0
> [   61.720382] xhci_hcd :0e:00.0: Poll event ring: 4294728960
> [   61.720394] xhci_hcd :0e:00.0: op reg status = 0x
> [   61.720398] xhci_hcd :0e:00.0: HW died, polling stopped.

That certainly looks bad.  Maybe it's not quite as bad as it looks, 
though.

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: cdc-acm and remote wakeup

[Daniele Palmas]

2012/11/26 Oliver Neukum :
> On Monday 26 November 2012 13:29:09 Daniele Palmas wrote:
>
>> Ok. Do you have any hint for adding the code in the proper place?
>
> First we need to define a new quirk.
>
>> >> According to the USB 2.0 specs it seems to me that this feature should
>> >> be always requested when suspending a device, so probably the driver
>> >> behavior is not correct.
>> >
>> > Hm. Which part of the spec do you base this on?
>> >
>>
>> The doc is "Universal Serial Bus Specification" revision 2.0 paragraph
>> 10.5.4.5, if I am not misunderstanding the topic.
>>
>> Here
>>
>> http://msdn.microsoft.com/en-us/library/windows/hardware/ff537628%28v=vs.85%29.aspx
>>
>> there is an interpretation coming from Microsoft
>>
>> "In USB terminology, a USB device is enabled for remote wakeup when
>> its DEVICE_REMOTE_WAKEUP feature is set. The USB specification
>> specifies that host software must set the remote wakeup feature on a
>> device "only just prior" to putting the device to sleep."
>
> Well, that tells us when to set DEVICE_REMOTE_WAKEUP, if we want remote
> wakeup, not whether we want it at all.
>

I see the point: to me having the device able to remote wakeup the
system was a direct consequence of going into suspend state, but
probably this is not the desired behaviour for all the situations.

Aside the specific quirk of my modem, at the moment is there the
possibility to tell the driver (or the usb stack) if we want this
request to be sent or not?

>> Modem is registered to the network. Host suspended, I want my device
>> to wake up the host when it receives, for example, a call or an sms.
>
> If you want a device to wake up the system, you need to declare it
> a wakeup source in sysfs.
>
>> This doesn't happen if the driver doesn't send the
>> DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
>> is bricked.
>
> That is not good.
>

So is it not enough to put "enabled" in the correct device of
/proc/acpi/wakeup ?

>> I understand that probably there are problems in the firmware of the
>> modem (because it should not brick), but I'm trying to find a
>> workaround to have things working.
>
> I am attaching a patch to introduce a new quirk type. You need to add
> your device to the list of quirky devices in drivers/usb/core/quirks.c
> with the new quirk type.
> You cannot solve this in the cdc-acm driver because there is an
> unsolvable race if your system is suspended after the device is enumerated
> but before the driver is loaded.
>
> Would you test this?
>

Thanks for you patch, I will try it as soon as possible.

Regards,
Daniele
--
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: cdc-acm and remote wakeup

[Alan Stern]

On Mon, 26 Nov 2012, Daniele Palmas wrote:

> Maybe I have to explain better my scenario:
> 
> Modem is registered to the network. Host suspended, I want my device
> to wake up the host when it receives, for example, a call or an sms.

What if the modem isn't registered to the network?  For example, if the 
cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled 
then?

> This doesn't happen if the driver doesn't send the
> DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
> is bricked.

Are you sure that "bricked" is the right word?  It means that the 
modem's firmware got corrupted so that it is impossible ever to use the 
modem again unless an EPROM chip is replaced.  Maybe you just meant 
that the modem crashed.

Alan Stern

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

Re: USB 2.0: No giveback comes for one submitted URB

[Alan Stern]

On Mon, 26 Nov 2012, naveen yadav wrote:

> Dear Alan,
> 
> Thanks for your reply ,
> 
> We check on 3.2.34 and 3.6.7 on X86 host machine. and result is same
> without connecting Bluetooth device.
> I am attaching log

Yes, very good.  But you still have to do what I mentioned in my
earlier email:

> On Thu, Nov 22, 2012 at 9:08 PM, Alan Stern  wrote:

> > Now you need to find out what other code has changed urb->use_count and
> > fix it.

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: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Alan Stern]

On Mon, 26 Nov 2012, Oliver Neukum wrote:

> On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
> 
> > > If it has to be running, the easiest fix would be the patch like
> > > below.  This will turn off the autopm essentially, but better than
> > > breakage.
> > >
> > > @@ -2074,6 +2077,8 @@ static void snd_usbmidi_input_start_ep(struct 
> > > snd_usb_midi_in_endpoint* ep)
> > >
> > > + ep->autopm_reference =
> > > + usb_autopm_get_interface(ep->umidi->iface) >= 0;
> > 
> > usb_autopm_get_interface() cannot be called from the USB probe callback.
> 
> You can use usb_autopm_get_interface_no_resume()
> During probe() the device is known to not be suspended.

In fact, as far as I know you _can_ use usb_autopm_get_interface() from
within a probe routine.  Is there some problem with it I'm not aware of?

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: cdc-acm and remote wakeup

[Alan Stern]

On Mon, 26 Nov 2012, Oliver Neukum wrote:

> > I understand that probably there are problems in the firmware of the
> > modem (because it should not brick), but I'm trying to find a
> > workaround to have things working.
> 
> I am attaching a patch to introduce a new quirk type. You need to add
> your device to the list of quirky devices in drivers/usb/core/quirks.c
> with the new quirk type.
> You cannot solve this in the cdc-acm driver because there is an
> unsolvable race if your system is suspended after the device is enumerated
> but before the driver is loaded.

There are some problems in your patch.  For one thing, you prevented
do_remote_wakeup from being turned off in an unlikely path, but you
never turned it on in the likely path.  For another, it's impossible to
enable remote wakeup for an unconfigured 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: Any followups concerning: cannot submit urb 0, error -22: internal error followed by USB hung tasks

[Alan Stern]

On Mon, 26 Nov 2012, Oliver Neukum wrote:

> On Friday 23 November 2012 11:42:02 Alan Stern wrote:
> > On Fri, 23 Nov 2012, Oliver Neukum wrote:
> > 
> > > Hi Alan,
> > > 
> > > did you ever recieve any feedback concerning the patch you wrote
> > > the patch in the message mentioned above for? I am getting reports
> > > from customers that it fixes issues with NVIDIA chipsets.
> > 
> > You mean the patch I posted on Oct. 9?  No, no feedback.  If people say 
> > that it fixes problems, I'm willing to submit it to Greg.  Can we get 
> > any Tested-by's?
> 
> Sure, it solves the problem. What is the impact on performance?

The impact ought to be minimal.

> Should it be restricted to affected systems?

I don't see any need to restrict it.

>   Regards
>   Oliver
> 
> Tested-by: Oliver Neukum 

Okay, thanks.  I'll submit the patch.  Too bad it isn't a complete
solution to the problem.

Alan Stern

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

Re: [RFC PATCH 4/5] omap4: panda: add smsc95xx regulator and reset dependent on root hub

[Roger Quadros]

Hi Andy,

On 11/26/2012 02:45 PM, Andy Green wrote:
> This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
> EHCI logical root hub existing.
> 
> Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
> all the time, which is around the same as the idle power of the SoC and
> rest of the board.
> 
> This allows us to start off with it depowered, and only power it if the
> ehci-hcd module is inserted.  When the module is removed, it's depowered
> again.
> 
> Signed-off-by: Andy Green 
> ---
>  arch/arm/mach-omap2/Kconfig|1 
>  arch/arm/mach-omap2/board-omap4panda.c |   90 
> +---
>  2 files changed, 72 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index d669e22..5105109 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -368,6 +368,7 @@ config MACH_OMAP4_PANDA
>   select OMAP_PACKAGE_CBL
>   select OMAP_PACKAGE_CBS
>   select REGULATOR_FIXED_VOLTAGE if REGULATOR
> + select USB_HUB_DEVICE_PATH_REGULATOR
>  
>  config OMAP3_EMU
>   bool "OMAP3 debugging peripherals"
> diff --git a/arch/arm/mach-omap2/board-omap4panda.c 
> b/arch/arm/mach-omap2/board-omap4panda.c
> index bfcd397..b032b6b 100644
> --- a/arch/arm/mach-omap2/board-omap4panda.c
> +++ b/arch/arm/mach-omap2/board-omap4panda.c
> @@ -154,11 +154,6 @@ static const struct usbhs_omap_board_data usbhs_bdata 
> __initconst = {
>   .reset_gpio_port[2]  = -EINVAL
>  };
>  
> -static struct gpio panda_ehci_gpios[] __initdata = {
> - { GPIO_HUB_POWER,   GPIOF_OUT_INIT_LOW,  "hub_power"  },
> - { GPIO_HUB_NRESET,  GPIOF_OUT_INIT_LOW,  "hub_nreset" },
> -};
> -
>  static void __init omap4_ehci_init(void)
>  {
>   int ret;
> @@ -173,23 +168,76 @@ static void __init omap4_ehci_init(void)
>   clk_set_rate(phy_ref_clk, 1920);
>   clk_prepare_enable(phy_ref_clk);
>  
> - /* disable the power to the usb hub prior to init and reset phy+hub */
> - ret = gpio_request_array(panda_ehci_gpios,
> -  ARRAY_SIZE(panda_ehci_gpios));
> - if (ret) {
> - pr_err("Unable to initialize EHCI power/reset\n");
> - return;
> - }
> + usbhs_init(&usbhs_bdata);
> +}
>  
> - gpio_export(GPIO_HUB_POWER, 0);
> - gpio_export(GPIO_HUB_NRESET, 0);
> - gpio_set_value(GPIO_HUB_NRESET, 1);
> +/*
> + * hub_nreset also resets the ULPI PHY and is required after powering SMSC 
> chip
> + *   ULPI PHY is always powered... need to do reset once for both once
> + * hub_power enables a 3.3V regulator for (hub + eth) chip
> + *   however there's no point having ULPI PHY in use alone
> + *   since it's only connected to the (hub + eth) chip
> + */
>  
> - usbhs_init(&usbhs_bdata);
> +static struct regulator_init_data panda_hub = {
> + .constraints = {
> + .name = "vhub",
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + },
> +};
>  
> - /* enable power to hub */
> - gpio_set_value(GPIO_HUB_POWER, 1);
> -}
> +static struct fixed_voltage_config panda_vhub = {
> + .supply_name = "vhub",
> + .microvolts = 330,
> + .gpio = GPIO_HUB_POWER,
> + .startup_delay = 7, /* 70msec */
> + .enable_high = 1,
> + .enabled_at_boot = 0,
> + .init_data = &panda_hub,
> +};
> +
> +static struct platform_device omap_vhub_device = {
> + .name   = "reg-fixed-voltage",
> + .id = 2,
> + .dev = {
> + .platform_data = &panda_vhub,
> + },
> +};
> +
> +static struct regulator_init_data panda_ulpireset = {
> + /*
> +  * idea is that when operating ulpireset, regulator api will make
> +  * sure that the hub+eth chip is powered, since it's the "parent"
> +  */
> + .supply_regulator = "vhub", /* we are a child of vhub */
> + .constraints = {
> + /*
> +  * this magic string associates us with ehci-omap.0 root hub
> +  * when the root hub logical device is up, we will power
> +  * and reset [ ULPI PHY + [ HUB + ETH ] ]
> +  */
> + .name = "/platform/usbhs_omap/ehci-omap.0/usb*",
> + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> + },
> +};
> +
> +static struct fixed_voltage_config panda_vulpireset = {
> + .supply_name = "/platform/usbhs_omap/ehci-omap.0/usb*",

Does this supply_name really needs to be the magic string?

> + .microvolts = 330,
> + .gpio = GPIO_HUB_NRESET,
> + .startup_delay = 7, /* 70msec */
> + .enable_high = 1,
> + .enabled_at_boot = 0,
> + .init_data = &panda_ulpireset,
> +};
> +
> +static struct platform_device omap_vulpireset_device = {
> + .name   = "reg-fixed-voltage",
> + .id = 3,
> + .dev = {
> + .platform_data = &panda_vulpireset,
> + },
> +};
>  
>  static struct omap_musb_board_data musb_

configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Sebastian Andrzej Siewior]

On 11/22/2012 09:59 PM, Michal Nazarewicz wrote:

echo MassStorage>  /cfg/usb-function-gadget/G1/C1/F1/name


Why not

mkdir /cfg/usb-function-gadget/G1/C1/F1/MassStorage

?


Let me add what I have in my head + what Michał said in other mail:

Lets assume we start at /sys/kernel/config/gadget and I don't mention
it here because I save keystrokes.

First we need a folder where we have a list of available UDCs:

/udcs/udc0
/udcs/udc1

And proper name of udc0 can be decided later on…


Step two is a folder where we setup individual configuration of a function.

/functions/ttyS0
/functions/ttyS1
/functions/storage

each one of the function folder has the file called "name". So for the
folder ttyS0 the file name contains "acm" because we use the ACM
function. The same is true for ttyS1 and for storage we write
"mass_storage" if that is what function will be called.

Alternative (my favorite): function_common-name
that would be

/functions/acm_ttyS0
/functions/acm_ttyS1
/functions/mass_storage_storage

So we avoid the _name_ file and it will be parsed from the directory 
name. That is what target/tcm does. You have

rd_mcp_X for a ramdisk and fileio_X for a file as backend.

After name is written it will request the module and special
configuration related files pop up. For ACM it will be almost nothing
while for storage we get nofua or something like that and we will be
able to create the lunX folder.


Step three ladies and gentleman.

/gadgets/gadget1/default-configuration
/gadgets/gadget1/hi-power-configuration

So what do we do here? Each directory created as a child of gadget1
(default-configuration in this example) will represent a configuration
descriptor. Within the configuration folder I would keep a file named
bConfigurationValue _or_ something else (like pre- or post fix for
default-configuration, note postfix here is my favorite again) so we
know how to sort configs IMHO this is important as the first config is
the default one.

In order to get any functions in here, we will symlink the ttyS0
function and others into "default-configuration" and /or hi-power-
configuration.
So we can have more than one function of one kind (i.e. multiple UART
ports) and we can distinguish between between those two.


Step four, link gadget1 to udc1
After that, we should be ready. So we could maybe avoid the avoid the
"ready" file. Obex has something like that where it disables the
function until userland is ready. Maybe we could remove ready and make
sure gadget1 is not linked to udc1 until user land is ready.



anyone?

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

Re: Mouse and keyboard freeze Ivy-bridge

[Alan Stern]

On Fri, 23 Nov 2012, Chris Holland wrote:

> On Fri, Nov 23, 2012 at 11:03 AM, Alan Stern  
> wrote:
> > On Thu, 22 Nov 2012, Chris Holland wrote:
> >
> >> https://bugzilla.kernel.org/show_bug.cgi?id=50821
> >>
> >>
> >> Summary: Mouse and keyboard freeze Ivy-bridge
> >> I have been having the problem of the mouse and keyboard freezing since
> >> upgrading my system in May 2012
> >>
> >> GIGABYTE GA-Z77X-UD5H LGA 1155 Intel Z77 HDMI SATA
> >> Intel Core i5-3550 Ivy Bridge
> >>
> >>
> >> Mouse and keyboard stop responding randomly. By using only the usb 
> >> connections
> >> on the motherboard it requires logging in by ssh to restart the computer or
> >> hard resetting. Unplugging and plugging the mouse or keyboard in has no 
> >> effect
> >> on the issue.
> >
> > Which USB controller were the mouse and keyboard plugged into?
> 
> They were plugged into the added pci controller. I have 2 sets of mice
> and keyboards plugged in 1 set to the pci card and 1 set to
> the motherboard.
> 
> It does not matter if its usb2 or usb3 ports you have them plugged
> into the motherboard when this happens they stop responding.
> And unplugging replugging has no effect. And running modprobe -r
> ehci_hcd && modprobe ehci_hcd results in
> FATAL: Module ehci_hcd is builtin

Can you supply similar logging information for the case where the 
mouse/keyboard is plugged into a USB-2 motherboard port?  Please 
include the contents of /sys/kernel/debug/usb/devices.

Alan Stern

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

Re: [RFC][PATCH] fs: configfs: programmatically create config groups

[Sebastian Andrzej Siewior]

On 11/26/2012 09:35 AM, Andrzej Pietrasiewicz wrote:

In some parts of the kernel (e.g. planned configfs integration into usb
gadget) there is a need to programmatically create config groups
(directories) but it would be preferable to disallow creating them by
the user. This is more or less what default_groups used to be for.
But e.g. in the mass storage gadget, after storing the number of
luns (logical units) into some configfs attribute, the corresponding lun#
directories should be created, their number is not known up front so
default_groups are no good for this.

Example:

$ echo 3>  /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


to be created. Yet

$ mkdir /cfg//mass_storage/

should not be allowed.

With create_group exported it is very easily achieved: make_group and make_item
are set to NULL in mass_storage's config_group, yet the kernel can
create_groups at will.

I kindly ask for comments. In particular, I would like to discuss
if this is the right approach. A counterpart to remove config groups
is also required. It is not implemented in this patch, though. What are
your opinions?


Could you please at the tcm gadget? This is a mass storage gadget using
target as backend and target is using configfs. Here is a snippet how
you setup it:

|mkdir -p $FABRIC/naa.6001405c3214b06a/tpgt_1
|mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_0
|mkdir $FABRIC/naa.6001405c3214b06a/tpgt_1/lun/lun_1

So you setup two luns without this patch. Would that work for you?

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

Re: cdc-acm and remote wakeup

[Daniele Palmas]

Hello Alan,

2012/11/26 Alan Stern :
> On Mon, 26 Nov 2012, Daniele Palmas wrote:
>
>> Maybe I have to explain better my scenario:
>>
>> Modem is registered to the network. Host suspended, I want my device
>> to wake up the host when it receives, for example, a call or an sms.
>
> What if the modem isn't registered to the network?  For example, if the
> cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled
> then?
>

That is a good question: in my specific scenario it is not useful to
have the remote wakeup enabled if the cdc-acm driver is unloaded. But,
though at the moment I cannot identify any, maybe there are situations
in which it is useful to have the remote wakeup enabled even if the
driver is not loaded.

>> This doesn't happen if the driver doesn't send the
>> DEVICE_REMOTE_WAKEUP request. Moreover without this request the modem
>> is bricked.
>
> Are you sure that "bricked" is the right word?  It means that the
> modem's firmware got corrupted so that it is impossible ever to use the
> modem again unless an EPROM chip is replaced.  Maybe you just meant
> that the modem crashed.
>

You are right, sorry for my poor English... The modem is crashed, but
after the device reset it still works.

Regards,
Daniele
--
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 6/7] usb: chipidea: usbmisc: add mx53 support

[Grant Likely]

On Sun, 25 Nov 2012 16:09:31 +0800, Peter Chen  wrote:
> On Fri, Nov 23, 2012 at 11:02:13AM +0100, Marc Kleine-Budde wrote:
> > On 11/23/2012 07:53 AM, Peter Chen wrote:
> > > On Wed, Nov 21, 2012 at 03:06:32PM +0100, Michael Grzeschik wrote:
> > >> This adds mx53 as the next user of the usbmisc driver and makes it
> > >> possible to disable the overcurrent-detection of the internal phy.
> > >>
> > >> Signed-off-by: Michael Grzeschik 
> > >> Signed-off-by: Marc Kleine-Budde 
> > >> ---
> > >> Changes since v2:
> > >> * added defines for register offsets and bitmasks
> > >> * fixed disable_oc option for all ports
> > >>
> > >>  drivers/usb/chipidea/usbmisc_imx.c |   51 
> > >> 
> > >>  1 file changed, 51 insertions(+)
> > >>
> > >> diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
> > >> b/drivers/usb/chipidea/usbmisc_imx.c
> > >> index e090e0f..b1811df 100644
> > >> --- a/drivers/usb/chipidea/usbmisc_imx.c
> > >> +++ b/drivers/usb/chipidea/usbmisc_imx.c
> > >> @@ -19,6 +19,13 @@
> > >>  
> > >>  #define USB_DEV_MAX 4
> > >>  
> > >> +#define MX53_USB_OTG_PHY_CTRL_0_OFFSET  0x08;
> > >> +#define MX53_USB_UH2_CTRL_OFFSET0x14;
> > >> +#define MX53_USB_UH3_CTRL_OFFSET0x18;
> > >> +#define MX53_BM_OVER_CUR_DIS_H1 BIT(5)
> > >> +#define MX53_BM_OVER_CUR_DIS_OTGBIT(8)
> > >> +#define MX53_BM_OVER_CUR_DIS_UHxBIT(30)
> > >> +
> > >>  #define MX6_BM_OVER_CUR_DIS BIT(7)
> > > 
> > > As every SoC platform's non-core register mapping is different,
> > > it is better to use .h to put register bit definition
> > 
> > AFAIK in the kernel we don't make extra .h files any more, if there is
> > only a single user of the contents.
> OK, if it is the current rule for kernel, then just keep it.
> My original mind was there will be more and more bit definition
> in future, and move it to .h to make the code clean and short.

Yeah. If there is only one user then keep it in the .c file. The kernel
is huge, so keeping things out of the global scope is a GoodThing(tm).

g.

--
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: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget

[Sebastian Andrzej Siewior]

On 11/23/2012 12:52 PM, Andrzej Pietrasiewicz wrote:

The general idea is that:

echo "some_name">  /cfg/usb-function-gadget/G1/C1/F1/name
echo "some_name">  /cfg/usb-function-gadget/G1/C2/F1/name

creates two separate instances of F1 in C1 and C2. Did you mean
the same instance of F1 used both in C1 and C2?

Anyway, since Michał proposed some alternative this scheme is
likely to be revised.


I posted something as well, please take a look at it.


/cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81
/cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81/attributes
/cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81/endpoint_addre
ss /cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81/interval
/cfg/usb-function-gadget/G1/C1/F1/interface00/endpoint81/max_packet_siz
e


Interresting. I have no idea if I do like or I don't. Some minor things:
You do have endpoint02 and you have endpoint_address. I guess
endpoint_address here reads 2. So I think this attribute is read only.
Same goes for max_packet_size since this is usually protocol specific.



Once upon a time Felipe expressed interest in having all these accessible
from userspace (e.g. for debugging purposes) so here it is.
Meant to be read-only.


Okay.


+config USB_FG
+   tristate "USB Functions Gadget (EXPERIMENTAL)"
+   select USB_LIBCOMPOSITE
+   depends on EXPERIMENTAL&&  CONFIGFS_FS


EXPERIMENTAL is going away. It is no longer under drivers/usb.



Anything else instead perhaps?


Nothing actually.


+   help
+ USB Functions Gadget is a device which aggregates a number of
+ USB functions. The gadget is composed by userspace through a
+ configfs interface, which enables specifying what USB
+ configurations the gadget is composed of, what USB functions
+ a USB configuration is composed of and enabling/disabling
+ the gadget.


It would be nice to point to Documentation/usb/file-with-examples.txt


You can expect it in the next version.


Yeah but easy. I have no problem with adding that file once we have
something file as you better things to do than updating the
documentation every second.


diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index fef41f5..09faa34 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_USB_MV_U3D)  += mv_u3d_core.o
#
# USB gadget drivers
#
+g_usb_functions-y  := usb_functions.o
g_zero-y:= zero.o
g_audio-y   := audio.o
g_ether-y   := ether.o
@@ -56,6 +57,7 @@ g_ncm-y   := ncm.o
g_acm_ms-y  := acm_ms.o
g_tcm_usb_gadget-y  := tcm_usb_gadget.o

+obj-$(CONFIG_USB_FG)   += g_usb_functions.o


Don't use this indirection and I don't see a reason why you shouldn't drop
the g_ at the beginning. After all this will not be a gadget but an
interface to create gadgets.



This calls for a discussion: where actually this kind of code should be
located? usb_functions.c or similar? composite.c?


Keep a separate file next to composite/functions but in the end I would
merge it some place if it fits. The same goes for the config option
because ideally there is no way without configfs :)


+static struct config_group *ufg_make_function_subgroup(
+   struct config_group *group, const char *name) {
+   struct ufg_function_grp *f_grp;
+   struct config_group *result;
+
+   /*
+* TODO:
+*
+* This makes "interface" an illegal name for a function.
+*/
+   if (!strncmp(name, "interface", 9)) {


Can't you use something else to match between function&  interface?
After all you know that gadget's parent has to be a "config"-folder,
followed by an interface, followed by the function.



I could have used another level of nesting, where by default there are

/cfg./C1/F1/name
/cfg./C1/F1/function/
/cfg./C1/F1/interfaces/

and

echo "some_name">  /cfg./C1/F1/name

creates

/cfg./C1/F1/function/some_name
/cfg./C1/F1/function/some_name/function-specific-stuff

and later binding the gadget creates

/cfg./C1/F1/interfaces/interface00

In such a situation the distinction between a function and
an interface is made by construction: a subdirectory of

/cfg./C1/F1/interfaces must be an interface

While a subdirectory of

/cfg./C1/F1/function must be a function

This can be done. However, I was not sure whether it was
desirable to have one more directory level.

Now it is

/cfg./C1/F1/name
/cfg./C1/F1/some_name
/cfg./C1/F1/some_name/function-specific-stuff
/cfg./C1/F1/interface00


I would put the interfaces as a child of function and not merge them in
one folder.





+static ssize_t ufg_function_grp_store_name(struct ufg_function_grp *grp,
+  const char *buf, size_t count) {
+   int rc;
+   struct dentry *parent

Re: USB issue with kernel 3.6

[Alan Stern]

On Thu, 22 Nov 2012, Piergiorgio Sartor wrote:

> OK, I got a log with working and then non working system,
> so there should be a transition,

The trace attached to Kernel Bugzilla #50381 didn't give any details.  
All it showed was that at one point the computer stopped getting data
from the drives.

Does the same problem occur if you use fewer drives or only one hub?

Below is a diagnostic patch which should add extra information to the 
dmesg log when the problem occurs.  It requires CONFIG_USB_DEBUG to be 
set.  Let's see what it shows.

Alan Stern



Index: usb-3.7/drivers/usb/host/ehci-hcd.c
===
--- usb-3.7.orig/drivers/usb/host/ehci-hcd.c
+++ usb-3.7/drivers/usb/host/ehci-hcd.c
@@ -907,6 +907,18 @@ static int ehci_urb_dequeue(struct usb_h
qh = (struct ehci_qh *) urb->hcpriv;
if (!qh)
break;
+
+   if (usb_pipetype(urb->pipe) == PIPE_BULK) {
+   char label[40];
+
+   sprintf(label, "dev %d ep %x state %d",
+   usb_pipedevice(urb->pipe),
+   usb_pipein(urb->pipe) +
+   usb_pipeendpoint(urb->pipe),
+   qh->qh_state);
+   dbg_qh(label, ehci, qh);
+   }
+
switch (qh->qh_state) {
case QH_STATE_LINKED:
case QH_STATE_COMPLETING:

--
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] fs: configfs: programmatically create config groups

[Michal Nazarewicz]

> On 11/26/2012 09:35 AM, Andrzej Pietrasiewicz wrote:
>> In some parts of the kernel (e.g. planned configfs integration into usb
>> gadget) there is a need to programmatically create config groups
>> (directories) but it would be preferable to disallow creating them by
>> the user. This is more or less what default_groups used to be for.
>> But e.g. in the mass storage gadget, after storing the number of
>> luns (logical units) into some configfs attribute, the corresponding lun#
>> directories should be created, their number is not known up front so
>> default_groups are no good for this.
>>
>> Example:
>>
>> $ echo 3>  /cfg//mass_storage/luns
>>
>> causes
>>
>> /cfg/../mass_storage/lun0
>> /cfg/../mass_storage/lun1
>> /cfg/../mass_storage/lun2

On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
> I though we did not want the luns file but instead use
>
> mkdir /cfg/../mass_storage/lun0
> mkdir /cfg/../mass_storage/lun1
>
> directly.

I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5 > nluns” is much nicer
than having to create 5 directories).

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgp9ZeFVTcFET.pgp
Description: PGP signature

Re: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Alan Stern]

On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:

> Step two is a folder where we setup individual configuration of a function.
> 
> /functions/ttyS0
> /functions/ttyS1
> /functions/storage
> 
> each one of the function folder has the file called "name". So for the
> folder ttyS0 the file name contains "acm" because we use the ACM
> function. The same is true for ttyS1 and for storage we write
> "mass_storage" if that is what function will be called.
> 
> Alternative (my favorite): function_common-name
> that would be
> 
> /functions/acm_ttyS0
> /functions/acm_ttyS1
> /functions/mass_storage_storage
> 
> So we avoid the _name_ file and it will be parsed from the directory 
> name. That is what target/tcm does. You have
> rd_mcp_X for a ramdisk and fileio_X for a file as backend.
> 
> After name is written it will request the module and special
> configuration related files pop up. For ACM it will be almost nothing
> while for storage we get nofua or something like that and we will be
> able to create the lunX folder.

Is there really any significant configuration to be done at this level?  
I would expect functions to be written so that different settings can 
be applied to different instances.

For example, if a config had two mass-storage interfaces, they should 
be configurable separately.  There should be very little, or nothing, 
that would apply across all the instances.

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: cdc-acm and remote wakeup

[Alan Stern]

On Mon, 26 Nov 2012, Daniele Palmas wrote:

> > What if the modem isn't registered to the network?  For example, if the
> > cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled
> > then?
> >
> 
> That is a good question: in my specific scenario it is not useful to
> have the remote wakeup enabled if the cdc-acm driver is unloaded. But,
> though at the moment I cannot identify any, maybe there are situations
> in which it is useful to have the remote wakeup enabled even if the
> driver is not loaded.

Without a driver, and without being registered with the network, I 
don't see how the modem could ever send a wakeup request in the first 
place.

Still, this is an important consideration.  It means that remote wakeup
doesn't need to be enabled when the driver isn't present.  Which means
that the cdc-acm driver is indeed the right place to fix this problem
-- although the way you did it isn't the right way.  The right way is
to have cdc-acm turn on the needs_remote_wakeup flag in the
usb_interface structure.

And by the way, /proc/acpi/wakeup is deprecated.  To allow the modem to 
wake up the system, you should do:

echo enabled >/sys/bus/usb/devices/.../power/wakeup

where the "..." part is filled in with the device name corresponding to
the modem.

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: cdc-acm and remote wakeup

[Daniele Palmas]

2012/11/26 Alan Stern :
> On Mon, 26 Nov 2012, Daniele Palmas wrote:
>
>> > What if the modem isn't registered to the network?  For example, if the
>> > cdc-acm driver is unloaded.  Does it need remote wakeup to be enabled
>> > then?
>> >
>>
>> That is a good question: in my specific scenario it is not useful to
>> have the remote wakeup enabled if the cdc-acm driver is unloaded. But,
>> though at the moment I cannot identify any, maybe there are situations
>> in which it is useful to have the remote wakeup enabled even if the
>> driver is not loaded.
>
> Without a driver, and without being registered with the network, I
> don't see how the modem could ever send a wakeup request in the first
> place.
>
> Still, this is an important consideration.  It means that remote wakeup
> doesn't need to be enabled when the driver isn't present.  Which means
> that the cdc-acm driver is indeed the right place to fix this problem
> -- although the way you did it isn't the right way.  The right way is
> to have cdc-acm turn on the needs_remote_wakeup flag in the
> usb_interface structure.

Ok, I'll try to take a look at that.

> And by the way, /proc/acpi/wakeup is deprecated.  To allow the modem to
> wake up the system, you should do:
>
> echo enabled >/sys/bus/usb/devices/.../power/wakeup
>
> where the "..." part is filled in with the device name corresponding to
> the modem.
>

Thanks for the tip.

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

[PATCH] USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue

[Alan Stern]

This patch (as1636) is a partial workaround for a hardware bug
affecting OHCI controllers by NVIDIA at least, maybe others too.  When
the controller retires a Transfer Descriptor, it is supposed to add
the TD onto the Done Queue.  But sometimes this doesn't happen, with
the result that ohci-hcd never realizes the corresponding transfer has
finished.  Symptoms can vary; a typical result is that USB audio stops 
working after a while.

The patch works around the problem by recognizing that TDs are always
processed in order.  Therefore, if a later TD is found on the Done
Queue than all the earlier TDs for the same endpoint must be finished
as well.

Unfortunately this won't solve the problem in cases where the missing
TD is the last one in the endpoint's queue.  A complete fix would
require a signficant amount of change to the driver.

Signed-off-by: Alan Stern 
Tested-by: Oliver Neukum 
CC: 

---

 drivers/usb/host/ohci-q.c |   19 +++
 1 file changed, 19 insertions(+)

Index: usb-3.7/drivers/usb/host/ohci-q.c
===
--- usb-3.7.orig/drivers/usb/host/ohci-q.c
+++ usb-3.7/drivers/usb/host/ohci-q.c
@@ -1128,6 +1128,25 @@ dl_done_list (struct ohci_hcd *ohci)
 
while (td) {
struct td   *td_next = td->next_dl_td;
+   struct ed   *ed = td->ed;
+
+   /*
+* Some OHCI controllers (NVIDIA for sure, maybe others)
+* occasionally forget to add TDs to the done queue.  Since
+* TDs for a given endpoint are always processed in order,
+* if we find a TD on the donelist then all of its
+* predecessors must be finished as well.
+*/
+   for (;;) {
+   struct td   *td2;
+
+   td2 = list_first_entry(&ed->td_list, struct td,
+   td_list);
+   if (td2 == td)
+   break;
+   takeback_td(ohci, td2);
+   }
+
takeback_td(ohci, td);
td = td_next;
}

--
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: cdc-acm and remote wakeup

[Oliver Neukum]

On Monday 26 November 2012 12:06:21 Alan Stern wrote:
> Still, this is an important consideration.  It means that remote wakeup
> doesn't need to be enabled when the driver isn't present.  Which means
> that the cdc-acm driver is indeed the right place to fix this problem
> -- although the way you did it isn't the right way.  The right way is
> to have cdc-acm turn on the needs_remote_wakeup flag in the
> usb_interface structure.

Well, no. You cannot be sure that the device is quiet if no driver is bound.
It is perfectly possible to access a device through usbfs and cause lasting
effects.
We could use RESET_RESUME, but it seems wrong to use that quirk
while gentler alternatives are available.

Regards
Oliver

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

Re: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Sebastian Andrzej Siewior]

On 11/26/2012 05:57 PM, Alan Stern wrote:

On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:


Step two is a folder where we setup individual configuration of a function.

/functions/ttyS0
/functions/ttyS1
/functions/storage

each one of the function folder has the file called "name". So for the
folder ttyS0 the file name contains "acm" because we use the ACM
function. The same is true for ttyS1 and for storage we write
"mass_storage" if that is what function will be called.

Alternative (my favorite): function_common-name
that would be

/functions/acm_ttyS0
/functions/acm_ttyS1
/functions/mass_storage_storage

So we avoid the _name_ file and it will be parsed from the directory
name. That is what target/tcm does. You have
rd_mcp_X for a ramdisk and fileio_X for a file as backend.

After name is written it will request the module and special
configuration related files pop up. For ACM it will be almost nothing
while for storage we get nofua or something like that and we will be
able to create the lunX folder.


Is there really any significant configuration to be done at this level?
I would expect functions to be written so that different settings can
be applied to different instances.

For example, if a config had two mass-storage interfaces, they should
be configurable separately.  There should be very little, or nothing,
that would apply across all the instances.


I don't follow. acm_ttyS0 and acm_ttyS1 are different instances and can
have different settings. The first one comes up with GS0 the latter
with GS1 as its node name.
Same would apply to mass storage.
Is it possible that I missed your point?



Alan Stern


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

Re: [RFC 2/8] USB: Ignore xHCI Reset Device status.

[Sarah Sharp]

On Fri, Nov 23, 2012 at 12:40:12PM -0500, Alan Stern wrote:
> On Wed, 21 Nov 2012, Sarah Sharp wrote:
> 
> > A device may need to be reset several times during enumeration, and this
> > causes a disconnect between the USB core's device state and the xHC's
> > device state.
> > 
> > For example, usb_reset_and_verify_device calls into hub_port_init in a
> > loop.  Say that on the first call into hub_port_init, the device is
> > successfully reset, but doesn't respond to several set address control
> > transfers.  Then the port will be disabled, but the udev will remain in
> > tact.  usb_reset_and_verify_device will call into hub_port_init again.
> > 
> > The problem is that the xHC was sent a Reset Device command after the
> > first port reset.  At that point, it thinks the device is in the Default
> > state.  The failed Set Address commands do not move the device from the
> > Default state.  On the second port reset, the Reset Device command is
> > issued again.  Since the xHC thinks device is already in the Default
> > state, it will reject the second Reset Device command.
> 
> That's kind of strange.  Why shouldn't the computer be allowed to reset
> a device twice in a row?  The hardware's "xHC knows best" attitude is
> a little annoying...

Yes, it is.

> >  This will cause
> > the port reset to fail until the device is logically disconnected.
> > 
> > Fix this by ignoring the return value of the HCD reset_device callback.
> 
> Does this really fix anything?  Since the device can't be reset after
> the first attempt, the end result is bound to be a failure anyway.

I'm not sure what you mean by "can't be reset after the first attempt".
The xHC thinks the device is already reset after the first Reset Device
command, so the second command is basically a no-op.

> Would it be simpler to just forget about the loop (set the number of
> tries to 1) in usb_reset_and_verify_device for SuperSpeed devices?

Remember that we can have USB 2.0 devices under an xHCI host.  We need
to be able to reset them multiple times as well.

For example, I know some devices take a long time to respond to the Set
Address command once they receive power.  I know Keith Packard is
attempting to bit-bang USB serial with an 8051, and it takes a long time
for the board to start responding to USB requests.  So his device won't
work under xHCI unless the USB core attempts to enumerate the device
multiple times.

> > This commit should be backported to kernels as old as 3.2, that contain
> > the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
> > warm reset logic".
> > 
> > Signed-off-by: Sarah Sharp 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/usb/core/hub.c |   13 +
> >  1 files changed, 5 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 7f8f10e..3bc50fc 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -2565,14 +2565,11 @@ static void hub_port_finish_reset(struct usb_hub 
> > *hub, int port1,
> > msleep(10 + 40);
> > update_devnum(udev, 0);
> > hcd = bus_to_hcd(udev->bus);
> > -   if (hcd->driver->reset_device) {
> > -   *status = hcd->driver->reset_device(hcd, udev);
> > -   if (*status < 0) {
> > -   dev_err(&udev->dev, "Cannot reset "
> > -   "HCD device state\n");
> > -   break;
> > -   }
> > -   }
> > +   /* The xHC may think the device is already reset,
> > +* so ignore the status.
> > +*/
> 
> When adding new comments, stick to the recommended format:
> 
>   /*
>* Comment
>* more comment
>*/
> 
> Don't worry if this clashes with comments that are already present.
> 
> Also, it would be best not to mention xHC here.  In theory, other 
> controller types might implement a reset_device method.  "The HC ..." 
> would be better.

Sure.

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

Re: [RFC][PATCH] fs: configfs: programmatically create config groups

[Michal Nazarewicz]

On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:
> Wouldn't say that. It may adds complexity on another level. The target
> subsystem has the same problem with adding luns and there seems nothing
> wrong with having lun3 and 4 and leaving 0 and 1 unsued.

That's not what Wikipedia claims though (from
):

LUN 0: There is one LUN which is required to exist in every
target: zero. The logical unit with LUN zero is special in that
it must implement a few specific commands, most notably Report
LUNs, which is how an initiator can find out all the other LUNs
in the target. But LUN zero need not provide any other services,
such as a storage volume.

That's why I proposed solution where one needs to have continuous
numbering of LUNs.  I'm not an expert on SCSI though.

> With the tcm gadget I get:
>
> |scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
> ANSI: 5
> |scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
> ANSI: 5
>
> You notice :2 and :3 instead :0 and :1. While should be there something
> wrong with this?

It may be that it works on Linux but fails on some other systems (or
even older Linux kernels).  Like I've said, I'm not SCSI expert, so my
knowledge of it is (embarrassingly) minimal.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpT7EvNM2rKY.pgp
Description: PGP signature

Re: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Michal Nazarewicz]

> On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:
>> Step two is a folder where we setup individual configuration of a function.
>> 
>> /functions/ttyS0
>> /functions/ttyS1
>> /functions/storage
>> 
>> each one of the function folder has the file called "name". So for the
>> folder ttyS0 the file name contains "acm" because we use the ACM
>> function. The same is true for ttyS1 and for storage we write
>> "mass_storage" if that is what function will be called.

On Mon, Nov 26 2012, Alan Stern wrote:
> Is there really any significant configuration to be done at this level?  
> I would expect functions to be written so that different settings can 
> be applied to different instances.
>
> For example, if a config had two mass-storage interfaces, they should 
> be configurable separately.  There should be very little, or nothing, 
> that would apply across all the instances.

In Sebastian's example, those are the instances which are attached to
gadgets.  A “pure” function has no representation.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpiMTCEEo1Ci.pgp
Description: PGP signature

Re: [RFC][PATCH] fs: configfs: programmatically create config groups

[Sebastian Andrzej Siewior]

On 11/26/2012 05:56 PM, Michal Nazarewicz wrote:

On 11/26/2012 09:35 AM, Andrzej Pietrasiewicz wrote:

In some parts of the kernel (e.g. planned configfs integration into usb
gadget) there is a need to programmatically create config groups
(directories) but it would be preferable to disallow creating them by
the user. This is more or less what default_groups used to be for.
But e.g. in the mass storage gadget, after storing the number of
luns (logical units) into some configfs attribute, the corresponding lun#
directories should be created, their number is not known up front so
default_groups are no good for this.

Example:

$ echo 3>   /cfg//mass_storage/luns

causes

/cfg/../mass_storage/lun0
/cfg/../mass_storage/lun1
/cfg/../mass_storage/lun2


On Mon, Nov 26 2012, Sebastian Andrzej Siewior wrote:

I though we did not want the luns file but instead use

mkdir /cfg/../mass_storage/lun0
mkdir /cfg/../mass_storage/lun1

directly.


I think that's suboptimal, and we can do better.  There are too many
corner cases (ie. what if user does “mkdir lun7” without the previous
luns?), it adds complexity to the kernel (ie. parsing of the name), and
the thing is overly complicated for user (“echo 5>  nluns” is much nicer
than having to create 5 directories).


Wouldn't say that. It may adds complexity on another level. The target
subsystem has the same problem with adding luns and there seems nothing
wrong with having lun3 and 4 and leaving 0 and 1 unsued.
With the tcm gadget I get:

|scsi 0:0:0:2: Direct-Access LIO-ORG  RAMDISK-MCP  4.0  PQ: 0 
ANSI: 5
|scsi 0:0:0:3: Direct-Access LIO-ORG  FILEIO   4.0  PQ: 0 
ANSI: 5


You notice :2 and :3 instead :0 and :1. While should be there something
wrong with this?

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

Re: [RFC 3/8] xHCI: Clear all USB 2.0 change bits on port disable.

[Sarah Sharp]

On Fri, Nov 23, 2012 at 12:55:29PM -0500, Alan Stern wrote:
> On Wed, 21 Nov 2012, Sarah Sharp wrote:
> 
> > The USB core disables the USB 2.0 ports in several different error
> > cases.  It expects that all USB hubs will act like external hubs, and
> > always return an interrupt event if a port change bit is set.  External
> > USB 2.0 and USB 3.0 hubs are level-triggered, so this works for them.
> > 
> > However, xHCI roothubs are edge-triggered.  If no port status change
> > bits are set, and a new change bit is set, the xHCI host sends an
> > interrupt and a Port Status Change Event.  It will not generate another
> > port event until all change bits are cleared and a new one is set.
> > 
> > This opens up issues with the USB core port disabling code.  Right now,
> > it assumes that it can simply clear the port enable bit, and wait for
> > the hub to send an interrupt when a change bit is set.  If previous
> > change bits weren't cleared, it's assumed to be fine because the hub
> > will continue to remind the USB core about them through the interrupt
> > endpoint.
> 
> Is port-disabling the only place where this problem occurs?

Probably not.

> A more defensive approach would be to copy what ohci-hcd does.  When a
> port-change interrupt occurs, the driver switches over to polling for
> root-hub status changes.  It doesn't switch back to interrupt-driven
> operation until the hub_status_data routine sees that none of the ports
> have any change bits set.

Yes, that does sound like a better idea.  I'll take a look into it.

But wouldn't I need to switch to polling in places in the roothub code
other than hub_status_data?  For example, the disable port code sets the
port state to disabled without checking the status afterwards.

> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index a686cf4..7d9dcd6 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -340,6 +340,10 @@ static void xhci_disable_port(struct usb_hcd *hcd, 
> > struct xhci_hcd *xhci,
> > return;
> > }
> >  
> > +   /* Clear all change bits, so that we get a device connect event. */
> > +   port_status |= PORT_CSC | PORT_PEC | PORT_WRC |
> > +   PORT_OCC | PORT_RC | PORT_PLC |
> > +   PORT_CEC;
> 
> What if a connect-change occurred just before this?  Would it get lost?

I think it wouldn't get lost, because the device would have to
re-connect after the port was disabled, and we're atomically clearing
the change bits as we disable the port.  But it's a moot point if this
code isn't necessary because I switch the xHCI driver over to polling
when a change bit is set.

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

Re: [PATCH] cppi_dma: mark cppi_controller_create() and cppi_pool_init() as '__devinit'

[Sergei Shtylyov]

Hello.

On 11/12/2012 09:01 PM, Sergei Shtylyov wrote:

> This patch fixes the following:

> WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference from 
> the function dma_controller_create() to the function 
> .init.text:cppi_controller_start()
> The function __devinit dma_controller_create() references
> a function __init cppi_controller_start().
> If cppi_controller_start is only used by dma_controller_create then
> annotate cppi_controller_start with a matching annotation.

> This warning is there due to the deficiency in the commit 07a67bbb (usb: musb:
> Make dma_controller_create __devinit).

> Since the start() method is only called from musb_init_controller() which is
> marked '__devinit', mark cppi_controller_start() '__devinit' and also mark
> cppi_pool_init() as such since it gets called from that function, to avoid
> another section mismatch warning...

> Signed-off-by: Sergei Shtylyov 
> Cc: sta...@vger.kernel.org # 3.7+

> ---
> This patch is atop of 'musb' branch of Felipe's tree...

> Would be good to have it in 3.7 as an amendment to the patch
> that went into 3.7-rc1, but if not, I CC'ed stable kernels.

   Felipe, are you going to finally queue this one?

WBR, Sergei

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

Re: [PATCH] musb_core: print new line in the driver banner again

[Sergei Shtylyov]

On 11/14/2012 06:49 PM, Sergei Shtylyov wrote:

> Commit 5c8a86e10a7c164f44537fabdc169fd8b4e7a440 (usb: musb: drop unneeded
> musb_debug trickery) erroneously removed '\n' from the driver's banner.
> Concatenate all the banner substrings while adding it back...

> Signed-off-by: Sergei Shtylyov 
> Cc: sta...@vger.kernel.org # 3.0+

> ---
> MUSB driver has been spoiling kernel output since 3.0 and nobody noticed --
> I wonder how good it's actually tested (especially given the face that
> loading DaVinci glue as module just hangs DM6446 EVM board).

> This patch is atop of 'musb' branch of Felipe's tree...

   ... and this one too?

WBR, Sergei

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

Re: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Alan Stern]

On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:

> On 11/26/2012 05:57 PM, Alan Stern wrote:
> > On Mon, 26 Nov 2012, Sebastian Andrzej Siewior wrote:
> >
> >> Step two is a folder where we setup individual configuration of a function.
> >>
> >> /functions/ttyS0
> >> /functions/ttyS1
> >> /functions/storage
> >>
> >> each one of the function folder has the file called "name". So for the
> >> folder ttyS0 the file name contains "acm" because we use the ACM
> >> function. The same is true for ttyS1 and for storage we write
> >> "mass_storage" if that is what function will be called.

> >> After name is written it will request the module and special
> >> configuration related files pop up. For ACM it will be almost nothing
> >> while for storage we get nofua or something like that and we will be
> >> able to create the lunX folder.
> >
> > Is there really any significant configuration to be done at this level?
> > I would expect functions to be written so that different settings can
> > be applied to different instances.
> >
> > For example, if a config had two mass-storage interfaces, they should
> > be configurable separately.  There should be very little, or nothing,
> > that would apply across all the instances.
> 
> I don't follow. acm_ttyS0 and acm_ttyS1 are different instances and can
> have different settings. The first one comes up with GS0 the latter
> with GS1 as its node name.
> Same would apply to mass storage.
> Is it possible that I missed your point?

It's more likely that I missed your point.  :-)

In your example, what files would appear under under
/functions/storage?  I gather that the "storage" part is just a
placeholder name with no real meaning.  The meaning is conveyed
when the user writes "mass_storage" to /functions/storage/name.

When this happens, would the additional files created in this directory
be those required specifically by the mass_storage function driver?  
And nothing else?

On the other hand, why have two separate directories for
/functions/ttyS0 and /functions/ttyS1?  Aren't these two different
instances of the same function?  So if the user then writes "acm"  to
/functions/ttyS0/name and /functions/ttyS1/name, wouldn't your
framework get an error when it tried to load the acm function module a
second time?

Alan Stern

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

Re: [RFC 2/8] USB: Ignore xHCI Reset Device status.

[Alan Stern]

On Mon, 26 Nov 2012, Sarah Sharp wrote:

> > >  This will cause
> > > the port reset to fail until the device is logically disconnected.
> > > 
> > > Fix this by ignoring the return value of the HCD reset_device callback.
> > 
> > Does this really fix anything?  Since the device can't be reset after
> > the first attempt, the end result is bound to be a failure anyway.
> 
> I'm not sure what you mean by "can't be reset after the first attempt".
> The xHC thinks the device is already reset after the first Reset Device
> command, so the second command is basically a no-op.

That's what I meant.  When you ignore the return value of a no-op, what
are you fixing?  The device will still end up being logically
disconnected, since it will see only one reset no matter how many you
try to do.

> > Would it be simpler to just forget about the loop (set the number of
> > tries to 1) in usb_reset_and_verify_device for SuperSpeed devices?
> 
> Remember that we can have USB 2.0 devices under an xHCI host.  We need
> to be able to reset them multiple times as well.

That's why I suggested using a single iteration for SuperSpeed devices.  
Since USB-2 devices aren't SuperSpeed, they can continue to have 
multiple iterations.

> For example, I know some devices take a long time to respond to the Set
> Address command once they receive power.  I know Keith Packard is
> attempting to bit-bang USB serial with an 8051, and it takes a long time
> for the board to start responding to USB requests.  So his device won't
> work under xHCI unless the USB core attempts to enumerate the device
> multiple times.

Does the xHCI controller allow multiple resets of non-SuperSpeed 
devices?

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: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Michal Nazarewicz]

On Mon, Nov 26 2012, Alan Stern wrote:
> In your example, what files would appear under under
> /functions/storage?  I gather that the "storage" part is just a
> placeholder name with no real meaning.  The meaning is conveyed
> when the user writes "mass_storage" to /functions/storage/name.
>
> When this happens, would the additional files created in this
> directory be those required specifically by the mass_storage function
> driver?  And nothing else?

Specifically by a single instance.

> On the other hand, why have two separate directories for
> /functions/ttyS0 and /functions/ttyS1?  Aren't these two different
> instances of the same function?  So if the user then writes "acm"  to
> /functions/ttyS0/name and /functions/ttyS1/name, wouldn't your
> framework get an error when it tried to load the acm function module a
> second time?

This would just create another instance of the same function.


This actually gave me an idea.  Why not:

mkdir functions/acm   # the f_acm module is loaded
mkdir functions/acm/blah  # instance of the function is created

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpApC9ftTedD.pgp
Description: PGP signature

Re: [RFC 3/8] xHCI: Clear all USB 2.0 change bits on port disable.

[Alan Stern]

On Mon, 26 Nov 2012, Sarah Sharp wrote:

> > Is port-disabling the only place where this problem occurs?
> 
> Probably not.
> 
> > A more defensive approach would be to copy what ohci-hcd does.  When a
> > port-change interrupt occurs, the driver switches over to polling for
> > root-hub status changes.  It doesn't switch back to interrupt-driven
> > operation until the hub_status_data routine sees that none of the ports
> > have any change bits set.
> 
> Yes, that does sound like a better idea.  I'll take a look into it.
> 
> But wouldn't I need to switch to polling in places in the roothub code
> other than hub_status_data?  For example, the disable port code sets the
> port state to disabled without checking the status afterwards.

You would need to switch over to polling whenever an interrupt occurs
with the port-status-change interrupt flag set -- hub_status_data is
where you switch _back_.

An extraneous interrupt every now and then won't hurt anything; the 
issue is to avoid missing events that don't cause an interrupt.

> > > + /* Clear all change bits, so that we get a device connect event. */
> > > + port_status |= PORT_CSC | PORT_PEC | PORT_WRC |
> > > + PORT_OCC | PORT_RC | PORT_PLC |
> > > + PORT_CEC;
> > 
> > What if a connect-change occurred just before this?  Would it get lost?
> 
> I think it wouldn't get lost, because the device would have to
> re-connect after the port was disabled, and we're atomically clearing
> the change bits as we disable the port.  But it's a moot point if this
> code isn't necessary because I switch the xHCI driver over to polling
> when a change bit is set.

True.

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: cdc-acm and remote wakeup

[Alan Stern]

On Mon, 26 Nov 2012, Oliver Neukum wrote:

> On Monday 26 November 2012 12:06:21 Alan Stern wrote:
> > Still, this is an important consideration.  It means that remote wakeup
> > doesn't need to be enabled when the driver isn't present.  Which means
> > that the cdc-acm driver is indeed the right place to fix this problem
> > -- although the way you did it isn't the right way.  The right way is
> > to have cdc-acm turn on the needs_remote_wakeup flag in the
> > usb_interface structure.
> 
> Well, no. You cannot be sure that the device is quiet if no driver is bound.
> It is perfectly possible to access a device through usbfs and cause lasting
> effects.

True, but you can blame the bad effects on the program that configured 
the modem via usbfs and then didn't unconfigure the modem when it was 
finished.

Of course, there would still be a problem if the system was suspended
while this program was running and using the modem.  There's no way to 
tell usbfs that remote wakeup is required.

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 01/27] usb: gadget: mv_udc: use udc_start and udc_stop functions

[Greg KH]

On Mon, Nov 26, 2012 at 04:34:31PM +0200, Felipe Balbi wrote:
> Hi,
> 
> On Mon, Nov 26, 2012 at 06:39:36AM -0800, Greg KH wrote:
> > On Sun, Nov 25, 2012 at 11:43:14PM -0500, Chao Xie wrote:
> > > From: Chao Xie 
> > > 
> > > This patches converts the driver into the new style start/stop
> > > interface. As a result the driver no longer uses the static
> > > global the_conroller variable.
> > > 
> > > Signed-off-by: Chao Xie 
> > 
> > How come your signed-off-by address does not match your "From:" address
> > on the patch?  The marvell.com address should be both here, right?
> 
> And how come I wasn't in Cc ???

The author obviously didn't want the patches to actually be applied to
any tree :)

--
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: configfs hierarchy (WAS: Re: [RFCv4 PATCH 02/13] usb: gadget: Add USB Functions Gadget)

[Alan Stern]

On Mon, 26 Nov 2012, Michal Nazarewicz wrote:

> On Mon, Nov 26 2012, Alan Stern wrote:
> > In your example, what files would appear under under
> > /functions/storage?  I gather that the "storage" part is just a
> > placeholder name with no real meaning.  The meaning is conveyed
> > when the user writes "mass_storage" to /functions/storage/name.
> >
> > When this happens, would the additional files created in this
> > directory be those required specifically by the mass_storage function
> > driver?  And nothing else?
> 
> Specifically by a single instance.

Ah, now I see.  I missed the part where Sebastian said that these 
directories would be symlinked under 
/gadgets/gadget1/default-configuration.

> > On the other hand, why have two separate directories for
> > /functions/ttyS0 and /functions/ttyS1?  Aren't these two different
> > instances of the same function?  So if the user then writes "acm"  to
> > /functions/ttyS0/name and /functions/ttyS1/name, wouldn't your
> > framework get an error when it tried to load the acm function module a
> > second time?
> 
> This would just create another instance of the same function.
> 
> 
> This actually gave me an idea.  Why not:
> 
> mkdir functions/acm   # the f_acm module is loaded
> mkdir functions/acm/blah  # instance of the function is created

That does seem to make more sense.

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 06/27] usb: host: ehci-mv: fix clk APIs

[Alan Stern]

On Sun, 25 Nov 2012, Chao Xie wrote:

> From: Chao Xie 
> 
> the clock common driver changes, and arch-mmp will make use of
> the common clock driver instead of its own.
> So for enable clock.
> first prepare the clock
> then enable the clock.
> 
> for disable clock
> first disable the clock
> then unprepare the clock
> 
> Signed-off-by: Chao Xie 

When you resubmit these patches with the right Signed-off-by: lines,
you can add

Acked-by: Alan Stern 

to the ones affecting ehci-mv.c (patches 6, 7, 11, 21, and 27).

Alan Stern

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

Re: [RFC 0/8] USB core reset changes

[Sarah Sharp]

On Fri, Nov 23, 2012 at 01:20:15PM -0500, Alan Stern wrote:
> On Wed, 21 Nov 2012, Sarah Sharp wrote:
> 
> > Hi Alan,
> > 
> > Can you take a look over this patchset to improve reset support under
> > xHCI roothubs?
> > 
> > There's a lot of changes here, but I tried to break it up into easily
> > verifiable chunks.  I'd like to backport all the patches except the last
> > one to stable trees, so I would really appreciate your review.
> 
> Mostly they look okay.  I posted some comments on a few of the patches; 
> you don't have to do anything about them right away if you prefer not 
> to.  I haven't looked at them in enough detail yet to make sure that 
> they don't change anything for USB-2 devices.  Assuming they don't, I 
> won't have any objections to the first 7 patches.
> 
> The last one is the trickiest.  Can you at least break it up into two 
> pieces: one to get rid of the recursion in the resetting code and the 
> other for everything else?

I'll try.  I'm not sure if it can be done though.

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Mon, 26 Nov 2012, Andy Green wrote:

> This adds a small optional API into drivers/base which deals with generating,
> matching and registration of wildcard device paths.
> 
> >From a struct device * you can generate a string like
> 
>  /platform/usbhs_omap/ehci-omap.0/usb1/1-1
> 
> which enapsulates the path of the device's connection to the board.
> 
> These can be used to match up other assets, for example struct regulators,
> that have been registed elsewhere with a device instance that is probed
> asynchronously from the other board assets.
> 
> If your device is on a bus, as it probably is, the device path will feature
> redundant bus indexes that do not contain information about the connectivity.
> 
> For example if more than one driver can generate devices on the same bus,
> then the ordering of device probing will change the path, despite the
> connectivity remains the same.
> 
> For that reason, to get a deterministic path for matching, wildcards are
> allowed.  If your target device has the path
> 
>  /platform/usbhs_omap/ehci-omap.0/usb1/1-1
> 
> generated, in the asset you wish to match with it you can instead use
> 
> /platform/usbhs_omap/ehci-omap.0/usb*/*-1
> 
> in order to only leave the useful, invariant parts of the path to match
> against.

Have you considered limiting these wildcards in various useful ways?  
In this example, the wildcard must match a string of decimal digits.  
(Furthermore the two wildcard strings will always match each other, 
although it's probably not necessary to add this sort of constraint.)

I don't know what sort of matches people will want in the future.  
Perhaps one for hex digits, or one for arbitrary text with the
exception of a few characters (such as '/' but perhaps others too).

To do what you want for now, the match should be restricted to digits.

> To avoid having to adapt every kind of "search by string" api to also use
> the wildcards, the api takes the approach you can register your wildcard,
> and if a matching path is generated for a device, the wildcard itself is
> handed back as the device path instead.
> 
> So if your board code or a (not yet done) DT binding registers this wildcard
> 
>  /platform/usbhs_omap/ehci-omap.0/usb*
> 
> and the usb hub driver asks to generate its device path
> 
>   device_path_generate(dev, name, sizeof name);
> 
> that is actually
> 
>  /platform/usbhs_omap/ehci-omap.0/usb1
> 
> then what will be returned is
> 
>  /platform/usbhs_omap/ehci-omap.0/usb*
> 
> providing the same literal string for ehci-omap.0 hub no matter how many\
> usb buses have been registered before.
> 
> This wildcard string can then be matched to regulators or other string-
> searchable assets intended for the device on that hardware path.

That's not how I would do it, at least, not for this application.  I
would register tuples containing a name, a pointer, and two callback
routines.  For example,

("/platform/usbhs_omap/ehci-omap.0/usb*", &omap_vhub_device,
turn_on_regulator, turn_off_regulator)

The when a device is registered whose path matches the string in such a
tuple, the device core would know to invoke the first callback.  The
arguments would be a pointer to the device being registered and the
pointer in the tuple.  Similarly, the device core would invoke the
second callback when the device is unregistered.

There doesn't have to be anything in this scheme that's specific to 
hubs or even to USB.  In particular, no changes to the hub driver would 
be needed.

Alan Stern

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Greg KH]

On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> +struct device_path list;
> +DEFINE_MUTEX(lock);

Those are some very descriptive global variables you just created :(

--
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 1/5] drivers : introduce device_path api

[Greg KH]

On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> This adds a small optional API into drivers/base which deals with generating,
> matching and registration of wildcard device paths.
> 
> >From a struct device * you can generate a string like
> 
>  /platform/usbhs_omap/ehci-omap.0/usb1/1-1
> 
> which enapsulates the path of the device's connection to the board.
> 
> These can be used to match up other assets, for example struct regulators,
> that have been registed elsewhere with a device instance that is probed
> asynchronously from the other board assets.
> 
> If your device is on a bus, as it probably is, the device path will feature
> redundant bus indexes that do not contain information about the connectivity.

Huh?  A bus "index" does show the connectivity, well, one type of
connectivity, but perhaps it's not the one _you_ happen to want at the
moment.  Which is fine, but I don't see why you want to try to figure
this out using the device path in the first place, surely you have some
other way that the hardware can describe itself to the kernel as to
where it needs to be hooked up to?

> For example if more than one driver can generate devices on the same bus,
> then the ordering of device probing will change the path, despite the
> connectivity remains the same.

That's an expected thing, I don't see the issue here.

> For that reason, to get a deterministic path for matching, wildcards are
> allowed.  If your target device has the path

Wait, no, why would you want a deterministic path and have that
hard-coded into the kernel here?  You can't rely on that any more than
userspace can, so let's not start making the mistake that lots of
userspace programmers originally did when they started using sysfs
please.  We have learned from our past mistakes.

>  /platform/usbhs_omap/ehci-omap.0/usb1/1-1
> 
> generated, in the asset you wish to match with it you can instead use
> 
> /platform/usbhs_omap/ehci-omap.0/usb*/*-1
> 
> in order to only leave the useful, invariant parts of the path to match
> against.
> 
> To avoid having to adapt every kind of "search by string" api to also use
> the wildcards, the api takes the approach you can register your wildcard,
> and if a matching path is generated for a device, the wildcard itself is
> handed back as the device path instead.
> 
> So if your board code or a (not yet done) DT binding registers this wildcard
> 
>  /platform/usbhs_omap/ehci-omap.0/usb*

Device tree lists sysfs paths in it's descriptions?  That's news to me.

> and the usb hub driver asks to generate its device path
> 
>   device_path_generate(dev, name, sizeof name);
> 
> that is actually
> 
>  /platform/usbhs_omap/ehci-omap.0/usb1
> 
> then what will be returned is
> 
>  /platform/usbhs_omap/ehci-omap.0/usb*
> 
> providing the same literal string for ehci-omap.0 hub no matter how many\
> usb buses have been registered before.
> 
> This wildcard string can then be matched to regulators or other string-
> searchable assets intended for the device on that hardware path.

Ah, here's the root of your problem, right?  You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device?  Using the device path and hard-coding it into the
kernel is not the proper way to solve this, sorry.  Use some other
unique way to describe the hardware, surely the hardware designers
couldn't have been that foolish not to provide this [1]?

thanks,

greg k-h

[1] Yeah, I know I'm being hopeful here, and probably wrong, but then
you need to push back.  We are not helpless here.
--
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/5] usb: hub: add device_path regulator control to generic hub

[Greg KH]

On Mon, Nov 26, 2012 at 12:45:45PM +, Andy Green wrote:
> This adds the config option to associate a regulator with each hub,
> when the hub on a specific, interesting device path appears, then
> the regular is powered while the logical hub exists.
> 
> Signed-off-by: Andy Green 
> ---
>  drivers/usb/core/Kconfig |   10 ++
>  drivers/usb/core/hub.c   |   26 +-
>  2 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index f70c1a1..4a91eb1 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -95,3 +95,13 @@ config USB_OTG_BLACKLIST_HUB
> and software costs by not supporting external hubs.  So
> are "Embedded Hosts" that don't offer OTG support.
>  
> +config USB_HUB_DEVICE_PATH_REGULATOR
> + bool "Support generic regulators at hubs"
> + select DEVICEPATH
> + depends on USB
> + default n
> + help
> +   Allows you to use the device_path APIs to associate kernel regulators
> +   with dynamically probed USB hubs, so the regulators are enabled
> +   as the appropriate hub instance gets created and disabled as it
> +   is destroyed.

Even if I did like the device_path code (which I do not), this needs to
be rewritten to actually make sense to a user who would have to pick
this option, not a kernel developer.

> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index a815fd2..49ebb5e 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -54,7 +55,9 @@ struct usb_hub {
>   struct usb_device   *hdev;
>   struct kref kref;
>   struct urb  *urb;   /* for interrupt polling pipe */
> -
> +#ifdef CONFIG_USB_HUB_DEVICE_PATH_REGULATOR

No #ifdefs in .c files, if at all possible please.

thanks,

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

Re: USB issue with kernel 3.6

[Piergiorgio Sartor]

On Mon, Nov 26, 2012 at 11:51:39AM -0500, Alan Stern wrote:
> On Thu, 22 Nov 2012, Piergiorgio Sartor wrote:
> 
> > OK, I got a log with working and then non working system,
> > so there should be a transition,
> 
> The trace attached to Kernel Bugzilla #50381 didn't give any details.  
> All it showed was that at one point the computer stopped getting data
> from the drives.
> 
> Does the same problem occur if you use fewer drives or only one hub?
> 
> Below is a diagnostic patch which should add extra information to the 
> dmesg log when the problem occurs.  It requires CONFIG_USB_DEBUG to be 
> set.  Let's see what it shows.
> 

Hi Alan,

thanks for the patch.

I'll try to apply it and report the results,
including the USB EHCI register files.

Unfortunately, I cannot provide a "deadline"
(so to speak), I'm quite busy at the moment.

Thanks again,

bye,

pg

> 
> 
> 
> Index: usb-3.7/drivers/usb/host/ehci-hcd.c
> ===
> --- usb-3.7.orig/drivers/usb/host/ehci-hcd.c
> +++ usb-3.7/drivers/usb/host/ehci-hcd.c
> @@ -907,6 +907,18 @@ static int ehci_urb_dequeue(struct usb_h
>   qh = (struct ehci_qh *) urb->hcpriv;
>   if (!qh)
>   break;
> +
> + if (usb_pipetype(urb->pipe) == PIPE_BULK) {
> + char label[40];
> +
> + sprintf(label, "dev %d ep %x state %d",
> + usb_pipedevice(urb->pipe),
> + usb_pipein(urb->pipe) +
> + usb_pipeendpoint(urb->pipe),
> + qh->qh_state);
> + dbg_qh(label, ehci, qh);
> + }
> +
>   switch (qh->qh_state) {
>   case QH_STATE_LINKED:
>   case QH_STATE_COMPLETING:

-- 

piergiorgio
--
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 1/5] drivers : introduce device_path api

[Greg KH]

On Mon, Nov 26, 2012 at 11:22:06AM -0800, Greg KH wrote:
> On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> > This adds a small optional API into drivers/base which deals with 
> > generating,
> > matching and registration of wildcard device paths.
> > 
> > >From a struct device * you can generate a string like
> > 
> >  /platform/usbhs_omap/ehci-omap.0/usb1/1-1
> > 
> > which enapsulates the path of the device's connection to the board.
> > 
> > These can be used to match up other assets, for example struct regulators,
> > that have been registed elsewhere with a device instance that is probed
> > asynchronously from the other board assets.
> > 
> > If your device is on a bus, as it probably is, the device path will feature
> > redundant bus indexes that do not contain information about the 
> > connectivity.
> 
> Huh?  A bus "index" does show the connectivity, well, one type of
> connectivity, but perhaps it's not the one _you_ happen to want at the
> moment.  Which is fine, but I don't see why you want to try to figure
> this out using the device path in the first place, surely you have some
> other way that the hardware can describe itself to the kernel as to
> where it needs to be hooked up to?
> 
> > For example if more than one driver can generate devices on the same bus,
> > then the ordering of device probing will change the path, despite the
> > connectivity remains the same.
> 
> That's an expected thing, I don't see the issue here.
> 
> > For that reason, to get a deterministic path for matching, wildcards are
> > allowed.  If your target device has the path
> 
> Wait, no, why would you want a deterministic path and have that
> hard-coded into the kernel here?  You can't rely on that any more than
> userspace can, so let's not start making the mistake that lots of
> userspace programmers originally did when they started using sysfs
> please.  We have learned from our past mistakes.
> 
> >  /platform/usbhs_omap/ehci-omap.0/usb1/1-1

Oh, and further proof of this, there are patches floating around to drop
the "platform" name from the sys/drivers/ tree, so your driver just
broke if that goes through, showing you really don't want to be
hard-coding sysfs paths in any type of logic.

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

Re: [PATCH 06/16] mfd: omap-usb-host: cleanup clock management code

[Felipe Balbi]

Hi,

On Mon, Nov 26, 2012 at 05:14:45PM +0200, Roger Quadros wrote:
> Felipe,
> 
> On 11/21/2012 03:39 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Thu, Nov 15, 2012 at 04:34:04PM +0200, Roger Quadros wrote:
> >> All ports have similarly named port clocks so we can
> >> bunch them into a port data structure and use for loop
> >> to enable/disable the clocks.
> >>
> >> Signed-off-by: Roger Quadros 
> >> ---
> >>  drivers/mfd/omap-usb-host.c |  208 
> >> +--
> >>  1 files changed, 101 insertions(+), 107 deletions(-)
> >>
> >> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> >> index 23cec57..7303c41 100644
> >> --- a/drivers/mfd/omap-usb-host.c
> >> +++ b/drivers/mfd/omap-usb-host.c
> >> @@ -76,6 +76,8 @@
> >>  
> >>  #define   OMAP_UHH_DEBUG_CSR  (0x44)
> >>  
> >> +#define MAX_HS_USB_PORTS  3   /* Increase this if any chip has more */
> >> +
> >>  /* Values of UHH_REVISION - Note: these are not given in the TRM */
> >>  #define OMAP_USBHS_REV1   0x0010  /* OMAP3 */
> >>  #define OMAP_USBHS_REV2   0x50700100  /* OMAP4 */
> >> @@ -87,14 +89,15 @@
> >>  #define is_ehci_tll_mode(x)   (x == OMAP_EHCI_PORT_MODE_TLL)
> >>  #define is_ehci_hsic_mode(x)  (x == OMAP_EHCI_PORT_MODE_HSIC)
> >>  
> >> +struct usbhs_port {
> >> +  struct clk  *utmi_clk;
> >> +};
> > 
> > I rather not since this will make it a lot more difficult to use
> > pm_clk_add() :-s Also, this sort of thing should be dynamically
> > allocated anyway ;-)
> > 
> 
> Why do you say so? The whole point of this patch is to group similarly
> named clocks so that we can use a for loop and set number of ports (or
> clocks) dynamically. I suppose it would be just a matter of replacing
> clk_enable/disable() with pm_clk_add() later, right?
> 
> If you see patch 11, we are adding 2 HSIC related clocks to this
> structure. This means 9 clocks (i.e. 3 clocks for 3 ports) can be
> managed using a simple for loop instead of coding each clock name by hand.

that's usually not what you want, actually. You want clock management to
be explicit so you can have micro-power optimizations. I fear that the
time omap-usb-host.c gets *truly* stabilized and we move to more
aggressive PM, we will undo these changes just to have a more granular
control of the clocks, at which point your patch would be rendered
useless.

-- 
balbi


signature.asc
Description: Digital signature

Re: [alsa-devel] [PATCH] usb: add USB_QUIRK_RESET_RESUME for M-Audio 49

[Clemens Ladisch]

Alan Stern wrote:
> On Mon, 26 Nov 2012, Oliver Neukum wrote:
>> On Monday 26 November 2012 14:43:13 Clemens Ladisch wrote:
>>> usb_autopm_get_interface() cannot be called from the USB probe callback.
>>
>> You can use usb_autopm_get_interface_no_resume()
>> During probe() the device is known to not be suspended.
>
> In fact, as far as I know you _can_ use usb_autopm_get_interface() from
> within a probe routine.  Is there some problem with it I'm not aware of?

It returns -EACCES.

But _no_resume() appears to work just fine.


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

Re: [PATCH 01/27] usb: gadget: mv_udc: use udc_start and udc_stop functions

[Felipe Balbi]

Hi,

On Mon, Nov 26, 2012 at 10:42:32AM -0800, Greg KH wrote:
> On Mon, Nov 26, 2012 at 04:34:31PM +0200, Felipe Balbi wrote:
> > Hi,
> > 
> > On Mon, Nov 26, 2012 at 06:39:36AM -0800, Greg KH wrote:
> > > On Sun, Nov 25, 2012 at 11:43:14PM -0500, Chao Xie wrote:
> > > > From: Chao Xie 
> > > > 
> > > > This patches converts the driver into the new style start/stop
> > > > interface. As a result the driver no longer uses the static
> > > > global the_conroller variable.
> > > > 
> > > > Signed-off-by: Chao Xie 
> > > 
> > > How come your signed-off-by address does not match your "From:" address
> > > on the patch?  The marvell.com address should be both here, right?
> > 
> > And how come I wasn't in Cc ???
> 
> The author obviously didn't want the patches to actually be applied to
> any tree :)

sounds about right :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] lsusb: Fix USB 3.0 link state reporting.

[Sarah Sharp]

Greg, ping?

On Thu, Nov 08, 2012 at 01:57:04PM -0800, Sarah Sharp wrote:
> The math in the link status reporting is wrong.  The link state is in
> bits 8:5 of the hub port status word, which is split across a char
> array.  Currently, if the link state is 0xb (Loopback mode), the status
> char array will look something like this:
> 
> status[0] = 0110 
> status[1] =  0001
> 
> The current math will mask and shift those bits like so:
> 
> (status[0] & 0xe0) >> 5 =  0011
> (status[1] & 0x1) << 4 =  0001 
> 
> This sets link_state to 0x13, which is not correct (it should be 0xb).
> This bug will cause valid link states greater than seven (Recovery, Hot
> Reset, Compliance Mode, and Loopback Mode) to not be printed.
> 
> It's important to correctly report Compliance Mode, since some TI USB
> 3.0 host controllers can get "stuck" in Compliance Mode.
> 
> Fix this by left shifting status[1] by 3, not 4.
> 
> Signed-off-by: Sarah Sharp 
> ---
>  lsusb.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/lsusb.c b/lsusb.c
> index 106dd33..5f0df11 100644
> --- a/lsusb.c
> +++ b/lsusb.c
> @@ -3276,7 +3276,7 @@ static void do_hub(libusb_device_handle *fd, unsigned 
> tt_type, unsigned speed)
>   (status[0] & 0x01) ? " connect" : "");
>   } else {
>   link_state = ((status[0] & 0xe0) >> 5) +
> - ((status[1] & 0x1) << 4);
> + ((status[1] & 0x1) << 3);
>   printf("%s%s%s%s%s%s",
>   (status[2] & 0x80) ? " C_CONFIG_ERROR" 
> : "",
>   (status[2] & 0x40) ? " C_LINK_STATE" : 
> "",
> -- 
> 1.7.9
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cppi_dma: mark cppi_controller_create() and cppi_pool_init() as '__devinit'

[Felipe Balbi]

Hi,

On Mon, Nov 26, 2012 at 10:14:30PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/12/2012 09:01 PM, Sergei Shtylyov wrote:
> 
> > This patch fixes the following:
> 
> > WARNING: vmlinux.o(.devinit.text+0x24ac): Section mismatch in reference 
> > from the function dma_controller_create() to the function 
> > .init.text:cppi_controller_start()
> > The function __devinit dma_controller_create() references
> > a function __init cppi_controller_start().
> > If cppi_controller_start is only used by dma_controller_create then
> > annotate cppi_controller_start with a matching annotation.
> 
> > This warning is there due to the deficiency in the commit 07a67bbb (usb: 
> > musb:
> > Make dma_controller_create __devinit).
> 
> > Since the start() method is only called from musb_init_controller() which is
> > marked '__devinit', mark cppi_controller_start() '__devinit' and also mark
> > cppi_pool_init() as such since it gets called from that function, to avoid
> > another section mismatch warning...
> 
> > Signed-off-by: Sergei Shtylyov 
> > Cc: sta...@vger.kernel.org # 3.7+
> 
> > ---
> > This patch is atop of 'musb' branch of Felipe's tree...
> 
> > Would be good to have it in 3.7 as an amendment to the patch
> > that went into 3.7-rc1, but if not, I CC'ed stable kernels.
> 
>Felipe, are you going to finally queue this one?

for v3.8-rc. The merge window isn't even open yet, chill out.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] lsusb: Fix USB 3.0 link state reporting.

[Greg KH]

On Mon, Nov 26, 2012 at 12:13:34PM -0800, Sarah Sharp wrote:
> Greg, ping?

Sorry, I've been swamped with kernel stuff.  This patch is in my
usbutils patch queue, along with a few other submitted patches, I hope
to get to them later this week.  Don't worry, it's not lost :)

thanks,

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

Re: USB issue with kernel 3.6

[Alan Stern]

On Mon, 26 Nov 2012, Piergiorgio Sartor wrote:

> Hi Alan,
> 
> thanks for the patch.
> 
> I'll try to apply it and report the results,
> including the USB EHCI register files.
> 
> Unfortunately, I cannot provide a "deadline"
> (so to speak), I'm quite busy at the moment.

Don't worry about it; I'm not in any hurry.

When you do get around to testing, don't forget to try combinations 
with fewer drives and/or only one hub.

Alan Stern

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

[PATCH] uwb: fix uwb_dev_unlock() missed at an error path in uwb_rc_cmd_async()

[Alexey Khoroshilov]

There is the only path in uwb_rc_cmd_async() where rc->uwb_dev is left unlocked.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/uwb/reset.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/uwb/reset.c b/drivers/uwb/reset.c
index 7032285..8b47c9c 100644
--- a/drivers/uwb/reset.c
+++ b/drivers/uwb/reset.c
@@ -97,6 +97,7 @@ int uwb_rc_cmd_async(struct uwb_rc *rc, const char *cmd_name,
neh = uwb_rc_neh_add(rc, cmd, expected_type, expected_event, cb, arg);
if (IS_ERR(neh)) {
result = PTR_ERR(neh);
+   uwb_dev_unlock(&rc->uwb_dev);
goto out;
}
 
-- 
1.7.9.5

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

Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Alan Stern]

On Mon, 26 Nov 2012, Greg KH wrote:

> Ah, here's the root of your problem, right?  You need a way for your
> hardware to tell the kernel that you have a regulator attached to a
> specific device?  Using the device path and hard-coding it into the
> kernel is not the proper way to solve this, sorry.  Use some other
> unique way to describe the hardware, surely the hardware designers
> couldn't have been that foolish not to provide this [1]?

As far as I know, the kernel has no other way to describe devices.

What about using partial matches?  In this example, instead of doing a 
wildcard match against

/platform/usbhs_omap/ehci-omap.0/usb*

(which would fail if the "platform" part of the path changes), suppose 
the string "ehci-omap.0/usb*" could be associated with the usbhs_omap 
component somehow.  Or even better, the string "usb*" could be 
associated with the ehci-omap.0 device.

Then the path-matching code could restrict its attention to that part
of the path and to devices below the specified one.  Naming changes
wouldn't be an issue, because the changes themselves would be made in
the same source file that contains the partial path string.


On the other hand, this may be way more general than we really need.  
For this particular case, all we need to do is take special action the
first time any device is registered below the ehci-omap.0 platform
device.  There ought to be a more direct way to accomplish this,
without using string pattern-matching or sysfs pathnames (and without 
adding overhead every time a device is added or deleted).

I don't know if such an approach would be sufficiently general for 
future requirements, but it would solve the problem at hand.

Alan Stern

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

Re: [RFC 2/8] USB: Ignore xHCI Reset Device status.

[Sarah Sharp]

On Mon, Nov 26, 2012 at 01:29:33PM -0500, Alan Stern wrote:
> On Mon, 26 Nov 2012, Sarah Sharp wrote:
> 
> > > >  This will cause
> > > > the port reset to fail until the device is logically disconnected.
> > > > 
> > > > Fix this by ignoring the return value of the HCD reset_device callback.
> > > 
> > > Does this really fix anything?  Since the device can't be reset after
> > > the first attempt, the end result is bound to be a failure anyway.
> > 
> > I'm not sure what you mean by "can't be reset after the first attempt".
> > The xHC thinks the device is already reset after the first Reset Device
> > command, so the second command is basically a no-op.
> 
> That's what I meant.  When you ignore the return value of a no-op, what
> are you fixing?  The device will still end up being logically
> disconnected, since it will see only one reset no matter how many you
> try to do.

The Reset Device command just changes the xHC device context state.
Unlike the Address Device command, the host hardware does not issue the
port reset itself.  Instead, software has to issue the control transfer
to start the port reset, time it, etc.  This patch just allows software
to issue multiple port resets by ignoring the error status of the no-op
Reset Device command.  So this fix does have an effect on how many port
resets the device sees.

Does that clarify why this patch is needed?

> > > Would it be simpler to just forget about the loop (set the number of
> > > tries to 1) in usb_reset_and_verify_device for SuperSpeed devices?
> > 
> > Remember that we can have USB 2.0 devices under an xHCI host.  We need
> > to be able to reset them multiple times as well.
> 
> That's why I suggested using a single iteration for SuperSpeed devices.  
> Since USB-2 devices aren't SuperSpeed, they can continue to have 
> multiple iterations.
> 
> > For example, I know some devices take a long time to respond to the Set
> > Address command once they receive power.  I know Keith Packard is
> > attempting to bit-bang USB serial with an 8051, and it takes a long time
> > for the board to start responding to USB requests.  So his device won't
> > work under xHCI unless the USB core attempts to enumerate the device
> > multiple times.
> 
> Does the xHCI controller allow multiple resets of non-SuperSpeed 
> devices?

See above.

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

Re: Mouse and keyboard freeze Ivy-bridge

[Alan Stern]

On Mon, 26 Nov 2012, Chris Holland wrote:

> > Can you supply similar logging information for the case where the
> > mouse/keyboard is plugged into a USB-2 motherboard port?  Please
> > include the contents of /sys/kernel/debug/usb/devices.
> >
> > Alan Stern
> >
> 
> Here is what I think is the last 1500 lines from logging the usb with
> the error happening.
> sudo cat /sys/kernel/debug/usb/usbmon/0u > busdata
> sudo lsusb -v > lsusb-v

lsusb -v isn't necessary for this.  The devices file has all the 
interesting information.

> sudo lsusb > lsusb
> sudo cat /sys/kernel/debug/usb/devices > devices

The usbmon trace shows that the keyboard attached to the PCI card
failed, then was unplugged and replugged, and then worked again.

> I will take the pci card out and try to get the information with out
> the extra mouse/kyb/controller. I dont have the  CONFIG_USB_DEBUG
> enabled kernel yet.

You don't need to take out the PCI card.  Just plug the keyboard and
wheel mouse into the motherboard (or into a hub attached to the
motherboard) instead of into the PCI card.  Leave the optical mouse
unplugged for the test.

Does this problem occur only with the LITEON keyboard, or does it 
affect the Logitech keyboard as well?

Alan Stern

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

Re: [RFC 2/8] USB: Ignore xHCI Reset Device status.

[Alan Stern]

On Mon, 26 Nov 2012, Sarah Sharp wrote:

> On Mon, Nov 26, 2012 at 01:29:33PM -0500, Alan Stern wrote:
> > On Mon, 26 Nov 2012, Sarah Sharp wrote:
> > 
> > > > >  This will cause
> > > > > the port reset to fail until the device is logically disconnected.
> > > > > 
> > > > > Fix this by ignoring the return value of the HCD reset_device 
> > > > > callback.
> > > > 
> > > > Does this really fix anything?  Since the device can't be reset after
> > > > the first attempt, the end result is bound to be a failure anyway.
> > > 
> > > I'm not sure what you mean by "can't be reset after the first attempt".
> > > The xHC thinks the device is already reset after the first Reset Device
> > > command, so the second command is basically a no-op.
> > 
> > That's what I meant.  When you ignore the return value of a no-op, what
> > are you fixing?  The device will still end up being logically
> > disconnected, since it will see only one reset no matter how many you
> > try to do.
> 
> The Reset Device command just changes the xHC device context state.
> Unlike the Address Device command, the host hardware does not issue the
> port reset itself.  Instead, software has to issue the control transfer
> to start the port reset, time it, etc.  This patch just allows software
> to issue multiple port resets by ignoring the error status of the no-op
> Reset Device command.  So this fix does have an effect on how many port
> resets the device sees.
> 
> Does that clarify why this patch is needed?

Yes, a lot.  From the patch description, I thought the controller was
preventing you from resetting the port when the device was in the
Default state.  I didn't realize that the Reset Device command was
separate from resetting the port.

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: Unreliable USB3 with NEC uPD720200 and Delock Cardreader

[Bjørn Mork]

Sarah Sharp  writes:

> It looks like both Ulrich and Andrew have the same issue.  I also have a
> Lenovo x220, and I confirmed that when I turn on PCI runtime suspend,
> the NEC host controller does not report port status changes when a new
> USB device is plugged in.
>
> I'm running 3.6.7, and I'm pretty sure that runtime suspend worked for
> the NEC host on some older kernel.  I don't think the NEC host went into
> D3cold on that kernel, though.  Is there a way to disable D3cold and
> just use D3hot instead?

Yes, you have /sys/bus/pci/devices/.../d3cold_allowed
See Documentation/ABI/testing/sysfs-bus-pci

If this really is a problem with the D3cold support that went into 3.6
then I guess you should include Huang Ying in the discussions as well
(CCed).


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: [RFC 2/8] USB: Ignore xHCI Reset Device status.

[Sarah Sharp]

On Mon, Nov 26, 2012 at 04:44:59PM -0500, Alan Stern wrote:
> On Mon, 26 Nov 2012, Sarah Sharp wrote:
> 
> > On Mon, Nov 26, 2012 at 01:29:33PM -0500, Alan Stern wrote:
> > > On Mon, 26 Nov 2012, Sarah Sharp wrote:
> > > 
> > > > > >  This will cause
> > > > > > the port reset to fail until the device is logically disconnected.
> > > > > > 
> > > > > > Fix this by ignoring the return value of the HCD reset_device 
> > > > > > callback.
> > > > > 
> > > > > Does this really fix anything?  Since the device can't be reset after
> > > > > the first attempt, the end result is bound to be a failure anyway.
> > > > 
> > > > I'm not sure what you mean by "can't be reset after the first attempt".
> > > > The xHC thinks the device is already reset after the first Reset Device
> > > > command, so the second command is basically a no-op.
> > > 
> > > That's what I meant.  When you ignore the return value of a no-op, what
> > > are you fixing?  The device will still end up being logically
> > > disconnected, since it will see only one reset no matter how many you
> > > try to do.
> > 
> > The Reset Device command just changes the xHC device context state.
> > Unlike the Address Device command, the host hardware does not issue the
> > port reset itself.  Instead, software has to issue the control transfer
> > to start the port reset, time it, etc.  This patch just allows software
> > to issue multiple port resets by ignoring the error status of the no-op
> > Reset Device command.  So this fix does have an effect on how many port
> > resets the device sees.
> > 
> > Does that clarify why this patch is needed?
> 
> Yes, a lot.  From the patch description, I thought the controller was
> preventing you from resetting the port when the device was in the
> Default state.  I didn't realize that the Reset Device command was
> separate from resetting the port.

Ok, I'll try to clarify the patch description.

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