LinuxPPC-Dev Archive on
 help / color / Atom feed
From: Rick Lindsley <>
To: Lijun Pan <>
Cc:, Lijun Pan <>,
	Tom Falcon <>,
	Paul Mackerras <>,
	Dany Madden <>, Jakub Kicinski <>,
	Sukadev Bhattiprolu <>,, David Miller <>
Subject: Re: [PATCH V2 net] ibmvnic: Continue with reset if set link down failed
Date: Thu, 22 Apr 2021 00:05:41 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Apr 21, 2021 at 3:06 AM Rick Lindsley
<> wrote:

>> Please describe the advantage in deferring it further by routing it through
>> do_hard_reset().  I don't see one.

On 4/21/21 10:12 PM, Lijun Pan replied:

> It is not deferred. It exits with error and calls do_hard_reset.
> See my reply to Suka's.

I saw your reply, but it does not answer the question I asked.  The patch
would have us reinitialize and restart the communication queues.  Your
suggestion would do more work than that.  Please describe the advantage
in deferring the reinitialization - and yes, defer is the right word -
by routing it through do_hard_reset() and executing that extra code.  I
see that route as doing more work than necessary and so introducing
additional risk, for no clear advantage.  So I would find it helpful
if you would describe the advantage.

> The testing was done on this patch. It was not performed on a full hard reset.
> So I don't think you could even compare the two results.

A problem has been noted, a patch has been proposed, and the reasoning that
the patch is correct has been given.  Testing with this patch has
demonstrated the problem has not returned.  So far, that sounds like a
pretty reasonable solution.

Your comment is curious - why would testing for this patch be done on a full
hard reset when this patch does not invoke a full hard reset?  If you have
data to consider then let's have it. I'm willing to be convinced, but so far
this just sounds like "I wouldn't do it that way myself, and I have a bad
feeling about doing it any other way."


  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 21:35 Dany Madden
2021-04-20 21:42 ` Lijun Pan
2021-04-21  6:45   ` Sukadev Bhattiprolu
2021-04-22  5:06     ` Lijun Pan
2021-04-22  6:58       ` Sukadev Bhattiprolu
2021-04-22  7:05       ` Rick Lindsley
2021-04-22 17:21       ` Michal Suchánek
2021-04-22 17:38         ` Lijun Pan
2021-04-23  2:26         ` Rick Lindsley
2021-05-04 19:05           ` Dany Madden
2021-04-21  7:54   ` Rick Lindsley
2021-04-22  5:12     ` Lijun Pan
2021-04-22  7:05       ` Rick Lindsley [this message]
2021-04-22  5:30 ` Lijun Pan
2021-04-22  7:07   ` Rick Lindsley
2021-04-22 17:01     ` Lijun Pan

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LinuxPPC-Dev Archive on

Archives are clonable:
	git clone --mirror linuxppc-dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linuxppc-dev linuxppc-dev/ \
	public-inbox-index linuxppc-dev

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone