kernel.org
Signed-off-by: Grant Hernandez
---
drivers/input/tablet/gtco.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 4b8b9d7aa75e..9771052ed027 100644
--- a/drivers/input/tablet/gtco.c
+++
Tested with a board containing LPC3250 SOC and STOTG04 PHY by using
serial gadget.
Needed patch series starting with "[PATCH 0/5] usb: gadget: udc:
lpc32xx: add stotg04 phy support" also.
Tested-by: James Grant
Regards,
James Grant.
On 11/05/2019 00:42, Alexandre Belloni wrot
Tested with a board containing LPC3250 SOC and STOTG04 PHY by using
serial gadget.
Needed patch "[PATCH] usb: gadget: udc: lpc32xx: allocate descriptor
with GFP_ATOMIC" also.
Tested-by: James Grant
Regards,
James Grant.
On 09/04/2019 14:09, Alexandre Belloni Wrote:
Hi,
T
Hi here
There are a lot of emails on this list. Do you use a bug tracker?
Otherwise, I can unsubscribe, and anyone can email me on j...@jguk.org if
they want to work on it.
Regards
Jonny
On 02/07/18 21:20, Jonny Grant wrote:
Hi!
My ZyDAS USB wifi works well on other laptop, and this
On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski wrote:
> On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler wrote:
>> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski
>> wrote:
>>>
>>> commit 90841047a01b452cc8c3f9b990698b264143334a upstream
>>>
t;
> Signed-off-by: Grant Grundler
> Reviewed-by: Douglas Anderson
> Signed-off-by: David S. Miller
> [krzk: Rebase on v4.4]
> Signed-off-by: Krzysztof Kozlowski
thanks krzk!
FTR, to support RTL8153B (HW ID 0x6010), the follow patch series to
bring r8152 v1.09.9 driver from 4.14 ke
On Sun, Oct 1, 2017 at 10:39 PM, David Miller wrote:
> From: Grant Grundler
> Date: Thu, 28 Sep 2017 11:35:00 -0700
>
>> This linksys dongle by default comes up in cdc_ether mode.
>> This patch allows r8152 to claim the device:
>>Bus 002 Device 002: ID 13b1:0041
This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
Bus 002 Device 002: ID 13b1:0041 Linksys
Signed-off-by: Grant Grundler
---
drivers/net/usb/cdc_ether.c | 10 ++
drivers/net/usb/r8152.c | 2 ++
2 files changed, 12 insertions
Hi Doug!
On Wed, Sep 27, 2017 at 4:47 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, Sep 27, 2017 at 10:28 AM, Grant Grundler
> wrote:
>> This linksys dongle by default comes up in cdc_ether mode.
>> This patch allows r8152 to claim the device:
>>Bus 002 De
This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
Bus 002 Device 002: ID 13b1:0041 Linksys
Signed-off-by: Grant Grundler
---
drivers/net/usb/cdc_ether.c | 10 ++
drivers/net/usb/r8152.c | 2 ++
2 files changed, 12 insertions
in this
>> situation that they simply need to enable the R8152 driver to get
>> continued support for their Ethernet adapter?
>
> Hi,
>
> yes, it is a valid concern. An #ifdef will be needed.
Good idea - I will post V3 shortly.
I'm assuming you mean to add #ifdef CO
On Mon, Sep 25, 2017 at 1:17 PM, Grant Grundler wrote:
...
> I didn't realize cdc_ether has a blacklist to make sure
> RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you
> prefer I add this device to the blacklist in the same patch?
I've sent a V2 which also up
This linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
Bus 002 Device 002: ID 13b1:0041 Linksys
Signed-off-by: Grant Grundler
---
drivers/net/usb/cdc_ether.c | 8
drivers/net/usb/r8152.c | 2 ++
2 files changed, 10 insertions
[grrhmail...sorry! resending as plain text]
Hallo Oliver!
On Mon, Sep 25, 2017 at 7:51 AM, Oliver Neukum wrote:
> Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler:
> > This Linksys dongle by default comes up in cdc_ether mode.
> > This patch allows r8152 to c
This Linksys dongle by default comes up in cdc_ether mode.
This patch allows r8152 to claim the device:
Bus 002 Device 002: ID 13b1:0041 Linksys
Signed-off-by: Grant Grundler
---
drivers/net/usb/r8152.c | 2 ++
1 file changed, 2 insertions(+)
This was tested on chromeos-3.14, chromeos-3.18
Local "#define DRIVER_LICENSE" obfuscates which license is used
in MODULE_LICENSE(). "fgrep -R MODULE_LICENSE" is more informative
when the string is hard coded in MODULE_LICENSE.
Signed-off-by: Grant Grundler
---
Most of the kernel already uses hard coded strings.
The few p
On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet wrote:
> On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote:
>
>> I'm not quite sure how the first From line was added, it
>> should not have been.
>> Grant Grundler is most definitely the author.
>>
>> Woul
e HW than you could possibly ever use. :)
2) Reviewers of this patch series are already wondering how you
verified the AX88772x patches work on current kernel.org (or
netdev-next) branches.
Please email me with your shipping address (OFFLIST!) and I'll try to
send you some Asix HW to test wit
-review.googlesource.com/#/q/Fix+AX88772x+resume+failures
And has substantial meta data regarding author and reviewers:
(summarized from https://chromium-review.googlesource.com/#/c/314520/)
Signed-off-by: Allan Chou
Signed-off-by: WK Tsai
Tested-by: Grant Grundler
Reviewed-by: Wang-Kai Tsai
https://chromium-review.googlesource.com/255931
resulted in some additional commit message meta-data that would be
nice to include in the kernel.org commit message:
Reviewed-by: Julius Werner
Reviewed-by: Douglas Anderson
Tested-by: Douglas Anderson
And yes, patch LGTM too. :)
cheers,
grant
[as plain text this time...]
Robert,
On Mon, Jul 25, 2016 at 10:40 AM, wrote:
> From: Grant Grundler
For the record, I believe I am not the author of these patches.
I believe the original author is
Signed-off-by: Freddy Xin
as recorded in the following code reviews (and testing) t
On Fri, Jul 15, 2016 at 2:25 PM, David Miller wrote:
> From: Grant Grundler
> Date: Thu, 14 Jul 2016 11:27:16 -0700
>
>> ethtool -i provides a driver version that is hard coded.
>> Export the same value via "modinfo".
>>
>> Signed-off-by: Grant Gr
ethtool -i provides a driver version that is hard coded.
Export the same value via "modinfo".
Signed-off-by: Grant Grundler
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0da72d3..1c01ed5 10
On Sun, 21 Jun 2015 21:44:30 +0200
, Stefan Agner
wrote:
> On 2015-06-21 01:49, Peter Stuge wrote:
> > Stefan Agner wrote:
> >> libftdi requires to detach the kernel driver to get access to the device
> >
> > Control transfers ought to be possible without a detach.
>
> Good to know, thanks for
On Tue, Jun 2, 2015 at 2:18 PM, Linus Walleij wrote:
> On Sat, May 30, 2015 at 10:29 PM, Grant Likely
> wrote:
>> On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
>> wrote:
>
>>>> However is the MFD cell approach acceptable?
>>>
>>> Y
On Tue, 26 May 2015 16:18:54 +0100
, Lee Jones
wrote:
> On Thu, 21 May 2015, Thierry Reding wrote:
>
> > On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> > > On Wed, 20 May 2015, Thierry Reding wrote:
> > > > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > > > On Tue
On Mon, Jul 7, 2014 at 6:31 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jul 07, 2014 at 12:44:28PM +0200, Linus Walleij wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Greg Kroah-Hartman
>> wrote:
>> > On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote:
>>
>> >> But I also want to bring the dev
On Tue, Apr 14, 2015 at 10:52:21AM -0400, Alan Stern wrote:
> On Tue, 14 Apr 2015, Alistair Grant wrote:
>
> > Hi Mathias and Alan,
> >
> > As Mathias requested, I've included the usbmon output with the patch
> > applied.
> >
> > It didn't ma
On Mon, Apr 13, 2015 at 04:24:50PM -0400, Alan Stern wrote:
> On Mon, 13 Apr 2015, Mathias Nyman wrote:
>
> > Another difference between EHCI and xHCI iss that xHCI needs to reset (the
> > host side)
> > of a control endpoint if it stalled.
> >
> > From xHCI 1.0 4.8.3:
> >
> > "A STALL detect
Hi Alan,
On Fri, Apr 10, 2015 at 7:23 PM, Alan Stern wrote:
> On Fri, 10 Apr 2015, Alistair Grant wrote:
>> On Fri, Apr 10, 2015 at 5:29 PM, Alan Stern
>> wrote:
>> > On Fri, 10 Apr 2015, Alistair Grant wrote:
>> > ...
>> >> i.e. the mouse works
On Mon, Mar 23, 2015 at 10:14 PM, Devin Heitmueller
wrote:
>
> My guess would be that there's some bug in the cx231xx that
> exacerbates an edge case in the XHCI core - like prematurely setting
> the USB alternate back to zero when stopping streaming and not
> canceling all the URBs first.
>
> ...
Hi Devin,
On Mon, Mar 23, 2015 at 8:16 PM, Devin Heitmueller
wrote:
> Hi Alistair,
>
>> There are some small differences in packet ordering, however the first
>> major difference is an isochronous in packet where the Live2 returns
>> "URB status: No such file or directory (-ENOENT) (-2)".
>>
>> D
Hi Mathias & Devin,
I've changed the subject to avoid any confusion with the patch series
that Mathias just posted for inclusion in 4.0-rc.
On Tue, Mar 17, 2015 at 4:21 PM, Alistair Grant wrote:
>>>>>>> It looks like I may have signed-off a little too soon
On Mon, Mar 16, 2015 at 5:29 PM, Mathias Nyman wrote:
> On 16.03.2015 17:21, Alistair Grant wrote:
>> On Mon, Mar 16, 2015 at 3:47 PM, Mathias Nyman
>> wrote:
>>> On 16.03.2015 16:31, Alistair Grant wrote:
>>>> On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman
On Mon, Mar 16, 2015 at 3:47 PM, Mathias Nyman wrote:
> On 16.03.2015 16:31, Alistair Grant wrote:
>> On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman
>> wrote:
>>> On 15.03.2015 21:18, Alistair Grant wrote:
>>>> On Sun, Mar 15, 2015 at 3:54 PM, Alistair Gran
On Mon, Mar 16, 2015 at 1:55 PM, Mathias Nyman
wrote:
> On 15.03.2015 21:18, Alistair Grant wrote:
>> On Sun, Mar 15, 2015 at 3:54 PM, Alistair Grant
>> wrote:
>>> On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant
>>> wrote:
>>>> On Thu, Ma
On Sun, Mar 15, 2015 at 3:54 PM, Alistair Grant wrote:
> On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant wrote:
>> On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu wrote:
>>> When a device with an isochronous endpoint is plugged into the Intel
>>> xHCI host controller, and
On Thu, Mar 12, 2015 at 8:14 PM, Alistair Grant wrote:
> On Thu, Mar 12, 2015 at 11:15 AM, Lu Baolu wrote:
>> When a device with an isochronous endpoint is plugged into the Intel
>> xHCI host controller, and the driver submits multiple frames per URB,
>> the xHCI driver wil
> Signed-off-by: Lu Baolu
> Tested-by: Alistair Grant
> Tested-by: Devin Heitmueller
> Cc: sta...@vger.kernel.org
> ...
As a workaround until this makes it to the various distributions,
would it be possible to create a config file that enables the quirk,
something like:
REBOOT;
> - xhci->quirks |= XHCI_AVOID_BEI;
> }
> if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
> pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
> --
> 2.1.0
>
> --
This works for me...
Computer: Dell XPS13 9333
Hi Preston,
Are you still maintaining GPIO support for the cp210x driver? I'm
looking at the last set of patches from 2012 that attempted to
mainline it, but it looks like it didn't get anywhere. I'd like to try
again.
Have you looked at CONFIG_GPIO support in the kernel? I think the
biggest comp
Hi Mathias,
On Thu, Mar 5, 2015 at 4:25 PM, Mathias Nyman
wrote:
> On 04.03.2015 15:27, Alistair Grant wrote:
>> On Tue, Mar 3, 2015 at 8:40 PM, Alistair Grant wrote:
>>> On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman
>>> wrote:
>>>> On
Hi Mathias,
On Tue, Mar 3, 2015 at 8:40 PM, Alistair Grant wrote:
> Hi Mathias,
>
> On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman
> wrote:
>> On 28.02.2015 09:16, Alistair Grant wrote:
>>> ...
>>> * 3.19.0 with the following patches:
>>> * xhci:
Hi Mathias,
On Tue, Mar 3, 2015 at 2:21 PM, Mathias Nyman
wrote:
> On 28.02.2015 09:16, Alistair Grant wrote:
>> ...
>> * 3.19.0 with the following patches:
>> * xhci: Allocate correct amount of scratchpad buffers
>> * xhci: Don't touch TRBs memory if those ar
Hi Mathias & Devin,
On Thu, Feb 19, 2015 at 3:18 PM, Mathias Nyman
wrote:
>
> Got one more patch added to the for-usb-next-branch.
> It makes sure we allocate enough scratchpad memory for xhci.
>
> It's one possible cause.
> Patch will anyway go to 3.20, but you can try it out first to see if it
Hi Mathias,
On Wed, Feb 4, 2015 at 5:26 PM, Mathias Nyman
wrote:
> On 27.01.2015 00:20, Alistair Grant wrote:
>> I've come across what appears to be another xHCI issue - attempting to
>> format a disk with gparted is causing a kernel Oops. This may not be
>> r
I've come across what appears to be another xHCI issue - attempting to
format a disk with gparted is causing a kernel Oops. This may not be
related to the issue you're currently investigating, but wanted to
pass it on in case it is (if it isn't let me know and I'll either keep
quiet or raise it se
On Mon, Jan 26, 2015 at 4:37 AM, Devin Heitmueller
wrote:
> Hi Mathias,
>
> Here's an interesting development: as a result of a related thread on
> linux-media, I came across a patch they are distributing in openelec:
>
> https://github.com/OpenELEC/OpenELEC.tv/commit/b636927dec20652ff020e54ed783
Hi Matthias,
On Thu, Jan 22, 2015 at 12:22 PM, Mathias Nyman
wrote:
> On 21.01.2015 21:16, Alistair Grant wrote:
>> Hi Matthias,
>>
>> On Tue, Jan 20, 2015 at 10:22 AM, Mathias Nyman
>> wrote:
>>> On 19.01.2015 22:02, Devin Heitmueller wrote:
>>>&g
Hi Matthias,
On Tue, Jan 20, 2015 at 10:22 AM, Mathias Nyman
wrote:
> On 19.01.2015 22:02, Devin Heitmueller wrote:
>> Hi Mathias,
>>
>> Thanks for getting back to me.
>>
>>> There are a couple of xhci bugs triggered by dvb devices:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=75521
>>> https:
On Wed, Oct 1, 2014 at 4:12 PM, Daniel Drake wrote:
> On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam
> wrote:
>> One reason i doubt why it could be coming is because we are
>> specifically putting the
>> child after doing everything with it.
>>
>> When we are getting the child node using for_each
nected to the host normally?
>> >
>> > Yes. But why do you want to do this?
>>
>>
>> My application calls for low noise so I'm hoping to feed a clean 5V
>> from a battery.
>
> Okay. Not much you can do about noise on the USB data lines, though.
t
>> > situation your comment doesn't apply.
>>
>>
>> I should have been more specific then. I think I understand, but to
>> be sure, if I splice a USB cable, power VBUS with an external 5V power
>> supply, and connect a host and device, the device will
t to
be sure, if I splice a USB cable, power VBUS with an external 5V power
supply, and connect a host and device, the device will work as if the
cable was connected to the host normally?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a m
anyone confirm that it should work? If I
connect a 5V external power supply to the VBUS wire in a USB cable,
the connected USB device should still function?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.
poration 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
/ohci_hcd on my USB3 laptop and it
didn't work.
http://www.newegg.com/Product/Product.aspx?Item=N82E16813190005
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
ples VBUS levels to know when the session is valid (VBUS > 4.4V).
Is that part of the USB spec or is it a Linux driver convention?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo
controller the Beaglebone uses. In general, however,
> it isn't possible to disable Vbus on a USB host port and still use the
> port. To do what you want, you would have to physically cut the Vbus
> wire in the USB cable and splice the device side of that wire to the
> external pow
g.
>
> We 'fixed' them by cutting the wire in the usb cable and driving the
> devices '5v sense' from its local 5v rail.
> (The USB device is permanently connected to the motherboard.)
>
> The ochi driver did recover from the disconnect, but xhci got
> terrib
DC power, your device
> wouldn't work afterward. As Felipe pointed out, the device would think
> the cable had been disconnected.
Understood. Can you tell me how to disable VBUS on the USB
hub/controller? I'll be attempting this on a Beaglebone.
- Grant
--
To unsubscribe from this
ples VBUS levels to know when the session is valid (VBUS > 4.4V).
What if I use a USB cable with a separate DC input for the VBUS?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo
to a USB spec, it's just part of a project I'm working on.
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ples VBUS levels to know when the session is valid (VBUS > 4.4V).
Darn. My goals are to minimize power usage and the amount of
electrical noise traveling to my USB device so I was hoping to
eliminate the otherwise unused VBUS. Any creative ways to pull this
off?
- Grant
--
To unsubscri
Can I disable VBUS while keeping the rest of USB functional for a
device that does not require bus power?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
000 : SPEED_100,
> + DUPLEX_FULL);
> + tp->speed = 0;
Nit: Could rtl_ops.up() set speed since it appears to be changing the
state of the link?
rtl8152_open() uses a remarkably similar code sequence. Is there an
opportunity to refactor and make sure th
usly shared
"for" loop.
Please add my Reported-by + Tested-by to this patch.
thanks
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nted:
e.g. "Don't resend packets during shutdown of this USB net device."
And instead of naming the queue "wait", call the field "shutdown queue".
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a m
On Thu, Mar 20, 2014 at 9:35 AM, Grant Grundler wrote:
> On Thu, Mar 20, 2014 at 12:15 AM, Oliver Neukum wrote:
> ...
>> I have an idea. Could you test this patch?
> ...
>> - if (dev->wait) {
> ..
>> + if (waitqueue_active(&dev->wait)) {
>
&
to check if the waitqueue is active?
This patch should also add a comment to hint why waitqueue_active()
must be called.
Why? Several experienced people looked at the code and didn't see the
problem including the original author of the patch.
thanks,
grant
--
To unsubscribe from this list: se
On Tue, Mar 18, 2014 at 6:40 PM, Grant Grundler wrote:
> On Tue, Mar 18, 2014 at 6:09 PM, Julius Werner wrote:
>> I think a better place for this would be in usbnet_probe() (together
>> with all the other dev->xxx initialization).
>
> Definitely better.
>
> @@ -
agree. I don't expect usbnet_open would get called multiple
times but I'll try the above anyway.
thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 18, 2014 at 1:51 PM, Grant Grundler wrote:
> On Mon, Mar 17, 2014 at 2:55 PM, Oliver Neukum wrote:
>> I am hping for the reporter of the original bug to test it.
>
> Oliver,
> on a haswell system running ChromeOS-3.8 kernel, this patch as-is
> resulted in a "
maybe short a few urbs?
} else if (netif_running (dev->net) &&
Please advise on what you'd like me to try next.
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
about it.
>
> I am hping for the reporter of the original bug to test it.
Ok. I didn't realize I was part of the dependency chain here. :)
It seemed "obvious" to me once Julius described the race.
I'll try it on the offending system but fear I will run into some other prob
On Tue, Mar 11, 2014 at 10:31 AM, Grant Grundler wrote:
> FWIW, I've reproduced this on "Samsung Chromebook" (Exynos 5250) with
FYA - I just noticed the system crashed on the 2048th iteration :)
...
RELOAD 2046 20140310202523 LINK 1000_full (3 sec) IP 192.168.1.116 (
On Tue, Mar 11, 2014 at 10:31 AM, Grant Grundler wrote:
...
> FWIW, I've reproduced this on "Samsung Chromebook" (Exynos 5250) with
> AX88772 USB dongle using the instructions I posted before (ie bouncing
> the USB port with reload_asix script).
Sorry - with AX88178
he
> wake_up() call in usbnet_bh().
Awesome - thanks Julius! :)
FWIW, I've reproduced this on "Samsung Chromebook" (Exynos 5250) with
AX88772 USB dongle using the instructions I posted before (ie bouncing
the USB port with reload_asix script).
cheers,
grant
[23231.533805] asix 3
On Mon, Mar 10, 2014 at 11:33 AM, Grant Grundler wrote:
> I've trying to unravel a page fault panic I've run into a few times
> while testing load/unload of asix driver with ChromeOS 3.8.11 based
> kernel. I'm running into this crash on both ARM and X86.
Correction -
ix driver
completes 200-5000 iterations before failing for different causes.
thanks,
grant
invoke the reload_asix script and monitor test ---
scp reload_asix $T:/tmp
for i in `seq 1`; do echo -n "RELOAD $i " ; ssh $T ".
/tmp/reload_asix eth0 100_full" ; J=$? ; if [ $J -
On Wed, Nov 20, 2013 at 10:54 AM, David Miller wrote:
> From: Grant Grundler
> Date: Wed, 20 Nov 2013 09:42:42 -0800
>
>> While this patch raises a new issue, can you apply this patch anyway
>> since in most cases (default settings) it improves "the user
>> exp
e case that REMOTE_WAKEUP feature doesn't
>> be set when system suspend. In this case, the PHY power will not be turned
>> on again when system resume, so the HW reset must be added in the resume
>> function.
>>
>> Signed-off-by: Freddy Xin
>> Tested-by: Gr
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King
wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King
for the drivers/of/platform.c portion:
Acked-by:
On Sun, Aug 11, 2013 at 8:08 PM, Mark Brown wrote:
> I know there's been some discussion of this topic but do we have any
> general consensus on how to handle such things both from a Linux driver
> model point of view and from a DT/ACPI point of view?
There is precedence for describing enumerated
Ming,
We are splitting hairs now. :) I want to be clear I think your changes
are good and the rest of this conversation is just to learn something
new.
On Thu, Aug 8, 2013 at 4:48 PM, Ming Lei wrote:
> On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler wrote:
...
>>> I am afraid that
On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei wrote:
> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler wrote:
...
>> Following that logic, shouldn't all the features/hw_features settings
>> be removed from reset code path?
>
> This patch won't touch other settings
r can do about it in this case. Perhaps add some udev
rules to preserve ethtool settings the same way I've seen udev rules
to record MAC address to enumerate devices (eth0, eth1, etc.)
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
clarifying. I couldn't find the implementation and
this documentation also helped:
http://kernelnewbies.org/EndianIssues
I don't remember implementing in-place endian correction for
arch/parisc (which is BE). I was expecting to find a generic
definition that did a load/swap/store and di
to no_sg;
> +
> + entry->length = 8;
> + cpu_to_le32s(&tx_hdr1);
> + cpu_to_le32s(&tx_hdr2);
http://lxr.free-electrons.com/source/include/linux/byteorder/generic.h#L111
http://lxr.free-electrons.com/ident?i=
On Tue, Jul 23, 2013 at 7:29 PM, Grant Grundler wrote:
> On Tue, Jul 23, 2013 at 4:46 PM, David Miller wrote:
> ...
>> A quick scan shows that smsc75xx, smsc95xx, and ax88179_178a all have
>> this problem.
>>
>> Instead of the patch starting this thread, I'
ze isn't necessary or helpful either.
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
eatures. I just guessing the skb_linearize()
could be removed until set_features support for SG and/or TSO is
added. Is that correct?
thanks,
grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Mon, Jun 24, 2013 at 08:59AM -0700, Sarah Sharp wrote:
> On Tue, Jun 18, 2013 at 02:09:13PM -0700, Reilly Grant wrote:
> > The context entries field of the slot context must be set to one more
> > than the highest endpoint index currently active. The previous logic
> > onl
The context entries field of the slot context must be set to one more
than the highest endpoint index currently active. The previous logic
only included the set of endpoints currently being added, meaning that
if an endpoint where dropped then the field would be reset to 1,
deactivating all configu
wer get reenumerated as if they had been
unplugged, causing any mounted filesystems to be lost. The
persist feature can still be enabled for individual devices
through the power/persist sysfs node. See
Documentation/usb/persist.txt for more info.
Should I file a kernel bug?
- Grant
--
To unsubsc
hcd'.
I originally wrote a problem report like this but then I convinced
myself that the *real* problem was the one I described in my previous
message which Greg proved it is not.
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ilities: [70] Express Endpoint, MSI 00
Capabilities: [b0] MSI-X: Enable+ Count=8 Masked-
Capabilities: [100] Advanced Error Reporting
Kernel driver in use: xhci_hcd
Kernel modules: xhci_hcd
Should I file a bug?
- Grant
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
th
The context entries field of the slot context must be set to one more
than the highest endpoint index currently active. The previous logic
only included the set of endpoints currently being added, meaning that
if an endpoint where dropped then the field would be reset to 1,
deactivating all configu
The context entries field of the slot context must be set to one more
than the highest endpoint index currently active. The previous logic
only included the set of endpoints currently being added, meaning that
if an endpoint where dropped then the field would be reset to 1,
deactivating all configu
configured endpoints.
The xHCI spec is decidedly unclear on whether this field includes all
configured endpoints or only those being modified by a configure
endpoint command. My interpretation is the former and is the behavior
observed in the Apple's xHCI driver.
Signed-off-by: Reilly
1 - 100 of 128 matches
Mail list logo
