Re: [PATCH] mt7601u: Fix system freeze after resuming from hibernation

[Jakub Kicinski <kubakici@wp.pl>]

On Tue, 27 Feb 2018 16:54:51 +0000, Luis R. Rodriguez wrote:
> On Tue, Feb 27, 2018 at 02:25:55PM +0200, cantabile wrote:
> > On 27/02/18 04:28, Jakub Kicinski wrote:  
> > > On Sun, 25 Feb 2018 17:54:25 +0000, Luis R. Rodriguez wrote:  
> >   
> > > > I want to understand the case where the firmware is *not* available on resume?
> > > > Why did that happen? I seem to have read that on a fresh reboot the firmware
> > > > was not needed, and so on probe request_firmware() was not called? Why would
> > > > firmware not be required on a reboot?  
> > > 
> > > Yes, that is a good question..  John, do you have a theory?  My initial
> > > thought was that the UEFI/BIOS loads it during pre-boot, but this is a
> > > USB card, so it's a bit unlikely that UEFI will have a driver for it...
> > > Does this happen when rebooting maybe?
> > 
> > Yes, it happens when rebooting:
> > 1) Plug in the dongle. Message about firmware appears in dmesg:
> > 
> > mt7601u 2-3:1.0: ASIC revision: 76010001 MAC revision: 76010500
> > mt7601u 2-3:1.0: Firmware Version: 0.1.00 Build: 7640 Build time:
> > 201302052146____
> > mt7601u 2-3:1.0: Warning: unsupported EEPROM version 0d
> > 
> > 2) `systemctl reboot`. Message about firmware does not appear in dmesg:
> > 
> > mt7601u 2-3:1.0: ASIC revision: 76010001 MAC revision: 76010500
> > mt7601u 2-3:1.0: Warning: unsupported EEPROM version 0d
> > 
> > The dongle is nevertheless perfectly functional after rebooting.
> > 
> > I have no idea why it works like this.
> > 
> > This is an older laptop, no UEFI.  
>
> 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.

> Is the vendor involved or not really?

Not really, we got the vendor to submit the FW to linux-firmware,
that's about it.

> I could imagine a situation where on reboot we just reset a device but
> since poweroff is never fully issued the firmware is not lost. So let me
> ask, why not do a full reset / shutdown of the device when the interface
> goes down?
> 
> If there is no gain from the behaviour observed, might as well make
> the device work as much others rather than adding an API for a one-off
> situation where there is no gain from it behaving in a unique way.

IDK what the reset procedure is :S