Hi, On 12/22/2016 09:18 PM, Felipe Balbi wrote: > 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. Greg was unhappy with my portmux patch set due to "faking a platform-device from a PCI device". We need to avoid this. Best regards, Lu Baolu > 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 ;-) > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
