On 04/09/2014 11:01 PM, Stephen Warren wrote:
Ok, the existing field is being replaced by something? I didn't get that
No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog.
from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable.
OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1.
What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both?
The generic PHY framework (drivers/phy/phy-core.c) supports multifunction "complex" PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function "simple" USB PHYs...
Naively, it sounds like the complex PHY driver should also be a pinctrl driver, since it sounds like the main feature it has beyond a simple PHY is the ability to do pin muxing.
It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same.
WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
