Hi,
On Mon, Feb 18, 2013 at 05:20:44PM -0500, Alan Stern wrote:
> On Fri, 15 Feb 2013, Felipe Balbi wrote:
>
> > Hi all,
> >
> > I keep seeing the following messages when transferring data to any USB3
> > mass storage I have (tried 3 different ones already):
> >
> > [618002.014556] xhci_hcd 000
Correction, this regression/commit (55bcdce) was introduced between
rc6 and rc7. Sorry about that.
2013/2/18 Ronald :
> CC'ing the author of the patch.
>
> 2013/2/18 Ronald :
> This e-mail is a follow-up as requested in this bug[1]. I will repost
> everything so far in this e-mail. Please
On Mon, Feb 18, 2013 at 05:34:35PM -0500, Alan Stern wrote:
> On Fri, 15 Feb 2013, Arnd Bergmann wrote:
>
> > From: Manjunath Goudar
> >
> > With the multiplatform changes in arm-soc tree, it becomes
> > possible to enable the mvebu platform (which uses
> > ehci-orion) at the same time as other
Use the generic PHY framework API to get the PHY. The usb_phy_set_suspend
and usb_phy_set_resume is replaced with phy_suspend and phy_resume to
align with the new PHY framework.
musb->xceiv can't be removed as of now because musb core uses xceiv.state and
xceiv.otg. Once there is a separate state
In order for controllers to get PHY in case of non dt boot, the phy
binding information should be added in the platform specific
initialization code using phy_bind. The previously added usb_bind_phy
can't be removed yet because the musb controller continues to use the
old PHY library which has OTG
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference to the PHY
without using phandle, the platform specfic intialization code (say from
Used the generic PHY framework API to create the PHY. twl4030_usb_suspend
and twl4030_usb_resume is added to phy_ops in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new
framework comp
Used the generic PHY framework API to create the PHY. omap_usb2_suspend
is split into omap_usb_suspend and omap_usb_resume in order to align
with the new framework.
However using the old USB PHY library cannot be completely removed
because OTG is intertwined with PHY and moving to the new framewor
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY without
using phandle, the platform specfic intialization code (say from board file)
shoul
From: Dan Williams
Date: Mon, 18 Feb 2013 21:25:09 -0600
> It advertises a standard CDC-ETHER interface, which actually should be
> driven by qmi_wwan.
>
> Signed-off-by: Dan Williams
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to m
It advertises a standard CDC-ETHER interface, which actually should be
driven by qmi_wwan.
Signed-off-by: Dan Williams
---
index 3f3d12d..57136dc 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -615,6 +615,13 @@ static const struct usb_device_id products [] = {
Hi all,
I checkout the usb-next branch (on 2/18) and following the
https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build the kernel.
After reboot, the new kernel version is Linux dev 3.8.0-rc5-usbnext #1 SMP Mon
Feb 18 18:04:02 CST 2013 i686 i686 i386 GNU/Linux.
I try the same operation t
4 ports; AT/PPP is standard CDC-ACM. The other three (added by this
patch) are QCDM/DIAG, possibly GPS, and unknown.
Signed-off-by: Dan Williams
---
diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c
index 9b1b96f..31f81c3 100644
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/u
On Tue, 19 Feb 2013, Stefan Tauner wrote:
> Well, I am not entirely sure if even I want this in (as is) yet,
> because it is just a part of a complete solution for my problem and I
> can't imagine a reason why user space would want to know this odd
> value as is.
> So I can not give a committable
On Mon, Feb 18, 2013 at 11:09:53AM +0100, Hannes Reinecke wrote:
>The PCI config space reseves a byte for the interrupt line,
>so irq 255 actually refers to 'not set'.
>However, the 'irq' field for struct pci_dev is an integer,
>so the original meaning is lost, causing the system to
>assign an inte
On Mon, 18 Feb 2013 07:20:56 -0800
Greg KH wrote:
> On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote:
> > This allows user space to retrieve the current frame number on a USB
> > as returned by usb_get_current_frame_number(...) via sysfs.
> >
> > Signed-off-by: Stefan Tauner
> > --
On Mon, Feb 18, 2013 at 7:38 PM, Alan Stern wrote:
> On Mon, 18 Feb 2013, Otavio Salvador wrote:
>
>> >> I thought the ehci-pci module would be load for every ehci PCI; What
>> >> do you think?
>> >
>> > The kernel can't guarantee anything about what driver modules are
>> > loaded. That's up to u
On Mon, 18 Feb 2013, Otavio Salvador wrote:
> >> I thought the ehci-pci module would be load for every ehci PCI; What
> >> do you think?
> >
> > The kernel can't guarantee anything about what driver modules are
> > loaded. That's up to userspace. In particular, the initramfs image
> > must be se
On Fri, 15 Feb 2013, Arnd Bergmann wrote:
> From: Manjunath Goudar
>
> With the multiplatform changes in arm-soc tree, it becomes
> possible to enable the mvebu platform (which uses
> ehci-orion) at the same time as other platforms that require
> a conflicting EHCI bus glue. At the moment, this
On Fri, 15 Feb 2013, Felipe Balbi wrote:
> Hi all,
>
> I keep seeing the following messages when transferring data to any USB3
> mass storage I have (tried 3 different ones already):
>
> [618002.014556] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with
> disabled ep 88012976cd40
>
On Mon, Feb 18, 2013 at 7:09 PM, Alan Stern wrote:
> On Sun, 10 Feb 2013, Otavio Salvador wrote:
>
>> On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern
>> wrote:
>> > On Sun, 10 Feb 2013, Otavio Salvador wrote:
>> >> I do have EHCI and PCI enabled so it should be working. Any clue about
>> >> why it
On Sun, 10 Feb 2013, Otavio Salvador wrote:
> On Sun, Feb 10, 2013 at 12:47 PM, Alan Stern
> wrote:
> > On Sun, 10 Feb 2013, Otavio Salvador wrote:
> >> I do have EHCI and PCI enabled so it should be working. Any clue about
> >> why it breaks it?
> >
> > Perhaps your system is not loading the ne
On Mon, 18 Feb 2013, Stefan Tauner wrote:
> This allows user space to retrieve the current frame number on a USB
> as returned by usb_get_current_frame_number(...) via sysfs.
>
> Signed-off-by: Stefan Tauner
> ---
> That's sadly not necessarily the raw value seen on the bus because
> the individ
On Mon, Feb 18, 2013 at 11:05:57AM -0800, Dmitry Torokhov wrote:
> The IMS PCU (Passenger Control Unit) device used custom protocol over serial
> line, so it is presenting itself as CDC ACM device.
>
> Now that we have proper in-kernel driver for it we need to black-list the
> device in cdc-acm dr
The PCU is a device installed in the armrest of a plane seat and
is connected to IMS Rave Entertainment System. It has a set of control
buttons (Volume Up/Down, Attendant, Lights, etc) on one side and
gamepad-like controls on the other side.
Originally the device was handled from userspace and bec
The IMS PCU (Passenger Control Unit) device used custom protocol over serial
line, so it is presenting itself as CDC ACM device.
Now that we have proper in-kernel driver for it we need to black-list the
device in cdc-acm driver.
Signed-off-by: Dmitry Torokhov
---
drivers/usb/class/cdc-acm.c | 1
IMS, an In Flight Entertainment System provider, has a number of seat displays
Linux. To interact with the user IMS uses a passenger Control Unit (PCU), which
communicates with Rave Display Unit via a USB interface.
Originally large part of the PCU handling was done from userspace and so it
presen
Entertainment systems used in aircraft need additional keycodes for their
Passenger Control Units, so let's add them.
Signed-off-by: Dmitry Torokhov
---
include/uapi/linux/input.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
ind
The difference between v2 and v3 of this patch was mostly cosmetic.
(!(xhci_all_ports_seen_u0(xhci))
... was changed to...
!(xhci_all_ports_seen_u0(xhci))
And ...
"Compliance Mode Recovery Timer Deleted!\n"
... was changed to ...
"Compliance Mode Recovery Timer deleted!\n"
On 02/18/2013
CC'ing the author of the patch.
2013/2/18 Ronald :
This e-mail is a follow-up as requested in this bug[1]. I will repost
everything so far in this e-mail. Please CC me as I'm not subscribed
to your list.
Current head gives this when I plug a 'Mass Storage Device' into a 2.
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP controller,
but it introduced a bug where resume from hibernate would add the
comp_mode_recovery_timer to the timer queue while it was already
active when saved to d
On Mon, Feb 18, 2013 at 03:34:07PM +0100, Stefan Tauner wrote:
> This allows user space to retrieve the current frame number on a USB
> as returned by usb_get_current_frame_number(...) via sysfs.
>
> Signed-off-by: Stefan Tauner
> ---
> That's sadly not necessarily the raw value seen on the bus b
This allows user space to retrieve the current frame number on a USB
as returned by usb_get_current_frame_number(...) via sysfs.
Signed-off-by: Stefan Tauner
---
That's sadly not necessarily the raw value seen on the bus because
the individual driver functions called by usb_get_current_frame_numb
Hi,
>> However, I think the root cause is the same as
>> in previous cores, so it is still would be worth to analyze them.
>> Here is a new picture of the panic:
>> https://dl.dropbox.com/u/8276110/3.7.4%20panic.jpg
>
> Do you have the UAS driver compiled in? I see some functions that could
>
On Monday 18 February 2013, Bo Shen wrote:
> > - .name = "atmel-ehci",
> > + .name = hcd_name,
>
> This change will cause atmel ehci won't work with the none device tree
> kernel.
>
> it can be fixed with replace other places using "atmel-ehci" with
> , that means re
The PCI config space reseves a byte for the interrupt line,
so irq 255 actually refers to 'not set'.
However, the 'irq' field for struct pci_dev is an integer,
so the original meaning is lost, causing the system to
assign an interrupt '255', which fails.
So we should _not_ assign an interrupt valu
On 02/15/2013 06:24 PM, Manjunath Goudar wrote:
Separate the Atmel host controller driver from ehci-hcd host code
into its own driver module.
In V2:
Resolved below compiler error.
drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
drivers/usb/host/ehci-atmel.c:167: error: implic
Hi,
On Monday 18 February 2013 11:40 AM, Chao Xie wrote:
Originaly, udc driver will call the callbacks in platform data
for PHY initialization and shut down.
With PHY driver, it will call the APIs provided by PHY driver
for PHY initialization and shut down. It removes the callbacks
in platform d
38 matches
Mail list logo
