On 01/03/18 23:01, Luis R. Rodriguez wrote:
On Thu, Mar 01, 2018 at 10:11:01PM +0200, cantabile wrote:
On 01/03/18 19:29, Luis R. Rodriguez wrote:
Correct?
The above log is from "20180227-firmware-cache" kernel plus your suggested
change that makes it always upload the firmw
On 01/03/18 19:29, Luis R. Rodriguez wrote:
On Thu, Mar 01, 2018 at 04:05:29PM +0200, cantabile wrote:
On 01/03/18 02:28, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 11:18:59PM +0200, cantabile wrote:
Feb 28 22:46:19 home kernel: mt7601u 2-3:1.0: Firmware Version: 0.1.00 Build:
7640
On 01/03/18 02:28, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 11:18:59PM +0200, cantabile wrote:
On 28/02/18 20:48, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 08:02:59PM +0200, cantabile wrote:
On 27/02/18 22:42, Luis R. Rodriguez wrote:
OK so we know that the optimization
On 28/02/18 20:45, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 08:03:26PM +0200, cantabile wrote:
On 28/02/18 01:20, Luis R. Rodriguez wrote:
Cantabile, please give these patches a spin and let me know if it fixes
your reported issue. They depend on other pending patches I have in line
On 28/02/18 20:48, Luis R. Rodriguez wrote:
On Wed, Feb 28, 2018 at 08:02:59PM +0200, cantabile wrote:
On 27/02/18 22:42, Luis R. Rodriguez wrote:
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
On 28/02/18 01:20, Luis R. Rodriguez wrote:
Cantabile, please give these patches a spin and let me know if it fixes
your reported issue. They depend on other pending patches I have in line
waiting to be merged so the easiest I thing I think is for you to test my
20180227-firmware-cache branch [0
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?
Yes.
On 27/02/18 04:28, Jakub Kicinski wrote:
On Sun, 25 Feb 2018 17:54:25 +, 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
On 19/02/18 07:55, Jakub Kicinski wrote:
On Sat, 17 Feb 2018 13:23:29 +0200, cantabile wrote:
Thanks for the info. Would it be cleaner to EXPORT fw_add_devm_name()
and just call that in case driver sees FW is already loaded? That
should inform the fw subsystem that we want the image around
On 15/02/18 23:47, Jakub Kicinski wrote:
On Thu, 15 Feb 2018 13:38:00 +0200, cantabile wrote:
On 15/02/18 02:45, Jakub Kicinski wrote:
On Wed, 14 Feb 2018 13:34:38 +0200, cantabile wrote:
The firmware running on the device sometimes survives a reboot
(firmware_running returns 1). When
On 15/02/18 02:45, Jakub Kicinski wrote:
On Wed, 14 Feb 2018 13:34:38 +0200, cantabile wrote:
The firmware running on the device sometimes survives a reboot
(firmware_running returns 1). When this happens the driver never calls
request_firmware, which means the kernel's firmware handling code
The firmware running on the device sometimes survives a reboot
(firmware_running returns 1). When this happens the driver never calls
request_firmware, which means the kernel's firmware handling code
doesn't know this firmware should be cached before hibernating. Upon
resuming from several
12 matches
Mail list logo
