Re: Clang and X86-EFlags (was Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning)

On Tue, Apr 24, 2018 at 6:28 AM, Sedat Dilek wrote: > > $ objdump -S clang-eflag.o > > Does this now look good? Looks fine to me. The instruction choice is still pretty odd: 1a: f6 c3 fftest $0xff,%bl 1d: 74 02 je 21

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:57 AM, Eric Dumazet wrote: > > Your patch considers TASKLET_SOFTIRQ being a candidate for 'immediate > handling', but TCP Small queues heavily use TASKLET, > so as far as I am concerned a revert would have the same effect. Does it actually? TCP ends

Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:42 AM, Mauro Carvalho Chehab wrote: > > On my preliminar tests, writing to a file on an ext4 partition at a > USB stick loses data up to the point to make it useless (1/4 of the data > is lost!). However, writing to a class 10 microSD card is

Re: Re: dvb usb issues since kernel 4.9

On Tue, Jan 9, 2018 at 9:27 AM, Eric Dumazet wrote: > > So yes, commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") has > shown up multiple times in various 'regressions' > simply because it could surface the problem more often. > But even if you revert it, you can

Re: dvb usb issues since kernel 4.9

On Mon, Jan 8, 2018 at 11:15 AM, Alan Stern wrote: > > Both dwc2_hsotg and ehci-hcd use the tasklets embedded in the > giveback_urb_bh member of struct usb_hcd. See usb_hcd_giveback_urb() > in drivers/usb/core/hcd.c; the calls are > > else if (high_prio_bh) >

Re: dvb usb issues since kernel 4.9

On Mon, Jan 8, 2018 at 9:55 AM, Ingo Molnar wrote: > > as I doubt we have enough time to root-case this properly. Well, it's not like this is a new issue, and we don't have to get it fixed for 4.15. It's been around since 4.9, it's not a "have to suddenly fix it this week"

Re: dvb usb issues since kernel 4.9

On Sat, Jan 6, 2018 at 11:54 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 6 Jan 2018 16:04:16 +0100 > "Josef Griebichler" escreveu: >> >> the causing commit has been identified. >> After reverting commit >>

Re: [GIT PULL] USB/PHY driver changes for 4.15-rc1

On Mon, Nov 13, 2017 at 8:19 AM, Greg KH wrote: > > Other major thing is the typec code that moved out of staging and into > the "real" part of the drivers/usb/ tree, which was nice to see happen. Hmm. So now it asks me about Type-C Port Controller Manager. Fair

Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be

On Mon, Oct 2, 2017 at 2:26 PM, Josh Poimboeuf wrote: > > The bisect is pointing to a commit which is almost 5 months old, so this > is pre-ORC. Kallsyms *is* enabled, but the unwinder dump isn't smart > enough to realize it's dumping misaligned stack addresses: Ahh, I

Re: 4879b7ae05 ("Merge tag 'dmaengine-4.12-rc1' of .."): WARNING: kernel stack regs at bd92bc2e in 01-cpu-hotplug:3811 has bad 'bp' value 000001be

Bringing in Josh on this, because the merge commit gets fingered because it seems to be an interaction between the new code from the merge and the ORC unwinder changes. It's probably some almost trivial code difference that just causes some code generation to change. And because Josh wasn't

Re: Two regressions on BYT/T ASUS T100TA 4.12-rc: #2 Keyboard no longer works

On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern wrote: > > So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans > to straighten this out. No, I think the main problem is that the hid_have_special_driver[] array change is garbage. It adds the ASUS ID,

Re: [REGRESSION] Failed network caused by: xhci: switch to pci_alloc_irq_vectors

