litmus-rt-imx6.git/drivers/usb/dwc3, branch master LITMUS^RT and MC^2 V1 support for the i.MX6 processor family. usb: dwc3: fix implementation of endpoint wedge 2013-12-20T15:45:08+00:00 Alan Stern stern@rowland.harvard.edu 2013-11-01T16:05:12+00:00 e6303463eee8685f5b7d7a1b58f6f7ff1518d3af commit a535d81c92615b8ffb99b7e1fd1fb01effaed1af upstream. The dwc3 UDC driver doesn't implement endpoint wedging correctly. When an endpoint is wedged, the gadget driver should be allowed to clear the wedge by calling usb_ep_clear_halt(). Only the host is prevented from resetting the endpoint. This patch fixes the implementation. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Pratyush Anand <pratyush.anand@st.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a535d81c92615b8ffb99b7e1fd1fb01effaed1af upstream.

The dwc3 UDC driver doesn't implement endpoint wedging correctly.
When an endpoint is wedged, the gadget driver should be allowed to
clear the wedge by calling usb_ep_clear_halt().  Only the host is
prevented from resetting the endpoint.

This patch fixes the implementation.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: add support for Merrifield 2013-10-05T14:13:11+00:00 David Cohen david.a.cohen@linux.intel.com 2013-09-26T20:01:44+00:00 3dbfe91ab236d6edd20c52d87b99c5de8b85429d commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream. Add PCI id for Intel Merrifield Signed-off-by: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream.

Add PCI id for Intel Merrifield

Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: pci: add support for BayTrail 2013-10-05T14:13:11+00:00 Heikki Krogerus heikki.krogerus@linux.intel.com 2013-09-17T07:38:13+00:00 85f78609d213684c3079a0e1716ee6082868814d commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream. Add PCI id for Intel BayTrail. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream.

Add PCI id for Intel BayTrail.

Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: gadget: don't request IRQs in atomic 2013-09-27T00:18:04+00:00 Felipe Balbi balbi@ti.com 2013-06-27T07:00:18+00:00 734b2fe93f4bcce29f7d971a106ea94e263e8676 commit b0d7ffd44ba9cd2dfbf299674418193a5f9ed21a upstream. We cannot request an IRQ with spinlocks held as that would trigger a sleeping inside spinlock warning. Reported-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit b0d7ffd44ba9cd2dfbf299674418193a5f9ed21a upstream.

We cannot request an IRQ with spinlocks held
as that would trigger a sleeping inside
spinlock warning.

Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: gadget: don't prevent gadget from being probed if we fail 2013-08-04T08:50:48+00:00 Felipe Balbi balbi@ti.com 2013-07-15T09:36:35+00:00 003dda8a8dedc8a2e90f33fd0745b9529afdf161 commit cdcedd6981194e511cc206887db661d016069d68 upstream. In case we fail our ->udc_start() callback, we should be ready to accept another modprobe following the failed one. We had forgotten to clear dwc->gadget_driver back to NULL and, because of that, we were preventing gadget driver modprobe from being retried. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cdcedd6981194e511cc206887db661d016069d68 upstream.

In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.

We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: fix wrong bit mask in dwc3_event_type 2013-08-04T08:50:48+00:00 Huang Rui ray.huang@amd.com 2013-06-26T17:08:11+00:00 41557736ac4acc112a1884177f62716c57852ddc commit 1974d494dea05ea227cb42f5e918828801e237aa upstream. Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the bit is 1, the event is represented Device-Specific Event, then use [7:1] bits as Device Specific Event to marked the type. It has 7 bits, and we can see the reserved8_31 variable name which means from 8 to 31 bits marked reserved, actually there are 24 bits not 25 bits between that. And 1 + 7 + 24 = 32, the event size is 4 byes. So in dwc3_event_type, the bit mask should be: is_devspec [0] 1 bit type [7:1] 7 bits reserved8_31 [31:8] 24 bits This patch should be backported to kernels as old as 3.2, that contain the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce DesignWare USB3 DRD Driver". Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 1974d494dea05ea227cb42f5e918828801e237aa upstream.

Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.

