date:20130331

Re: [PATCH 2/4] usb: introduce usb force power off mechanism

2013-03-31 Thread Lan Tianyu

On 2013年03月29日 22:11, Alan Stern wrote:
> On Fri, 29 Mar 2013, Lan Tianyu wrote:
> 
>> Actually, I exposed pm qos flags for usb port via dev_pm_qos_expose_flags().
>> It creates power/pm_qos_no_power_off under usb port sysfs directory.
>> User can echo 0 > pm_qos_no_power_off to power off the empty port.
> 
> Before it's too late, we should consider changing the flag's name.  
> Writing 0 to a file named pm_qos_no_power_off is a double negative, 
> which is always awkward to think about.
> 
> Instead, how about calling the file pm_qos_allow_power_off?  Will the
> PM-QOS system allow something like that, i.e., something that is the
> opposite of a constraint?
> 
> If not, how about naming it pm_qos_keep_power_on?
This is PM core sysfs attribute and I am not sure that this can be changed.

CC: Rafael.

> 
> Alan Stern
> 


-- 
Best regards
Tianyu Lan
--
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] drivers/usb/core: processing failure, maching resume condition with suspend condition

2013-03-31 Thread Chen Gang


  when suspend, it need check 'udev->actconfig'.
  so when process failure, also need check it.

Signed-off-by: Chen Gang 
---
 drivers/usb/core/driver.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index eb1d00a..1a50003 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1253,10 +1253,12 @@ static int usb_suspend_both(struct usb_device *udev, 
pm_message_t msg)
 