On Fri, May 19, 2017 at 5:46 AM, Christoph Hellwig wrote: > > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 33c2b0b77429..5a7fd3b6a7b9 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1342,7 +1342,7 @@ pci_alloc_irq_vectors_affinity(struct pci_dev

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu, Feb 16, 2017 at 12:06 PM, Pavel Machek wrote: > > Hmm, that would explain problems at boot _and_ problems during > suspend/resume. I've committed the revert, and I'm just assuming that the revert also fixed your suspend/resume issues, but I wanted to just double-check that

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Thu, Feb 16, 2017 at 10:13 AM, Frederic Weisbecker wrote: > > I haven't followed the discussion but this patch has a known issue which is > fixed > with: > 7bdb59f1ad474bd7161adc8f923cdef10f2638d1 > "tick/nohz: Fix possible missing clock reprog after tick soft

Re: v4.10-rc8 (-rc6) boot regression on Intel desktop, does not boot after cold boots, boots after reboot

On Wed, Feb 15, 2017 at 3:20 PM, Pavel Machek wrote: > 4.10-rc4 broken > 4.10-rc3 ok Hmm. If those actually end up being reliable, then there's not a whole lot in between them wrt PCI or USB. What looked like the most likely candidate seems to be xhci-specific, though. But maybe

Re: net2280 Driver Bug

On Sun, Dec 25, 2016 at 8:09 AM, Raz Manor wrote: > > I had a problem with the net2280 driver- reading from an endpoint resulted > with a wrong read size in some cases. > > I found the problem and fixed it, and I wanted to publish the fix. However, > I have no push access,

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 1:27 PM, Sedat Dilek wrote: > > I just grepped for some "buzzwords" people gave me in this > email-thread and I was looking at (llvm.git HEAD - upcoming v3.9 > release) and found these comments in [1] > > > [1] >

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Jun 27, 2016 at 12:50 PM, Sedat Dilek wrote: > > $ objdump -S clang-eflag.o > > clang-eflag.o: file format elf64-x86-64 > > > Disassembly of section .text: > > : >0: 55 push %rbp >1: 48 89 e5mov

Re: [GIT PULL] USB driver patches for 4.6-rc1

On Fri, Mar 18, 2016 at 3:51 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > The commit that ends up being marked bad is odd, but there it is: > 69bec7259853 "USB: core: let USB device know device node". Confirmed. Not only did it bisect to that, reverting

Re: [GIT PULL] USB driver patches for 4.6-rc1

On Wed, Mar 16, 2016 at 5:09 PM, Greg KH wrote: > > USB patches for 4.6-rc1 > > Here is the big USB patchset for 4.6-rc1. Something in this - or possibly the tty pull, but that doesn't sound very likely - has killed my USB keyboard on my desktop. I'm bisecting right

Re: [GIT PULL] USB driver patches for 4.6-rc1

On Fri, Mar 18, 2016 at 2:43 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Something in this - or possibly the tty pull, but that doesn't sound > very likely - has killed my USB keyboard on my desktop. Yeah, the bisect is now solidly in the usb part. The machine h

Re: [GIT PULL] USB driver patches for 4.6-rc1

On Fri, Mar 18, 2016 at 3:58 PM, Greg KH wrote: > > Yes, people did report issues with that yesterday, and I queued up a > patch for it, it's attached below, but I didn't think it would cause any > issues with non-OF systems either. I wanted to give it a few days >

Re: [GIT PULL] USB driver patches for 4.6-rc1

On Fri, Mar 18, 2016 at 2:58 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > Yeah, the bisect is now solidly in the usb part. The commit that ends up being marked bad is odd, but there it is: 69bec7259853 "USB: core: let USB device know device node". Very odd,

Re: [PATCH] cdc_ncm: do not call usbnet_link_change from cdc_ncm_bind

On Mon, Mar 7, 2016 at 12:15 PM, Bjørn Mork wrote: > usbnet_link_change will call schedule_work and should be > avoided if bind is failing. Otherwise we will end up with > scheduled work referring to a netdev which has gone away. > > Instead of making the call conditional, we can

Re: [PATCH] usbhid: Fix lockdep unannotated irqs-off warning

On Mon, Mar 7, 2016 at 10:07 AM, Alan Stern wrote: > > Of course, there are other ways to save a single flag value (such as > setz). It's up to the compiler developers to decide what they think is > best. Using 'setcc' to save eflags somewhere is definitely the right

Re: Possible double-free in the usbnet driver

On Sat, Mar 5, 2016 at 11:53 AM, Bjørn Mork wrote: > > > Definitely. The patch is so obviously correct that we can only wonder how it > was possible to miss it it the first place :) > > Will take a look to see if we could do a better job cleaning up in other > places. What

Re: Possible double-free in the usbnet driver

On Fri, Mar 4, 2016 at 2:26 PM, Andrey Konovalov wrote: > > and when I run the vm and connect the device I get: > > [ 23.672662] cdc_ncm 1-1:1.6: bind() failure > [ 23.673447] usbnet_probe(): freeing netdev: 88006ab48000 > [ 23.675822] usbnet_probe(): freeing

