Hi, Hans de Goede <hdegoede@xxxxxxxxxx> writes: >>> Here are 2 patches which can and should be merged separately, but >>> which do belong together, as together they add support for the >>> usb-phy / mux bits found in the Intel Cherrytrail xhci vendor defined >>> extended capabilities registers. >>> >>> I did not want to hide an entire phy driver inside the xhci code, >>> nor did I want to add an extcon dependency to the xhci code, so >>> I've chosen to simply make the xhci code register a platform childdev >>> with an IOMEM resource with the Intel Cherrytrail xhci vendor defined >>> extended capabilities registers when these are found. This keeps the >>> xhci driver clean and allows writing a separate phy driver, this is >>> the first patch, which should be merged through the USB tree. >>> >>> The second patch adds the actual phy driver, one thing which stands >>> out is that it completely depends on extcon devices to get idpin and >>> vbus state as that is done by other chips on cherrytrail devices, >>> atm the extcon devices are hardcoded to axp288_extcon for the vbus >>> detection and the ACPI INT3496:00 device for the idpin detection. >>> >>> On some boards a different pmic then the axp288 may be used, so in >>> the future we may end up with an array with extcon device names to >>> try until we've found one. >>> >>> The phy driver also adds a mode sysfs attribute, this is useful for >>> testing, as well with a so called charging oth hub, where the idpin >>> will indicate device/charge mode, but we can also use usb-devices >>> plugged into the hub by switching the data lines to host mode. >> >> Baolu has worked on this for months but it turned out that several folks >> said 'no' to his patchset. You're not really dealing with a PHY, it's >> just a portmux which can generate some UTMI messages to make sure dwc3 >> is happy. > > Right, I opted for a phy driver because that is the closest I could > get to something resembling what this thing does. > >> The end of the story about this, at least for broxton, was that mux >> control was moved to ASL. I'm not sure why folks didn't update CHT (or >> other devices') BIOS though. > > I don't think expecting things to get "fixed" by firmware updates, esp. > firmware updates adding whole new functionality is going to happen, that > just is not realistic (esp. with cheap devices like these). And even if > it were fixed in firmware users are really bad add updating there firmware. True that. If you can convince all folks involved that a PHY driver or a portmux framework is acceptable, then more power for you :-) Frankly, though, this should always have been handled at ASL level because port role is really decided at cable connection time (well... not 100% true). >> Baolu, any comments to this series? >> >> Personally, I'm unwilling to take this (or the other 2-patch dwc3 series >> adding IDA) because there will only be a single user. > > Only a single user ? You mean only a single SoC will use this I guess ? yeah > But there are many many devices with this SoC and lots of people are > trying to run "plain" Linux on these. don't get me wrong. I'd really like to have Up Board running mainline with no extra hacks necessary ;-) > I can see how you don't want this as a phy driver though, I would > be happy to drop the phy-binding bits (they're not really used > anyways) and drop this under drivers/misc adding myself to MAINTAINERS > for it, would that be an acceptable solution ? For me? sure :-) Let's get Greg and Oliver to agree though. > About the "other 2-patch dwc3 series", I'm fine with you not taking > the IDA patch, but the first patch is unrelated to IDA, it is a pure > bug-fix and really should be upstreamed. right, that's true. > Matthias, assuming Felipe is ok with putting this in drivers/misc > (minus the phy bindings), are you ok with the xhci blurb which > registers the platform-device for the "misc" driver to bind to? This is the one thing Greg was against. The creation of the "fake" platform-device from XHCI. I mean, turning it into a real PCI device will require firmware update, so we might as well update the firmware to move MUX handling to ASL altogether ;-) -- balbi
Attachment:
signature.asc
Description: PGP signature