/* If the suspend failed, resume interfaces that did get suspended */
if (status != 0) {
-   msg.event ^= (PM_EVENT_SUSPEND | PM_EVENT_RESUME);
-   while (++i < n) {
-   intf = udev->actconfig->interface[i];
-   usb_resume_interface(udev, intf, msg, 0);
+   if (udev->actconfig) {
+   msg.event ^= (PM_EVENT_SUSPEND | PM_EVENT_RESUME);
+   while (++i < n) {
+   intf = udev->actconfig->interface[i];
+   usb_resume_interface(udev, intf, msg, 0);
+   }
}
 
/* If the suspend succeeded then prevent any more URB submissions
-- 
1.7.7.6
--
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 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)

2013-03-31 Thread Linus Torvalds

On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki  wrote:
>
> So, I have two patches (on top of the Linus' tree) that will follow shortly:

Should I take these directly as patches, or expect them to show up in
a pull soon (ie do you have or expect to have other things pending)?

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

Re: [PATCH 1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()

2013-03-31 Thread Greg Kroah-Hartman

On Mon, Apr 01, 2013 at 12:57:21AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
> "usb: Add driver/usb/core/(port.c,hub.h) files", from
> usb_port_device_release(), because (1) it is completely unnecessary
> (the flags have been removed already by the PM core during the
> unregistration of the device object) and (2) it triggers a NULL
> pointer dereference in sysfs_find_dirent() (dev->kobj->sd is NULL at
> this point).
> 
> Signed-off-by: Rafael J. Wysocki 

Acked-by: Greg Kroah-Hartman 
--
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 v9 7/8] usb: chipidea: udc: prepare qhead with dma_alloc_coherent

2013-03-31 Thread Peter Chen

On Fri, Mar 29, 2013 at 12:32:00AM +0100, Michael Grzeschik wrote:
> The prepared memory for the qhead needs to be contiguos and 2K aligned.
> We change the code from allocating extra buffer for every ep qhead to
> one big area. This patch lowers the amount of code to prepare the
> memory.
> 
> Signed-off-by: Michael Grzeschik 
> ---
>  drivers/usb/chipidea/ci.h  |  9 +++--
>  drivers/usb/chipidea/udc.c | 32 +++-
>  drivers/usb/chipidea/udc.h |  2 +-
>  3 files changed, 23 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 7dcd390..7319bf6 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -121,7 +121,7 @@ struct hw_bank {
>   * @is_otg: if the device is otg-capable
>   * @work: work for role changing
>   * @wq: workqueue thread
> - * @qh_pool: allocation pool for queue heads
> + * @qh: allocation struct for queue heads
>   * @td_pool: allocation pool for transfer descriptors
>   * @gadget: device side representation for peripheral controller
>   * @driver: gadget driver
> @@ -154,7 +154,12 @@ struct ci13xxx {
>   struct work_struct  vbus_work;
>   struct workqueue_struct *wq;
>  
> - struct dma_pool *qh_pool;
> + struct {
> + struct ci13xxx_qh   *ptr;
> + dma_addr_t  dma;
> + size_t  size;
> + }   qh;
> +
>   struct dma_pool *td_pool;
>  
>   struct usb_gadget   gadget;
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index dd4fe75..21f6558 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -13,9 +13,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1401,7 +1403,7 @@ static int ci13xxx_vbus_session(struct usb_gadget 
> *_gadget, int 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);
> + hw_device_state(ci, ci->qh.dma);
>   } else {
>   hw_device_state(ci, 0);
>   if (ci->platdata->notify_event)
> @@ -1504,8 +1506,8 @@ static int init_eps(struct ci13xxx *ci)
>   mEp->ep.maxpacket = (unsigned short)~0;
>  
>   INIT_LIST_HEAD(&mEp->qh.queue);
> - mEp->qh.ptr = dma_pool_alloc(ci->qh_pool, GFP_KERNEL,
> -  &mEp->qh.dma);
> + mEp->qh.ptr = &ci->qh.ptr[i * 2 + j];
> +
>   if (mEp->qh.ptr == NULL)
>   retval = -ENOMEM;
>   else
> @@ -1533,13 +1535,8 @@ static int init_eps(struct ci13xxx *ci)
>  
>  static void destroy_eps(struct ci13xxx *ci)
>  {
> - int i;
> -
> - for (i = 0; i < ci->hw_ep_max; i++) {
> - struct ci13xxx_ep *mEp = &ci->ci13xxx_ep[i];
> -
> - dma_pool_free(ci->qh_pool, mEp->qh.ptr, mEp->qh.dma);
> - }
> + dma_free_coherent(ci->dev, ci->qh.size,
> + ci->qh.ptr, ci->qh.dma);
>  }
>  
>  /**
> @@ -1585,7 +1582,7 @@ static int ci13xxx_start(struct usb_gadget *gadget,
>   }
>   }
>  
> - retval = hw_device_state(ci, ci->ep0out->qh.dma);
> + retval = hw_device_state(ci, ci->qh.dma);
>   if (retval)
>   pm_runtime_put_sync(&ci->gadget.dev);
>  
> @@ -1736,11 +1733,14 @@ static int udc_start(struct ci13xxx *ci)
>   ci->gadget.dev.parent   = dev;
>   ci->gadget.dev.release  = udc_release;
>  
> + ci->qh.size = ci->hw_ep_max * sizeof(struct ci13xxx_qh);
> + ci->qh.size = ALIGN(ci->qh.size, SZ_2K);
> +

What's the value of sizeof(struct ci13xxx_qh) after you pack it
as 64 bytes aligned?

QH is 48-bytes structure, but needs 64-bytes aligned, it can't
avoid wasting 16 bytes. 

So, please make sure the memory layout is correct for qh arrays.

>   /* alloc resources */
> - ci->qh_pool = dma_pool_create("ci13xxx_qh", dev,
> -sizeof(struct ci13xxx_qh),
> -64, CI13XXX_PAGE_SIZE);
> - if (ci->qh_pool == NULL)
> + ci->qh.ptr = dma_alloc_coherent(dev, ci->qh.size,
> + &ci->qh.dma, GFP_ATOMIC);
> +

GFP_ATMOIC isn't needed.

> + if (ci->qh.ptr == NULL)
>   return -ENOMEM;
>  
>   ci->td_pool = dma_pool_create("ci13xxx_td", dev,
> @@ -1814,7 +1814,6 @@ destroy_eps:
>  free_pools:
>   dma_pool_destroy(ci->td_pool);
>  free_qh_pool:
> - dma_pool_destroy(ci->qh_pool);

You may need dma_free_coherent.

>   return retval;
>  }
>  
> @@ -1836,7 +1835,6 @

[PATCH] usb: renesas_usbhs: fixup sparse errors for common.c

2013-03-31 Thread Kuninori Morimoto

This patch fixup below sparse errors

${RENESAS_USB} = ${LINUX}/drivers/usb/renesas_usbhs

CHECK   ${RENESAS_USB}/common.c
${RENESAS_USB}/common.c:313:17: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:322:17: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:384:17: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:524:9: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:545:9: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:574:9: error: incompatible types in conditional 
expression (different base types)
${RENESAS_USB}/common.c:606:9: error: incompatible types in conditional 
expression (different base types)

Signed-off-by: Kuninori Morimoto 
---
>> Felipe

Does this solve "error" issue ?
# I guess common.c still has "warning" though...

 arch/arm/mach-shmobile/board-armadillo800eva.c |8 ++--
 arch/arm/mach-shmobile/board-kzm9g.c   |8 ++--
 arch/arm/mach-shmobile/board-mackerel.c|   12 +---
 arch/sh/boards/mach-ecovec24/setup.c   |4 +++-
 include/linux/usb/renesas_usbhs.h  |6 +++---
 5 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c 
b/arch/arm/mach-shmobile/board-armadillo800eva.c
index 81db74a..2dfb1f8 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -172,7 +172,7 @@ static int usbhsf_get_id(struct platform_device *pdev)
return USBHS_GADGET;
 }
 
-static void usbhsf_power_ctrl(struct platform_device *pdev,
+static int usbhsf_power_ctrl(struct platform_device *pdev,
  void __iomem *base, int enable)
 {
struct usbhsf_private *priv = usbhsf_get_priv(pdev);
@@ -226,6 +226,8 @@ static void usbhsf_power_ctrl(struct platform_device *pdev,
clk_disable(priv->pci); /* usb work around */
clk_disable(priv->usb24);   /* usb work around */
}
+
+   return 0;
 }
 
 static int usbhsf_get_vbus(struct platform_device *pdev)
@@ -242,7 +244,7 @@ static irqreturn_t usbhsf_interrupt(int irq, void *data)
return IRQ_HANDLED;
 }
 
-static void usbhsf_hardware_exit(struct platform_device *pdev)
+static int usbhsf_hardware_exit(struct platform_device *pdev)
 {
struct usbhsf_private *priv = usbhsf_get_priv(pdev);
 
@@ -267,6 +269,8 @@ static void usbhsf_hardware_exit(struct platform_device 
*pdev)
priv->usbh_base = NULL;
 
free_irq(IRQ7, pdev);
+
+   return 0;
 }
 
 static int usbhsf_hardware_init(struct platform_device *pdev)
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c 
b/arch/arm/mach-shmobile/board-kzm9g.c
index e2d3324..e6b775a 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -157,12 +157,14 @@ static int usbhs_get_vbus(struct platform_device *pdev)
return !((1 << 7) & __raw_readw(priv->cr2));
 }
 
