On 07-09-17 15:14, Mathias Nyman wrote:
On 05.09.2017 19:42, Hans de Goede wrote:
The Intel cherrytrail xhci controller has an extended cap mmio-rangeI think it would be better to have one place where we add handlers for
which contains registers to control the muxing to the xhci (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.
Having a mux driver included in the xhci code (or under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform mux driver for the
vendor specific extended capabilities.
Something like xhci-vendor-ext-caps.c, or just xhci-ext-caps.c as
there's a xhci-ext-caps.h header already
We could walk through the capability list once and add the needed handlers.
+int xhci_ext_cap_init(void __iomem *base)
This will need to take a struct xhci_hcd *xhci param instead
as some of the ext_cap handling (including the cht mux code)
will need access to this.
So I see 2 options here (without making this function PCI specific)
1) Add an u32 product_id field to struct xhci_hcd; or
2) Use a quirk flag as my current code is doing.
I'm fine with doing this either way, please let me know your preference.
Can you do a "git format-patch" of that and send it to me? If you
can give me that + your preference for how to check if we're
dealing with a cht xhci hcd in xhci_ext_cap_init I can do a v3
with your suggestions applied.