On Tue, 2014-04-15 at 20:54 +0200, Stefani Seibold wrote:
> > > > > [1.170029] xhci_hcd 0001:03:00.0: xHCI Host Controller
> > > > > [1.175306] xhci_hcd 0001:03:00.0: new USB bus registered,
> > > > > assigned bus number 1
> > > > > [1.212561] xhci_hcd 0001:03:00.0: Hos
> First of all, please reply to the original thread and make sure to not
> drop people or lists from CC.
Sorry this is my first patch and i didn't know that. Now I know.
> For arrays you can use the ARRAY_SIZE() macro if that was the reason for
> this change. I should have mentioned that when I p
Signed-off-by: Mickael Maison
---
drivers/usb/gadget/mv_udc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/mv_udc_core.c b/drivers/usb/gadget/mv_udc_core.c
index fcff3a5..040fb16 100644
--- a/drivers/usb/gadget/mv_udc_core.c
+++ b/drivers/usb/gad
On 2014-06-03 10:29, Oliver Neukum wrote:
No, if you are using the current upstream, xhci_hcd can do dynamic
debugging. No need to recompile.
Can you please provide me with instructions (console commands) on how to
enable and capture xhci_hcd dynamic debugging verbatim with the current
upstre
[Added Mathias to CC: list]
On Sat, 7 Jun 2014, Benjamin Herrenschmidt wrote:
> I'm trying to kexec from our OPAL FW bootloader (3.10.23 based) to a
> fedora 3.14.3 on a new machine and am still seeing the above.
>
> A reset brings the chip back.
>
> Do we have any resolution here ? It looks l
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote:
> The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP)
> that causes the shutdown routine to reset the controller. It wasn't
> meant for fixing kexec problems, but I bet you could use it for that
> purpose.
>
> In addition
Just got the below when I plugged in a new webcam. Not sure it's a bug
in xhci (using GFP_KERNEL presumably) or (less likely?) in the USB
autosuspend code.
johannes
[ 141.317464] usb 1-1: new high-speed USB device number 2 using xhci_hcd
[ 141.558966] usb 1-1: New USB device found, idVendor=058
On mer., 2014-05-21 at 13:50 -0400, Alan Stern wrote:
> On Wed, 21 May 2014, Mildred Ki'Lya wrote:
>
> > Hi,
> >
> > I have a problem with a USB device (4255:1000), running various kernels
> > from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux). When I connect the
> > device, it appears all right. But
>> Can I disable VBUS while keeping the rest of USB functional for a
>> device that does not require bus power?
>
> unfortunately not, your device would see a disconnection. The reason is
> that even though you don't really put any load on the bus, the PHY still
> samples VBUS levels to know when t
On Sat, 2014-06-07 at 11:40 -0400, Alan Stern wrote:
> The current xhci-hcd driver includes a quirk flag (XHCI_SPURIOS_WAKEUP)
> that causes the shutdown routine to reset the controller. It wasn't
> meant for fixing kexec problems, but I bet you could use it for that
> purpose.
>
> In additio
On Sat, 7 Jun 2014, Grant wrote:
> >> Can I disable VBUS while keeping the rest of USB functional for a
> >> device that does not require bus power?
> >
> > unfortunately not, your device would see a disconnection. The reason is
> > that even though you don't really put any load on the bus, the PH
On Sun, 8 Jun 2014, Benjamin Herrenschmidt wrote:
> Looking at the code a bit more ... that xhci_shutdown() worries me.
>
> It basically just whacks xhci_halt() and optionally reset() but nothing
> is done that I can see to ensure that we aren't concurrently
> doing things like queuing URBs, poll
On Sat, 7 Jun 2014, Mildred Ki'Lya wrote:
> On mer., 2014-05-21 at 13:50 -0400, Alan Stern wrote:
> > On Wed, 21 May 2014, Mildred Ki'Lya wrote:
> >
> > > Hi,
> > >
> > > I have a problem with a USB device (4255:1000), running various kernels
> > > from 3.12.6 (Fedora) up to 2.14.4 (ArchLinux).
13 matches
Mail list logo
