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.
Yes, but we cannot change the firmware on shipped devices, so we need
another solution for those.
I'm probably not aware of all possible solutions to this kind of a MFD-like
situation so I'm open to other Ideas.
Well, the mfd framework which was especially made for this uses the create
platform child devices approach, even if the main device is no on the
platform bus (typically it will be on an i2c bus).
Now converting the the entire xhci code into using the mfd framework
seems overkill, but I believe we can and should borrow the platform
child device approach from there.
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
