Hi Kai-Heng, >> Found this thread google searching. >> >> >> 4.13.0-0.rc4.git1.1.fc27.x86_64 Problem sometimes happens with this kernel. >> This translates to git 623ce3456671. >> >> 4.13.0-0.rc3.git0.1.fc27.x86_64 But not this kernel, which translates >> to the actual rc3 release (clean). >> >> It seems to be a regression between those two. The problem only >> happens when waking from suspend to RAM, but it doesn't always happen. > > My theory is that if you request firmware when firmware_class is in > cache mode consecutively, and the device is changed, you will hit this > issue. > Can you give this patch a try? > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > index bfbe1e154128..910dce498f53 100644 > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -1177,6 +1177,9 @@ _request_firmware_prepare(struct firmware > **firmware_p, const char *name, > > ret = fw_lookup_and_allocate_buf(name, &fw_cache, &buf, dbuf, size); > > + if (!firmware_enabled() && device && (ret == 0 || ret == 1)) > + fw_add_devm_name(device, buf->fw_id); > + > /* > * bind with 'buf' now to avoid warning in failure path > * of requesting firmware. if a fix in firmware_class can handle this, then I assume we also do not need all the per driver / hardware workarounds for firmware caching? Or are these other patches also needed? 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
