On 08/11/2016 04:13 PM, Wolfram Sang wrote:
kmalloc will print enough information in case of failure.
Signed-off-by: Wolfram Sang
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
Acked-by: Larry Finger
diff --git a/drivers/net
Alan,
The Lenovo Yogi 13 tablet comes with a Realtek RTL8723AU wireless device built
in. Realtek sent me a driver that I modified so that it would build on new
kernels, and created a GitHub repo so that it would be available to the
community. One of the users of this driver is reporting interm
On 10/05/2013 02:52 PM, Alan Stern wrote:
On Sat, 5 Oct 2013, Larry Finger wrote:
I do however have something fishy to report, but this is probably an
off-topic for linux-usb mailing list so I'll just mention it here
briefly for completeness. Fist, I've compared the speed of the
rt
On 10/05/2013 10:01 AM, Alan Stern wrote:
On Sat, 5 Oct 2013, Arokux X wrote:
Hi all,
first of all thank you all for your help. I now have some news to
report. Using your hint about timing I've inserted a bunch of udelays
around the read/write functions that get called from _rtl92c_write_fw
an
On 09/28/2013 09:57 PM, Alan Stern wrote:
On Sun, 29 Sep 2013, Arokux X wrote:
What happens if you back-port your glue driver to the vendor's kernel?
I have now 200 lines of code which are (almost) identical. They work
in vendor's kernel and fail in mainline.
This indicates that the problem
On 02/06/2013 02:03 PM, Thomas Rosenkranz wrote:
Sorry for aksing back.
1. You mean I should get the kernel clean of the realtek driver first
to prevent a crash during patching? Cause unplugging is no option for
a onboard device.
2. I have no idea what to do with the patching file and couldn't fi
gged; however, the
rest of the system is chugging along.
If 0bda:819a works with rtl8192cu, let me know, and I'll update the USB device
table.
Larry
>From 2bd60bf2a4b91c9ae4e552568c4b76e238fc01a9 Mon Sep 17 00:00:00 2001
From: Larry Finger
Date: Wed, 6 Feb 2013 12:41:36 -0600
S
On 12/27/2012 05:18 PM, Alan Stern wrote:
On Thu, 27 Dec 2012, Larry Finger wrote:
I could not do exactly the experiment that you wanted, as ehci-hcd was loaded
even though it was blacklisted. Rather than solve that problem, I generated a
kernel from just before commit adfa79d with ohci-hcd
On 12/26/2012 09:56 PM, Alan Stern wrote:
This looks like a matter of getting modules to load in the right order.
Apparently your OHCI controller doesn't work right if the EHCI driver
isn't present. Before the troublesome commit, this meant ehci-hcd had
to be loaded before ohci-hcd. Now it mean
On 12/26/2012 10:45 AM, Alan Stern wrote:
I see. Do you happen to have CONFIG_USB_EHCI_HCD=y and
CONFIG_USB_EHCI_PCI=m in your .config? If you do, try changing
EHCI_PCI to y.
One additional data point: When the EHCI and HCD parameters are set to y rather
than m as in the list that follows,
On 12/26/2012 10:45 AM, Alan Stern wrote:
I see. Do you happen to have CONFIG_USB_EHCI_HCD=y and
CONFIG_USB_EHCI_PCI=m in your .config? If you do, try changing
EHCI_PCI to y.
No, they are both "m". My configuration parameters with EHCI in them are
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_EHCI_
On 12/25/2012 10:26 AM, Alan Stern wrote:
On Mon, 24 Dec 2012, Larry Finger wrote:
The problem has been bisected to commit adfa79d entitled "USB: EHCI: make
ehci-pci a separate driver". The symptom is that my NVIDIA controller again
reverts to unended logging of messages of the for
The problem has been bisected to commit adfa79d entitled "USB: EHCI: make
ehci-pci a separate driver". The symptom is that my NVIDIA controller again
reverts to unended logging of messages of the form "hub 2-0:1.0: unable to
enumerate USB device on port 5".
This behavior was previously fixed w
13 matches
Mail list logo
