On Thu, May 20, 2021 at 02:14:15PM -0700, Matthias Kaehlcke wrote: > On Thu, May 20, 2021 at 06:41:23AM -0700, Matthias Kaehlcke wrote: > > On Wed, May 19, 2021 at 10:05:21PM -0400, Alan Stern wrote: > > > On Wed, May 19, 2021 at 04:07:17PM -0700, Matthias Kaehlcke wrote: > > > > On Wed, May 19, 2021 at 10:43:56AM -0400, Alan Stern wrote: > > > > > On Tue, May 18, 2021 at 02:40:47PM -0700, Matthias Kaehlcke wrote: > > > > > > > > > > > > Could you also have a look at "[4/5] usb: host: xhci-plat: > > > > > > Create platform device for onboard hubs in probe()" > > > > > > (https://lore.kernel.org/patchwork/patch/1425453/)? It's a > > > > > > relatively short patch that creates the platform device for > > > > > > the driver from xhci-plat as you suggested in the v4 > > > > > > discussion. > > > > > > > > > > I'm not the maintainer for xhci-related drivers. > > > > > > > > > > However, there is at least one thing about this patch which looks > > > > > suspicious: Adding the onboard_hub_dev pointer to struct usb_hcd instead > > > > > of to struct xhci_plat_priv, where it would make a lot more sense. > > > > > > > > I can move it to struct usb_hcd if that's preferred > > > > > > Thinko: The patch already has it in struct usb_hcd. I suggested moving > > > it to struct xhci_plat_priv. > > > > Ah, didn't actively recall to which struct I added it to, it has been a > > while since I wrote that patch ;-) > > > Agreed that struct xhci_plat_priv is a better place. > > Or not, xhci_plat_priv is optional, which doesn't make it a good candidate > for holding a field that could be used by any xHCI controller. You could always allocate an xhci_plat_priv structure in cases where an onboard-hub device is present, if one doesn't exist already. > Should I move the field to struct xhci_hcd instead? That's another option. Look, I'm not the person you should be asking about this. What I say doesn't matter -- you need to get approval from Mathias Nyman, the xhci-hcd maintainer. Alan Stern
