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
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 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
[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 Mon, Jul 25, 2016 at 10:40 AM, wrote:
> From: Vincent Palatin
>
> Check the answers from the USB stack and avoid re-sending multiple times
> the request if the device has disappeared.
>
> Signed-off-by: Vincent Palatin
The original chromium.org code review:
https://chromium-review.googl
-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
On Tue, Jul 26, 2016 at 2:14 PM, Robert Foss wrote:
...
> Thanks for the feedback (for this patch and the other ones)!
> I'm preparing a v2 and will submit it withing a day or two.
Excellent! very welcome and thanks again for picking this up.
...
>> FTR, current drivers/net/usb/ax88179_178a.c u
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
On Mon, Jul 22, 2013 at 10:07 AM, Eric Dumazet wrote:
...
> I guess that if a driver does not advertise NETIF_F_SG, this
> skb_linearize() call is not needed : All frames reaching your xmit
> function should already be linear
As Ben Hutchings pointed out, hw_features is still setting this...but
I
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'd like to see one that
> hits all three drivers and removes all SG and TSO features bits from
> both the
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'
On Wed, Jul 31, 2013 at 3:51 AM, Ming Lei wrote:
> This patch enables 'can_dma_sg' flag for ax88179_178a device
> if the attached host controller supports building packet from
> discontinuous buffers(DMA SG is possible), so both frame header
> and skb data buffers can be passed to usb stack via ur
On Thu, Aug 1, 2013 at 8:36 AM, Eric Dumazet wrote:
...
>> IIRC, cpu_to_leXX() macros return the endian "corrected" value.
>> In other words, they need to be assigned to something, no?
>
> Nope, this in in-place byte swapping (for Big Endian only)
Ah ok - thanks for clarifying. I couldn't find th
On Tue, Aug 6, 2013 at 5:22 AM, Eric Dumazet wrote:
...
>> @@ -1310,6 +1318,10 @@ static int ax88179_reset(struct usbnet *dev)
>>
>> dev->net->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
>>NETIF_F_RXCSUM;
>> + if (dev->can_dma_sg) {
>> +
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
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
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 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
On Sun, Jan 20, 2008 at 01:53:51AM +0100, Stefan Richter wrote:
> Grant Grundler wrote:
> > https://bugs.launchpad.net/ubuntu/+source/hal/+bug/180472
> ...
> > I have a usbmon trace for 2.6.23.13 (appended) along with dmesg output.
> > What I need is someone to inter
On Sat, Jan 19, 2008 at 07:28:29PM -0700, Grant Grundler wrote:
...
> Thanks for reminding me...I had collected strace output of udev and all
> it's children a few days ago (probably with 2.6.22-14-generic (Ubuntu
> kernel). I've appended everything for PID 17972 (which is only
On Sat, Jan 19, 2008 at 08:56:31PM -0600, James Bottomley wrote:
> > it's children a few days ago (probably with 2.6.22-14-generic (Ubuntu
> > kernel). I've appended everything for PID 17972 (which is only 12k, full
> > output is 559KB). Key bit is this:
> > 17972 _llseek(3, 31129600, [3112960
On Sat, Jan 19, 2008 at 08:10:08PM -0700, Grant Grundler wrote:
> [EMAIL PROTECTED]:~ # strace -o strace-dd-HPr707.out dd if=/dev/sda
> of=/dev/null skip=60800 count=1
> dd: reading `/dev/sda': Input/output error
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 55
Hi,
I'm slightly confused by this declaration in drivers/usb/storage/usb.c:
#define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
vendorName, productName,useProtocol, useTransport, \
initFunction, flags) \
...
and in unusual.h:
UAL_DEV( 0
now reports 60800 sectors and udev is happy.
email thread reference:
http://marc.info/?t=12007648332&r=1&w=2
Signed-off-by: Grant Grundler <[EMAIL PROTECTED]>
--- linux-2.6.23.13/drivers/usb/storage/unusual_devs.h 2008-01-19
19:59:15.0 -0800
+++ linux-2.6.23-GG
On Sat, Jan 19, 2008 at 10:09:47PM -0800, Matthew Dharm wrote:
> On Sat, Jan 19, 2008 at 09:25:57PM -0700, Grant Grundler wrote:
> > Hi,
> > I'm slightly confused by this declaration in drivers/usb/storage/usb.c:
> > #define UNUSUAL_DEV(id_vendor, id_product,
On Tue, Jan 22, 2008 at 09:27:09PM -0800, Phil Dibowitz wrote:
...
> Patch looks fine to me. Let me get my tree in order (sorry, been really
> swamped lately so I haven't updated in a while), make sure this diff's
> nicely against the latest rc's,
It's not. It's against 2.6.23. But I expect it to
On Tue, Jan 22, 2008 at 11:55:56PM -0700, Grant Grundler wrote:
...
> > http://www.phildev.net/linux/usb-unusualdevs-notes.html
>
> In general, a very helpful document! Thanks!
...
I read the rest of the document and explains exactly my confusion.
Can you please include that d
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. Panic output
below is from Exynos 5422 system. Test script attached.
My _guess_ is usbnet_stop() is raci
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 -
On Mon, Mar 10, 2014 at 7:53 PM, Julius Werner wrote:
> I think usbnet_stop() raced with the dev->bh tasklet, which by itself
> might not be a problem (usbnet_stop() later kills the tasklet itself,
> so it should expect that it can be running before that). The issue is
> that it calls usbnet_termi
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
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 Mon, Mar 17, 2014 at 2:55 PM, Oliver Neukum wrote:
> On Mon, 2014-03-17 at 14:53 -0700, Julius Werner wrote:
>> Hi Oliver,
>>
>> Any update on the state of this patch? Did it get picked up for merge
>> somewhere? Do you agree with my suggestion of sticking closer to the
>> original logic instea
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 "Bad Spinlock Magic" error and subsequent pagefault.
I believe the sequence was:
usbnet_op
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 "
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.
@@ -1536,6 +1536,7 @@ usbnet_probe (struct usb_interface *udev, const struct usb
dev->driver_name
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.
>
> @@ -
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)) {
Yes - building new image now (and transfer to USB and boot from USB).
Should know in an hour or so (doing other t
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)) {
>
&
On Fri, Mar 21, 2014 at 1:33 AM, Oliver Neukum wrote:
...
> Very well. Thorough testing is good. I'll wait for the result. Could
> you notify me of the final outcome?
Ceratinly. Bad news is I had to restart my workstation that was
driving the test due to completely different issue (loopbacks hung
On Fri, Mar 21, 2014 at 1:33 AM, Oliver Neukum wrote:
...
> Very well. Thorough testing is good. I'll wait for the result. Could
> you notify me of the final outcome?
Ship it. :)
The testing so far has completed over 15K iterations of unload/reload
of the asix driver on the original failing syst
On Tue, Mar 4, 2014 at 4:01 AM, Hayes Wang wrote:
> Reset and reinitialize the device when the tx timeout occurs.
Hayes,
I believe this patch was dropped after the series was split.
Can you please repost this patch by itself?
(and fix the "function" typo in the patch header)
>
> Signed-off-by:
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 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
>>>
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/r8152.c | 2 ++
1 file changed, 2 insertions(+)
This was tested on chromeos-3.14, chromeos-3.18
[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/cdc_ether.c | 8
drivers/net/usb/r8152.c | 2 ++
2 files changed, 10 insertions
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
On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote:
> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>
>> I know that for at least some of the adapters in the CDC Ethernet
>> blacklist it was claimed that the CDC Ethernet support in the adapter
>> was kinda broken anyway so th
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
53 matches
Mail list logo
