RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[Grant Grundler]

Hi Hayes,
"r8152: ecm and vendor modes coexist" patch prevents RTL8153 device
from establishing a link in the backport I've worked on for
chromeos-3.8 kernel. IIRC, r815x driver claims this device. Without
this patch, r8152 is able to establish a link with RTL8153 device.

This was the last patch in the series of 40 patches that I
cherry-picked and r8152 driver seems to "basically" work WITHOUT this
last patch.  I've not tested much yet...but DHCP worked and I'm able
to run netperf tests. I've not investigated why this patch fails and
probably won't.

If you have opportunity, can you confirm RTL8153 devices work for you
with any recent upstream kernel?

I'm testing with a Realtek branded device that lsusb says is:
   Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.

cheers
grant

git log drivers/net/usb/r8152.c
...
commit c7de7dec2ff2528ec630c55e68c25bd9d972b677
Author: hayeswang <hayeswang@realtek.com>
Date:   Wed Jan 15 10:42:16 2014 +0800

    r8152: ecm and vendor modes coexist

    Remove the limitation that the ecm and r8152 drivers couldn't coexist.
     - Remove the devices from the blacklist of relative drivers.
     - Remove usb_driver_set_configuration() from r8152 driver.
     - Modify the id_table of the r8152 driver for the vendor mode only.

    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

 Grant Grundler [mailto:grundler@google.com] 
> Sent: Tuesday, February 11, 2014 9:39 AM
> To: Hayes Wang
> Cc: inky.yoo@samsung.com; netdev; David Miller
> Subject: RTL8153 fails to get link after applying c7de7dec2 
> to 3.8 kernel
> 
> Hi Hayes,
> "r8152: ecm and vendor modes coexist" patch prevents RTL8153 device
> from establishing a link in the backport I've worked on for
> chromeos-3.8 kernel. IIRC, r815x driver claims this device. Without
> this patch, r8152 is able to establish a link with RTL8153 device.
> 
> This was the last patch in the series of 40 patches that I
> cherry-picked and r8152 driver seems to "basically" work WITHOUT this
> last patch.  I've not tested much yet...but DHCP worked and I'm able
> to run netperf tests. I've not investigated why this patch fails and
> probably won't.
> 
> If you have opportunity, can you confirm RTL8153 devices work for you
> with any recent upstream kernel?

I had tested the patch before I sent it, and I didn't see any problem.
I would test the RTL8153 again with kernel 3.14-RC2.

Does it work if you unplug and plug the dangle again?
 
Best Regards,
Hayes

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

[Grant Grundler]

On Mon, Feb 10, 2014 at 6:36 PM, hayeswang <hayeswang@realtek.com> wrote:
>  Grant Grundler [mailto:grundler@google.com]
>> Sent: Tuesday, February 11, 2014 9:39 AM
>> To: Hayes Wang
>> Cc: inky.yoo@samsung.com; netdev; David Miller
>> Subject: RTL8153 fails to get link after applying c7de7dec2
>> to 3.8 kernel
>>
>> Hi Hayes,
>> "r8152: ecm and vendor modes coexist" patch prevents RTL8153 device
>> from establishing a link in the backport I've worked on for
>> chromeos-3.8 kernel. IIRC, r815x driver claims this device. Without
>> this patch, r8152 is able to establish a link with RTL8153 device.
>>
>> This was the last patch in the series of 40 patches that I
>> cherry-picked and r8152 driver seems to "basically" work WITHOUT this
>> last patch.  I've not tested much yet...but DHCP worked and I'm able
>> to run netperf tests. I've not investigated why this patch fails and
>> probably won't.
>>
>> If you have opportunity, can you confirm RTL8153 devices work for you
>> with any recent upstream kernel?
>
> I had tested the patch before I sent it, and I didn't see any problem.

Excellent - thank you! :)

> I would test the RTL8153 again with kernel 3.14-RC2.

