On 04/09/2014 12:16 PM, Sergei Shtylyov wrote: > Hello. > > On 04/09/2014 09:56 PM, Alan Stern 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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