So in dwc3_event_type, the bit mask should be:
is_devspec	[0]		1  bit
type		[7:1]		7  bits
reserved8_31	[31:8]		24 bits

This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
DesignWare USB3 DRD Driver".

Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: fix the error returned with usb3_phy failure 2013-08-04T08:50:48+00:00 Ruchika Kharwar ruchika@ti.com 2013-07-04T05:59:34+00:00 a53338faf612c0f3c0c4031b6844963540979ac4 commit 315955d707b50c8aad20a32ec0dd4c9fe243cabe upstream. When there is an error with the usb3_phy probe or absence, the error returned is erroneously for usb2_phy. Signed-off-by: Ruchika Kharwar <ruchika@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 315955d707b50c8aad20a32ec0dd4c9fe243cabe upstream.

When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.

Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: dwc3: gadget: free trb pool only from epnum 2 2013-05-28T19:17:20+00:00 George Cherian george.cherian@ti.com 2013-05-27T09:05:49+00:00 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 we never allocate a TRB pool for physical endpoints 0 and 1 so trying to free it (a invalid TRB pool pointer) will lead us in a warning while removing dwc3.ko module. In order to fix the situation, all we have to do is skip dwc3_free_trb_pool() for physical endpoints 0 and 1 just as we while deleting endpoints from the endpoints list. Cc: stable@vger.kernel.org Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> 
we never allocate a TRB pool for physical endpoints
0 and 1 so trying to free it (a invalid TRB pool pointer)
will lead us in a warning while removing dwc3.ko module.

In order to fix the situation, all we have to do is skip
dwc3_free_trb_pool() for physical endpoints 0 and 1 just
as we while deleting endpoints from the endpoints list.

Cc: stable@vger.kernel.org
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: exynos: PHY should be deleted later than dwc3 core 2013-05-28T19:17:08+00:00 Peter Chen peter.chen@freescale.com 2013-05-24T06:30:16+00:00 022d0547aa8b00ff5035ba6207ebc2c08ea0a51f If the glue layer is removed first (core layer later), it deletes the phy device first, then the core device. But at core's removal, it still uses PHY's resources, it may cause kernel's oops. It is much like the problem Paul Zimmerman reported at: http://marc.info/?l=linux-usb&m=136547502011472&w=2. Besides, it is reasonable the PHY is deleted at last as the controller is the PHY's user. Signed-off-by: Peter Chen <peter.chen@freescale.com> Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <balbi@ti.com> 
If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.

Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: dwc3: pci: PHY should be deleted later than dwc3 core 2013-05-28T19:16:49+00:00 Peter Chen peter.chen@freescale.com 2013-05-24T06:29:20+00:00 f28c42c576b293b3a1daaed8ca2775ebc2fe5398 If the glue layer is removed first (core layer later), it deletes the phy device first, then the core device. But at core's removal, it still uses PHY's resources, it may cause kernel's oops. It is much like the problem Paul Zimmerman reported at: http://marc.info/?l=linux-usb&m=136547502011472&w=2. Besides, it is reasonable the PHY is deleted at last as the controller is the PHY's user. Signed-off-by: Peter Chen <peter.chen@freescale.com> Cc: <stable@vger.kernel.org> Signed-off-by: Felipe Balbi <balbi@ti.com> 
If the glue layer is removed first (core layer later),
it deletes the phy device first, then the core device.
But at core's removal, it still uses PHY's resources, it may
cause kernel's oops. It is much like the problem
Paul Zimmerman reported at:
http://marc.info/?l=linux-usb&m=136547502011472&w=2.

Besides, it is reasonable the PHY is deleted at last as
the controller is the PHY's user.

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>