Ok - if it worked before...I expect it will continue to work for you.

> Does it work if you unplug and plug the dangle again?

No, it didn't. Same symptom. I did try that.

Offhand, do you know of a reason I should pursue fixing this on
chromeos-3.8? (better performance or more robust?)

Right now I don't think it's worth pursuing since ChromeOS moves to
new kernels slowly but regularly and without this one patch seems to
be working.  We have a fair number of USB and USBNET backports to
support USB 3.0 devices.  So it's a bit of a mess that I really don't
want to dig into unless I have a good reason to.

As long as you are comfortable kernel.org releases are working for
you, the driver should "just work" for ChromeOS when we get to 3.14
(or later) kernels.

thanks for the help!
grant

>
> Best Regards,
> Hayes
>

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

 Grant Grundler [mailto:grundler@google.com] 
> Sent: Wednesday, February 12, 2014 6:27 AM
> To: hayeswang
> Cc: Inki Yoo; netdev; David Miller
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> > I would test the RTL8153 again with kernel 3.14-RC2.
> 
> Ok - if it worked before...I expect it will continue to work for you.

It still works for me. The followings are some messages from Fedora 20 with kernel 3.14.rc2.

# uname -a
Linux fc20.localdomain 3.14.0-rc2 #1 SMP Tue Feb 11 12:36:32 CST 2014 x86_64 x86_64 x86_64 GNU/Linux

# dmesg | tail
[   95.967662] usb 9-1: new SuperSpeed USB device number 2 using xhci_hcd
[   95.984017] usb 9-1: New USB device found, idVendor=0bda, idProduct=8153
[   95.984022] usb 9-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   95.984026] usb 9-1: Product: USB 10/100/1000 LAN
[   95.984030] usb 9-1: Manufacturer: Realtek
[   95.984033] usb 9-1: SerialNumber: 00E04C680022
[   96.011116] usbcore: registered new interface driver cdc_ether
[   96.020634] r815x 9-1:2.0 eth0: register 'r815x' at usb-0000:04:00.0-1, RTL8153 ECM Device, 00:e0:4c:68:00:22
[   96.021866] usbcore: registered new interface driver r815x

# lsusb -d 0bda:8153
Bus 009 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. 

