[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d43ad04e-8c24-d17c-ef09-984924ad1c4c@gmail.com>
Date: Thu, 17 Nov 2022 02:13:49 +1100
From: Albert Zhou <albert.zhou.50@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
nic_swsd@...ltek.com, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, netdev@...r.kernel.org,
Hayes Wang <hayeswang@...ltek.com>
Subject: Re: [PATCH net-next RFC 0/5] Update r8152 to version two
On 10/11/22 05:40, Jakub Kicinski wrote:
> On Wed, 9 Nov 2022 15:43:21 +1100 Albert Zhou wrote:
>> The version-one r8152 module, for some reason, cannot maintain high
>> data-transfer speeds. I personally experienced this problem myself, when
>> I bought a new USB-C to ethernet adapter. The version-two module fixes
>> this issue.
>
> I see, perhaps it'd be possible to zero in on how the datapath of
> the driver is implemented?
Hi all,
After a lot of testing, I have come to the conclusion that the reason
for the speed difference between the v1 and v2 driver is actually the
firmware.
The v2 driver doesn't even #include <linux/firmware.h>; so it doesn't
load the standard firmware in /lib/firmware/rtl_nic. It seems the
firmware is actually written in the source and loaded directly.
Since firmware is not even part of the kernel, it's probably
inappropriate to submit a patch that modifies the firmware of a device,
would that be correct?
If that's the case, it's probably best if Realtek can update the
firmware on the linux firmware git.
Not sure otherwise how to proceed. Any suggestions?
Best,
Albert
Download attachment "OpenPGP_0x218FE344C5A6867D.asc" of type "application/pgp-keys" (641 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists