From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nsekhar-l0cyMroinI0@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
balbi-l0cyMroinI0@public.gmane.org,
santosh.shilimkar-l0cyMroinI0@public.gmane.org,
benoit.cousson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
Subject: Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Date: Tue, 4 Jun 2013 17:56:01 +0530 [thread overview]
Message-ID: <51ADDCD9.8080400@ti.com> (raw)
In-Reply-To: <51ADBF9B.5060403-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi,
On Tuesday 04 June 2013 03:51 PM, Sylwester Nawrocki wrote:
> On 04/29/2013 12:03 PM, 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>> ---
>> .../devicetree/bindings/phy/phy-bindings.txt | 66 +++
>> Documentation/phy.txt | 123 +++++
>> MAINTAINERS | 7 +
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 2 +
>> drivers/phy/Kconfig | 13 +
>> drivers/phy/Makefile | 5 +
>> drivers/phy/phy-core.c | 539 ++++++++++++++++++++
>> include/linux/phy/phy.h | 248 +++++++++
>> 9 files changed, 1005 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>> create mode 100644 Documentation/phy.txt
>> create mode 100644 drivers/phy/Kconfig
>> create mode 100644 drivers/phy/Makefile
>> create mode 100644 drivers/phy/phy-core.c
>> create mode 100644 include/linux/phy/phy.h
>
>> +static inline int phy_init(struct phy *phy)
>> +{
>> + pm_runtime_get_sync(&phy->dev);
>
> Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don’t enable pm_runtime.
> possibly have runtime_resume callback of a PHY device called before ops->init()
> call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
>
>> + if (phy->ops->init)
>> + return phy->ops->init(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_exit(struct phy *phy)
>> +{
>> + int ret = -EINVAL;
>> +
>> + if (phy->ops->exit)
>> + ret = phy->ops->exit(phy);
>> +
>> + pm_runtime_put_sync(&phy->dev);
>> +
>> + return ret;
>> +}
>
> Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
> nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
> returned if a callback is not implemented, so PHY users can recognize
> such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
>
>> +static inline int phy_power_on(struct phy *phy)
>> +{
>> + if (phy->ops->power_on)
>> + return phy->ops->power_on(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_power_off(struct phy *phy)
>> +{
>> + if (phy->ops->power_off)
>> + return phy->ops->power_off(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_pm_runtime_get(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_get_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get_sync(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put_sync(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_allow(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_allow(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_forbid(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_forbid(&phy->dev);
>> +}
>
> Do we need to have all these runtime PM wrappers ? I guess you
> intended to avoid referencing phy->dev from the PHY consumers ?
Yeah.. I dint want pm_runtime of phy core device to be called from PHY
consumers.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Date: Tue, 4 Jun 2013 17:56:01 +0530 [thread overview]
Message-ID: <51ADDCD9.8080400@ti.com> (raw)
In-Reply-To: <51ADBF9B.5060403@samsung.com>
Hi,
On Tuesday 04 June 2013 03:51 PM, Sylwester Nawrocki wrote:
> On 04/29/2013 12:03 PM, 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> .../devicetree/bindings/phy/phy-bindings.txt | 66 +++
>> Documentation/phy.txt | 123 +++++
>> MAINTAINERS | 7 +
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 2 +
>> drivers/phy/Kconfig | 13 +
>> drivers/phy/Makefile | 5 +
>> drivers/phy/phy-core.c | 539 ++++++++++++++++++++
>> include/linux/phy/phy.h | 248 +++++++++
>> 9 files changed, 1005 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>> create mode 100644 Documentation/phy.txt
>> create mode 100644 drivers/phy/Kconfig
>> create mode 100644 drivers/phy/Makefile
>> create mode 100644 drivers/phy/phy-core.c
>> create mode 100644 include/linux/phy/phy.h
>
>> +static inline int phy_init(struct phy *phy)
>> +{
>> + pm_runtime_get_sync(&phy->dev);
>
> Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don?t enable pm_runtime.
> possibly have runtime_resume callback of a PHY device called before ops->init()
> call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
>
>> + if (phy->ops->init)
>> + return phy->ops->init(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_exit(struct phy *phy)
>> +{
>> + int ret = -EINVAL;
>> +
>> + if (phy->ops->exit)
>> + ret = phy->ops->exit(phy);
>> +
>> + pm_runtime_put_sync(&phy->dev);
>> +
>> + return ret;
>> +}
>
> Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
> nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
> returned if a callback is not implemented, so PHY users can recognize
> such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
>
>> +static inline int phy_power_on(struct phy *phy)
>> +{
>> + if (phy->ops->power_on)
>> + return phy->ops->power_on(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_power_off(struct phy *phy)
>> +{
>> + if (phy->ops->power_off)
>> + return phy->ops->power_off(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_pm_runtime_get(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_get_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get_sync(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put_sync(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_allow(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_allow(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_forbid(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_forbid(&phy->dev);
>> +}
>
> Do we need to have all these runtime PM wrappers ? I guess you
> intended to avoid referencing phy->dev from the PHY consumers ?
Yeah.. I dint want pm_runtime of phy core device to be called from PHY
consumers.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: <grant.likely@linaro.org>, <tony@atomide.com>, <balbi@ti.com>,
<arnd@arndb.de>, <swarren@nvidia.com>,
<linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-usb@vger.kernel.org>, <rob.herring@calxeda.com>,
<rob@landley.net>, <b-cousson@ti.com>, <linux@arm.linux.org.uk>,
<gregkh@linuxfoundation.org>, <benoit.cousson@linaro.org>,
<mchehab@redhat.com>, <akpm@linux-foundation.org>,
<cesarb@cesarb.net>, <davem@davemloft.net>, <rnayak@ti.com>,
<shawn.guo@linaro.org>, <santosh.shilimkar@ti.com>,
<devicetree-discuss@lists.ozlabs.org>,
<linux-doc@vger.kernel.org>, <nsekhar@ti.com>
Subject: Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Date: Tue, 4 Jun 2013 17:56:01 +0530 [thread overview]
Message-ID: <51ADDCD9.8080400@ti.com> (raw)
In-Reply-To: <51ADBF9B.5060403@samsung.com>
Hi,
On Tuesday 04 June 2013 03:51 PM, Sylwester Nawrocki wrote:
> On 04/29/2013 12:03 PM, 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. For dt-boot, the PHY drivers should
>> also register *PHY provider* with the framework.
>>
>> PHY drivers should create the PHY by passing id and ops like init, exit,
>> power_on and power_off. This framework is also pm runtime enabled.
>>
>> The documentation for the generic PHY framework is added in
>> Documentation/phy.txt and the documentation for dt binding can be found at
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> .../devicetree/bindings/phy/phy-bindings.txt | 66 +++
>> Documentation/phy.txt | 123 +++++
>> MAINTAINERS | 7 +
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 2 +
>> drivers/phy/Kconfig | 13 +
>> drivers/phy/Makefile | 5 +
>> drivers/phy/phy-core.c | 539 ++++++++++++++++++++
>> include/linux/phy/phy.h | 248 +++++++++
>> 9 files changed, 1005 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
>> create mode 100644 Documentation/phy.txt
>> create mode 100644 drivers/phy/Kconfig
>> create mode 100644 drivers/phy/Makefile
>> create mode 100644 drivers/phy/phy-core.c
>> create mode 100644 include/linux/phy/phy.h
>
>> +static inline int phy_init(struct phy *phy)
>> +{
>> + pm_runtime_get_sync(&phy->dev);
>
> Hmm, no need to check return value here ? Also it looks a bit unexpected to
I purposely dint check the return values in order to support platforms
that don’t enable pm_runtime.
> possibly have runtime_resume callback of a PHY device called before ops->init()
> call ? It seems a bit unclear what the purpose of init() callback is.
Not really. Anything that is used to initialize the PHY (internal
configuration) can go in phy_init. Usually in runtime_resume callback,
optional functional clocks are enabled and also in some cases context
restore is done. So it really makes sense to enable clocks/module
(pm_runtime_get_sync) before doing a PHY configuration (phy_init).
>
>> + if (phy->ops->init)
>> + return phy->ops->init(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_exit(struct phy *phy)
>> +{
>> + int ret = -EINVAL;
>> +
>> + if (phy->ops->exit)
>> + ret = phy->ops->exit(phy);
>> +
>> + pm_runtime_put_sync(&phy->dev);
>> +
>> + return ret;
>> +}
>
> Do phy_init/phy_exit need to be mandatory ? What if there is really
No. phy_init/phy_exit is not mandatory at all.
> nothing to do in those callbacks ? Perhaps -ENOIOCTLCMD should be
> returned if a callback is not implemented, so PHY users can recognize
> such situation and proceed ?
So currently these APIs return -EINVAL if these callbacks are not
populated which is good enough IMHO.
>
>> +static inline int phy_power_on(struct phy *phy)
>> +{
>> + if (phy->ops->power_on)
>> + return phy->ops->power_on(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_power_off(struct phy *phy)
>> +{
>> + if (phy->ops->power_off)
>> + return phy->ops->power_off(phy);
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static inline int phy_pm_runtime_get(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_get_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_get_sync(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put(&phy->dev);
>> +}
>> +
>> +static inline int phy_pm_runtime_put_sync(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return -EINVAL;
>> +
>> + return pm_runtime_put_sync(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_allow(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_allow(&phy->dev);
>> +}
>> +
>> +static inline void phy_pm_runtime_forbid(struct phy *phy)
>> +{
>> + if (WARN(IS_ERR(phy), "Invalid PHY reference\n"))
>> + return;
>> +
>> + pm_runtime_forbid(&phy->dev);
>> +}
>
> Do we need to have all these runtime PM wrappers ? I guess you
> intended to avoid referencing phy->dev from the PHY consumers ?
Yeah.. I dint want pm_runtime of phy core device to be called from PHY
consumers.
Thanks
Kishon
next prev parent reply other threads:[~2013-06-04 12:26 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 10:03 [PATCH v6 0/9] Generic PHY Framework Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 1/9] drivers: phy: add generic PHY framework Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
[not found] ` <1367229812-30574-2-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2013-05-28 22:37 ` Sylwester Nawrocki
2013-05-28 22:37 ` Sylwester Nawrocki
2013-05-28 22:37 ` Sylwester Nawrocki
2013-05-29 5:38 ` Kishon Vijay Abraham I
2013-05-29 5:38 ` Kishon Vijay Abraham I
2013-05-29 5:38 ` Kishon Vijay Abraham I
2013-06-04 10:19 ` Sylwester Nawrocki
2013-06-04 10:19 ` Sylwester Nawrocki
2013-06-04 10:21 ` Sylwester Nawrocki
2013-06-04 10:21 ` Sylwester Nawrocki
2013-06-04 10:21 ` Sylwester Nawrocki
[not found] ` <51ADBF9B.5060403-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-06-04 12:26 ` Kishon Vijay Abraham I [this message]
2013-06-04 12:26 ` Kishon Vijay Abraham I
2013-06-04 12:26 ` Kishon Vijay Abraham I
2013-06-04 13:43 ` Sylwester Nawrocki
2013-06-04 13:43 ` Sylwester Nawrocki
[not found] ` <51ADEEF6.1030200-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-06-05 5:25 ` Kishon Vijay Abraham I
2013-06-05 5:25 ` Kishon Vijay Abraham I
2013-06-05 5:25 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 2/9] usb: phy: omap-usb2: use the new " Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 4/9] usb: phy: twl4030: twl4030 shouldn't be subsys_initcall Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 6/9] ARM: dts: omap: update usb_otg_hs data Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 7/9] usb: musb: omap2430: use the new generic PHY framework Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
[not found] ` <1367229812-30574-1-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
2013-04-29 10:03 ` [PATCH v6 3/9] usb: phy: twl4030: " Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 5/9] ARM: OMAP: USB: Add phy binding information Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 8/9] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` [PATCH v6 9/9] usb: phy: twl4030-usb: remove *set_suspend* and *phy_init* ops Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-04-29 10:03 ` Kishon Vijay Abraham I
2013-05-21 5:01 ` [PATCH v6 0/9] Generic PHY Framework Kishon Vijay Abraham I
2013-05-21 5:01 ` Kishon Vijay Abraham I
2013-05-21 5:01 ` Kishon Vijay Abraham I
2013-05-28 6:35 ` Kishon Vijay Abraham I
2013-05-28 6:35 ` Kishon Vijay Abraham I
2013-05-28 6:35 ` Kishon Vijay Abraham I
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=51ADDCD9.8080400@ti.com \
--to=kishon-l0cymroini0@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=balbi-l0cyMroinI0@public.gmane.org \
--cc=benoit.cousson-QSEj5FYQhm4dnm+yROfE0A@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=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@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=nsekhar-l0cyMroinI0@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=santosh.shilimkar-l0cyMroinI0@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@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.