# ethtool -i eth0
driver: r815x
version: 22-Aug-2005
firmware-version: RTL8153 ECM Device
bus-info: usb-0000:04:00.0-1
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 32
	Transceiver: internal
	Auto-negotiation: on
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.94.35  netmask 255.255.255.0  broadcast 192.168.94.255
        inet6 fe80::2e0:4cff:fe68:22  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4c:68:00:22  txqueuelen 1000  (Ethernet)
        RX packets 6  bytes 1593 (1.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51  bytes 6165 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 
> > Does it work if you unplug and plug the dangle again?
> 
> No, it didn't. Same symptom. I did try that.

Is your dangle from Samsung?
I would ask our PM to check if there is any difference between our devices.
Maybe it is not the driver issue.
 
Best Regards,
Hayes

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

[Grant Grundler]

On Tue, Feb 11, 2014 at 7:47 PM, hayeswang <hayeswang@realtek.com> wrote:
> It still works for me. The followings are some messages from Fedora 20 with kernel 3.14.rc2.

Perfect - thanks for following up.

...
> # ethtool -i eth0
> driver: r815x
> version: 22-Aug-2005

BTW, can you please update the version number to match adding RTL8153 support?
Makes life easier for anyone maintaining older kernels.

> Is your dangle from Samsung?

It's labeled "Realtek USB 3.0 Gigabit Ethernet" externally. I'm not
sure if we got these from Samsung or directly from RealTek.

What's notable is this device has no link or activity LEDs visible.
Normally I'd expect those near the RJ45 port.

Also no MAC address or serial number or anything to further identify
the devices. just the "rectangular black plastic" enclosure with a
silver sticker carrying the Realtek logo + text.

> I would ask our PM to check if there is any difference between our devices.
> Maybe it is not the driver issue.

I don't think it's a r8152 or r815x driver issue either. It's much
more likely related to chromeos-3.8 USB NET patches not matching 3.14
kernel behaviors.

Please don't pursue further. Unless I have a good reason to debug
chromeos-3.8 kernel, I'd rather not. If I have problems with 3.12 or
later kernels, I'd be more motivated and will pester you again. :)

Thanks!
grant

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

 Grant Grundler [mailto:grundler@google.com] 
> Sent: Thursday, February 13, 2014 7:58 AM
> To: hayeswang
> Cc: Inki Yoo; netdev; David Miller
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> > # ethtool -i eth0
> > driver: r815x
> > version: 22-Aug-2005
> 
> BTW, can you please update the version number to match adding 
> RTL8153 support?
> Makes life easier for anyone maintaining older kernels.

The information is from ecm driver, maybe cdc_ether or usbnet. I don't
think I could modify it.

> > Is your dangle from Samsung?
> 
> It's labeled "Realtek USB 3.0 Gigabit Ethernet" externally. I'm not
> sure if we got these from Samsung or directly from RealTek.
> 
> What's notable is this device has no link or activity LEDs visible.
> Normally I'd expect those near the RJ45 port.
> 
> Also no MAC address or serial number or anything to further identify
> the devices. just the "rectangular black plastic" enclosure with a
> silver sticker carrying the Realtek logo + text.

According to the information from our FAE about the dangles for samsung,
the default values of some device power are disabled or off. I don't know
the history about this. However, it would cause the dangle no link, because
the ecm driver wouldn't enable them. That is, the dangle couldn't use the
ECM mode. I think you should create a udev rule to change the configuration
to 1 when the dangle is plugged. Then, it could load the vendor mode driver.

> > I would ask our PM to check if there is any difference 
> between our devices.
> > Maybe it is not the driver issue.
> 
> I don't think it's a r8152 or r815x driver issue either. It's much
> more likely related to chromeos-3.8 USB NET patches not matching 3.14
> kernel behaviors.

I don't think so. The reason is as above. Change the configuration of the
device to 1 (vendor mode) is what you have to do.
 
Best Regards,
Hayes

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

[Grant Grundler]

On Wed, Feb 12, 2014 at 6:55 PM, hayeswang <hayeswang@realtek.com> wrote:
...
> According to the information from our FAE about the dangles for samsung,
> the default values of some device power are disabled or off. I don't know
> the history about this. However, it would cause the dangle no link, because
> the ecm driver wouldn't enable them. That is, the dangle couldn't use the
> ECM mode.

That makes sense. How can I check that?

> I think you should create a udev rule to change the configuration
> to 1 when the dangle is plugged. Then, it could load the vendor mode driver.

Which "configuration" are you referring to?
Something like this? /sys/devices/12110000.usb/usb3/3-2/bConfigurationValue

I'm happy to try any command line you give me.

If that command works, I can write the udev rule for future testing
with these devices.

> I don't think so. The reason is as above. Change the configuration of the
> device to 1 (vendor mode) is what you have to do.

Ok...just need one more bit of guidance from you and this will be
resolved I think.

cheers,
grant

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

Grant Grundler [mailto:grundler@google.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.

> > I think you should create a udev rule to change the configuration
> > to 1 when the dangle is plugged. Then, it could load the 
> vendor mode driver.
> 
> 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.

> I'm happy to try any command line you give me.
> 
> If that command works, I can write the udev rule for future testing
> with these devices.

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"
 
Best Regards,
Hayes

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

[Grant Grundler]

On Thu, Feb 13, 2014 at 7:13 PM, hayeswang <hayeswang@realtek.com> wrote:
> Grant Grundler [mailto:grundler@google.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

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

[Grant Grundler]

On Fri, Feb 14, 2014 at 1:53 PM, Grant Grundler <grundler@google.com> wrote:
...
>>> /sys/devices/12110000.usb/usb3/3-2/bConfigurationValue
>>
>> Yes. Modify the value from 2 to 1.

Hayes,
Good News! :)

Setting bConfigurationValue to 1 automatically resulted in the r8152 device
driver getting loaded, claiming the device, and establishing a link when the
 last patch is included.

The first time I tried, I might have mucked something up and was
getting something about "interrupt status -71". I disconnected the
device, rebooted, and started with a clean slate. It worked fine the
second time.  I will temporarily add the udev rule you previously
posted in order to automate testing this until I can get HW that comes
up in "vendor mode".

> This value was 1 by default on the ARM systems

I think I was confused by previous attempts to set the value,
rebooting and still
seeing it set to 1. The ARM system now came up with value 2 after
removing/inserting the Realtek 8153 USB dongle.

> 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.

After "echo 1 > ..../bConfigurationValue" dmesg now says:
[  107.676386] r8152 2-1:1.0 eth0: v1.04.0 (2014/01/15)
[  107.676508] usbcore: registered new interface driver r8152
[  107.695634] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  110.765036] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Thanks for the help Hayes!


cheers,
grant

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

Grant Grundler [mailto:grundler@google.com] 
> Sent: Thursday, February 20, 2014 8:08 AM
> To: hayeswang
> Cc: Inki Yoo; netdev
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
> 
> On Fri, Feb 14, 2014 at 1:53 PM, Grant Grundler 
> <grundler@google.com> wrote:
[...]
> I will temporarily add the udev rule you previously
> posted in order to automate testing this until I can get HW that comes
> up in "vendor mode".

Excuse me if I misunderstand your meaning. Our device has two
configurations and I don't think you would get one with vendor
mode only without ECM mode. Besides, according to the information
from one of the maintainers of the kernel, when a USB device with
more than one configuration is plugged, the USB core would select
the configuration which is not vendor mode first if it exists.
Therefore, it is reasonably considered that the configuration 2
would be set by default for our device if you do nothing.

 
Best Regards,
Hayes

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

[Grant Grundler]

On Wed, Feb 19, 2014 at 8:00 PM, hayeswang <hayeswang@realtek.com> wrote:
> Grant Grundler [mailto:grundler@google.com]
>> Sent: Thursday, February 20, 2014 8:08 AM
>> To: hayeswang
>> Cc: Inki Yoo; netdev
>> Subject: Re: RTL8153 fails to get link after applying
>> c7de7dec2 to 3.8 kernel
>>
>> On Fri, Feb 14, 2014 at 1:53 PM, Grant Grundler
>> <grundler@google.com> wrote:
> [...]
>> I will temporarily add the udev rule you previously
>> posted in order to automate testing this until I can get HW that comes
>> up in "vendor mode".
>
> Excuse me if I misunderstand your meaning. Our device has two
> configurations and I don't think you would get one with vendor
> mode only without ECM mode.

Hayes,
I expect the device to come up in a mode that "just works". I don't
have an expectation of which mode that should be. Perhaps there is
another bug that is causing the ECM mode (bConfigurationValue=2) to
not work?

> Besides, according to the information
> from one of the maintainers of the kernel, when a USB device with
> more than one configuration is plugged, the USB core would select
> the configuration which is not vendor mode first if it exists.

Ah ok. I didn't know that. that sounds reasonable....but it should work.
The drivers clearly don't work with c7de7dec2 patch applied (and
default device settings).

