From: Arnd Bergmann <arnd@arndb.de>
To: balbi@ti.com
Cc: kishon <kishon@ti.com>,
rob@landley.net, tony@atomide.com, linux@arm.linux.org.uk,
eballetbo@gmail.com, javier@dowhile0.org,
gregkh@linuxfoundation.org, akpm@linux-foundation.org,
mchehab@redhat.com, cesarb@cesarb.net, davem@davemloft.net,
santosh.shilimkar@ti.com, broonie@opensource.wolfsonmicro.com,
swarren@nvidia.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
linux-usb@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v2 0/5] Generic PHY Framework
Date: Tue, 19 Feb 2013 14:34:40 +0000 [thread overview]
Message-ID: <201302191434.40495.arnd@arndb.de> (raw)
In-Reply-To: <20130219131258.GV23197@arwen.pp.htv.fi>
On Tuesday 19 February 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> > > 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 ;-)
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.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] Generic PHY Framework
Date: Tue, 19 Feb 2013 14:34:40 +0000 [thread overview]
Message-ID: <201302191434.40495.arnd@arndb.de> (raw)
In-Reply-To: <20130219131258.GV23197@arwen.pp.htv.fi>
On Tuesday 19 February 2013, Felipe Balbi wrote:
> On Tue, Feb 19, 2013 at 12:33:54PM +0000, Arnd Bergmann wrote:
> > > 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 ;-)
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.
Arnd
next prev parent reply other threads:[~2013-02-19 14:34 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 5:53 [PATCH v2 0/5] Generic PHY Framework Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` [PATCH v2 1/5] drivers: phy: add generic PHY framework Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 8:01 ` Felipe Balbi
2013-02-19 8:01 ` Felipe Balbi
2013-02-19 8:01 ` Felipe Balbi
2013-02-19 12:56 ` Arnd Bergmann
2013-02-19 12:56 ` Arnd Bergmann
2013-02-19 13:56 ` kishon
2013-02-19 13:56 ` kishon
2013-02-19 13:56 ` kishon
2013-02-19 14:28 ` Arnd Bergmann
2013-02-19 14:28 ` Arnd Bergmann
2013-02-23 22:44 ` Rob Landley
2013-02-23 22:44 ` Rob Landley
2013-02-23 22:44 ` Rob Landley
2013-02-25 6:41 ` kishon
2013-02-25 6:41 ` kishon
2013-02-25 6:41 ` kishon
2013-02-19 5:53 ` [PATCH v2 2/5] usb: phy: omap-usb2: use the new " Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 8:11 ` Felipe Balbi
2013-02-19 8:11 ` Felipe Balbi
2013-02-19 8:11 ` Felipe Balbi
2013-02-19 5:53 ` [PATCH v2 3/5] usb: otg: twl4030: " Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` [PATCH v2 4/5] ARM: OMAP: USB: Add phy binding information Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` [PATCH v2 5/5] usb: musb: omap2430: use the new generic PHY framework Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 5:53 ` Kishon Vijay Abraham I
2013-02-19 10:44 ` [PATCH v2 0/5] Generic PHY Framework Arnd Bergmann
2013-02-19 10:44 ` Arnd Bergmann
2013-02-19 11:28 ` kishon
2013-02-19 11:28 ` kishon
2013-02-19 11:28 ` kishon
[not found] ` <512361F0.1070500-l0cyMroinI0@public.gmane.org>
2013-02-19 12:33 ` Arnd Bergmann
2013-02-19 12:33 ` Arnd Bergmann
2013-02-19 12:33 ` Arnd Bergmann
2013-02-19 13:12 ` Felipe Balbi
2013-02-19 13:12 ` Felipe Balbi
2013-02-19 13:12 ` Felipe Balbi
2013-02-19 14:34 ` Arnd Bergmann [this message]
2013-02-19 14:34 ` Arnd Bergmann
2013-02-19 15:05 ` Felipe Balbi
2013-02-19 15:05 ` Felipe Balbi
2013-02-19 15:05 ` Felipe Balbi
2013-02-19 15:28 ` Arnd Bergmann
2013-02-19 15:28 ` Arnd Bergmann
2013-02-19 15:47 ` Felipe Balbi
2013-02-19 15:47 ` Felipe Balbi
2013-02-19 15:47 ` Felipe Balbi
2013-02-19 16:07 ` Marc Kleine-Budde
2013-02-19 16:07 ` Marc Kleine-Budde
2013-02-19 16:17 ` Felipe Balbi
2013-02-19 16:17 ` Felipe Balbi
2013-02-19 16:17 ` Felipe Balbi
2013-02-23 20:05 ` Rob Landley
2013-02-23 20:05 ` Rob Landley
2013-02-23 20:05 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201302191434.40495.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=akpm@linux-foundation.org \
--cc=balbi@ti.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=cesarb@cesarb.net \
--cc=davem@davemloft.net \
--cc=eballetbo@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=javier@dowhile0.org \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mchehab@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rob@landley.net \
--cc=santosh.shilimkar@ti.com \
--cc=swarren@nvidia.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.