Date:   Thu, 11 Mar 2021 18:43:54 +0200
From:   gmail <ljakku77@...il.com>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Leon Romanovsky <leon@...nel.org>, netdev@...r.kernel.org,
        nic_swsd@...ltek.com
Subject: Re: NET: r8168/r8169 identifying fix


Heiner Kallweit kirjoitti 11.3.2021 klo 18.23:
> On 11.03.2021 17:00, gmail wrote:
>> 15. huhtik. 2020, 19.18, Heiner Kallweit <hkallweit1@...il.com <mailto:hkallweit1@...il.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 <ljakku77@...il.com
>>         <mailto:ljakku77@...il.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 <lja@....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.
>>
>>
> I have no clue what you're trying to say. The last patch wasn't acceptable at all.
> If you want to submit a patch:
>
> - Follow kernel code style
> - Explain what the exact problem is, what the root cause is, and how your patch fixes it
> - Explain why you're sure that it doesn't break processing on other chip versions
>    and systems.
>
Ok, i'll make nice patch that has in comment what is the problem and how 
does the patch help the case at hand.

I don't know the rootcause, but something in subsystem that possibly is 
initializing bit slowly, cause the reloading

of the module provides working network connection, when done via insmod 
cycle. I'm not sure is it just a timing

issue or what. I'd like to check where is the driver pointer populated, 
and put some debugs to see if the issue is just

timing, let's see.


The problem is that (1st load) fails, but there is valid HW found (the 
ID is known), when the hacky patch of mine

is applied, the second time of loading module works ok, and network is 
connected ok etc.


I make the change so that when the current HEAD code is going to return 
failure, i do check that if the HW id is read ok

from the HW, then pass -EAGAIN ja try to load 5 times, sleeping 250ms in 
between.


--Lauri J.

Powered by blists - more mailing lists