Re: Possible double-free in the usbnet driver

[ Moving this to proper lists ] On Thu, Mar 3, 2016 at 4:19 PM, Andrey Konovalov wrote: > > I found another double-free, this time in the usbnet driver. Hmm. It doesn't look like a double free to me, at least from the logs you attached. > Whenever the `bind()` function

Re: [GIT PULL] USB driver fixes for 4.5-rc4

On Sun, Feb 14, 2016 at 11:01 AM, Greg KH wrote: > > USB and PHY fixes for 4.5-rc4 > > Here are a number of USB and PHY driver fixes for 4.5-rc4. Actually, only PHY fixes. The USB fixes you already sent me for rc3. See merge commit 46df55ceeaf3. Apparently you

Re: [GIT PULL] USB driver fixes for 4.5-rc4

On Sun, Feb 14, 2016 at 12:39 PM, Greg KH wrote: > > Ugh, you are right, sorry about that, do you need an updated pull > request, or are you ok with this one? I took it and updates the merge log appropriately. Linus -- To unsubscribe from this list:

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, Oct 29, 2015 at 4:44 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > That said, I'm pretty sure it's just that there were (and probably > still are) tons of bad USB sticks with cheap controllers with 8-bit > sector counts, and you're better off picking som

Re: [PATCH] usb: storage: scsiglue: increase transfer size limit

On Thu, Oct 29, 2015 at 4:25 PM, Felipe Balbi wrote: > > Fair enough. Linus, do you have any recollection of which device you > found to be quirky ? Your original commit limitting to 240 sectors > doesn't make that clear at all ;-) > > [1]

Re: First kernel patch (optimization)

On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin wrote: > My first kernel patch, hope I did everything correctly! Instead of calling > strlen on every iteration of the for loop, just call it once instead and > store in a variable. Heh. Ok, that resulted in a rather long

Fwd: [PATCH] net:usb:cdc_ncm: fix that tag Huawei devices as wwan

Hmm. Oliver is marked as the maintainer of the USB CDC code, but others have touched it more recently. So I'm just wildly adding people to the cc to comment on this patch and maybe apply it. Oliver/David/Ben/Bjørn? Linus -- Forwarded message -- From: xiaomao

Re: [GIT PULL] USB driver patches for 3.19-rc1

On Mon, Dec 15, 2014 at 3:32 AM, Hans de Goede hdego...@redhat.com wrote: Code wise this looks good and I've just given: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master a spin with an uas disk enclosure, and verified that tcq is being used, and everything works fine.

Re: [GIT PULL] USB driver patches for 3.19-rc1

