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 firmware:
diff
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 firmware:
>
> diff --git
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 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 Build time: 201302052146
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 is
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 is optional, not a requirement.
> > That
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 Wed, Feb 28, 2018 at 08:18:33PM +0100, Arend van Spriel wrote:
> On 2/28/2018 7:48 PM, 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
On 2/28/2018 7:48 PM, 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
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 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
b/drivers/net/wireless/mediatek/mt7601u/mcu.c
index 65a8004418ea..04cbffd225a1 100644
---
On Tue, Feb 27, 2018 at 10:22:53AM -0800, Jakub Kicinski wrote:
> On Tue, 27 Feb 2018 16:54:51 +, 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
On Tue, 27 Feb 2018 16:54:51 +, 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 +, Luis R. Rodriguez wrote:
> >
> > > > I want to understand the case where the
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 +, 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
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 Sun, 25 Feb 2018 17:54:25 +, Luis R. Rodriguez wrote:
> On Mon, Feb 19, 2018 at 05:01:27PM +0200, cantabile wrote:
> > 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
On Mon, Feb 19, 2018 at 05:01:27PM +0200, cantabile wrote:
> 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
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 in
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 in case of
> > hibernation, but
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 this
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 this happens the driver never calls
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
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
> doesn't know this firmware should
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
24 matches
Mail list logo