> Therefore, it is reasonably considered that the configuration 2
> would be set by default for our device if you do nothing.

Ok.

I can't apply c7de7dec2 as-is to ChromeOS with the current behaviors.

How would you like to see this fixed?
Have the r815x driver flip the device to "Vendor Mode" and not claim
it so r8152 driver can?
Or you have any idea why ECM mode doesn't work with c7de7dec2 patch?

cheers.
grant

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

Grant Grundler [mailto:grundler@google.com] 
> Sent: Friday, February 21, 2014 1:21 AM
> To: hayeswang
> Cc: Inki Yoo; netdev
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> I can't apply c7de7dec2 as-is to ChromeOS with the current behaviors.
> 
> How would you like to see this fixed?
> Have the r815x driver flip the device to "Vendor Mode" and not claim
> it so r8152 driver can?
> Or you have any idea why ECM mode doesn't work with c7de7dec2 patch?

The reason is that your dangle has the settings of the
customization for some purposes. And it limites the dangle
could use the vendor mode only. My dangle with the official
settings works fine, so I consider that this is not a bug.
Instead, I consider it it the limitation of the hardware.
 
Best Regards,
Hayes

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

[Grant Grundler]

Hi Hayes,

On Sun, Feb 23, 2014 at 10:00 PM, hayeswang <hayeswang@realtek.com> wrote:
...
>> Or you have any idea why ECM mode doesn't work with c7de7dec2 patch?
>
> The reason is that your dangle has the settings of the
> customization for some purposes. And it limites the dangle
> could use the vendor mode only.

