From: JeffyChen <jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: jcliang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
xxm-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
aisheng.dong-3arQi8VN3Tc@public.gmane.org
Subject: Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
Date: Fri, 26 Jan 2018 17:45:31 +0800 [thread overview]
Message-ID: <5A6AF8BB.4040601@rock-chips.com> (raw)
In-Reply-To: <f06d2d9f-3869-ed02-43f4-f4ea4a104a57-5wv7dgnIgG8@public.gmane.org>
Hi Robin,
Thanks for your reply.
On 01/24/2018 09:49 PM, Robin Murphy wrote:
>>
>> +Optional properties:
>> +- clocks : A list of master clocks requires for the IOMMU to be
>> accessible
>
> s/requires/required/
ok
>
>> + by the host CPU. The number of clocks depends on the master
>> + block and might as well be zero. See [1] for generic clock
>
> Oops, some subtleties of English here :)
>
> To say "the number of clocks ... might as well be zero" effectively
> implies "there's no point ever specifying any clocks". I guess what you
> really mean here is "...might well be...", i.e. it is both valid and
> reasonably likely to require zero clocks.
ok
>
>> + bindings description.
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> Optional properties:
>> - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
>> @@ -27,5 +34,6 @@ Example:
>> reg = <0xff940300 0x100>;
>> interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>> interrupt-names = "vopl_mmu";
>> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
>> #iommu-cells = <0>;
>> };
>> diff --git a/drivers/iommu/rockchip-iommu.c
>> b/drivers/iommu/rockchip-iommu.c
>> index c4131ca792e0..8a5e2a659b67 100644
>> --- a/drivers/iommu/rockchip-iommu.c
>> +++ b/drivers/iommu/rockchip-iommu.c
>> @@ -4,6 +4,7 @@
>> * published by the Free Software Foundation.
>> */
>> +#include <linux/clk.h>
>> #include <linux/compiler.h>
>> #include <linux/delay.h>
>> #include <linux/device.h>
>> @@ -91,6 +92,8 @@ struct rk_iommu {
>> struct device *dev;
>> void __iomem **bases;
>> int num_mmu;
>> + struct clk_bulk_data *clocks;
>> + int num_clocks;
>> bool reset_disabled;
>> struct iommu_device iommu;
>> struct list_head node; /* entry in rk_iommu_domain.iommus */
>> @@ -450,6 +453,38 @@ static int rk_iommu_force_reset(struct rk_iommu
>> *iommu)
>> return 0;
>> }
>> +static int rk_iommu_of_get_clocks(struct rk_iommu *iommu)
>> +{
>> + struct device_node *np = iommu->dev->of_node;
>> + int ret;
>> + int i;
>> +
>> + ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>> + if (ret == -ENOENT)
>> + return 0;
>> + else if (ret < 0)
>> + return ret;
>> +
>> + iommu->num_clocks = ret;
>> + iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
>> + sizeof(*iommu->clocks), GFP_KERNEL);
>> + if (!iommu->clocks)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < iommu->num_clocks; ++i) {
>> + iommu->clocks[i].clk = of_clk_get(np, i);
>> + if (IS_ERR(iommu->clocks[i].clk)) {
>> + ret = PTR_ERR(iommu->clocks[i].clk);
>> + goto err_clk_put;
>> + }
>> + }
>
> Just to confirm my understanding from a quick scan through the code, the
> reason we can't use clk_bulk_get() here is that currently, clocks[i].id
> being NULL means we'd end up just getting the first clock multiple
> times, right?
right, without a valid name, it would return the first clock.
/* Walk up the tree of devices looking for a clock that matches */
while (np) {
int index = 0;
/*
* For named clocks, first look up the name in the
* "clock-names" property. If it cannot be found, then
* index will be an error code, and of_clk_get() will fail.
*/
if (name)
index = of_property_match_string(np, "clock-names", name);
clk = __of_clk_get(np, index, dev_id, name);
>
> I guess there could be other users who also want "just get whatever
> clocks I have" functionality, so it might be worth proposing that for
> the core API as a separate/follow-up patch, but it definitely doesn't
> need to be part of this series.
right, i can try to do it later :)
>
> I really don't know enough about correct clk API usage, but modulo the
> binding comments it certainly looks nice and tidy now;
>
> Acked-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
thanks.
>
> Thanks,
> Robin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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: jeffy.chen@rock-chips.com (JeffyChen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
Date: Fri, 26 Jan 2018 17:45:31 +0800 [thread overview]
Message-ID: <5A6AF8BB.4040601@rock-chips.com> (raw)
In-Reply-To: <f06d2d9f-3869-ed02-43f4-f4ea4a104a57@arm.com>
Hi Robin,
Thanks for your reply.
On 01/24/2018 09:49 PM, Robin Murphy wrote:
>>
>> +Optional properties:
>> +- clocks : A list of master clocks requires for the IOMMU to be
>> accessible
>
> s/requires/required/
ok
>
>> + by the host CPU. The number of clocks depends on the master
>> + block and might as well be zero. See [1] for generic clock
>
> Oops, some subtleties of English here :)
>
> To say "the number of clocks ... might as well be zero" effectively
> implies "there's no point ever specifying any clocks". I guess what you
> really mean here is "...might well be...", i.e. it is both valid and
> reasonably likely to require zero clocks.
ok
>
>> + bindings description.
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> Optional properties:
>> - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
>> @@ -27,5 +34,6 @@ Example:
>> reg = <0xff940300 0x100>;
>> interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>> interrupt-names = "vopl_mmu";
>> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
>> #iommu-cells = <0>;
>> };
>> diff --git a/drivers/iommu/rockchip-iommu.c
>> b/drivers/iommu/rockchip-iommu.c
>> index c4131ca792e0..8a5e2a659b67 100644
>> --- a/drivers/iommu/rockchip-iommu.c
>> +++ b/drivers/iommu/rockchip-iommu.c
>> @@ -4,6 +4,7 @@
>> * published by the Free Software Foundation.
>> */
>> +#include <linux/clk.h>
>> #include <linux/compiler.h>
>> #include <linux/delay.h>
>> #include <linux/device.h>
>> @@ -91,6 +92,8 @@ struct rk_iommu {
>> struct device *dev;
>> void __iomem **bases;
>> int num_mmu;
>> + struct clk_bulk_data *clocks;
>> + int num_clocks;
>> bool reset_disabled;
>> struct iommu_device iommu;
>> struct list_head node; /* entry in rk_iommu_domain.iommus */
>> @@ -450,6 +453,38 @@ static int rk_iommu_force_reset(struct rk_iommu
>> *iommu)
>> return 0;
>> }
>> +static int rk_iommu_of_get_clocks(struct rk_iommu *iommu)
>> +{
>> + struct device_node *np = iommu->dev->of_node;
>> + int ret;
>> + int i;
>> +
>> + ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>> + if (ret == -ENOENT)
>> + return 0;
>> + else if (ret < 0)
>> + return ret;
>> +
>> + iommu->num_clocks = ret;
>> + iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
>> + sizeof(*iommu->clocks), GFP_KERNEL);
>> + if (!iommu->clocks)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < iommu->num_clocks; ++i) {
>> + iommu->clocks[i].clk = of_clk_get(np, i);
>> + if (IS_ERR(iommu->clocks[i].clk)) {
>> + ret = PTR_ERR(iommu->clocks[i].clk);
>> + goto err_clk_put;
>> + }
>> + }
>
> Just to confirm my understanding from a quick scan through the code, the
> reason we can't use clk_bulk_get() here is that currently, clocks[i].id
> being NULL means we'd end up just getting the first clock multiple
> times, right?
right, without a valid name, it would return the first clock.
/* Walk up the tree of devices looking for a clock that matches */
while (np) {
int index = 0;
/*
* For named clocks, first look up the name in the
* "clock-names" property. If it cannot be found, then
* index will be an error code, and of_clk_get() will fail.
*/
if (name)
index = of_property_match_string(np, "clock-names", name);
clk = __of_clk_get(np, index, dev_id, name);
>
> I guess there could be other users who also want "just get whatever
> clocks I have" functionality, so it might be worth proposing that for
> the core API as a separate/follow-up patch, but it definitely doesn't
> need to be part of this series.
right, i can try to do it later :)
>
> I really don't know enough about correct clk API usage, but modulo the
> binding comments it certainly looks nice and tidy now;
>
> Acked-by: Robin Murphy <robin.murphy@arm.com>
thanks.
>
> Thanks,
> Robin.
WARNING: multiple messages have this Message-ID (diff)
From: JeffyChen <jeffy.chen@rock-chips.com>
To: Robin Murphy <robin.murphy@arm.com>, linux-kernel@vger.kernel.org
Cc: jcliang@chromium.org, xxm@rock-chips.com, tfiga@chromium.org,
devicetree@vger.kernel.org, Heiko Stuebner <heiko@sntech.de>,
linux-rockchip@lists.infradead.org,
iommu@lists.linux-foundation.org,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org, aisheng.dong@nxp.com
Subject: Re: [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU
Date: Fri, 26 Jan 2018 17:45:31 +0800 [thread overview]
Message-ID: <5A6AF8BB.4040601@rock-chips.com> (raw)
In-Reply-To: <f06d2d9f-3869-ed02-43f4-f4ea4a104a57@arm.com>
Hi Robin,
Thanks for your reply.
On 01/24/2018 09:49 PM, Robin Murphy wrote:
>>
>> +Optional properties:
>> +- clocks : A list of master clocks requires for the IOMMU to be
>> accessible
>
> s/requires/required/
ok
>
>> + by the host CPU. The number of clocks depends on the master
>> + block and might as well be zero. See [1] for generic clock
>
> Oops, some subtleties of English here :)
>
> To say "the number of clocks ... might as well be zero" effectively
> implies "there's no point ever specifying any clocks". I guess what you
> really mean here is "...might well be...", i.e. it is both valid and
> reasonably likely to require zero clocks.
ok
>
>> + bindings description.
>> +
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> Optional properties:
>> - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
>> @@ -27,5 +34,6 @@ Example:
>> reg = <0xff940300 0x100>;
>> interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>> interrupt-names = "vopl_mmu";
>> + clocks = <&cru ACLK_VOP1>, <&cru DCLK_VOP1>, <&cru HCLK_VOP1>;
>> #iommu-cells = <0>;
>> };
>> diff --git a/drivers/iommu/rockchip-iommu.c
>> b/drivers/iommu/rockchip-iommu.c
>> index c4131ca792e0..8a5e2a659b67 100644
>> --- a/drivers/iommu/rockchip-iommu.c
>> +++ b/drivers/iommu/rockchip-iommu.c
>> @@ -4,6 +4,7 @@
>> * published by the Free Software Foundation.
>> */
>> +#include <linux/clk.h>
>> #include <linux/compiler.h>
>> #include <linux/delay.h>
>> #include <linux/device.h>
>> @@ -91,6 +92,8 @@ struct rk_iommu {
>> struct device *dev;
>> void __iomem **bases;
>> int num_mmu;
>> + struct clk_bulk_data *clocks;
>> + int num_clocks;
>> bool reset_disabled;
>> struct iommu_device iommu;
>> struct list_head node; /* entry in rk_iommu_domain.iommus */
>> @@ -450,6 +453,38 @@ static int rk_iommu_force_reset(struct rk_iommu
>> *iommu)
>> return 0;
>> }
>> +static int rk_iommu_of_get_clocks(struct rk_iommu *iommu)
>> +{
>> + struct device_node *np = iommu->dev->of_node;
>> + int ret;
>> + int i;
>> +
>> + ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
>> + if (ret == -ENOENT)
>> + return 0;
>> + else if (ret < 0)
>> + return ret;
>> +
>> + iommu->num_clocks = ret;
>> + iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
>> + sizeof(*iommu->clocks), GFP_KERNEL);
>> + if (!iommu->clocks)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < iommu->num_clocks; ++i) {
>> + iommu->clocks[i].clk = of_clk_get(np, i);
>> + if (IS_ERR(iommu->clocks[i].clk)) {
>> + ret = PTR_ERR(iommu->clocks[i].clk);
>> + goto err_clk_put;
>> + }
>> + }
>
> Just to confirm my understanding from a quick scan through the code, the
> reason we can't use clk_bulk_get() here is that currently, clocks[i].id
> being NULL means we'd end up just getting the first clock multiple
> times, right?
right, without a valid name, it would return the first clock.
/* Walk up the tree of devices looking for a clock that matches */
while (np) {
int index = 0;
/*
* For named clocks, first look up the name in the
* "clock-names" property. If it cannot be found, then
* index will be an error code, and of_clk_get() will fail.
*/
if (name)
index = of_property_match_string(np, "clock-names", name);
clk = __of_clk_get(np, index, dev_id, name);
>
> I guess there could be other users who also want "just get whatever
> clocks I have" functionality, so it might be worth proposing that for
> the core API as a separate/follow-up patch, but it definitely doesn't
> need to be part of this series.
right, i can try to do it later :)
>
> I really don't know enough about correct clk API usage, but modulo the
> binding comments it certainly looks nice and tidy now;
>
> Acked-by: Robin Murphy <robin.murphy@arm.com>
thanks.
>
> Thanks,
> Robin.
next prev parent reply other threads:[~2018-01-26 9:45 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 10:35 [PATCH v5 00/13] iommu/rockchip: Use OF_IOMMU Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 02/13] iommu/rockchip: Fix error handling in probe Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 03/13] iommu/rockchip: Request irqs in rk_iommu_probe() Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 04/13] iommu/rockchip: Fix error handling in attach Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 06/13] iommu/rockchip: Fix TLB flush of secondary IOMMUs Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 09/13] iommu/rockchip: Use IOMMU device for dma mapping operations Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 11/13] iommu/rockchip: Fix error handling in init Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
[not found] ` <20180124103516.2571-1-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-01-24 10:35 ` [PATCH v5 01/13] iommu/rockchip: Prohibit unbind and remove Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 07/13] ARM: dts: rockchip: add clocks in vop iommu nodes Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 08/13] iommu/rockchip: Control clocks needed to access the IOMMU Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 13:49 ` Robin Murphy
2018-01-24 13:49 ` Robin Murphy
[not found] ` <f06d2d9f-3869-ed02-43f4-f4ea4a104a57-5wv7dgnIgG8@public.gmane.org>
2018-01-26 9:45 ` JeffyChen [this message]
2018-01-26 9:45 ` JeffyChen
2018-01-26 9:45 ` JeffyChen
2018-02-14 10:03 ` Vivek Gautam
2018-02-14 10:03 ` Vivek Gautam
2018-02-14 10:03 ` Vivek Gautam
[not found] ` <edc5002d-c83f-cf11-ecfb-0c4400b10d07-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-14 11:27 ` Tomasz Figa via iommu
2018-02-14 11:27 ` Tomasz Figa
2018-02-14 11:27 ` Tomasz Figa
[not found] ` <20180124103516.2571-9-jeffy.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-01-30 17:05 ` Rob Herring
2018-01-30 17:05 ` Rob Herring
2018-01-30 17:05 ` Rob Herring
2018-01-31 7:52 ` Tomasz Figa
2018-01-31 7:52 ` Tomasz Figa
2018-01-31 7:52 ` Tomasz Figa
[not found] ` <CAAFQd5A383Ey3Ntg_hcsvzHj2DsSuW6RMQ+kP=LPAZ1YmqjHOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-01-31 13:50 ` Rob Herring
2018-01-31 13:50 ` Rob Herring
2018-01-31 13:50 ` Rob Herring
2018-02-01 11:19 ` JeffyChen
[not found] ` <5A72F7D2.1050201-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-02-23 10:24 ` JeffyChen
[not found] ` <5A8FEBC6.4000408-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-02-27 16:59 ` Robin Murphy
2018-02-27 16:59 ` Robin Murphy
2018-02-27 16:59 ` Robin Murphy
2018-02-28 13:00 ` JeffyChen
2018-02-28 13:00 ` JeffyChen
[not found] ` <5A96A809.2020509-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2018-02-28 15:06 ` Robin Murphy
2018-02-28 15:06 ` Robin Murphy
2018-02-28 15:06 ` Robin Murphy
[not found] ` <34a60ab2-a3af-3302-6612-740cba5460db-5wv7dgnIgG8@public.gmane.org>
2018-03-01 1:37 ` JeffyChen
2018-03-01 1:37 ` JeffyChen
2018-03-01 1:37 ` JeffyChen
2018-01-24 10:35 ` [PATCH v5 10/13] iommu/rockchip: Use OF_IOMMU to attach devices automatically Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 12/13] iommu/rockchip: Add runtime PM support Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` [PATCH v5 13/13] iommu/rockchip: Support sharing IOMMU between masters Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
2018-01-24 10:35 ` Jeffy Chen
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=5A6AF8BB.4040601@rock-chips.com \
--to=jeffy.chen-tnx95d0mmh7dzftrwevzcw@public.gmane.org \
--cc=aisheng.dong-3arQi8VN3Tc@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=jcliang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
--cc=tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=xxm-TNX95d0MmH7DzftRWevZcw@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.