Message-ID: <3e3b4402-3b6f-7d26-10f3-8e2b18eb65c4@gmail.com>
Date:   Thu, 11 Mar 2021 17:23:39 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     ljakku77@...il.com
Cc:     Leon Romanovsky <leon@...nel.org>, netdev@...r.kernel.org,
        nic_swsd@...ltek.com
Subject: Re: NET: r8168/r8169 identifying fix

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.

Powered by blists - more mailing lists