Does Realtek have a publicly available tool that I can use to set all
customization back to "official" values?

> My dangle with the official settings works fine, so I consider that this
> is not a bug. Instead, I consider it it the limitation of the hardware.

Sorry, I disagree. Where "customization" is available, I expect the
device driver to know/understand those values OR set them to some
state the driver knows how to deal with. This is a limitation of the
driver, not the HW.



>
> Best Regards,
> Hayes
>

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

Grant Grundler [mailto:grundler@google.com] 
> Sent: Tuesday, February 25, 2014 12:18 AM
> To: hayeswang
> Cc: Inki Yoo; netdev
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> Does Realtek have a publicly available tool that I can use to set all
> customization back to "official" values?

Please contact with the person who give you the dangle.
You should need the another one.

[...]
> Sorry, I disagree. Where "customization" is available, I expect the
> device driver to know/understand those values OR set them to some
> state the driver knows how to deal with. This is a limitation of the
> driver, not the HW.

You couldn't fix it in ECM mode.
The only way is to switch the config to the vendor mode.
 
Best Regards,
Hayes

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

[David Miller]

From: hayeswang <hayeswang@realtek.com>
Date: Wed, 26 Feb 2014 18:13:00 +0800

> Grant Grundler [mailto:grundler@google.com] 
>> Sent: Tuesday, February 25, 2014 12:18 AM
>> To: hayeswang
>> Cc: Inki Yoo; netdev
>> Subject: Re: RTL8153 fails to get link after applying 
>> c7de7dec2 to 3.8 kernel
> [...]
>> Does Realtek have a publicly available tool that I can use to set all
>> customization back to "official" values?
> 
> Please contact with the person who give you the dangle.
> You should need the another one.

This is not an appropriate response.

Your company made a chip, and people are going to repackage it and
reuse it in their own implementations.

Sometimes they will set jumpers incorrectly, add bugs to the firmware,
and make other mistakes.

When you are made explicitly awre of such situations, your driver
should absolutely strive to handle that, rather than refuse to.

It is mysterious to me when a driver author behaves in such a way that
they seem to want their driver to work on fewer instances of their
hardware rather than support more of them.

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

[Grant Grundler]

On Wed, Feb 26, 2014 at 2:13 AM, hayeswang <hayeswang@realtek.com> wrote:
> Grant Grundler [mailto:grundler@google.com]
>> Sent: Tuesday, February 25, 2014 12:18 AM
>> To: hayeswang
>> Cc: Inki Yoo; netdev
>> Subject: Re: RTL8153 fails to get link after applying
>> c7de7dec2 to 3.8 kernel
> [...]
>> Does Realtek have a publicly available tool that I can use to set all
>> customization back to "official" values?
>
> Please contact with the person who give you the dangle.
> You should need the another one.

