[PATCH v2 1/5] drivers: phy: add generic PHY framework

[Rob Landley]

On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference  
> to the
> PHY with or without using phandle. To obtain a reference to the PHY  
> without
> using phandle, the platform specfic intialization code (say from  
> board file)
> should have already called phy_bind with the binding information. The  
> binding
> information consists of phy's device name, phy user device name and  
> an index.
> The index is used when the same phy user binds to mulitple phys.

Given that this has a separately selectable config option, I'm guessing  
that it's useful all by itself even in the absence of a driver using  
this phy? (Or it gives user visibility to the phy buried in an E1000 or  
SATA drive or some such?)

> +1. Introduction
> +
> +*PHY* is the abbreviation for physical layer. It is used to connect  
> a device
> +to the physical medium e.g., the USB controller has a PHY to provide  
> functions
> +such as serialization, de-serialization, encoding, decoding and is  
> responsible
> +for obtaining the required data transmission rate. Note that some USB
> +controller has PHY functionality embedded into it and others use an  
> external
> +PHY. Other peripherals that uses a PHY include Wireless LAN,  
> Ethernet,
> +SATA etc.

I've usually heard the word "transciever" used to describe these.

> +The intention of creating this framework is to bring the phy drivers  
> spread
> +all over the Linux kernel to drivers/phy to increase code re-use and  
> to
> +increase code maintainability.
> +
> +This framework will be of use only to devices that uses external PHY  
> (PHY
> +functionality is not embedded within the controller).
> +
> +2. Creating the PHY
> +
> +The PHY driver should create the PHY in order for other peripheral  
> controllers
> +to make use of it. The PHY framework provides 2 APIs to create the  
> PHY.

Given that a PHY is a chip (random example  
http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY),  
you seem to be saying that software should manifest a piece of hardware  
out of thin air through sheer willpower. I'm pretty sure I've  
misunderstood this phrasing.

> +struct phy *phy_create(struct device *dev, struct phy_descriptor  
> *desc);
> +struct phy *devm_phy_create(struct device *dev, struct  
> phy_descriptor *desc);
> +
> +The PHY drivers can use one of the above 2 APIs to create the PHY by  
> passing

Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize?

> +6. Destroying the PHY

I've run drivers like that. I try not to, though.

> +7. Current Status
> +
> +Currently only USB in OMAP is made to use this framework. However  
> using the
> +USB PHY library cannot be completely removed because it is  
> intertwined with
> +OTG. Once we move OTG out of PHY completely, using the old PHY  
> library can be
> +completely removed. SATA in OMAP will also more likely use this new  
> framework
> +and we should have a patch for it soon.

Does this paragraph belong in the documentation? (Git commit, sure, but  
I've seen a lot of stale paragraphs like these hang around a  
surprisingly long time.)

Rob