On Sun, Dec 14, 2014 at 2:35 PM, Greg KH gre...@linuxfoundation.org wrote: Hans de Goede (1): uas: Make uas work with blk-mq So I got some fairly trivial conflicts on this one (conflicting with the scsi cleanups mainly by Christoph Hellwig. I resolved the conflict easily, and it all

Re: [GIT PULL] USB driver patches for 3.19-rc1

On Sun, Dec 14, 2014 at 3:17 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Attached is the message I sent about this on Nov 24 to which I received no response and so assumed it was ok ... Looks like the same resolution I got. I'd still prefer to get an actual positive yup, tested it about

Re: [GIT PULL] USB driver fixes for 3.18-rc7

Hmm, Greg. I seem to get this problem possibly more commonly at boot these days: usb 1-6: new full-speed USB device number 2 using xhci_hcd usb 1-6: device descriptor read/64, error -71 xhci_hcd :00:14.0: Setup ERROR: setup context command for slot 1. usb 1-6: hub failed to enable

Re: Linux 3.16-rc6

On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra pet...@infradead.org wrote: So going by the nifty picture rostedt made: [ 61.454336]CPU0CPU1 [ 61.454336] [ 61.454336] lock((p-alloc_lock)-rlock); [ 61.454336]

Re: Linux 3.16-rc6

On Wed, Jul 23, 2014 at 2:53 AM, Borislav Petkov b...@alien8.de wrote: Well, it looks like we f*cked up something after -rc5 since I'm starting to see lockdep splats all over the place which I didn't see before. I'm running rc6 + tip/master. There was one in r8169 yesterday:

Re: [GIT PULL] USB patches for 3.15-rc1

On Tue, Apr 1, 2014 at 11:49 AM, Greg KH gre...@linuxfoundation.org wrote: USB patches for 3.15-rc1 Here's the big USB pull request for 3.15-rc1. Hmm. I'm getting this when testing: warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct dependencies (HAS_IOMEM OF (ARM64 ||

Re: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt joshhun...@gmail.com wrote: Both ahci and sata_svw call ata_host_activate(), which call ata_host_register() and async_schedule(async_port_probe, ap). Well, with the modern logic (only wait for async probing if the module itself did async probing) the

Re: [3.8-rc3 - 3.8-rc4 regression] Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

On Tue, Nov 26, 2013 at 2:12 PM, Josh Hunt joshhun...@gmail.com wrote: I should have clarified that I'm not using dm/md in my setup. I know the modules are getting loaded in the log I attached, but root is not a md/dm device. Hmm. The initcall debugging doesn't actually show any of the wait

Re: [PATCH] usb: gadget LLVMLinux: Removing the use of VLAIS from the gadget driver

On Mon, Sep 23, 2013 at 12:30 PM, Felipe Balbi ba...@ti.com wrote: I remember there was a discussion of not dropping variable length array support, wasn't there ? We should definitely drop it. The feature is an abomination. I thought gcc only allowed them at the end of structs, in the middle

Re: [PATCH] USB: remove remaining instances of USB_SUSPEND

On Wed, May 1, 2013 at 9:13 AM, Alan Stern st...@rowland.harvard.edu wrote: This patch (as1677) removes the remaining instances of that symbol. Btw, what are these as ID's, and what does the noise buy us? Doing a git log | egrep -w 'as[0-9]{3,}' shows that this has been going on

Re: [GIT PATCH] USB patches for 3.10-rc1

On Mon, Apr 29, 2013 at 9:23 AM, Greg KH gre...@linuxfoundation.org wrote: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.10-rc1 This has some odd things in it, but I made the mistake of pushing out my merge before I noticed, so it's out there now regardless. See

Re: [GIT PATCH] USB patches for 3.10-rc1

On Mon, Apr 29, 2013 at 2:14 PM, Alan Stern st...@rowland.harvard.edu wrote: What other things seemed odd about Greg's pull request? The only other thing I noticed was the new CONFIG_USB_PHY quesiton, which is not something that I think is sensible to ask from a user, and the help text doesn't

Re: [PATCH 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)

On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki r...@sisk.pl wrote: So, I have two patches (on top of the Linus' tree) that will follow shortly: Should I take these directly as patches, or expect them to show up in a pull soon (ie do you have or expect to have other things pending)?

Re: [GIT PATCH] USB patches for 3.9-rc1

On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki r...@sisk.pl wrote: It won't revert, there's more stuff on top of it. And it is a fix, so reverting it is not really a good idea anyway. Rafael, please don't *ever* write that crap again. We revert stuff whether it fixed something else or

Re: [GIT PATCH] USB patches for 3.9-rc1

On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki r...@sisk.pl wrote: The problem is, though, that even if bisection turns up something, it doesn't automatically mean that this particular commit is the one that caused the problem to happen in the first place. No, I agree. I just react *very*

Re: [GIT PATCH] USB patches for 3.9-rc1

On Thu, Feb 21, 2013 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. Ok, so there were a couple of conflicts with Thierry Reding's series to convert

Re: [PATCH 1/2] init, block: try to load default elevator module early during boot

...@linux.intel.com Cc: Linus Torvalds torva...@linux-foundation.org Cc: Alex Riesen raa.l...@gmail.com --- block/elevator.c | 16 include/linux/elevator.h |1 + include/linux/init.h |1 + init/do_mounts_initrd.c |3 +++ init/initramfs.c |8

Re: [PATCH] async: fix __lowest_in_progress()

Tejun, mind explaining this one a bit more to me? If ordering matters, and we have a running queue and a pending queue, how could the pending queue *ever* be lower than the running one? That implies that something was taken off the pending queue and put on the running queue out of order, right?

Re: [PATCH 1/2] init, block: try to load default elevator module early during boot

On Thu, Jan 17, 2013 at 10:59 AM, Tejun Heo t...@kernel.org wrote: If you're okay with it, I'll route these two and the patches to add warning through a wq branch. There's already a wq/for-3.9 patch which am_i_async() can make use of, so it's gonna be easier this way. Sounds good to me.

Re: [PATCH 2/3] workqueue, async: implement work/async_current_func()

On Thu, Jan 17, 2013 at 5:25 PM, Tejun Heo t...@kernel.org wrote: Implement work/async_current_func() which query whether the current task is a workqueue or async worker respectively and, if so, return the current function being executed along with work / async item related information. So

Re: [PATCH 2/3] workqueue, async: implement work/async_current_func()

On Thu, Jan 17, 2013 at 7:04 PM, Tejun Heo t...@kernel.org wrote: Another thing is that it seems like having introspection type interface often lead to abuses - work_pending(), work_busy() both ended up bringing more unnecessary dependencies and subtle bugginess on internal details than

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

On Wed, Jan 16, 2013 at 9:03 AM, Arjan van de Ven ar...@linux.intel.com wrote: we can even try twice the first time right after we mount the initramfs the second time when the initramfs code exits, and before we exec init (the initramfs supposedly mounted the real root fs at this point)

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

[ Added Tejun to the discussion, since he's the async go-to-guy ] On Mon, Jan 14, 2013 at 10:23 PM, Ming Lei ming@canonical.com wrote: But I have another idea to address the problem, and let module code call async_synchronize_full() only if the module requires that explicitly, so how

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Tue, Jan 15, 2013 at 9:36 AM, Linus Torvalds torva...@linux-foundation.org wrote: This kind of let's randomly encourage people to write subtly buggy code that has magical timing dependencies, so that the developer won't likely even see it because he has fast disks etc code is totally

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Tue, Jan 15, 2013 at 10:32 AM, Tejun Heo t...@kernel.org wrote: I think the root problem here, apart from request_module() from block - which is a bit nasty but making that part completely async would too be quite nasty albeit in a different way - is that async_synchronize_full() is way

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Tue, Jan 15, 2013 at 3:50 PM, Tejun Heo t...@kernel.org wrote: For now, I'm gonna implement simple I'm not gonna wait for myself self-deadlock avoidance. You can't really do that. Or rather, it won't *help*. The thing is, the module loading in particular is not necessarily happening in the

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Tue, Jan 15, 2013 at 4:36 PM, Linus Torvalds torva...@linux-foundation.org wrote: There's a reason I asked for a warning for this. Or the let's flag the current thread if it ever started anything asynchronous. Because it's complicated. Btw, the sequence counter (that is *not* taking

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

On Tue, Jan 15, 2013 at 6:52 PM, Tejun Heo t...@kernel.org wrote: It makes me feel dirty but makes the problem go away and I can't think of anything better, so here is the implementation of used async workaround. Ok, people, can we get a tested-by (or Nope, doesn't work) from the people who

Re: [PATCH] module, async: async_synchronize_full() on module init iff async is used

On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo t...@kernel.org wrote: Hello, Linus. On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote: That said, maybe we could just make the rule be that you can't pick a default IO scheduler that is modular. This is definitely much more preferable

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Sun, Jan 13, 2013 at 11:15 PM, Ming Lei ming@canonical.com wrote: The deadlock problem is caused by calling request_module() inside async function of do_scan_async(), and it was introduced by Linus's below commit: commit d6de2c80e9d758d2e36c21699117db6178c0f517 Author: Linus Torvalds

Re: USB device cannot be reconnected and khubd blocked for more than 120 seconds

On Mon, Jan 14, 2013 at 10:04 AM, Alan Stern st...@rowland.harvard.edu wrote: How about skipping that call if the current thread is one of the async helpers? Is it possible to detect when that happens? Or maybe such a check should go inside async_synchronize_full() itself. Do we have some

Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware

On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei ming@canonical.com wrote: The below patch should fix the problem above. Actually, I think we could make this even simpler. There's nothing wrong with saying user mode is enabled *just* before we unthaw things, if we also simply guarantee that there

Re: [RFC] firmware load: defer request_firmware during early boot and resume

On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov b...@alien8.de wrote: Question: is there any other reason [besides maybe embedded people who care about each single Kb of memory on the system] why we don't make this cache/uncache firmware thing *implicit*? That is, load it once at

Re: [RFC] firmware load: defer request_firmware during early boot and resume

On Fri, Jul 20, 2012 at 5:33 AM, Ming Lei tom.leim...@gmail.com wrote: The RFC patch is just for discussing if the idea of deferring request_firmware is doable for addressing the issue of request_firmware in resume path, which is caused by driver unbind/rebind during resume. NAK. It really