From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: balbi-l0cyMroinI0@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
b-cousson-l0cyMroinI0@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org,
mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
santosh.shilimkar-l0cyMroinI0@public.gmane.org,
broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Date: Wed, 03 Apr 2013 17:54:11 -0600 [thread overview]
Message-ID: <515CC123.4060402@wwwdotorg.org> (raw)
In-Reply-To: <1364993634-6378-2-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
On 04/03/2013 06:53 AM, 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.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> power_on, power_off.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> +extern struct phy *devm_phy_create(struct device *dev, const char *label,
> + struct device_node *of_node, int type, struct phy_ops *ops,
> + void *priv);
Can't the function get of_node from dev->of_node?
I wonder if we shouldn't split up the registration a bit though:
A function which registers a PHY object itself. That's the function above.
A function which registers a DT-based PHY provider.
Then, the of_xlate op would be part of the PHY provider, not part of
some random PHY that happens to exist on that node. So:
struct phy {
struct device *dev;
struct module *owner;
int (*init)(struct phy *phy);
int (*exit)(struct phy *phy);
int (*suspend)(struct phy *phy);
int (*resume)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
};
int phy_register(struct phy *phy);
All PHY providers would use that API, whether running in a DT-base
system or not.
struct of_phy_provider {
struct device *dev;
struct phy * (*of_xlate)(struct of_phy_provider *provider,
struct of_phandle_args *args);
};
int phy_register_of_provider(struct of_phy_provider *provider);
Only DT-based PHY providers would use that API.
... or something like that?
phy_get() would do something like:
if dev->of_node:
# look up using registerd of_phy_providers
phy = phy_get_of(...)
if phy: return phy
# now look up using whatever other mapping table exists
phy = ...
return phy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Date: Wed, 03 Apr 2013 17:54:11 -0600 [thread overview]
Message-ID: <515CC123.4060402@wwwdotorg.org> (raw)
In-Reply-To: <1364993634-6378-2-git-send-email-kishon@ti.com>
On 04/03/2013 06:53 AM, 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.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> power_on, power_off.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> +extern struct phy *devm_phy_create(struct device *dev, const char *label,
> + struct device_node *of_node, int type, struct phy_ops *ops,
> + void *priv);
Can't the function get of_node from dev->of_node?
I wonder if we shouldn't split up the registration a bit though:
A function which registers a PHY object itself. That's the function above.
A function which registers a DT-based PHY provider.
Then, the of_xlate op would be part of the PHY provider, not part of
some random PHY that happens to exist on that node. So:
struct phy {
struct device *dev;
struct module *owner;
int (*init)(struct phy *phy);
int (*exit)(struct phy *phy);
int (*suspend)(struct phy *phy);
int (*resume)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
};
int phy_register(struct phy *phy);
All PHY providers would use that API, whether running in a DT-base
system or not.
struct of_phy_provider {
struct device *dev;
struct phy * (*of_xlate)(struct of_phy_provider *provider,
struct of_phandle_args *args);
};
int phy_register_of_provider(struct of_phy_provider *provider);
Only DT-based PHY providers would use that API.
... or something like that?
phy_get() would do something like:
if dev->of_node:
# look up using registerd of_phy_providers
phy = phy_get_of(...)
if phy: return phy
# now look up using whatever other mapping table exists
phy = ...
return phy
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Kishon Vijay Abraham I <kishon@ti.com>
Cc: balbi@ti.com, gregkh@linuxfoundation.org, arnd@arndb.de,
akpm@linux-foundation.org, sylvester.nawrocki@gmail.com,
rob@landley.net, netdev@vger.kernel.org, davem@davemloft.net,
cesarb@cesarb.net, linux-usb@vger.kernel.org,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
tony@atomide.com, grant.likely@secretlab.ca,
rob.herring@calxeda.com, b-cousson@ti.com,
linux@arm.linux.org.uk, eballetbo@gmail.com, javier@dowhile0.org,
mchehab@redhat.com, santosh.shilimkar@ti.com,
broonie@opensource.wolfsonmicro.com, swarren@nvidia.com,
linux-doc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 1/6] drivers: phy: add generic PHY framework
Date: Wed, 03 Apr 2013 17:54:11 -0600 [thread overview]
Message-ID: <515CC123.4060402@wwwdotorg.org> (raw)
In-Reply-To: <1364993634-6378-2-git-send-email-kishon@ti.com>
On 04/03/2013 06:53 AM, 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.
>
> PHY drivers should create the PHY by passing phy_descriptor that has
> describes the PHY (label, type etc..) and ops like init, exit, suspend, resume,
> power_on, power_off.
>
> The documentation for the generic PHY framework is added in
> Documentation/phy.txt and the documentation for the sysfs entry is added
> in Documentation/ABI/testing/sysfs-class-phy and the documentation for
> dt binding is can be found at
> Documentation/devicetree/bindings/phy/phy-bindings.txt
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> +extern struct phy *devm_phy_create(struct device *dev, const char *label,
> + struct device_node *of_node, int type, struct phy_ops *ops,
> + void *priv);
Can't the function get of_node from dev->of_node?
I wonder if we shouldn't split up the registration a bit though:
A function which registers a PHY object itself. That's the function above.
A function which registers a DT-based PHY provider.
Then, the of_xlate op would be part of the PHY provider, not part of
some random PHY that happens to exist on that node. So:
struct phy {
struct device *dev;
struct module *owner;
int (*init)(struct phy *phy);
int (*exit)(struct phy *phy);
int (*suspend)(struct phy *phy);
int (*resume)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
};
int phy_register(struct phy *phy);
All PHY providers would use that API, whether running in a DT-base
system or not.
struct of_phy_provider {
struct device *dev;
struct phy * (*of_xlate)(struct of_phy_provider *provider,
struct of_phandle_args *args);
};
int phy_register_of_provider(struct of_phy_provider *provider);
Only DT-based PHY providers would use that API.
... or something like that?
phy_get() would do something like:
if dev->of_node:
# look up using registerd of_phy_providers
phy = phy_get_of(...)
if phy: return phy
# now look up using whatever other mapping table exists
phy = ...
return phy
next prev parent reply other threads:[~2013-04-03 23:54 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-03 12:53 [PATCH v5 0/6] Generic PHY Framework Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` [PATCH v5 4/6] ARM: OMAP: USB: Add phy binding information Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` [PATCH v5 5/6] ARM: dts: omap: update usb_otg_hs data Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
[not found] ` <1364993634-6378-1-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2013-04-03 12:53 ` [PATCH v5 1/6] drivers: phy: add generic PHY framework Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
[not found] ` <1364993634-6378-2-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2013-04-03 13:42 ` Felipe Balbi
2013-04-03 13:42 ` Felipe Balbi
2013-04-03 13:42 ` Felipe Balbi
[not found] ` <20130403134102.GC14680-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2013-04-03 14:18 ` Kishon Vijay Abraham I
2013-04-03 14:18 ` Kishon Vijay Abraham I
2013-04-03 14:18 ` Kishon Vijay Abraham I
[not found] ` <515C3A42.4020404-l0cyMroinI0@public.gmane.org>
2013-04-03 14:27 ` Felipe Balbi
2013-04-03 14:27 ` Felipe Balbi
2013-04-03 14:27 ` Felipe Balbi
2013-04-03 14:32 ` Kishon Vijay Abraham I
2013-04-03 14:32 ` Kishon Vijay Abraham I
2013-04-03 14:32 ` Kishon Vijay Abraham I
[not found] ` <515C3D94.1060000-l0cyMroinI0@public.gmane.org>
2013-04-03 15:47 ` Felipe Balbi
2013-04-03 15:47 ` Felipe Balbi
2013-04-03 15:47 ` Felipe Balbi
[not found] ` <20130403154704.GD19093-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2013-04-04 8:56 ` Kishon Vijay Abraham I
2013-04-04 8:56 ` Kishon Vijay Abraham I
2013-04-04 8:56 ` Kishon Vijay Abraham I
2013-04-03 23:54 ` Stephen Warren [this message]
2013-04-03 23:54 ` Stephen Warren
2013-04-03 23:54 ` Stephen Warren
[not found] ` <515CC123.4060402-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-04-04 7:15 ` Felipe Balbi
2013-04-04 7:15 ` Felipe Balbi
2013-04-04 7:15 ` Felipe Balbi
2013-04-08 13:21 ` Kishon Vijay Abraham I
2013-04-08 13:21 ` Kishon Vijay Abraham I
2013-04-08 13:21 ` Kishon Vijay Abraham I
2013-04-03 21:46 ` Sylwester Nawrocki
2013-04-03 21:46 ` Sylwester Nawrocki
2013-04-04 9:21 ` Kishon Vijay Abraham I
2013-04-04 9:21 ` Kishon Vijay Abraham I
2013-04-04 9:21 ` Kishon Vijay Abraham I
[not found] ` <515D462F.9050109-l0cyMroinI0@public.gmane.org>
2013-04-04 10:41 ` Sylwester Nawrocki
2013-04-04 10:41 ` Sylwester Nawrocki
2013-04-04 10:41 ` Sylwester Nawrocki
2013-04-04 11:11 ` Kishon Vijay Abraham I
2013-04-04 11:11 ` Kishon Vijay Abraham I
2013-04-04 11:11 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` [PATCH v5 2/6] usb: phy: omap-usb2: use the new " Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
[not found] ` <1364993634-6378-3-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2013-04-03 13:48 ` Felipe Balbi
2013-04-03 13:48 ` Felipe Balbi
2013-04-03 13:48 ` Felipe Balbi
2013-04-03 14:55 ` Arnd Bergmann
2013-04-03 14:55 ` Arnd Bergmann
2013-04-03 15:48 ` Felipe Balbi
2013-04-03 15:48 ` Felipe Balbi
2013-04-03 15:48 ` Felipe Balbi
2013-04-03 12:53 ` [PATCH v5 3/6] usb: otg: twl4030: " Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` [PATCH v5 6/6] usb: musb: omap2430: " Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 12:53 ` Kishon Vijay Abraham I
2013-04-03 23:42 ` [PATCH v5 0/6] Generic PHY Framework Stephen Warren
2013-04-03 23:42 ` Stephen Warren
2013-04-03 23:42 ` Stephen Warren
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=515CC123.4060402@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=b-cousson-l0cyMroinI0@public.gmane.org \
--cc=balbi-l0cyMroinI0@public.gmane.org \
--cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
--cc=cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org \
--cc=kishon-l0cyMroinI0@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=santosh.shilimkar-l0cyMroinI0@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=sylvester.nawrocki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
/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.