I'm having that conversation now since I don't know what firmware this
device has or how to update it.

> [...]
>> Sorry, I disagree. Where "customization" is available, I expect the
>> device driver to know/understand those values OR set them to some
>> state the driver knows how to deal with. This is a limitation of the
>> driver, not the HW.
>
> You couldn't fix it in ECM mode.
> The only way is to switch the config to the vendor mode.

Hrm. Or replace the firmware on the device?

cheers,
grant

>
> Best Regards,
> Hayes
>

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

[Grant Grundler]

On Wed, Feb 26, 2014 at 8:58 AM, David Miller <davem@davemloft.net> wrote:
> From: hayeswang <hayeswang@realtek.com>
> Date: Wed, 26 Feb 2014 18:13:00 +0800
>
>> Grant Grundler [mailto:grundler@google.com]
>>> Sent: Tuesday, February 25, 2014 12:18 AM
>>> To: hayeswang
>>> Cc: Inki Yoo; netdev
>>> Subject: Re: RTL8153 fails to get link after applying
>>> c7de7dec2 to 3.8 kernel
>> [...]
>>> Does Realtek have a publicly available tool that I can use to set all
>>> customization back to "official" values?
>>
>> Please contact with the person who give you the dangle.
>> You should need the another one.
>
> This is not an appropriate response.
>
> Your company made a chip, and people are going to repackage it and
> reuse it in their own implementations.
>
> Sometimes they will set jumpers incorrectly, add bugs to the firmware,
> and make other mistakes.
>
> When you are made explicitly awre of such situations, your driver
> should absolutely strive to handle that, rather than refuse to.

Dave,
I agree with this - but it's possible Samsung sent me prototype
devices that are not "final HW" and I sympathize with Hayes that these
handful of devices should be replaced/recycled.  Since these have
"RealTek" logo on them, I expect the HW to be final and something is
b0rked in this device's firmware.

I'll report back once I get this sorted out. I've made it clear to
contacts at both Samsung and Realtek the upstream driver needs to work
and they need to sort out why the devices I have now don't "just
work".

> It is mysterious to me when a driver author behaves in such a way that
> they seem to want their driver to work on fewer instances of their
> hardware rather than support more of them.

Well, we don't know the whole story. Samsung asked for a different USB
Vendor/Device ID and it's possible a few other things got change along
the way.

If this HW/FW was clearly production and I had a patch that made it
work, then we'd be in the situation you are describing.

thanks,
grant

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

[David Miller]

From: Grant Grundler <grundler@google.com>
Date: Wed, 26 Feb 2014 09:19:29 -0800

> On Wed, Feb 26, 2014 at 8:58 AM, David Miller <davem@davemloft.net> wrote:
>> It is mysterious to me when a driver author behaves in such a way that
>> they seem to want their driver to work on fewer instances of their
>> hardware rather than support more of them.
> 
> Well, we don't know the whole story. Samsung asked for a different USB
> Vendor/Device ID and it's possible a few other things got change along
> the way.
> 
> If this HW/FW was clearly production and I had a patch that made it
> work, then we'd be in the situation you are describing.

Ok, fair enough.

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8kernel

[hayeswang]

David Miller [mailto:davem@davemloft.net] 
> Sent: Thursday, February 27, 2014 12:59 AM
> To: hayeswang@realtek.com
> Cc: grundler@google.com; inky.yoo@samsung.com; netdev@vger.kernel.org
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8kernel
[...]
> > Please contact with the person who give you the dangle.
> > You should need the another one.
> 
> This is not an appropriate response.
> 
> Your company made a chip, and people are going to repackage it and
> reuse it in their own implementations.
> 
> Sometimes they will set jumpers incorrectly, add bugs to the firmware,
> and make other mistakes.
> 
> When you are made explicitly awre of such situations, your driver
> should absolutely strive to handle that, rather than refuse to.
> 
> It is mysterious to me when a driver author behaves in such a way that
> they seem to want their driver to work on fewer instances of their
> hardware rather than support more of them.

