[ledtrig_usbport])
[ 61.060685] [] (led_trigger_set) from []
[...]
Signed-off-by: Christian Lamparter <chunk...@googlemail.com>
---
drivers/usb/core/ledtrig-usbport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/core/ledtrig-usbport.c
b/drivers/usb/core/ledtrig-usbport.c
On Tuesday, January 10, 2017 3:23:24 PM CET John Youn wrote:
> On 1/10/2017 3:03 PM, Christian Lamparter wrote:
> > On Tuesday, January 10, 2017 1:46:56 PM CET John Youn wrote:
> >> On 12/19/2016 6:49 AM, Christian Lamparter wrote:
> >>> (Lot's of old stuf
On Tuesday, January 10, 2017 1:46:56 PM CET John Youn wrote:
> On 12/19/2016 6:49 AM, Christian Lamparter wrote:
> > (Lot's of old stuff, that doesn't matter anymore)
Hello John,
> This should be fixed against the latest dwc2 param rework series [1]
> which i hope to get queued f
Hello John, hello Felipe
On Monday, November 28, 2016 7:32:20 PM CET John Youn wrote:
> On 11/22/2016 12:51 PM, Christian Lamparter wrote:
> > On Monday, November 21, 2016 7:32:30 PM CET John Youn wrote:
> >> On 11/21/2016 1:10 PM, Christian Lamparter wrote:
> >>> O
On Monday, November 21, 2016 7:32:30 PM CET John Youn wrote:
> On 11/21/2016 1:10 PM, Christian Lamparter wrote:
> > On Monday, November 21, 2016 12:16:31 PM CET John Youn wrote:
> >> On 11/18/2016 12:18 PM, Christian Lamparter wrote:
> >>> On Friday, November 18, 2
Hello John,
On Monday, November 21, 2016 12:16:31 PM CET John Youn wrote:
> On 11/18/2016 12:18 PM, Christian Lamparter wrote:
> > On Friday, November 18, 2016 8:16:08 AM CET Rob Herring wrote:
> >> On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
> >&g
| 2 +-
> drivers/usb/dwc2/hcd.c | 8 +--
> drivers/usb/dwc2/params.c | 79
> ++
> drivers/usb/dwc2/pci.c | 1 +
> 6 files changed, 85 insertions(+), 16 deletions(-)
>
Tested-by: Chr
tforms may see better or worse performance based on this
> > > value. The HAPS platform is one example where all INCRx have worse
> > > performance than INCR.
> > >
> > > Other platforms (such as the Canyonlands board) report that the default
> > > val
On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
> On 11/11/2016 2:05 PM, Christian Lamparter wrote:
> > On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
> >> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
> >>> This patch adds support
Hello,
On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
> > This patch adds support for the "amcc,usb-otg" device
> > which is found in the PowerPC Canyonlands' dts.
> >
> > The devic
Cc: Felipe Balbi <felipe.ba...@linux.intel.com>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
drivers/usb/dwc2/params.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 5d822c5..222a83c 1
x.intel.com>
Cc: John Youn <johny...@synopsys.com>
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
v1->v2
- moved definitons to params.c
- removed dma_enable / host_dma parameter
- added dma_desc_fs_enable parameter
---
Documentation/devicetree/bind
to the
linuxppc-dev at the time. However, it was never integrated.
Signed-off-by: Christian Lamparter <chunk...@gmail.com>
---
For anyone interested: the driver was sent to the ML multiple times back
in 2012 [0], [1].
[0] <https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-May/097847.html&g
Hello,
On Tuesday, June 21, 2016 05:56:58 AM Yoshihiro Shimoda wrote:
> > From: Christian Lamparter
> > Sent: Tuesday, June 21, 2016 12:32 AM
> >
> > On Wednesday, June 08, 2016 12:14:57 AM Christian Lamparter wrote:
> > > This patch adds a firmware
On Wednesday, June 08, 2016 12:14:57 AM Christian Lamparter wrote:
> This patch adds a firmware check for the uPD720201K8-711-BAC-A
> and uPD720202K8-711-BAA-A variant. Both of these chips are listed
> in Renesas' R19UH0078EJ0500 Rev.5.00 "User's Manual: Hardware" as
&
an't setup: -110
[ 32.340179] xhci_hcd :45:00.0: USB bus 2 deregistered
[ 32.345587] xhci_hcd :45:00.0: init :45:00.0 fail, -110
[ 32.351496] xhci_hcd: probe of :45:00.0 failed with error -110
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Christian
On Tuesday, May 17, 2016 04:50:48 PM John Youn wrote:
> On 5/14/2016 6:11 AM, Christian Lamparter wrote:
> > On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
> >> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> >>> On Thursday, May 12, 2016 0
On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> >>>>>> Detecti
On Friday, May 13, 2016 03:52:27 PM Arnd Bergmann wrote:
> A patch that went into Linux-4.4 to fix big-endian mode on a Lantiq
> MIPS system unfortunately broke big-endian operation on PowerPC
> APM82181 as reported by Christian Lamparter, and likely other
> systems.
>
> It a
On Thursday, May 12, 2016 11:40:28 AM John Youn wrote:
> On 5/12/2016 6:30 AM, Christian Lamparter wrote:
> > On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> >> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> >>>>>> Detecti
On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> > > > > Detecting the endianess of the
> > > > > device is probably the best future-proof solution, but it's also
> > > >
t would break the one big-endian
> MIPS machine we know about.
>
> > > Detecting the endianess of the
> > > device is probably the best future-proof solution, but it's also
> > > considerably more work to do in the driver, and comes with a
> > > tiny runtime o
t; On Sun, 2016-05-08 at 13:44 +0200, Christian Lamparter wrote:
> > >
> > > The patch that caused the problem had multiple issues:
> > >
> > > - it broke big-endian ARM kernels: any machine that was working
> > > correctly with a little-endian kernel is n
On Sunday, May 08, 2016 08:40:55 PM Benjamin Herrenschmidt wrote:
> On Sun, 2016-05-08 at 00:54 +0200, Christian Lamparter via Linuxppc-dev
> wrote:
> > I've been looking in getting the MyBook Live Duo's USB OTG port
> > to function. The SoC is a APM82181. Which has
Hello,
I've been looking in getting the MyBook Live Duo's USB OTG port
to function. The SoC is a APM82181. Which has a PowerPC 464 core
and related to the supported canyonlands architecture in arch/powerpc/.
Currently in -next the dwc2 module doesn't load:
dwc2 4bff8.usbotg:
. For anyone interested:
support is available with the latest wireshark master/dev tree.
Simply select a packet from the usbip's tcp-stream you are
intrested on and select the USBIP as the protocol in the
"Decode As" dialog box [1].
Signed-off-by: Christian Lamparter <chunk...@google
. For anyone interested:
support is available with the latest wireshark master/dev tree.
Simply select a packet from the usbip's tcp-stream you are
intrested on and select the USBIP as the protocol in the
"Decode As" dialog box [1].
Signed-off-by: Christian Lamparter <chunk...@google
On Thursday 08 August 2013 17:35:34 Oleksij Rempel wrote:
Am 31.07.2013 08:52, schrieb Oleksij Rempel:
Am 28.07.2013 22:41, schrieb Christian Lamparter:
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb
On Thursday 08 August 2013 22:19:32 Alan Stern wrote:
On Thu, 8 Aug 2013, Christian Lamparter wrote:
Anyway, I do have a question about something else too.
in ath9k_htc's hif_usb:
struct usb_host_interface *alt = hif_dev-interface-altsetting[0];
struct usb_endpoint_descriptor
On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
Am 28.07.2013 14:12, schrieb Oleksij Rempel:
Am 28.07.2013 13:38, schrieb Christian Lamparter:
Anyway, I tried the -next branch.
commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
Author: Oleksij Rempel li...@rempel-privat.de
On Wednesday, July 24, 2013 12:37:55 PM Oleksij Rempel wrote:
Am 23.07.2013 20:26, schrieb Christian Lamparter:
On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
Am 22.07.2013 23:23, schrieb Christian Lamparter:
On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
Am
On Tuesday, July 23, 2013 06:59:46 AM Oleksij Rempel wrote:
Am 22.07.2013 23:23, schrieb Christian Lamparter:
On Monday, July 22, 2013 10:47:41 PM Oleksij Rempel wrote:
Am 22.07.2013 21:54, schrieb Christian Lamparter:
Hello!
On Monday, July 22, 2013 05:21:54 PM Oleksij Rempel wrote
On Monday, February 25, 2013 12:41:06 AM Alan Stern wrote:
On Sun, 24 Feb 2013, Christian Lamparter wrote:
The usbmon trace indicates that the data gets delivered to the device
as it should, but the device doesn't accept it for several seconds.
Looking at the logs, I find myself
On Monday, February 25, 2013 04:29:55 PM Alan Stern wrote:
On Mon, 25 Feb 2013, Christian Lamparter wrote:
In fact this is both normal and required. Packets to any particular
endpoint must always be delivered in order. Therefore the URBs have
to complete in the same order as they were
On Monday, February 25, 2013 08:46:23 PM Seth Forshee wrote:
On Mon, Feb 25, 2013 at 11:13:57AM -0800, Sarah Sharp wrote:
Hmm, yeah, that kind of points to an Intel xHCI hardware issue. It's
too bad you don't have a USB analyzer (the high speed ones are about
$480). Can you send me a link
, Christian Lamparter wrote:
So it looks like we need to ask whenever the USB transport
is reliable or not. Did you (by any change) also monitor
usb_tx_anch_urbs [And does it get stuck at some 1 value
as well?]. I'm asking this because if the driver has more than
8 (=AR9170_NUM_TX_URBS
36 matches
Mail list logo
