[PATCH v2 0/5] Generic PHY Framework

Hi,

On Tue, Feb 19, 2013 at 02:34:40PM +0000, Arnd Bergmann wrote:

On Tuesday 19 February 2013, Felipe Balbi wrote:

quoted

On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:

quoted

quoted

Currently drivers/phy and drivers/net/phy are independent and are not 
related to each other. There are some fundamental differences on how 
these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to 
match a PHY device with a PHY driver and the Ethernet device uses the 
bus layer to get the PHY.
The Generic PHY Framework however doesn't have any bus layer. The PHY 
should be like any other Platform Devices and Drivers and the framework 
will provide some APIs to register with the framework. And there are 
other APIs which any controller can use to get the PHY (for e.g., in the 
case of dt boot, it can use phandle to get a reference to the PHY).

Hmm, I think the use of a bus_type for a PHY actually sounds quite
appropriate. The actual PHY device would then be a child of the

really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI,
UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a
bit overkill IMO.

Imagine an I2C-controlled PHY driver like isp1301, that driver will have
to register i2c_driver and phy_driver, which looks weird to me. If the
only substitute for class is a bus, we can't drop classes just yet, I'm
afraid.

Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make
sense IMHO.

It's a fine line, but I think a phy is something that resembles a device
more than an LED does. When I read patch 1, I also noticed and commented
on the fact that it does use a 'class'. Now, according to Greg, we should
use 'bus_type' instead of 'class' in new code. I originally disagreed with
that concept, but he's the boss here and it's good if he has a vision
how things should be lined out.

In practice, there is little difference between a 'bus_type' and a 'class',
so just replace any instance of the former with the latter in your head
when reading the code ;-)

it's not so simple :-) if we must use bus_type we need to introduce all
the device/driver matching mechanism which isn't necessary with a class.

I understand that there is not a real common bus here, and the bus_type
infrastructure would basically be used as a way to represent each PHY
in sysfs and provide a way to enumerate and look them up inside of the
kernel.

right, but maybe we need another mechanism. If, in the long run we must
use bus_type, then eventually pwm, led, regulators, etc will all be
converted to bus_type. It will look quite weird IMHO.

Greg, can you pitch your suggestion here ? It would be great to hear
your rationale behind dropping class infrastructure, couldn't find
anything through Google and since feature-removal-schedule.txt has been
removed (without adding it to feature-removal-schedule.txt, I must add
:-) I don't know what's the idea behind removing classes.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130219/c0d87372/attachment.sig>