From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 09 Apr 2014 19:01:03 +0000 Subject: Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver' Message-Id: <534598EF.3010102@wwwdotorg.org> List-Id: References: <53458E95.4080505@cogentembedded.com> In-Reply-To: <53458E95.4080505-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sergei Shtylyov , Alan Stern Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Peter.Chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, balbi-l0cyMroinI0@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org 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.