netdev - Re: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANEJEGtGbVajk+GOSkRk1QXDkOOPCM8vO8VA8Zc=TEOfZDjwNQ@mail.gmail.com>
Date:	Fri, 14 Feb 2014 13:53:21 -0800
From:	Grant Grundler <grundler@...gle.com>
To:	hayeswang <hayeswang@...ltek.com>
Cc:	Inki Yoo <inky.yoo@...sung.com>, netdev <netdev@...r.kernel.org>
Subject: Re: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

On Thu, Feb 13, 2014 at 7:13 PM, hayeswang <hayeswang@...ltek.com> wrote:
> Grant Grundler [mailto:grundler@...gle.com]
>> Sent: Friday, February 14, 2014 6:23 AM
>> To: hayeswang
>> Cc: Inki Yoo; netdev; David Miller
>> Subject: Re: RTL8153 fails to get link after applying
>> c7de7dec2 to 3.8 kernel
> [...]
>> That makes sense. How can I check that?
>
> The simple way is to see the led on the device to check the linking
> with the cable attatched before any driver is loaded. Normally, I
> would see the linking before running the OS when I plug the dangle
> and then power on the PC. If you couldn't see the led on the device,
> you could check the one on the switch.

The device has no activity/link state LEDs...but I have the switch
sitting on my desk (8-port Netgear) that I connect it to.

>> Which "configuration" are you referring to?
>
> Configuration 1. That has more power saving features.
>
>> Something like this?
>> /sys/devices/12110000.usb/usb3/3-2/bConfigurationValue
>
> Yes. Modify the value from 2 to 1.

This value was 1 by default on the ARM systems where I don't have
r815x driver and r8152 is claiming the device. I previously tried to
set this value to 1 and I'm wondering if that value will now "stick"
until I reboot. I will add c7de7dec patch again and see what it says.

Testing on x86 (below) shows the value as 2. The x86 system is still
running a kernel that doesn't have either r8152 or r815x driver
enabled.

Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.

localhost 2-1 # cat manufacturer product bConfigurationValue
Realtek
USB 10/100/1000 LAN
2

I've swapped the devices between the two systems and each system
reports the same values. I'll update the x86 system to run a new
kernel (with the c7de7dec patch) and see if what it reports is
different.

...
> My udev rule (50-usb-realtek-net.rules) likes the following.
>
> ACTION!="add", GOTO="usb_realtek_net_end"
> SUBSYSTEM!="usb", GOTO="usb_realtek_net_end"
> ENV{DEVTYPE}!="usb_device", GOTO="usb_realtek_net_end"
> ATTR{idVendor}=="0bda", ATTR{idProduct}=="8153", ATTR{bConfigurationValue}!="1", ATTR{bConfigurationValue}="1"
> LABEL="usb_realtek_net_end"

Thanks for including that.  Would have taken a while for me to figure it out.

cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html