Normally, the settings are used in Windows driver which fix the
config of the usb device. It is the known issue that the ecm mode
couldn't work with such settings. I don't sure the Samsung understand
this clearly, but our fae has notices them again to explain what
would happen. If you want to fix it, you should switch the config
to the vendor mode to let such vendor control transfers valid.
Therefore, I say it couldn't be fixed in ecm mode, and it is the
limitation of the hardware.

Although we provide the possibility of customization, we wouldn't
know which settings they would use completely. I think the tester
is asked by Samsung, so the better way is to get the device from
the Samsung.

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

 Grant Grundler [mailto:grundler@google.com] 
> Sent: Thursday, February 27, 2014 1:09 AM
> To: hayeswang
> Cc: Inki Yoo; netdev
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> > You couldn't fix it in ECM mode.
> > The only way is to switch the config to the vendor mode.
> 
> Hrm. Or replace the firmware on the device?

The settings are embedded in the hw IC. They could be programed
only once for each IC, and they couldn't be recovered. You could
not modify them by sw or updating something, so I don't know if
there is any tool to change it. The best way is to get an empty
IC and program another settings.
 
Best Regards,
Hayes

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

[Grant Grundler]

On Sun, Mar 2, 2014 at 7:00 PM, hayeswang <hayeswang@realtek.com> wrote:
...
>> Hrm. Or replace the firmware on the device?
>
> The settings are embedded in the hw IC. They could be programed
> only once for each IC, and they couldn't be recovered.

Samsung apparently didn't understand this either and will get me new
devices that are programmed to work with the Linux driver. It's clear
now I'm not going to be able to use the devices I have for ECM mode
testing since a few of the settings are not final.

I now slightly better understand your previous "Windows settings"
comment. And I'm under the impression questions about any HW vendor
shipping devices with "Windows Settings" will land in this forum again
with "WTF? link doesn't come up". Am I judging this correctly?

I think it's Realtek's responsibility to advise those HW vendors more
carefully to make sure what happened to Samsung doesn't happen again.
Either by removing the settings or by adding the support (if possible
for a given setting) to the ECM mode linux driver.

And seriously, thanks for your help since it properly unraveled a
situation neither I nor Samsung engineers could have identified.

thanks,
grant

RE: RTL8153 fails to get link after applying c7de7dec2 to 3.8 kernel

[hayeswang]

Grant Grundler [mailto:grundler@google.com] 
> Sent: Wednesday, March 05, 2014 5:28 AM
> To: hayeswang
> Cc: Inki Yoo; netdev
> Subject: Re: RTL8153 fails to get link after applying 
> c7de7dec2 to 3.8 kernel
[...]
> I now slightly better understand your previous "Windows settings"
> comment. And I'm under the impression questions about any HW vendor
> shipping devices with "Windows Settings" will land in this forum again
> with "WTF? link doesn't come up". Am I judging this correctly?

Excuse me. I don't sure what is your question. I hope the followings
could answer you. The action of setting the configuration for Windows
is done, when the driver is loaded. Therefore, the driver could determine
which config to set, and could avoid this situation. However, the config
is set before loading the the device driver for Linux. Besides, for
keeping the config switchable, the driver wouldn't change the config.
Additionally, the default config which would be set is the ECM mode.
All of them result in the problem you find.

I think the settings is for power saving, because it could save the power
before loading the driver. However, it is not suitable for Linux platform.

> I think it's Realtek's responsibility to advise those HW vendors more
> carefully to make sure what happened to Samsung doesn't happen again.
> Either by removing the settings or by adding the support (if possible
> for a given setting) to the ECM mode linux driver.

Thanks for you suggestions. I would report them to the relative people.