On 11.03.2021 17:00, gmail wrote: > 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. > >
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.
