Re: bluetooth related firmware loader spew on resume.

From: Takashi Iwai
Date: Wed Nov 26 2014 - 05:53:54 EST


At Wed, 26 Nov 2014 11:43:36 +0100,
Oliver Neukum wrote:
>
> On Wed, 2014-11-26 at 11:31 +0100, Takashi Iwai wrote:
> > At Wed, 26 Nov 2014 11:10:23 +0100,
> > Oliver Neukum wrote:
> > >
> > > On Wed, 2014-11-26 at 09:52 +0100, Takashi Iwai wrote:
> > > > At Wed, 26 Nov 2014 14:15:27 +0900,
> > >
> > > > 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
request_firmware() for a non-existing file in the resume path, it
actually reaches to the f/w loading part again unexpectedly.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/