Hi, On 12/23/2016 06:10 AM, Hans de Goede wrote: > Hi, > > On 22-12-16 17:28, Mathias Nyman wrote: >> On 22.12.2016 14:45, Hans de Goede wrote: >>> Hi, >>> >>> On 22-12-16 13:11, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Hans de Goede <hdegoede@xxxxxxxxxx> writes: >>>>> Hi All, >>>>> >>>>> 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. >>> >>>> 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 ? >>> >>> But there are many many devices with this SoC and lots of people are >>> trying to run "plain" Linux on these. >>> >>> 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 ? >>> >>> 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. >>> >>> 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? >> >> Not the ideal solution, but creating a device would sound better than carrying it >> in xhci driver. ASL/firmware would be the preferred solution. >> >> I'm probably not aware of all possible solutions to this kind of a MFD-like >> situation so I'm open to other Ideas. >> >> patch [1/2] will create a platform device for almost all Intel hosts, even if >> we only want it for CHT, so as is that solution can't be accepted. > > Hmm, so all Intel hosts have the have the extended capability with id 192 ? It's not true that "all Intel hosts have the extended capability with id 192", but it's a fact that "many non-CHT hosts also have the extended capability with id 192". At least an xhci host in Broxton SoC has this. We have moved portmux handling to ASL on Broxton platforms. Best regards, Lu Baolu > I got the impression from the android patch that that id marked the cht > specific extended capability bits. If that is not unique, what should I > use instead, pci vendor + product id ? > > Regards, > > Hans > -- > 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 > -- 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
