From: Alexandra Winter <wintera@linux.ibm.com>
To: Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-s390@vger.kernel.org,
Heiko Carstens <hca@linux.ibm.com>,
Thorsten Winkler <twinkler@linux.ibm.com>
Subject: Re: [PATCH net 1/2] s390/qeth: update cached link_info for ethtool
Date: Fri, 5 Aug 2022 09:05:47 +0200 [thread overview]
Message-ID: <7735d444-5041-ccde-accc-5a69af2f2731@linux.ibm.com> (raw)
In-Reply-To: <20220804132742.73f8bfda@kernel.org>
On 04.08.22 22:27, Jakub Kicinski wrote:
> 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?
This was a discussion about existing code. We display default speed and
duplex even when the device is down. And this patch does not change that
behaviour. Andrew rightfully pointed out that this should (eventually) be
changed.
>
>> 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.
This patch is a pre-req for [PATCH net 2/2] s390/qeth: use cached link_info for ethtool
2/2 is the regression fix.
Guidance is welcome. Should I merge them into a single commit?
Or clarify in the commit message of 1/1 that this is a preparation for 2/2?
next prev parent reply other threads:[~2022-08-05 7:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 14:40 [PATCH net 0/2] s390/qeth: cache link_info for ethtool Alexandra Winter
2022-08-03 14:40 ` [PATCH net 1/2] s390/qeth: update cached " Alexandra Winter
2022-08-03 15:19 ` Andrew Lunn
2022-08-04 8:53 ` Alexandra Winter
2022-08-04 13:08 ` Andrew Lunn
2022-08-04 13:44 ` Alexandra Winter
2022-08-04 20:27 ` Jakub Kicinski
2022-08-05 7:05 ` Alexandra Winter [this message]
2022-08-05 21:29 ` Jakub Kicinski
2022-08-03 14:40 ` [PATCH net 2/2] s390/qeth: use " Alexandra Winter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7735d444-5041-ccde-accc-5a69af2f2731@linux.ibm.com \
--to=wintera@linux.ibm.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hca@linux.ibm.com \
--cc=kuba@kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=twinkler@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox