linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
	linux-usb@vger.kernel.org, Cyril Brulebois <kibi@debian.org>
Subject: Re: [PATCH] xhci-pci: Make xhci-pci-renesas a proper modular driver
Date: Thu, 25 Jul 2024 07:06:56 +0200	[thread overview]
Message-ID: <2024072515-specks-gradient-6779@gregkh> (raw)
In-Reply-To: <ZqGeehVxETDl57eT@decadent.org.uk>

On Thu, Jul 25, 2024 at 02:38:18AM +0200, Ben Hutchings wrote:
> If CONFIG_USB_XHCI_PCI_RENESAS is enabled, xhci-pci conditionally
> calls into the xhci-pci-renesas module, which means both modules must
> be loaded to use any xHCI PCI controller.
> 
> The MODULE_FIRMWARE declaration in the base xhci-pci module causes
> initramfs-tools to check for and warn about missing firmware for the
> Renesas xHCI controllers, when any xHCI PCI controller is present.
> And because of the previous oddity, simply moving this declaration to
> xhci-pci-renesas wouldn't help.
> 
> To fix this, reverse the relationship between the modules:
> 
> - Remove the quirk for the Renesas xHCIs, and the driver_data
>   structure used only for them
> - In xhci-pci:
>   - Rename xhci_pci_probe() to xhci_pci_common_probe()
>   - Export xhci_pci_common_probe() and xhci_pci_remove()
>   - Use a new probe function that rejects the Renesas xHCIs and then
>     calls the common probe function
> - In xhci-pci-renesas:
>   - Stop exporting renesas_xhci_check_request_fw()
>   - Add a probe function that calls renesas_xhci_check_request_fw()
>     followed by xhci_pci_common_probe()
>   - Add and register a new pci_driver matching only the Renesas xHCIs
>     and using its own probe function, but with other operations the
>     same as in xhci-pci
> - Make CONFIG_USB_XHCI_PCI_RENESAS depend on CONFIG_USB_XHCI_PCI,
>   not the other way around
> 
> Finally, move the MODULE_FIRMWARE declaration to xhci-pci-renesas.

Thanks for doing this, this has long bugged me, and "simple" fixes
didn't seem to do it, but this looks nice.  I'll queue it up after -rc1
is out.

greg k-h

  reply	other threads:[~2024-07-25  5:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-25  0:38 [PATCH] xhci-pci: Make xhci-pci-renesas a proper modular driver Ben Hutchings
2024-07-25  5:06 ` Greg KH [this message]
2024-07-27 11:55 ` Cyril Brulebois
2024-07-31  8:45 ` Greg KH
2024-07-31 20:32   ` [PATCH v2] " Ben Hutchings
2024-07-31 22:06     ` Cyril Brulebois

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2024072515-specks-gradient-6779@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=ben@decadent.org.uk \
    --cc=kibi@debian.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).