Messages in this thread |  | | Subject | Re: [PATCH v6 0/5] usb: xhci: Add support for Renesas USB controllers | From | Mathias Nyman <> | Date | Tue, 4 Feb 2020 18:33:58 +0200 |
| |
On 31.1.2020 10.40, Vinod Koul wrote: > Hi Mathias, > > On 30-01-20, 19:07, Mathias Nyman wrote: >> On 25.1.2020 7.32, Vinod Koul wrote: >>>>>>>> >>>>>>>> On Mon, Jan 13, 2020 at 12:42 AM Vinod Koul <vkoul@kernel.org> wrote: >>>>>>>>> >>>>>>>>> This series add support for Renesas USB controllers uPD720201 and uPD720202. >>>>>>>>> These require firmware to be loaded and in case devices have ROM those can >>>>>>>>> also be programmed if empty. If ROM is programmed, it runs from ROM as well. >>>>>>>>> >>>>>>>>> This includes two patches from Christian which supported these controllers >>>>>>>>> w/o ROM and later my patches for ROM support and multiple firmware versions, >>>>>>>>> debugfs hook for rom erase and export of xhci-pci functions. >>>>>>>>>
...
>> >> There are a few other opens regarding this series. Mostly because I'm not (yet) >> familiar with all the details, so I'll just just list them here. >> >> - Is it really enough to add the Renesas driver to Makefile before xhci-pci >> driver to make sure it gets matched and probed based on vendor/device id >> before xhci-pci driver is matched and probed based on pci class? >> What if the Renesas driver is a module and xhci-pci compiled in? > > The driver loading rules are based on level and makefile order. So > renesas will always be loaded before xhci driver. This is required since > xhci claims all devices, so we need to make sure it loads before. > > I think we should make it inbuilt driver rather than a module. xhci > driver is only inbuilt. > > If there is a better way to handle this, am all for it. > >> - Previously probe didn't return before hcd's were added and everything set up. >> Now with request_firmware_nowait() probe returns early successfully, and the >> old xhci_pci_probe() which sets up everything is called later by the request >> firmware callback. So there could be whole new set of races possible. >> For example pci remove can be called mid firmware loading, or when the old >> xhci_pci_probe is still setting up things. > > I think this is a valid concern. Let me think about how to solve this.. > maybe add a flag in remove which ensure remove doesnt run untill the > probe/firmware callback is completed.
How about initiating async firmware loading before probe is called by using DECLARE_PCI_FIXUP_*() hooks?
Probe would then just check if there is a valid running firmware, if not just defer probe until later (return -EPROBE_DEFER).
No need for a separate Renesas xhci driver, no worries about which driver claims the device first, no races because of probe returning successfully too early.
Can we check the device for a valid running firmware without disrupting a ongoing firmware write?
-Mathias
|  |