-static void usbhs_phy_reset(struct platform_device *pdev)
+static int usbhs_phy_reset(struct platform_device *pdev)
 {
struct usbhs_private *priv = usbhs_get_priv(pdev);
 
/* init phy */
__raw_writew(0x8a0a, priv->cr2);
+
+   return 0;
 }
 
 static int usbhs_get_id(struct platform_device *pdev)
@@ -204,7 +206,7 @@ static int usbhs_hardware_init(struct platform_device *pdev)
return 0;
 }
 
-static void usbhs_hardware_exit(struct platform_device *pdev)
+static int usbhs_hardware_exit(struct platform_device *pdev)
 {
struct usbhs_private *priv = usbhs_get_priv(pdev);
 
@@ -212,6 +214,8 @@ static void usbhs_hardware_exit(struct platform_device 
*pdev)
__raw_writew(USB_PHY_MODE | USB_PHY_INT_CLR, priv->phy);
 
free_irq(IRQ15, pdev);
+
+   return 0;
 }
 
 static u32 usbhs_pipe_cfg[] = {
diff --git a/arch/arm/mach-shmobile/board-mackerel.c 
b/arch/arm/mach-shmobile/board-mackerel.c
index 1a9c753..2b60f2b 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -597,12 +597,14 @@ static int usbhs_get_vbus(struct platform_device *pdev)
return usbhs_is_connected(usbhs_get_priv(pdev));
 }
 
-static void usbhs_phy_reset(struct platform_device *pdev)
+static int usbhs_phy_reset(struct platform_device *pdev)
 {
struct usbhs_private *priv = usbhs_get_priv(pdev);
 
/* init phy */
__raw_writew(0x8a0a, priv->usbcrcaddr);
+
+   return 0;
 }
 
 static int usbhs0_get_id(struct platform_device *pdev)
@@ -629,11 +631,13 @@ static int usbhs0_hardware_init(struct platform_device 
*pdev)
return 0;
 }
 
