15. huhtik. 2020, 19.18, Heiner Kallweit <hkallwe...@gmail.com
<mailto:hkallwe...@gmail.com>> kirjoitti:
On 15.04.2020 16:39, Lauri Jakku wrote:
Hi, There seems to he Something odd problem, maybe timing
related. Stripped version not workingas expected. I get back to
you, when i have it working.
There's no point in working on your patch. W/o proper justification it
isn't acceptable anyway. And so far we still don't know which problem
you actually have.
FIRST please provide the requested logs and explain the actual problem
(incl. the commit that caused the regression).
13. huhtik. 2020, 14.46, Lauri Jakku <ljakk...@gmail.com
<mailto:ljakk...@gmail.com>> kirjoitti: Hi, Fair enough, i'll
strip them. -lja On 2020-04-13 14:34, Leon Romanovsky wrote: On
Mon, Apr 13, 2020 at 02:02:01PM +0300, Lauri Jakku wrote: Hi,
Comments inline. On 2020-04-13 13:58, Leon Romanovsky wrote: On
Mon, Apr 13, 2020 at 01:30:13PM +0300, Lauri Jakku wrote: From
2d41edd4e6455187094f3a13d58c46eeee35aa31 Mon Sep 17 00:00:00
2001 From: Lauri Jakku <l...@iki.fi> Date: Mon, 13 Apr 2020
13:18:35 +0300 Subject: [PATCH] NET: r8168/r8169 identifying fix
The driver installation determination made properly by checking
PHY vs DRIVER id's. ---
drivers/net/ethernet/realtek/r8169_main.c | 70
++++++++++++++++++++--- drivers/net/phy/mdio_bus.c | 11 +++- 2
files changed, 72 insertions(+), 9 deletions(-) I would say that
most of the code is debug prints. I tought that they are helpful
to keep, they are using the debug calls, so they are not visible
if user does not like those. You are missing the point of who
are your users. Users want to have working device and the code.
They don't need or like to debug their kernel. Thanks
Hi, now i got time to tackle with this again :) .. I know the proposed fix
is quite hack, BUT it does give a clue what is wrong.
Something in subsystem is not working at the first time, but it needs to be
reloaded to work ok (second time). So what I will do
is that I try out re-do the module load within the module, if there is
known HW id available but driver is not available, that
would be much nicer and user friendly way.
When the module setup it self nicely on first load, then can be the hunt
for late-init of subsystem be checked out. Is the HW
not brought up correct way during first time, or does the HW need time to
brough up, or what is the cause.
The justification is the same as all HW driver bugs, the improvement is
always better to take in. Or do this patch have some-
thing what other patches do not?
Is there legit reason why NOT to improve something, that is clearly issue
for others also than just me ? I will take on the
task to fiddle with the module to get it more-less hacky and fully working
version. Without the need for user to do something
for the module to work.
--Lauri J.
