Hi Takashi, >>>> 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. I think this should be indeed fixed. The firmware loader needs to remember the information. Since sometimes the firmware is optional. No point in re-loading it. And realistically, if the firmware was not present before suspend, it will not magically appear during resume. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
