linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
	cantabile <cantabile.desu@gmail.com>,
	linux-wireless@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mt7601u: Fix system freeze after resuming from hibernation
Date: Tue, 27 Feb 2018 20:42:40 +0000	[thread overview]
Message-ID: <20180227204240.GW14069@wotan.suse.de> (raw)
In-Reply-To: <20180227102253.04a3a01c@cakuba.netronome.com>

On Tue, Feb 27, 2018 at 10:22:53AM -0800, Jakub Kicinski wrote:
> On Tue, 27 Feb 2018 16:54:51 +0000, Luis R. Rodriguez wrote:
> > OK, this just confirms that firmware is not needed on reboot sometimes,
> > but it does not explain *why*. What driver and code lines are involved
> > so I can go read? 
> 
> mt7601u_load_firmware() is probably the place to look at.

I checked.

static inline int firmware_running(struct mt7601u_dev *dev)                     
{                                                                               
        return mt7601u_rr(dev, MT_MCU_COM_REG0) == 1;                           
}

static int mt7601u_load_firmware(struct mt7601u_dev *dev)                       
{  
	...
        if (firmware_running(dev))                                              
                return 0;    

There you go. That's why. Now one would have to check the spec or
ask a person at the company what it means when:

	MT_MCU_COM_REG0 (0x0730) == 1.

Note that when we load the firmware we use the same check on intervals until
this is true to confirm or deny if the firmware got loaded.  I can only infer
this just means that the firmware is loaded and the device is ready. So this
just seems like an optimization given mt7601u_upload_firmware() seems to hint 
that this this device can take up to 100 * 10ms = 1s to load. Ie, we check
every 10ms to see if the firmware loaded, and we do so 100 times, so minimum
time expected for firmware load can take may be 10ms, and max 1s.

I'd be curious if someone who can trigger the situation can test what
happens if you use:

diff --git a/drivers/net/wireless/mediatek/mt7601u/mcu.c b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index 65a8004418ea..04cbffd225a1 100644
--- a/drivers/net/wireless/mediatek/mt7601u/mcu.c
+++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c
@@ -421,7 +421,7 @@ static int mt7601u_load_firmware(struct mt7601u_dev *dev)
 					 MT_USB_DMA_CFG_TX_BULK_EN));
 
 	if (firmware_running(dev))
-		return 0;
+		pr_info("Firmware already loaded but going to reload...");
 
 	ret = request_firmware(&fw, MT7601U_FIRMWARE, dev->dev);
 	if (ret)
 


Curious, will it really fail?

Note that I see mt7601u_stop() just calls mt7601u_mac_stop(). The big cleanup
happens via mt7601u_cleanup(), but I see mt7601u_disconnect() calls it.

Just curious, does that not get called on shutdown?

diff --git a/drivers/net/wireless/mediatek/mt7601u/usb.c b/drivers/net/wireless/mediatek/mt7601u/usb.c
index b9e4f6793138..126ef2ba77c2 100644
--- a/drivers/net/wireless/mediatek/mt7601u/usb.c
+++ b/drivers/net/wireless/mediatek/mt7601u/usb.c
@@ -311,6 +311,7 @@ static void mt7601u_disconnect(struct usb_interface *usb_intf)
 {
 	struct mt7601u_dev *dev = usb_get_intfdata(usb_intf);
 
+	pr_info("Calling mt7601u_disconnect()...");
 	ieee80211_unregister_hw(dev->hw);
 	mt7601u_cleanup(dev);

If it does, one option is mt7601u_cleanup() can use some love to really shut down
the device more... But its not clear to me what else could be done and I'm very
inclined to believe its not sensible.

The idea of an optimization of *not* having to load firmware one more time if
it already has it since power hasn't been shut off on the device seems sensible
to me.

Give the few deltas above a quick test just to fill in curiosity if you like
and to be complete -- I'll post RFCs shortly for you Cantabile to test, is
that your name?

  Luis

  reply	other threads:[~2018-02-27 20:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 11:34 [PATCH] mt7601u: Fix system freeze after resuming from hibernation cantabile
2018-02-15  0:45 ` Jakub Kicinski
2018-02-15 11:38   ` cantabile
2018-02-15 21:47     ` Jakub Kicinski
2018-02-17 11:23       ` cantabile
2018-02-19  5:55         ` Jakub Kicinski
2018-02-19 15:01           ` cantabile
2018-02-25 17:54             ` Luis R. Rodriguez
2018-02-27  2:28               ` Jakub Kicinski
2018-02-27 12:25                 ` cantabile
2018-02-27 16:54                   ` Luis R. Rodriguez
2018-02-27 18:22                     ` Jakub Kicinski
2018-02-27 20:42                       ` Luis R. Rodriguez [this message]
2018-02-28 18:02                         ` cantabile
2018-02-28 18:48                           ` Luis R. Rodriguez
2018-02-28 19:18                             ` Arend van Spriel
2018-02-28 20:41                               ` Luis R. Rodriguez
2018-02-28 21:18                             ` cantabile
2018-03-01  0:28                               ` Luis R. Rodriguez
2018-03-01 14:05                                 ` cantabile
2018-03-01 17:29                                   ` Luis R. Rodriguez
2018-03-01 20:11                                     ` cantabile
2018-03-01 21:01                                       ` Luis R. Rodriguez
2018-03-02 10:43                                         ` cantabile

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=20180227204240.GW14069@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cantabile.desu@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kubakici@wp.pl \
    --cc=linux-wireless@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).