[Fixed address of devicetree mailing list and added more people on CC.]

For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813

Best regards,
Tomasz

On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:

Hi Alan,

On Monday 22 of July 2013 10:44:39 Alan Stern wrote:

quoted

On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:

quoted

quoted

	The PHY and the controller it is attached to are both 

physical

quoted

quoted

quoted

	devices.
	
	The connection between them is hardwired by the system
	manufacturer and cannot be changed by software.
	
	PHYs are generally described by fixed system-specific 

board

quoted

quoted

quoted

	files or by Device Tree information.  Are they ever 

discovered

quoted

quoted

quoted

	dynamically?

No. They are created just like any other platform devices are
created.

Okay.  Are PHYs _always_ platform devices?

They can be i2c, spi or any other device types as well.

quoted

quoted

quoted

	Is the same true for the controllers attached to the PHYs?
	If not -- if both a PHY and a controller are discovered
	dynamically -- how does the kernel know whether they are
	connected to each other?

No differences here. Both PHY and controller will have dt
information
or hwmod data using which platform devices will be created.

quoted

	The kernel needs to know which controller is attached to 

which

quoted

quoted

quoted

	PHY.  Currently this information is represented by name or 

ID

quoted

quoted

quoted

	strings embedded in platform data.

right. It's embedded in the platform data of the controller.

It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?

By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)

quoted

quoted

quoted

	The PHY's driver (the supplier) uses the platform data to
	construct a platform_device structure that represents the 

PHY.

quoted

quoted

Currently the driver assigns static labels (corresponding to the
label
used in the platform data of the controller).

quoted

	Until this is done, the controller's driver (the client) 

cannot

quoted

quoted

quoted

	use the PHY.

right.

quoted

	Since there is no parent-child relation between the PHY 

and the

quoted

quoted

quoted

	controller, there is no guarantee that the PHY's driver 

will be

quoted

quoted

quoted

	ready when the controller's driver wants to use it.  A 

deferred

quoted

quoted

quoted

	probe may be needed.

right.

quoted

	The issue (or one of the issues) in this discussion is 

that

quoted

quoted

quoted

	Greg does not like the idea of using names or IDs to 

associate

quoted

quoted

quoted

	PHYs with controllers, because they are too prone to
	duplications or other errors.  Pointers are more reliable.
	
	But pointers to what?  Since the only data known to be
	available to both the PHY driver and controller driver is 

the

quoted

quoted

quoted

	platform data, the obvious answer is a pointer to platform 

data

quoted

quoted

quoted

	(either for the PHY or for the controller, or maybe both).

hmm.. it's not going to be simple though as the platform device for
the PHY and controller can be created in entirely different places.
e.g., in some cases the PHY device is a child of some mfd core
device
(the device will be created in drivers/mfd) and the controller
driver
(usually) is created in board file. I guess then we have to come up
with something to share a pointer in two different files.

The ability for two different source files to share a pointer to a
data
item defined in a third source file has been around since long before
the C language was invented.  :-)

In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is.  Let's take a simple
example.  Suppose the system design includes a PHY named "foo".  Then
the board file could contain:

struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);

and a header file would contain:

extern struct phy_info phy_foo;

The PHY supplier could then call phy_create(&phy_foo), and the PHY
client could call phy_find(&phy_foo).  Or something like that; make up
your own structure tags and function names.

It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.

This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:

SoC	PHY	consumer
A	PHY1	HOST1
B	PHY1	HOST2
C	PHY2	HOST1
D	PHY2	HOST2

So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.

Best regards,
Tomasz