[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1307211453450.19133-100000@netrider.rowland.org>
Date: Sun, 21 Jul 2013 15:22:21 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Sylwester Nawrocki <sylvester.nawrocki@...il.com>
cc: Greg KH <gregkh@...uxfoundation.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Kishon Vijay Abraham I <kishon@...com>,
<kyungmin.park@...sung.com>, <balbi@...com>, <jg1.han@...sung.com>,
<s.nawrocki@...sung.com>, <kgene.kim@...sung.com>,
<grant.likely@...aro.org>, <tony@...mide.com>, <arnd@...db.de>,
<swarren@...dia.com>, <devicetree-discuss@...ts.ozlabs.org>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-samsung-soc@...r.kernel.org>, <linux-omap@...r.kernel.org>,
<linux-usb@...r.kernel.org>, <linux-media@...r.kernel.org>,
<linux-fbdev@...r.kernel.org>, <akpm@...ux-foundation.org>,
<balajitk@...com>, <george.cherian@...com>, <nsekhar@...com>
Subject: Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sun, 21 Jul 2013, Sylwester Nawrocki wrote:
> > What's wrong with the platform_data structure, why can't that be used
> > for this?
>
> At the point the platform data of some driver is initialized, e.g. in
> board setup code the PHY pointer is not known, since the PHY supplier
> driver has not initialized yet. Even though we wanted to pass pointer
> to a PHY through some notifier call, it would have been not clear
> which PHY user driver should match on such notifier. A single PHY
> supplier driver can create M PHY objects and this needs to be mapped
> to N PHY user drivers. This mapping needs to be defined somewhere by
> the system integrator. It works well with device tree, but except that
> there seems to be no other reliable infrastructure in the kernel to
> define links/dependencies between devices, since device identifiers are
> not known in advance in all cases.
>
> What Tomasz proposed seems currently most reasonable to me for non-dt.
>
> > Or, if not, we can always add pointers to the platform device structure,
> > or even the main 'struct device' as well, that's what it is there for.
>
> Still we would need to solve a problem which platform device structure
> gets which PHY pointer.
Can you explain the issues in more detail? I don't fully understand
the situation.
Here's what I think I know:
The PHY and the controller it is attached to are both physical
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
files or by Device Tree information. Are they ever discovered
dynamically?
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?
The kernel needs to know which controller is attached to which
PHY. Currently this information is represented by name or ID
strings embedded in platform data.
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the PHY.
Until this is done, the controller's driver (the client) cannot
use the PHY.
Since there is no parent-child relation between the PHY and the
controller, there is no guarantee that the PHY's driver will be
ready when the controller's driver wants to use it. A deferred
probe may be needed.
The issue (or one of the issues) in this discussion is that
Greg does not like the idea of using names or IDs to associate
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
platform data, the obvious answer is a pointer to platform data
(either for the PHY or for the controller, or maybe both).
Probably some of the details above are wrong; please indicate where I
have gone astray. Also, I'm not clear about the role played by various
APIs. For example, where does phy_create() fit into this picture?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists