On Wed, Mar 6, 2013 at 3:06 PM, Bjørn Mork wrote:
> Ming Lei writes:
>> On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei wrote:
>>> On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork wrote:
>>>
I guess proper error handling here require the USB core to see the
interface driver as dead if it fails t
Hi,
On Mon, Mar 04, 2013 at 12:21:44PM -0800, Paul Zimmerman wrote:
> Add a usb_otg_state_string() routine to print the OTG state for
> debugging
>
> Signed-off-by: Paul Zimmerman
> Acked-by: Felipe Balbi
> ---
> drivers/usb/usb-common.c | 26 ++
> include/linux/usb/phy
Ming Lei writes:
> On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei wrote:
>> On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork wrote:
>>
>>> I guess proper error handling here require the USB core to see the
>>> interface driver as dead if it fails to suspend on system suspend, and
>>> do forced rebinding o
On Wed, Mar 6, 2013 at 10:51 AM, Ming Lei wrote:
> On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork wrote:
>> Ming Lei writes:
>>
>> I am starting to wonder why the USB core has combined system suspend and
>> runtime suspend if we are going to end up with every driver testing
>> PMSG_IS_AUTO(message)
On Wed, Mar 6, 2013 at 12:08 AM, Bjørn Mork wrote:
> Ming Lei writes:
>
> I am starting to wonder why the USB core has combined system suspend and
> runtime suspend if we are going to end up with every driver testing
> PMSG_IS_AUTO(message) and selecting a completely different code path.
>
> You
On Tue, Mar 5, 2013 at 7:04 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Mar 05, 2013 at 10:03:01AM +0800, Chao Xie wrote:
>> >> +enum mv_usb2_phy_type {
>> >> + PXA168_USB,
>> >> + PXA910_USB,
>> >> + MMP2_USB,
>> >> +};
>> >
>> >
>> > ewww... you really don't need (and *shouldn't* use)
On Tue, Mar 05, 2013 at 02:10:50PM -0800, Sarah Sharp wrote:
> On Fri, Mar 01, 2013 at 08:48:39AM -0800, Greg KH wrote:
> > On Wed, Feb 13, 2013 at 02:12:50PM -0800, Sarah Sharp wrote:
> > > On Wed, Feb 13, 2013 at 01:31:29PM -0800, Greg KH wrote:
> > > > On Wed, Feb 13, 2013 at 01:08:46PM -0800, S
On Wed, Mar 06, 2013 at 01:34:44AM +, Linlei (Lei Lin) wrote:
> Hello Mork,
>
> >> -- Because in the embedded linux system, Android, or Chrome OS,
> >> etc. They don't integrate userspace usb_modeswitch utility for
> >> switching.
>
> >Why not? If they can upgrade the kernel, then they
Hello Felipe,
On Mon, Mar 04, 2013 at 04:38:10PM +0200, Felipe Balbi wrote:
> On Thu, Feb 28, 2013 at 11:38:52AM +0100, Fabio Baltieri wrote:
> > Add transceiver notifier event handling to the ux500 driver to set vbus
> > on specific transceiver events.
> >
> > Acked-by: Linus Walleij
> > Signed
On Tue, Mar 05, 2013 at 01:23:33PM +0100, Bjørn Mork wrote:
> As you are well aware of, we parse descriptors as needed on Linux and
> can just as easy support the Windows look'n'feel if required. There is
> absolutely no need to create special Linux descriptors to adapt to
> existing drivers. We'
Hello Mork,
>> -- Because in the embedded linux system, Android, or Chrome OS,
>> etc. They don't integrate userspace usb_modeswitch utility for
>> switching.
>Why not? If they can upgrade the kernel, then they most certainly can install
>a userspace utility.
>There is no excuse for an e
On Wed, Mar 06, 2013 at 12:22:24AM +0200, Felipe Balbi wrote:
> Hi,
>
> On Tue, Mar 05, 2013 at 11:16:44PM +0100, Arnd Bergmann wrote:
> > 1bf0cf6040 "usb: gadget: omap_udc: convert to udc_start/udc_stop"
> > made some trivial changes but was missing a ';' character.
> >
> > 8c4cc00552 "ARM: OMAP
Looks fine on the xHCI portion. Thanks for catching the XHCI_BROKEN_MSI
case.
Acked-by: Sarah Sharp
On Mon, Mar 04, 2013 at 05:14:43PM +0100, Thomas Renninger wrote:
> From: Hannes Reinecke
>
> xhci has its own interrupt enabling routine, which will try to
> use MSI-X/MSI if present. So the u
[now this discussion has turned to usb gadget
+cc Felipe Balbi, linux-usb, -cc Dave Jones, Ilya Zykov]
On Tue, 2013-03-05 at 23:39 +0100, Jiri Slaby wrote:
> On 03/05/2013 11:20 PM, Peter Hurley wrote:
> > [--cc Alan Cox]
> >
> > On Tue, 2013-03-05 at 21:50 +0100, Sebastian Andrzej Siewior wrote:
On Thu, Feb 28, 2013 at 12:40:46PM -0500, Tony Camuso wrote:
> On 02/27/2013 07:20 PM, Sarah Sharp wrote:
> >
> >Basically, I'd like Tony to make his first patch work, rather than
> >pursuing moving the timer manipulation to xhci_bus_suspend/resume.
> >
>
> Not to add confusion, but here is a less
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, March 05, 2013 2:48 AM
>
> On Mon, Mar 04, 2013 at 12:21:46PM -0800, Paul Zimmerman wrote:
> > +#include "hcd.h"
> > +
> > +#ifdef VERBOSE_DEBUG
>
> could move this inside the function body so you can call it
> unconditionally.
Will do.
On Fri, Mar 01, 2013 at 08:41:13AM +0100, Hannes Reinecke wrote:
> On 02/27/2013 10:13 PM, Bjorn Helgaas wrote:
> >[+cc Andy]
> >
> >3) I don't understand why the xhci init fails in the first place. It
> >looks like the "request interrupt 255 failed" message is from
> >xhci_try_enable_msi(), but t
On Tue, 2013-03-05 at 23:10 +0100, Jiri Slaby wrote:
> On 03/05/2013 11:02 PM, Peter Hurley wrote:
> > On Tue, 2013-03-05 at 22:56 +0100, Jiri Slaby wrote:
> >> On 03/05/2013 06:06 PM, Peter Hurley wrote:
> > @@ -225,15 +232,13 @@ void tty_port_hangup(struct tty_port *port)
> spin_
Hi,
On Tue, Mar 05, 2013 at 11:16:44PM +0100, Arnd Bergmann wrote:
> 1bf0cf6040 "usb: gadget: omap_udc: convert to udc_start/udc_stop"
> made some trivial changes but was missing a ';' character.
>
> 8c4cc00552 "ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions
> to mach-omap1" added a defini
On Fri, Mar 01, 2013 at 08:48:39AM -0800, Greg KH wrote:
> On Wed, Feb 13, 2013 at 02:12:50PM -0800, Sarah Sharp wrote:
> > On Wed, Feb 13, 2013 at 01:31:29PM -0800, Greg KH wrote:
> > > On Wed, Feb 13, 2013 at 01:08:46PM -0800, Sarah Sharp wrote:
> > > > On Wed, Feb 13, 2013 at 09:04:13PM +0100, M
On 03/05/2013 11:02 PM, Peter Hurley wrote:
> On Tue, 2013-03-05 at 22:56 +0100, Jiri Slaby wrote:
>> On 03/05/2013 06:06 PM, Peter Hurley wrote:
> @@ -225,15 +232,13 @@ void tty_port_hangup(struct tty_port *port)
spin_lock_irqsave(&port->lock, flags);
port->count = 0;
On Tue, 2013-03-05 at 22:56 +0100, Jiri Slaby wrote:
> On 03/05/2013 06:06 PM, Peter Hurley wrote:
> >>> @@ -225,15 +232,13 @@ void tty_port_hangup(struct tty_port *port)
> >> spin_lock_irqsave(&port->lock, flags);
> >> port->count = 0;
> >> port->flags &= ~ASYNC_NORMAL_ACTI
On 03/05/2013 06:06 PM, Peter Hurley wrote:
>>> @@ -225,15 +232,13 @@ void tty_port_hangup(struct tty_port *port)
>> spin_lock_irqsave(&port->lock, flags);
>> port->count = 0;
>> port->flags &= ~ASYNC_NORMAL_ACTIVE;
>> - if (port->tty) {
>> + if (port->tty)
>>
kfree on NULL pointer is a no-op.
Signed-off-by: Syam Sidhardhan
---
drivers/usb/serial/mos7840.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index 809fb32..107ff9e 100644
--- a/drivers/usb/serial/mos7840.c
kfree on NULL pointer is a no-op.
Signed-off-by: Syam Sidhardhan
---
drivers/usb/otg/fsl_otg.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/otg/fsl_otg.c b/drivers/usb/otg/fsl_otg.c
index d16adb4..37e8e15 100644
--- a/drivers/
* Fengguang Wu | 2013-03-05 18:35:13 [+0800]:
>Note that I still get this warning, however looks like an unrelated
>issue:
>
>[ 602.536679] [ INFO: possible circular locking dependency detected ]
>[ 602.536672]
>[ 602.536679] ==
>[ 602.53667
* Felipe Balbi | 2013-03-05 12:49:44 [+0200]:
>> I kinda assumed that this was already fixed (i.e. a patch like this was sent)
>> but it seems not to be that case.
>
>already in Greg's queue, cheers
great…
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the b
Alan Stern writes:
> On Tue, 5 Mar 2013, Bjørn Mork wrote:
>> Ming Lei writes:
>>
>> > Yes, USB core will flush any outstanding URBs, but the driver still need
>> > to deal with suspend failure carefully, for example, suppose usb_resume()
>> > is called in suspend failure path, and the submitted
On Tue, Mar 05, 2013 at 11:43:35AM -0500, Alan Stern wrote:
> On Tue, 5 Mar 2013, Felipe Balbi wrote:
>
> > Anyway, details are as follows:
> >
> > readl() and writel() always add a memory barrier around each operation.
>
> Is that supposed to be true on all architectures or only on ARM?
I beli
On Tue, 2013-03-05 at 17:02 +0100, Jiri Slaby wrote:
> On 02/28/2013 09:57 PM, Peter Hurley wrote:
> > Hi Jiri,
> >
> > Just wanted to make sure you saw this series.
>
> Hi, thanks for letting me know. Johan, care to CC Alan Cox and me (or at
> least LKML) when you're changing the TTY core next t
On Tue, 5 Mar 2013, Bjørn Mork wrote:
> Ming Lei writes:
>
> > Yes, USB core will flush any outstanding URBs, but the driver still need
> > to deal with suspend failure carefully, for example, suppose usb_resume()
> > is called in suspend failure path, and the submitted URBs are killed
> > by US
On 03/05/2013 07:21 AM, Kishon Vijay Abraham I wrote:
> From: Graeme Gregory
>
> This is the driver for the OTG transceiver built into the Palmas chip. It
> handles the various USB OTG events that can be generated by cable
> diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
> b
On Tue, 5 Mar 2013, Felipe Balbi wrote:
> Anyway, details are as follows:
>
> readl() and writel() always add a memory barrier around each operation.
Is that supposed to be true on all architectures or only on ARM?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-u
On Tue, 5 Mar 2013, Lan Tianyu wrote:
> Ok apply it. Retest. No problem.
>
> The following log only takes place When I stop ehci-test or unplug
> device during test.
> [ 140.871303] ehci-pci :00:1a.0: shutdown urb 88014545f0c0 ep1in-bulk
> [ 140.878231] ehci-pci :00:1a.0: shutdown u
Ming Lei writes:
> Yes, USB core will flush any outstanding URBs, but the driver still need
> to deal with suspend failure carefully, for example, suppose usb_resume()
> is called in suspend failure path, and the submitted URBs are killed
> by USB core later. But after the device is wakeup, and t
On 02/28/2013 09:57 PM, Peter Hurley wrote:
> Hi Jiri,
>
> Just wanted to make sure you saw this series.
Hi, thanks for letting me know. Johan, care to CC Alan Cox and me (or at
least LKML) when you're changing the TTY core next time?
I have a couple of questions for 2/4:
> Move HUPCL handling
On Tue, Mar 5, 2013 at 11:03 PM, Bjørn Mork wrote:
> Ming Lei writes:
>> On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork wrote:
>>
>>> Now, after inspecting wdm_suspend() which hides behind
>>> info->subdriver->suspend(), I see that this is a completely theoretical
>>> discussion as it always will re
On Tue, Mar 05, 2013 at 08:48:24PM +0530, kishon wrote:
> Hi,
>
> On Tuesday 05 March 2013 08:36 PM, Felipe Balbi wrote:
> >On Tue, Mar 05, 2013 at 08:31:58PM +0530, kishon wrote:
> >>Hi,
> >>
> >>On Tuesday 05 March 2013 08:26 PM, Felipe Balbi wrote:
> >>>On Tue, Mar 05, 2013 at 07:51:58PM +0530,
Hi,
On Tuesday 05 March 2013 08:36 PM, Felipe Balbi wrote:
On Tue, Mar 05, 2013 at 08:31:58PM +0530, kishon wrote:
Hi,
On Tuesday 05 March 2013 08:26 PM, Felipe Balbi wrote:
On Tue, Mar 05, 2013 at 07:51:58PM +0530, Kishon Vijay Abraham I wrote:
return -EPROBE_DEFER from dwc3_omap_mailbox in
On Tue, Mar 05, 2013 at 08:29:34PM +0530, kishon wrote:
> Hi,
>
> On Tuesday 05 March 2013 08:24 PM, Felipe Balbi wrote:
> >On Tue, Mar 05, 2013 at 07:51:57PM +0530, Kishon Vijay Abraham I wrote:
> >>While creating the child devices, *of_platform_populate* sets only
> >>coherent_dma_mask but USBHC
On Tue, Mar 05, 2013 at 08:31:58PM +0530, kishon wrote:
> Hi,
>
> On Tuesday 05 March 2013 08:26 PM, Felipe Balbi wrote:
> >On Tue, Mar 05, 2013 at 07:51:58PM +0530, Kishon Vijay Abraham I wrote:
> >>return -EPROBE_DEFER from dwc3_omap_mailbox in dwc3-omap.c, if the probe of
> >>dwc3-omap has not
Hi,
On Tuesday 05 March 2013 08:24 PM, Felipe Balbi wrote:
On Tue, Mar 05, 2013 at 07:51:57PM +0530, Kishon Vijay Abraham I wrote:
While creating the child devices, *of_platform_populate* sets only
coherent_dma_mask but USBHCD sets *uses_dma* (determines whether the
controller is DMA'able) base
Ming Lei writes:
> On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork wrote:
>
>> Now, after inspecting wdm_suspend() which hides behind
>> info->subdriver->suspend(), I see that this is a completely theoretical
>> discussion as it always will return 0 if PMSG_IS_AUTO(msg) is true...
>>
>> Which means th
Hi,
On Tuesday 05 March 2013 08:11 PM, Sergei Shtylyov wrote:
Hello.
On 05-03-2013 18:37, Kishon Vijay Abraham I wrote:
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-o
Hi,
On Tuesday 05 March 2013 08:26 PM, Felipe Balbi wrote:
On Tue, Mar 05, 2013 at 07:51:58PM +0530, Kishon Vijay Abraham I wrote:
return -EPROBE_DEFER from dwc3_omap_mailbox in dwc3-omap.c, if the probe of
dwc3-omap has not yet been executed or failed.
Signed-off-by: Kishon Vijay Abraham I
-
On Tue, Mar 05, 2013 at 07:51:58PM +0530, Kishon Vijay Abraham I wrote:
> return -EPROBE_DEFER from dwc3_omap_mailbox in dwc3-omap.c, if the probe of
> dwc3-omap has not yet been executed or failed.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/usb/dwc3/dwc3-omap.c |7 +--
>
On Tue, Mar 05, 2013 at 07:51:57PM +0530, Kishon Vijay Abraham I wrote:
> While creating the child devices, *of_platform_populate* sets only
> coherent_dma_mask but USBHCD sets *uses_dma* (determines whether the
> controller is DMA'able) based on dma_mask. So If we haven't explicitly set
> dma_mask
On Tue, Mar 5, 2013 at 9:46 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>> On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork wrote:
>>> Ming Lei writes:
>>>
If suspend callback fails in system sleep context, usb core will
ignore the failure and let system sleep go ahead further, so
this
Hello.
On 05-03-2013 18:37, Kishon Vijay Abraham I wrote:
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dts
Hi,
On Tue, Mar 05, 2013 at 08:07:03PM +0530, Kishon Vijay Abraham I wrote:
> Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
> data file. The information for the entered data node is available @
> Documentation/devicetree/bindings/usb/dwc3.txt
>
> Signed-off-by: Kishon Vija
Add omap-usb3 and omap-usb2 data node in omap5 device tree file.
The information for the node added here is available @
Documentation/devicetree/bindings/usb/usb-phy.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 14 ++
1 file changed, 14 insertions(+)
Add ocp2scp data node in omap5 device tree file. The information for
the node added here can be found @
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arc
Add omap control usb data in omap5 device tree file. This will have the
register address of registers to power on the USB2 PHY and USB3 PHY. The
information for the node added here is available in
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/a
Hi Benoit,
Here are the dt data patches to get usb device functional in OMAP platforms.
This series applies cleanly in both for_3.9/dts and 3.8-rc6.
All the patches deal with modifying arch/arm/boot except one which modifies
Documentation/../usb/omap-usb.txt
Changes from v1:
Patch *ARM: dts: om
Add omap-usb2 data node in omap4 device tree file. Since omap-usb2 is
connected to ocp2scp, omap-usb2 dt data is added as a child node
of ocp2scp. The information about this data node is availabe @
Documentation/devicetree/bindings/usb/usb-phy.txt
Acked-by: Felipe Balbi
Signed-off-by: Kishon Vija
Add dwc3 omap glue data to the omap5 dt data file. The information about
the dt node added here is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --gi
Add dwc3 core dt data as a subnode to dwc3 omap glue data in omap5 dt
data file. The information for the entered data node is available @
Documentation/devicetree/bindings/usb/dwc3.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/omap5.dtsi |7 +++
1 file changed, 7 insert
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-.dts file.
The dt data specifies among others the interface type (ULPI or UTMI), mode
which is mostly OTG, power that specifies the amount of power this can supply
when in host mode.
The
Add omap control usb data in omap4 device tree file. This will have the
register address of registers to power on the PHY and to write to
mailbox. The information about this data node is available @
Documentation/devicetree/bindings/usb/omap-usb.txt
Signed-off-by: Kishon Vijay Abraham I
---
arch
From: Graeme Gregory
This is the driver for the OTG transceiver built into the Palmas chip. It
handles the various USB OTG events that can be generated by cable
insertion/removal.
Signed-off-by: Graeme Gregory
Signed-off-by: Moiz Sonasath
Signed-off-by: Ruchika Kharwar
Signed-off-by: Kishon V
No functional change. Replace *_* with *-* in property names of otg to
follow the general convention.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 12 ++--
drivers/usb/musb/omap2430.c|6 +++---
2 files change
Added palmas-usb driver which is mainly used as comparator driver to
detect vbus/id events when a USB cable is connected and passes on the
event information to omap glue (dwc3-omap.c)
The other fixes include setting dma_mask for dwc3 device since device
tree doesn't fill dma_mask, returning EPROBE
While creating the child devices, *of_platform_populate* sets only
coherent_dma_mask but USBHCD sets *uses_dma* (determines whether the
controller is DMA'able) based on dma_mask. So If we haven't explicitly set
dma_mask, the HCD thinks the controller is not DMA'able and the
controller will fail. So
return -EPROBE_DEFER from dwc3_omap_mailbox in dwc3-omap.c, if the probe of
dwc3-omap has not yet been executed or failed.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/dwc3-omap.c |7 +--
include/linux/usb/dwc3-omap.h |6 +++---
2 files changed, 8 insertions(+), 5 dele
Oliver Neukum writes:
> On Tuesday 05 March 2013 11:07:05 Bjørn Mork wrote:
>> "Fangxiaozhi (Franko)" writes:
>>
>> > -- commit 200e0d99 and commit cd060956, only put the switch
>> > command into kernel, instead of userspace usb_modeswitch utility.
>>
>> Yes. And that is the problem. It wa
On Tue, Mar 5, 2013 at 9:28 PM, Oliver Neukum wrote:
> On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
>> On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum wrote:
>
>> > In other words, if we don't handle errors, there must be no errors,
>> > otherwise it doesn't matter what we do in the error case
Ming Lei writes:
> On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork wrote:
>> Ming Lei writes:
>>
>>> If suspend callback fails in system sleep context, usb core will
>>> ignore the failure and let system sleep go ahead further, so
>>> this patch doesn't recover device under this situation.
>>>
>>> C
On Tuesday 05 March 2013 21:08:09 Ming Lei wrote:
> On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum wrote:
> > In other words, if we don't handle errors, there must be no errors,
> > otherwise it doesn't matter what we do in the error case. We'd leave
> > the problem to generic layers.
>
> Generic
Ming Lei writes:
> On Tue, Mar 5, 2013 at 3:03 PM, Bjørn Mork wrote:
>> Ming Lei writes:
>>
>>> Hi,
>>>
>>> This patch adds comments on interface driver suspend callback
>>> to emphasize that the failure return value is ignored by
>>> USB core in system sleep context, so do not try to recover
>
On Tue, Mar 5, 2013 at 12:01 PM, Ming Lei wrote:
> This patch adds comments on interface driver suspend callback
> to emphasize that the failure return value is ignored by
> USB core in system sleep context, so do not try to recover
> device for this case.
>
> Signed-off-by: Ming Lei
> ---
> inc
On Tue, Mar 5, 2013 at 8:50 PM, Oliver Neukum wrote:
>>
>> IMO, for autosuspend, that is right, but it is not for system suspend,
>> and the driver's suspend callback can't return in resumed state
>> because the USB core will ignore the failure return value and force
>> to suspend the device.
>
>
On Tuesday 05 March 2013 18:55:42 Ming Lei wrote:
> > All these drivers suspend in multiple steps, where each step can
> > fail. If a later step fails then they revert any previously successful
> > step before returning the failure, thereby ensuring that the
> > device/driver state when suspend ret
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>> If suspend callback fails in system sleep context, usb core will
>> ignore the failure and let system sleep go ahead further, so
>> this patch doesn't recover device under this situation.
>>
>> Cc: Bjørn Mork
>> Signed-off
On Tuesday 05 March 2013 11:07:05 Bjørn Mork wrote:
> "Fangxiaozhi (Franko)" writes:
>
> > -- commit 200e0d99 and commit cd060956, only put the switch
> > command into kernel, instead of userspace usb_modeswitch utility.
>
> Yes. And that is the problem. It was agreed years ago that this
>
Oliver Neukum writes:
> On Monday 04 March 2013 23:28:47 Josua Dietze wrote:
>> > I guess the real problem will be verifying that all of the entries can
>> > go away. This type of hardware tends to get old very fast, but there is
>> > always someone having a really ancient device.
>>
>> I will ch
When running 100 randconfig iterations, I found
the following warning:
drivers/usb/musb/musb_core.c: In function ‘musb_init_controller’:
drivers/usb/musb/musb_core.c:1981:1: warning: label ‘fail5’ defined \
but not used [-Wunused-label]
this patch fixes it by removing the unnecessary
ifde
those are quite unnecessary, the only thing
we need to be careful about is USB_OTG_UTILS
which get properly selected by PHY drivers.
For now, MUSB will select only USB_OTG_UTILS
until we add stubs for the cases when PHY
layer isn't enabled.
Signed-off-by: Felipe Balbi
---
Hi folks,
I plan to s
On Tue, Mar 05, 2013 at 10:50:12AM +, Li Yang-R58472 wrote:
> > Subject: [PATCH 1/1] usb: gadget: fsl_udc_core: Use
> > module_platform_driver_probe macro
> >
> > module_platform_driver_probe() eliminates the boilerplate and simplifies
> > the code.
> >
> > Signed-off-by: Sachin Kamat
> > Cc
Hi,
On Tue, Mar 05, 2013 at 09:42:36AM +0800, Chen Gang wrote:
> 于 2013年03月04日 22:35, Felipe Balbi 写道:
> > this is the wrong fix, I believe. Looks like when I wrote the commits
> > you mention, I deleted more code then I should. Looks like the real fix
> > would be to add back:
> >
> > /* rep
On Tue, Mar 5, 2013 at 3:09 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>> If suspend callback fails in system sleep context, usb core will
>> ignore the failure and let system sleep go ahead further, so
>> this patch doesn't recover device under this situation.
>>
>> Cc: Bjørn Mork
>> Signed-off
Hi,
On Tue, Mar 05, 2013 at 10:03:01AM +0800, Chao Xie wrote:
> >> +enum mv_usb2_phy_type {
> >> + PXA168_USB,
> >> + PXA910_USB,
> >> + MMP2_USB,
> >> +};
> >
> >
> > ewww... you really don't need (and *shouldn't* use) u2o_set() or
> > u2o_clear(). They clearly prevent compiler from o
Commit 80ab72e1 (usb: musb: omap2430: fix the readiness check
in omap_musb_mailbox) made the check incorrect, as we will lose the
glue/link status during the normal built-in probe order (twl4030_usb is
probed after musb omap2430, but before musb core is ready).
As a result, if you boot with USB ca
Fix the following sparse warning:
drivers/usb/musb/omap2430.c:54:33: warning: symbol '_glue' was not declared.
Should it be static?
Signed-off-by: Aaro Koskinen
---
drivers/usb/musb/omap2430.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/
On Tue, Mar 5, 2013 at 3:03 PM, Bjørn Mork wrote:
> Ming Lei writes:
>
>> Hi,
>>
>> This patch adds comments on interface driver suspend callback
>> to emphasize that the failure return value is ignored by
>> USB core in system sleep context, so do not try to recover
>> device for this case, othe
> Subject: [PATCH 1/1] usb: gadget: fsl_udc_core: Use
> module_platform_driver_probe macro
>
> module_platform_driver_probe() eliminates the boilerplate and simplifies
> the code.
>
> Signed-off-by: Sachin Kamat
> Cc: Li Yang
Acked-by: Li Yang
> ---
> drivers/usb/gadget/fsl_udc_core.c | 1
On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> into the kernel. The problem was that u_serial was used by g_cdc before
> u_serial was initialized. In the module case eveything is initialized in
Hi,
On Mon, Mar 04, 2013 at 12:21:46PM -0800, Paul Zimmerman wrote:
> These files contain the HCD code, and implement the Linux
> hc_driver API. Support for both slave mode and buffer DMA mode
> of the controller is included.
>
> Signed-off-by: Paul Zimmerman
> ---
> drivers/usb/dwc2/hcd.c
On Monday, March 04, 2013 05:14:43 PM Thomas Renninger wrote:
> From: Hannes Reinecke
>
> xhci has its own interrupt enabling routine, which will try to
> use MSI-X/MSI if present. So the usb core shouldn't try to enable
> legacy interrupts; on some machines the xhci legacy IRQ setting
> is inval
On Tue, Mar 05, 2013 at 05:57:34PM +0800, Fengguang Wu wrote:
> On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> > Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> > into the kernel. The problem was that u_serial was used by g_cdc before
> > u_s
"Fangxiaozhi (Franko)" writes:
> -- commit 200e0d99 and commit cd060956, only put the switch
> command into kernel, instead of userspace usb_modeswitch utility.
Yes. And that is the problem. It was agreed years ago that this
functionality belongs in userspace. Ref e.g
https://lkml.org/lkml
Hi,
On Tue, Mar 05, 2013 at 08:25:43AM +0800, Greg KH wrote:
> On Mon, Mar 04, 2013 at 12:21:43PM -0800, Paul Zimmerman wrote:
> > Hi Greg,
> >
> > Here is the latest version of the DWC2 patch set. This version includes
> > changes suggested by Felipe in his last review, plus a couple of changes
On Mon, Mar 04, 2013 at 10:28:09PM +0100, Sebastian Andrzej Siewior wrote:
> Fengguang Wu run into a kernel ops after he complied dummy_hcd and g_cdc
> into the kernel. The problem was that u_serial was used by g_cdc before
> u_serial was initialized. In the module case eveything is initialized in
On Fri, Mar 01, 2013 at 03:42:27PM +0100, Michael Grzeschik wrote:
> This patch removes the limitation of having a limited amount of only
> four active tds on one endpoint. We use the linked list implementation
> to manage all tds which get added and removed by hardware_{en,de}queue.
>
> Signed-of
Dear Oliver:
> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.de]
> Sent: Tuesday, March 05, 2013 4:49 PM
> To: Fangxiaozhi (Franko)
> Cc: Bjørn Mork; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> Xueguiying (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil)
Acked-by: Matthew Dharm
Signed-off-by: Bjørn Mork
---
Changes since RFC:
- grammar fix, thanks to Sergei Shtylyov
- added ack from Matthew Dharm
drivers/usb/storage/unusual_devs.h |8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/storage/unusual_devs.h
b/drivers/usb
Bo Shen a écrit :
> Hi Alan,
>
> On 3/4/2013 23:16, Alan Stern wrote:
>> On Mon, 4 Mar 2013, Bo Shen wrote:
>>
>>> Hi Alan,
>>>
>>> On 02/26/2013 04:54 AM, Alan Stern wrote:
Sarah (and anyone else who's interested):
A while ago I wrote about a hardware bug in my Intel ICH5 and ICH8
On Tuesday 05 March 2013 02:28:07 Fangxiaozhi wrote:
Hi,
> 1. As far as I know, usb_modeswitch is now only integrated in the PC
> Linux. It isn't integrated to other system with linux kernel, such as
> Android, Chrome OS, etc. On these system, how can we switch the device?
Then those sys
On Fri, Mar 01, 2013 at 03:42:26PM +0100, Michael Grzeschik wrote:
> Instead of having a limited number of usable tds in the udc we use a
> linked list to support dynamic amount of needed tds for all special
> gadget types. This improves throughput.
>
> This patch also adresses a possible momory l
On Monday 04 March 2013 23:28:47 Josua Dietze wrote:
> > I guess the real problem will be verifying that all of the entries can
> > go away. This type of hardware tends to get old very fast, but there is
> > always someone having a really ancient device.
>
> I will check this and add any missing U
99 matches
Mail list logo
