From: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
balbi-l0cyMroinI0@public.gmane.org,
arnd-r2nGTMty4D4@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org,
rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org,
b-cousson-l0cyMroinI0@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
benoit.cousson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
mchehab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
cesarb-PWySMVKUnqmsTnJN9+BGXg@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
rnayak-l0cyMroinI0@public.gmane.org,
shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
santosh.shilimkar-l0cyMroinI0@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
nsekhar-l0cyMroinI0@public.gmane.org
Subject: Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Date: Tue, 04 Jun 2013 12:21:15 +0200 [thread overview]
Message-ID: <51ADBF9B.5060403@samsung.com> (raw)
In-Reply-To: <1367229812-30574-2-git-send-email-kishon-l0cyMroinI0@public.gmane.org>
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
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.
> + 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
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 ?
> +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 ?
Thanks,
Sylwester
--
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: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Date: Tue, 04 Jun 2013 12:21:15 +0200 [thread overview]
Message-ID: <51ADBF9B.5060403@samsung.com> (raw)
In-Reply-To: <1367229812-30574-2-git-send-email-kishon@ti.com>
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
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.
> + 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
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 ?
> +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 ?
Thanks,
Sylwester
WARNING: multiple messages have this Message-ID (diff)
From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Kishon Vijay Abraham I <kishon@ti.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, 04 Jun 2013 12:21:15 +0200 [thread overview]
Message-ID: <51ADBF9B.5060403@samsung.com> (raw)
In-Reply-To: <1367229812-30574-2-git-send-email-kishon@ti.com>
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
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.
> + 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
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 ?
> +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 ?
Thanks,
Sylwester
next prev parent reply other threads:[~2013-06-04 10:21 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 [this message]
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
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
[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-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
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=51ADBF9B.5060403@samsung.com \
--to=s.nawrocki-sze3o3uu22jbdgjk7y7tuq@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=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=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=nsekhar-l0cyMroinI0@public.gmane.org \
--cc=rnayak-l0cyMroinI0@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=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=swarren-DDmLM1+adcrQT0dZR+AlfA@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.