-static void usbhs0_hardware_exit(struct platform_device *pdev)
+static int usbhs0_hardware_exit(struct platform_device *pdev)
 {
struct usbhs_private *priv = us

Re: Renesas sparse errors

2013-03-31 Thread Kuninori Morimoto


Hi Felipe

> > On Wed, Mar 27, 2013 at 06:21:19PM -0700, Kuninori Morimoto wrote:
> > > > linux/drivers/usb/renesas_usbhs/common.c:313:17: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:322:17: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:384:17: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:524:9: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:545:9: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:574:9: error: incompatible 
> > > > types in conditional expression (different base types)
> > > > linux/drivers/usb/renesas_usbhs/common.c:606:9: error: incompatible 
> > > > types in conditional expression (different base types)
(snip)
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/common.c
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/mod.c
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/pipe.c
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/fifo.c
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/mod_host.c
>   CHECK   /home/balbi/workspace/linux/drivers/usb/renesas_usbhs/mod_gadget.c
>   CC  drivers/usb/renesas_usbhs/mod.o
>   CC  drivers/usb/renesas_usbhs/pipe.o
>   CC  drivers/usb/renesas_usbhs/fifo.o
> drivers/usb/renesas_usbhs/mod_gadget.c:233:28: warning: symbol 
> 'req_clear_feature' was not declared. Should it be static?
> drivers/usb/renesas_usbhs/mod_gadget.c:274:28: warning: symbol 
> 'req_set_feature' was not declared. Should it be static?
> drivers/usb/renesas_usbhs/mod_gadget.c:375:28: warning: symbol 
> 'req_get_status' was not declared. Should it be static?
> drivers/usb/renesas_usbhs/common.c:313:17: error: incompatible types in 
> conditional expression (different base types)
>   CC  drivers/usb/renesas_usbhs/mod_gadget.o
> drivers/usb/renesas_usbhs/common.c:322:17: error: incompatible types in 
> conditional expression (different base types)
> drivers/usb/renesas_usbhs/common.c:384:17: error: incompatible types in 
> conditional expression (different base types)
> drivers/usb/renesas_usbhs/common.c:524:9: error: incompatible types in 
> conditional expression (different base types)
> drivers/usb/renesas_usbhs/common.c:545:9: error: incompatible types in 
> conditional expression (different base types)
> drivers/usb/renesas_usbhs/common.c:574:9: error: incompatible types in 
> conditional expression (different base types)
> drivers/usb/renesas_usbhs/common.c:606:9: error: incompatible types in 
> conditional expression (different base types)
>   CC  drivers/usb/renesas_usbhs/common.o
>   CC  drivers/usb/renesas_usbhs/mod_host.o
>   LD  drivers/usb/renesas_usbhs/renesas_usbhs.o
>   LD  drivers/usb/renesas_usbhs/built-in.o

Thank you. I could understand.
I send fixup patch in next email.
It solve above error.
But renesas_usbhs common.c still has warning...

Best regards
---
Kuninori Morimoto
--
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: Driver for PL-2303 HX not working

2013-03-31 Thread Greg KH

On Sun, Mar 31, 2013 at 07:15:22PM +0200, Karsten Malcher wrote:
> Am 31.03.2013 18:58, schrieb Greg KH:
> >On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote:
> >>Am 31.03.2013 17:50, schrieb Greg KH:
> >>>On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote:
> Hello,
> 
> I have a problem with the PL2303HX chip.
> 
> Please refer to this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242
> 
> Where can i address such a bug?
> How can i debug and help to solve the problem?
> >>>Please provide the output of the kernel log when using this device on
> >>>the 3.8 kernel release.
> >>>
> >>>thanks,
> >>>
> >>>greg k-h
> >>It seems that the driver is the same i am using in kernel 3.2.0-3.
> >>https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5
> >>
> >>So please don't be angry, but it's much effort of installing and compiling 
> >>for the same result.
> >>
> >>The main problem is that there is no special output in the kernel messages 
> >>with this PL-2303 HX chip.
> >>Exactly no message or error appears, the driver simply gives no data that 
> >>arrives.
> >Can you provide the output of 'lsusb -v' with the device plugged in?
> >
> >thanks,
> >
> >greg k-h
> 
> Of course.
> 
> First the overview over all devices:
> 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 008: ID 058f:6254 Alcor Micro Corp. USB Hub
> Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty
> Bus 001 Device 009: ID 16c0:05dc VOTI shared ID for use with libusb
> Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
> Bus 001 Device 011: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader
> 
> 
> The output of lsusb -v for the device:
> (Complete output attached as file)
> 
> 
> Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   1.10
>   bDeviceClass0 (Defined at Interface level)
>   bDeviceSubClass 0
>   bDeviceProtocol 0
>   bMaxPacketSize064

Ok, this should be detected as a HX device by the driver.

Can you do, as root, unplug the device and type:
rmmod pl2303
dmesg -c
modprobe pl2303 debug=1

plug the device in, and then send the output of 'dmesg' that gets sent?

I really don't know why prolific decided to change their device, yet use
the same device id, and not tell us how to talk to the device at all.
The fact that this driver even works is pretty amazing at times...

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

[PATCH 2/2] PM / QoS: Avoid possible deadlock related to sysfs access

2013-03-31 Thread Rafael J. Wysocki

From: Rafael J. Wysocki 

Commit b81ea1b (PM / QoS: Fix concurrency issues and memory leaks in
device PM QoS) put calls to pm_qos_sysfs_add_latency(),
pm_qos_sysfs_add_flags(), pm_qos_sysfs_remove_latency(), and
pm_qos_sysfs_remove_flags() under dev_pm_qos_mtx, which was a
mistake, because it may lead to deadlocks in some situations.
For example, if pm_qos_remote_wakeup_store() is run in parallel
with dev_pm_qos_constraints_destroy(), they may deadlock in the
following way:

 ==
 [ INFO: possible circular locking dependency detected ]
 3.9.0-rc4-next-20130328-sasha-00014-g91a3267 #319 Tainted: GW
 ---
 trinity-child6/12371 is trying to acquire lock:
  (s_active#54){.+}, at: [] sysfs_addrm_finish+0x31/0x60

 but task is already holding lock:
  (dev_pm_qos_mtx){+.+.+.}, at: [] 
dev_pm_qos_constraints_destroy+0x23/0x250

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #1 (dev_pm_qos_mtx){+.+.+.}:
[] lock_acquire+0x1aa/0x240
[] __mutex_lock_common+0x59/0x5e0
[] mutex_lock_nested+0x3f/0x50
[] dev_pm_qos_update_flags+0x3f/0xc0
[] pm_qos_remote_wakeup_store+0x3f/0x70
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xfa/0x150
[] __kernel_write+0x81/0x150
[] write_pipe_buf+0x4d/0x80
[] splice_from_pipe_feed+0x7c/0x120
[] __splice_from_pipe+0x45/0x80
[] splice_from_pipe+0x4c/0x70
[] default_file_splice_write+0x18/0x30
[] do_splice_from+0x83/0xb0
[] direct_splice_actor+0x1e/0x20
[] splice_direct_to_actor+0xe7/0x200
[] do_splice_direct+0x4c/0x70
[] do_sendfile+0x169/0x300
[] SyS_sendfile64+0x64/0xb0
[] tracesys+0xe1/0xe6

 -> #0 (s_active#54){.+}:
[] __lock_acquire+0x15bf/0x1e50
[] lock_acquire+0x1aa/0x240
[] sysfs_deactivate+0x122/0x1a0
[] sysfs_addrm_finish+0x31/0x60
[] sysfs_hash_and_remove+0x7f/0xb0
[] sysfs_unmerge_group+0x51/0x70
[] pm_qos_sysfs_remove_flags+0x14/0x20
[] __dev_pm_qos_hide_flags+0x30/0x70
[] dev_pm_qos_constraints_destroy+0x35/0x250
[] dpm_sysfs_remove+0x11/0x50
[] device_del+0x3f/0x1b0
[] device_unregister+0x48/0x60
[] usb_hub_remove_port_device+0x1c/0x20
[] hub_disconnect+0xdd/0x160
[] usb_unbind_interface+0x67/0x170
[] __device_release_driver+0x87/0xe0
[] device_release_driver+0x29/0x40
[] bus_remove_device+0x148/0x160
[] device_del+0x14f/0x1b0
[] usb_disable_device+0xf9/0x280
[] usb_set_configuration+0x268/0x840
[] usb_remove_store+0x4c/0x80
[] dev_attr_store+0x13/0x20
[] sysfs_write_file+0xfa/0x150
[] do_loop_readv_writev+0x4d/0x90
[] do_readv_writev+0xf9/0x1e0
[] vfs_writev+0x3a/0x60
[] SyS_writev+0x50/0xd0
[] tracesys+0xe1/0xe6

 other info that might help us debug this:

  Possible unsafe locking scenario:

CPU0CPU1

   lock(dev_pm_qos_mtx);
lock(s_active#54);
lock(dev_pm_qos_mtx);
   lock(s_active#54);

  *** DEADLOCK ***

To avoid that, remove the calls to functions mentioned above from
under dev_pm_qos_mtx and introduce a separate lock to prevent races
between functions that add or remove device PM QoS sysfs attributes
from happening.

Reported-by: Sasha Levin 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/base/power/qos.c |   60 ---
 1 file changed, 47 insertions(+), 13 deletions(-)

Index: linux-pm/drivers/base/power/qos.c
===
--- linux-pm.orig/drivers/base/power/qos.c
+++ linux-pm/drivers/base/power/qos.c
@@ -46,6 +46,7 @@
 #include "power.h"
 
 static DEFINE_MUTEX(dev_pm_qos_mtx);
+static DEFINE_MUTEX(dev_pm_qos_sysfs_mtx);
 
 static BLOCKING_NOTIFIER_HEAD(dev_pm_notifiers);
 
@@ -216,12 +217,17 @@ void dev_pm_qos_constraints_destroy(stru
struct pm_qos_constraints *c;
struct pm_qos_flags *f;
 
-   mutex_lock(&dev_pm_qos_mtx);
+   mutex_lock(&dev_pm_qos_sysfs_mtx);
 
/*
 * If the device's PM QoS resume latency limit or PM QoS flags have been
 * exposed to user space, they have to be hidden at this point.
 */
+   pm_qos_sysfs_remove_latency(dev);
+   pm_qos_sysfs_remove_flags(dev);
+
+   mutex_lock(&dev_pm_qos_mtx);
+
__dev_pm_qos_hide_latency_limit(dev);
__dev_pm_qos_hide_flags(dev);
 
@@ -254,6 +260,8 @@ void dev_pm_qos_constraints_destroy(stru
 
  out:
mutex_unlock(&dev_pm_qos_mtx);
+
+   mutex_unlock(&dev_pm_qos_sysfs_mtx);
 }
 
 /**
@@ -558,6 +566,14 @@ static void __dev_pm_qos_drop_user_reque

[PATCH 1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()

2013-03-31 Thread Rafael J. Wysocki

From: Rafael J. Wysocki 

Remove the call to dev_pm_qos_hide_flags(), added by commit 6e30d7cb
"usb: Add driver/usb/core/(port.c,hub.h) files", from
usb_port_device_release(), because (1) it is completely unnecessary
(the flags have been removed already by the PM core during the
unregistration of the device object) and (2) it triggers a NULL
pointer dereference in sysfs_find_dirent() (dev->kobj->sd is NULL at
this point).

Signed-off-by: Rafael J. Wysocki 
---
 drivers/usb/core/port.c |1 -
 1 file changed, 1 deletion(-)

Index: linux-pm/drivers/usb/core/port.c
===
--- linux-pm.orig/drivers/usb/core/port.c
+++ linux-pm/drivers/usb/core/port.c
@@ -67,7 +67,6 @@ static void usb_port_device_release(stru
 {
struct usb_port *port_dev = to_usb_port(dev);
 
-   dev_pm_qos_hide_flags(dev);
kfree(port_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

[PATCH 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)

2013-03-31 Thread Rafael J. Wysocki

On Sunday, March 31, 2013 03:41:11 AM Rafael J. Wysocki wrote:
> [Moving the thread to the LKML.]
> 
> On Saturday, March 30, 2013 06:41:16 PM Sasha Levin wrote:
> > On 03/15/2013 01:06 PM, Rafael J. Wysocki wrote:
> [...]
> > >> Rafael, Is there anything you would like me to test?
> > > 
> > > Please just test 3.9-rc2 (or later).
> > 
> > Hi Rafael,
> 
> Hi,
> 
> > I got this after a bit of fuzzing, it looks related to the fix:
> 
> So the complaint is that we shouldn't call pm_qos_sysfs_remove_flags() under
> dev_pm_qos_mtx, because then it may deadlock with dev_pm_qos_update_flags()
> called from pm_qos_remote_wakeup_store(), for example.  This appears to be a
> valid one.
> 
> To avoid that, we can use a separate mutex for exposing/hiding the flags
> (and the latency limit too) that won't be acquired by 
> dev_pm_qos_update_flags()
> or dev_pm_qos_update_request().
> 
> Can you please try the patch below?

Never mind, I have reproduced the lockdep splat and the patch fixes it for me.

Moreover, I've discovered that we call dev_pm_qos_hide_flags() from
usb_port_device_release(), which is totally incorrect.

So, I have two patches (on top of the Linus' tree) that will follow shortly:

[1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()
[2/2] PM / QoS: Avoid possible deadlock related to sysfs access

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r

2013-03-31 Thread Jiri Kosina

On Thu, 21 Mar 2013, Daniel Vetter wrote:

> Indeed, this is pretty useful and allowed me to quickly reproduce that
> phantom irq on my gm45. Thanks to module reloading we can even reset the
> kernel's irq disabling logic and so test different tricks quickly without
> rebooting. Really useful.

Daniel,

out of curiosity, have you been able to make some sense of the phantom 
legacy IRQs on GM45 systems, or are we just staying with my original 
bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect?

Thanks,

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

Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver

2013-03-31 Thread Arnd Bergmann

On Saturday 30 March 2013, Arnd Bergmann wrote:
> > > In V3:
> > >  -Detailed commit message added here about why this patch is required.
> > >  -Eliminated ehci_spear_setup routine beacuse hcd registers
> > >   directly setting in spear_ehci_hcd_drv_probe function.
> > 
> > Fix the grammar, please.
> 
> Done. I agree some of this is hardly legible.
> 

I realized later that the other patches have similarly screwed up
changelogs. I'll send a new version once you've commented on v4,
so in case there is anything else I missed I'm not spamming everyone
another time.

Arnd
--
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: Driver for PL-2303 HX not working

2013-03-31 Thread Karsten Malcher


Am 31.03.2013 18:58, schrieb Greg KH:

On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote:

Am 31.03.2013 17:50, schrieb Greg KH:

On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote:

Hello,

I have a problem with the PL2303HX chip.

Please refer to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242

Where can i address such a bug?
How can i debug and help to solve the problem?

Please provide the output of the kernel log when using this device on
the 3.8 kernel release.

thanks,

greg k-h

It seems that the driver is the same i am using in kernel 3.2.0-3.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5

So please don't be angry, but it's much effort of installing and compiling for 
the same result.

The main problem is that there is no special output in the kernel messages with 
this PL-2303 HX chip.
Exactly no message or error appears, the driver simply gives no data that 
arrives.

Can you provide the output of 'lsusb -v' with the device plugged in?

thanks,

greg k-h


Of course.

First the overview over all devices:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 008: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty
Bus 001 Device 009: ID 16c0:05dc VOTI shared ID for use with libusb
Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 011: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader


The output of lsusb -v for the device:
(Complete output attached as file)


Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x067b Prolific Technology, Inc.
  idProduct  0x2303 PL2303 Serial Port
  bcdDevice3.00
  iManufacturer   1
  iProduct2
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0



Here the lsusb -v from the old PL2303H device that is working:


Bus 001 Device 018: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor   0x067b Prolific Technology, Inc.
  idProduct  0x2303 PL2303 Serial Port
  bcdDevice2.02
  iManufacturer   0
  iProduct0
  iSerial 0
  bNumConfigurations  1
  Configuration Descriptor:
bLength

Re: Driver for PL-2303 HX not working

2013-03-31 Thread Greg KH

On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote:
> Am 31.03.2013 17:50, schrieb Greg KH:
> >On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote:
> >>Hello,
> >>
> >>I have a problem with the PL2303HX chip.
> >>
> >>Please refer to this bug:
> >>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242
> >>
> >>Where can i address such a bug?
> >>How can i debug and help to solve the problem?
> >Please provide the output of the kernel log when using this device on
> >the 3.8 kernel release.
> >
> >thanks,
> >
> >greg k-h
> 
> It seems that the driver is the same i am using in kernel 3.2.0-3.
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5
> 
> So please don't be angry, but it's much effort of installing and compiling 
> for the same result.
> 
> The main problem is that there is no special output in the kernel messages 
> with this PL-2303 HX chip.
> Exactly no message or error appears, the driver simply gives no data that 
> arrives.

Can you provide the output of 'lsusb -v' with the device plugged in?

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: Driver for PL-2303 HX not working

2013-03-31 Thread Karsten Malcher


Am 31.03.2013 17:50, schrieb Greg KH:

On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote:

Hello,

I have a problem with the PL2303HX chip.

Please refer to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242

Where can i address such a bug?
How can i debug and help to solve the problem?

Please provide the output of the kernel log when using this device on
the 3.8 kernel release.

thanks,

greg k-h


It seems that the driver is the same i am using in kernel 3.2.0-3.
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5

So please don't be angry, but it's much effort of installing and compiling for 
the same result.

The main problem is that there is no special output in the kernel messages with 
this PL-2303 HX chip.
Exactly no message or error appears, the driver simply gives no data that 
arrives.

Regards
Karsten


--
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: Multiple usb_storage problems

2013-03-31 Thread Alan Stern

On Sat, 30 Mar 2013, Andy Lutomirski wrote:

> On Sat, Mar 30, 2013 at 8:21 PM, Andy Lutomirski  wrote:
> > I have a Corsair Flash Voyager GT and a Lenovo x220 running Fedora's
> > 3.8.2 kernel.  It doesn't work very well, and the problems vary
> > depending on whether I'm using usb2 or usb3.
> >
> >  - On usb3, the device node can't be opened with O_DIRECT (using, for
> > example, dd oflag=direct).  It returns -EINVAL.  (On usb2, O_DIRECT
> > works.)
> >  - Also on usb3, if I dd if=/dev/zero of=/dev/sdb bs=1M, dd finishes
> > in a second or two and no I/O occurs.  This system only has 2GB of RAM
> > -- caching shouldn't be that extreme.
> 
> *facepalm*.  The issue is that one of the I/O errors caused the sdb
> block device to get sufficiently wedged that it still exists in /sys,
> but udev removed sdb (and I replaced it with a file).  If I manually
> recreate the sdb device node, ejecting it gets an IO error.  (It's not
> plugged in any more.)  rmmoding and modprobing usb_storage got rid of
> the bogus sdb device.

Does this mean that none of the problems mentioned in the first email 
require any attention?  What about the "sufficiently wedged" issue?

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: Driver for PL-2303 HX not working

2013-03-31 Thread Greg KH

On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote:
> Hello,
> 
> I have a problem with the PL2303HX chip.
> 
> Please refer to this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242
> 
> Where can i address such a bug?
> How can i debug and help to solve the problem?

Please provide the output of the kernel log when using this device on
the 3.8 kernel release.

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

Driver for PL-2303 HX not working

2013-03-31 Thread Karsten Malcher


Hello,

I have a problem with the PL2303HX chip.

Please refer to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242

Where can i address such a bug?
How can i debug and help to solve the problem?

Best regards
Karsten Malcher

--
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: EHCI: port power regression when canceling suspend-to-disk

2013-03-31 Thread Matthijs Kooijman

Hi Alan,

> Are you totally certain about this?  I can't see how removing code to
> change the EHCI port power would make any difference in your case,
> because the power was on the whole time.

Hmm, something fishy is going on: If I revert the patch on top of
3.9-rc4 (ignoring any conflicts and removing the ehci-pci.c part since I
can't see how that could call the static ehci-port-power function in
ehci-hcd.c), it is still broken.

So either something more complicated is happening, or I messed up my
bisection results. I'll retest the rev under suspicion and its parent
and get back to you.

Gr.

Matthijs
--
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 2/4] usb: introduce usb force power off mechanism

[PATCH] drivers/usb/core: processing failure, maching resume condition with suspend condition

Re: [PATCH 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)

Re: [PATCH 1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()

Re: [PATCH v9 7/8] usb: chipidea: udc: prepare qhead with dma_alloc_coherent

[PATCH] usb: renesas_usbhs: fixup sparse errors for common.c

Re: Renesas sparse errors

Re: Driver for PL-2303 HX not working

[PATCH 2/2] PM / QoS: Avoid possible deadlock related to sysfs access

[PATCH 1/2] USB / PM: Don't try to hide PM QoS flags from usb_port_device_release()

[PATCH 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)

Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r

Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver

Re: Driver for PL-2303 HX not working

Re: Driver for PL-2303 HX not working

Re: Driver for PL-2303 HX not working

Re: Multiple usb_storage problems

Re: Driver for PL-2303 HX not working

Driver for PL-2303 HX not working

Re: EHCI: port power regression when canceling suspend-to-disk

20 matches

Site Navigation

Mail list logo

Footer information