On Thu, 4 Aug 2022 15:08:11 +0200 Andrew Lunn wrote: > On Thu, Aug 04, 2022 at 10:53:33AM +0200, Alexandra Winter wrote: > > Thank you Andrew for the review. I fully understand your point. > > I would like to propose that I put that on my ToDo list and fix > > that in a follow-on patch to net-next. > > > > The fields in the link_info control blocks are used today to generate > > other values (e.g. supported speed) which will not work with *_UNKNOWN, > > so the follow-on patch will be more than just 2 lines. > > So it sounds like your code is all backwards around. If you know what > the hardware is, you know the supported link modes are, assuming its > not an SFP and the SFP module is not plugged in. Those link modes > should be independent of if the link is up or not. speed/duplex is > only valid when the link is up and negotiation has finished. To make sure I understand - the code depends on the speed and duplex being set to something specific when the device is _down_? Can this be spelled out more clearly in the commit message? > Since this is for net, than yes, maybe it would be best to go with a > minimal patch to make your backwards around code work. But for > net-next, you really should fix this properly. Then again this patch doesn't look like a regression fix (and does not have a fixes tag). Channeling my inner Greg I'd say - fix this right and then worry about backports later.
