Re: bluetooth related firmware loader spew on resume.

At Wed, 26 Nov 2014 15:23:20 +0100,
Oliver Neukum wrote:

On Wed, 2014-11-26 at 11:53 +0100, Takashi Iwai wrote:

quoted

At Wed, 26 Nov 2014 11:43:36 +0100,
Oliver Neukum wrote:

quoted

On Wed, 2014-11-26 at 11:31 +0100, Takashi Iwai wrote:

quoted

At Wed, 26 Nov 2014 11:10:23 +0100,
Oliver Neukum wrote:

quoted

On Wed, 2014-11-26 at 09:52 +0100, Takashi Iwai wrote:

quoted

At Wed, 26 Nov 2014 14:15:27 +0900,

quoted

In order to paper over this, we may also remember the failing firmware
and avoid loading it.  This might be an easer way than the endless
fight against UMH race...

Hi,

the full fix would be to implement reset_resume() for btusb.
It seems to me that setup() should be split in two methods,
one to request the firmware from user space and the second
to transfer it to the device. reset_resume() would just need
to repeat the second operation.

I'm not against it, but one slight drawback is that you'll have to
remember the firmware content to transfer by the driver itself in this
scenario.   In the firmware loader framework, the content is re-read
at resume so that the largish content isn't kept unnecessarily during
the whole operation. 

That isn't a drawback but an advantage. Firmware for devices that
do power management needs to be in RAM. The right time to free it
is in disconnect(). But why does that mean that the driver has to
manage the firmware? Can't the firmware layer do it?

The f/w loader remembers the f/w names of the successful loads, and
retries to load them automatically at the suspend time.  But it
doesn't remember/cache the failed loads.  So, when the driver retires

Two issues

1. the firmware may be added later. So we could only record the name,
not the result of the query.

It records only the name.  The content is cached only between suspend
and resume.  But this reminds me that it's also a problem when the
firmware file on disk is replaced after the driver is loaded.  Then
the firmware content differs from what the driver had.

2. a driver may query several firmwares in turn to find its firmware

Right, and this kind of behavior hits the problem.

It seems to me that a firmware that will be needed again should
just not be evicted from RAM.

quoted

request_firmware() for a non-existing file in the resume path, it
actually reaches to the f/w loading part again unexpectedly.

And that is probably a bug. We just cannot request a firmware during
resumption. On anything but a leave node it is potentially deadly.

Yes, that's what I mentioned in my reply.  But, actually more puzzling
is that the WARNING shouldn't have been triggered at all.  That is,
something is still racy there, so we'd need to fix it.

Of course, robustifying the firmware loader itself is another good
thing.


Takashi