Re: [PATCH v6 0/5] usb: xhci: Add support for Renesas USB controllers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux