All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Kevin Hilman <khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple platform
Date: Wed, 3 Feb 2016 10:00:15 +0100	[thread overview]
Message-ID: <56B1C19F.9070300@gmail.com> (raw)
In-Reply-To: <1454476968.2847.59.camel@mtksdaap41>



On 03/02/16 06:22, James Liao wrote:
> Hi Matthias,
>
> On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
>> On 02/02/16 07:56, James Liao wrote:
>>> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
>>>>> On 20/01/16 07:08, James Liao wrote:
>>>>>>> Refine scpsys driver common code to support multiple SoC / platform.
>>>>>>>
>>>>>>> Signed-off-by: James Liao<jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
>>>>>>>    2 files changed, 270 insertions(+), 203 deletions(-)
>>>>>>>    create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>>>>>
>>>>> In general this approach looks fine to me, comments below.
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> index 0221387..339adfc 100644
>>>>>>> --- a/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> @@ -11,29 +11,17 @@
>>>>>>>     * GNU General Public License for more details.
>>>>>>>     */
>>>>>>>    #include <linux/clk.h>
>>>>>>> -#include <linux/delay.h>
>>>>>>> +#include <linux/init.h>
>>>>>>>    #include <linux/io.h>
>>>>>>> -#include <linux/kernel.h>
>>>>>>>    #include <linux/mfd/syscon.h>
>>>>>
>>>>> When at it, do we need this include?
>>> syscon_regmap_lookup_by_phandle() is declared in this head file.
>>>
>>>>>>> -#include <linux/init.h>
>>>>>>>    #include <linux/of_device.h>
>>>>>>>    #include <linux/platform_device.h>
>>>>>>>    #include <linux/pm_domain.h>
>>>>>>> -#include <linux/regmap.h>
>>>>>>> -#include <linux/soc/mediatek/infracfg.h>
>>>>>>>    #include <linux/regulator/consumer.h>
>>>>>>> -#include <dt-bindings/power/mt8173-power.h>
>>>>>>> +#include <linux/soc/mediatek/infracfg.h>
>>>>>>> +
>>>>>>> +#include "mtk-scpsys.h"
>>>>>>>
>>>>>>> -#define SPM_VDE_PWR_CON			0x0210
>>>>>>> -#define SPM_MFG_PWR_CON			0x0214
>>>>>>> -#define SPM_VEN_PWR_CON			0x0230
>>>>>>> -#define SPM_ISP_PWR_CON			0x0238
>>>>>>> -#define SPM_DIS_PWR_CON			0x023c
>>>>>>> -#define SPM_VEN2_PWR_CON		0x0298
>>>>>>> -#define SPM_AUDIO_PWR_CON		0x029c
>>>>>>> -#define SPM_MFG_2D_PWR_CON		0x02c0
>>>>>>> -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
>>>>>>> -#define SPM_USB_PWR_CON			0x02cc
>>>>>
>>>>> I would prefer to keep this defines and declare SoC specific ones where
>>>>> necessary. It makes the code more readable.
>>> Some register address may be reused by other modules among SoCs, so it's
>>> not easy to maintain the defines when we implement multiple SoC drivers
>>> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
>>> but it is MJC_PWR_CON on other chips.
>>>
>>
>> So that sounds as if 0x0298 offset is MT8173 specific.
>> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135
>> and mt6589 and they all have the same offset. So it doesn't seem as if
>> the offset randomly changes for every SoC.
>>
>>> Furthermore, these register offsets are only used in scp_domain_data[],
>>> and each element has its own power domain name. So I think it's enough
>>> to know which power domain are using these registers and status bits.
>>>
>>
>> Yes that's true, but it will make it easier for another person to
>> understand the driver, especially if he want's to implement the driver
>> for a new SoC.
>
> There are two kinds of conflicts may happen:
>
> 1. Different modules use the same register address.
> 2. Different register addresses are used by the same module (on
> different IC).
>
> Type 1. for example:
>
> 	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
> 	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */
>
> We can resolve this conflict easily, such as define these two register
> name to the same register address.
>
> Type 2. for example:
>
> 	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
> 	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */
>
> We can not reuse the register defines in this case. We may need to name
> the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
> MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
> I prefer to remove register defines if we implement multiple SoC's
> scpsys in a single file.
>
>

Well type 2 for me is no problem at all. As stated in my last mail, 
mt6755 would get the SoC name in the define (as a postfix preferably).
I don't think that this will make a lot of pain regarding maintaining 
it. Even less if we have the defines in alphabetic order.

I we see in the future that this converts to a mess, we always can get 
rid of the defines quite easily.

Regards,
Matthias
--
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: matthias.bgg@gmail.com (Matthias Brugger)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple platform
Date: Wed, 3 Feb 2016 10:00:15 +0100	[thread overview]
Message-ID: <56B1C19F.9070300@gmail.com> (raw)
In-Reply-To: <1454476968.2847.59.camel@mtksdaap41>



On 03/02/16 06:22, James Liao wrote:
> Hi Matthias,
>
> On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
>> On 02/02/16 07:56, James Liao wrote:
>>> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
>>>>> On 20/01/16 07:08, James Liao wrote:
>>>>>>> Refine scpsys driver common code to support multiple SoC / platform.
>>>>>>>
>>>>>>> Signed-off-by: James Liao<jamesjj.liao@mediatek.com>
>>>>>>> ---
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
>>>>>>>    2 files changed, 270 insertions(+), 203 deletions(-)
>>>>>>>    create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>>>>>
>>>>> In general this approach looks fine to me, comments below.
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> index 0221387..339adfc 100644
>>>>>>> --- a/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> @@ -11,29 +11,17 @@
>>>>>>>     * GNU General Public License for more details.
>>>>>>>     */
>>>>>>>    #include <linux/clk.h>
>>>>>>> -#include <linux/delay.h>
>>>>>>> +#include <linux/init.h>
>>>>>>>    #include <linux/io.h>
>>>>>>> -#include <linux/kernel.h>
>>>>>>>    #include <linux/mfd/syscon.h>
>>>>>
>>>>> When at it, do we need this include?
>>> syscon_regmap_lookup_by_phandle() is declared in this head file.
>>>
>>>>>>> -#include <linux/init.h>
>>>>>>>    #include <linux/of_device.h>
>>>>>>>    #include <linux/platform_device.h>
>>>>>>>    #include <linux/pm_domain.h>
>>>>>>> -#include <linux/regmap.h>
>>>>>>> -#include <linux/soc/mediatek/infracfg.h>
>>>>>>>    #include <linux/regulator/consumer.h>
>>>>>>> -#include <dt-bindings/power/mt8173-power.h>
>>>>>>> +#include <linux/soc/mediatek/infracfg.h>
>>>>>>> +
>>>>>>> +#include "mtk-scpsys.h"
>>>>>>>
>>>>>>> -#define SPM_VDE_PWR_CON			0x0210
>>>>>>> -#define SPM_MFG_PWR_CON			0x0214
>>>>>>> -#define SPM_VEN_PWR_CON			0x0230
>>>>>>> -#define SPM_ISP_PWR_CON			0x0238
>>>>>>> -#define SPM_DIS_PWR_CON			0x023c
>>>>>>> -#define SPM_VEN2_PWR_CON		0x0298
>>>>>>> -#define SPM_AUDIO_PWR_CON		0x029c
>>>>>>> -#define SPM_MFG_2D_PWR_CON		0x02c0
>>>>>>> -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
>>>>>>> -#define SPM_USB_PWR_CON			0x02cc
>>>>>
>>>>> I would prefer to keep this defines and declare SoC specific ones where
>>>>> necessary. It makes the code more readable.
>>> Some register address may be reused by other modules among SoCs, so it's
>>> not easy to maintain the defines when we implement multiple SoC drivers
>>> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
>>> but it is MJC_PWR_CON on other chips.
>>>
>>
>> So that sounds as if 0x0298 offset is MT8173 specific.
>> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135
>> and mt6589 and they all have the same offset. So it doesn't seem as if
>> the offset randomly changes for every SoC.
>>
>>> Furthermore, these register offsets are only used in scp_domain_data[],
>>> and each element has its own power domain name. So I think it's enough
>>> to know which power domain are using these registers and status bits.
>>>
>>
>> Yes that's true, but it will make it easier for another person to
>> understand the driver, especially if he want's to implement the driver
>> for a new SoC.
>
> There are two kinds of conflicts may happen:
>
> 1. Different modules use the same register address.
> 2. Different register addresses are used by the same module (on
> different IC).
>
> Type 1. for example:
>
> 	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
> 	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */
>
> We can resolve this conflict easily, such as define these two register
> name to the same register address.
>
> Type 2. for example:
>
> 	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
> 	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */
>
> We can not reuse the register defines in this case. We may need to name
> the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
> MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
> I prefer to remove register defines if we implement multiple SoC's
> scpsys in a single file.
>
>

Well type 2 for me is no problem at all. As stated in my last mail, 
mt6755 would get the SoC name in the define (as a postfix preferably).
I don't think that this will make a lot of pain regarding maintaining 
it. Even less if we have the defines in alphabetic order.

I we see in the future that this converts to a mess, we always can get 
rid of the defines quite easily.

Regards,
Matthias

WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <matthias.bgg@gmail.com>
To: James Liao <jamesjj.liao@mediatek.com>
Cc: Sascha Hauer <kernel@pengutronix.de>,
	Rob Herring <robh@kernel.org>, Kevin Hilman <khilman@kernel.org>,
	Daniel Kurtz <djkurtz@chromium.org>,
	srv_heupstream@mediatek.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple platform
Date: Wed, 3 Feb 2016 10:00:15 +0100	[thread overview]
Message-ID: <56B1C19F.9070300@gmail.com> (raw)
In-Reply-To: <1454476968.2847.59.camel@mtksdaap41>



On 03/02/16 06:22, James Liao wrote:
> Hi Matthias,
>
> On Tue, 2016-02-02 at 11:44 +0100, Matthias Brugger wrote:
>> On 02/02/16 07:56, James Liao wrote:
>>> On Sun, 2016-01-31 at 12:51 +0100, Matthias Brugger wrote:
>>>>> On 20/01/16 07:08, James Liao wrote:
>>>>>>> Refine scpsys driver common code to support multiple SoC / platform.
>>>>>>>
>>>>>>> Signed-off-by: James Liao<jamesjj.liao@mediatek.com>
>>>>>>> ---
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.c | 418 ++++++++++++++++++++------------------
>>>>>>>    drivers/soc/mediatek/mtk-scpsys.h |  55 +++++
>>>>>>>    2 files changed, 270 insertions(+), 203 deletions(-)
>>>>>>>    create mode 100644 drivers/soc/mediatek/mtk-scpsys.h
>>>>>
>>>>> In general this approach looks fine to me, comments below.
>>>>>
>>>>>>>
>>>>>>> diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> index 0221387..339adfc 100644
>>>>>>> --- a/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> +++ b/drivers/soc/mediatek/mtk-scpsys.c
>>>>>>> @@ -11,29 +11,17 @@
>>>>>>>     * GNU General Public License for more details.
>>>>>>>     */
>>>>>>>    #include <linux/clk.h>
>>>>>>> -#include <linux/delay.h>
>>>>>>> +#include <linux/init.h>
>>>>>>>    #include <linux/io.h>
>>>>>>> -#include <linux/kernel.h>
>>>>>>>    #include <linux/mfd/syscon.h>
>>>>>
>>>>> When at it, do we need this include?
>>> syscon_regmap_lookup_by_phandle() is declared in this head file.
>>>
>>>>>>> -#include <linux/init.h>
>>>>>>>    #include <linux/of_device.h>
>>>>>>>    #include <linux/platform_device.h>
>>>>>>>    #include <linux/pm_domain.h>
>>>>>>> -#include <linux/regmap.h>
>>>>>>> -#include <linux/soc/mediatek/infracfg.h>
>>>>>>>    #include <linux/regulator/consumer.h>
>>>>>>> -#include <dt-bindings/power/mt8173-power.h>
>>>>>>> +#include <linux/soc/mediatek/infracfg.h>
>>>>>>> +
>>>>>>> +#include "mtk-scpsys.h"
>>>>>>>
>>>>>>> -#define SPM_VDE_PWR_CON			0x0210
>>>>>>> -#define SPM_MFG_PWR_CON			0x0214
>>>>>>> -#define SPM_VEN_PWR_CON			0x0230
>>>>>>> -#define SPM_ISP_PWR_CON			0x0238
>>>>>>> -#define SPM_DIS_PWR_CON			0x023c
>>>>>>> -#define SPM_VEN2_PWR_CON		0x0298
>>>>>>> -#define SPM_AUDIO_PWR_CON		0x029c
>>>>>>> -#define SPM_MFG_2D_PWR_CON		0x02c0
>>>>>>> -#define SPM_MFG_ASYNC_PWR_CON		0x02c4
>>>>>>> -#define SPM_USB_PWR_CON			0x02cc
>>>>>
>>>>> I would prefer to keep this defines and declare SoC specific ones where
>>>>> necessary. It makes the code more readable.
>>> Some register address may be reused by other modules among SoCs, so it's
>>> not easy to maintain the defines when we implement multiple SoC drivers
>>> in the same file. For example, offset 0x0298 is VEN2_PWR_CON on MT8173,
>>> but it is MJC_PWR_CON on other chips.
>>>
>>
>> So that sounds as if 0x0298 offset is MT8173 specific.
>> I checked [VDE, MFG, VEN, IFR, ISP, DIS, DPY]_PWR_CON on mt8173, mt8135
>> and mt6589 and they all have the same offset. So it doesn't seem as if
>> the offset randomly changes for every SoC.
>>
>>> Furthermore, these register offsets are only used in scp_domain_data[],
>>> and each element has its own power domain name. So I think it's enough
>>> to know which power domain are using these registers and status bits.
>>>
>>
>> Yes that's true, but it will make it easier for another person to
>> understand the driver, especially if he want's to implement the driver
>> for a new SoC.
>
> There are two kinds of conflicts may happen:
>
> 1. Different modules use the same register address.
> 2. Different register addresses are used by the same module (on
> different IC).
>
> Type 1. for example:
>
> 	#define SPM_BDP_PWR_CON			0x029c /* 2701 */
> 	#define SPM_AUDIO_PWR_CON		0x029c /* 8173 */
>
> We can resolve this conflict easily, such as define these two register
> name to the same register address.
>
> Type 2. for example:
>
> 	#define SPM_VDE_PWR_CON			0x0300 /* 6755 */
> 	#define SPM_VDE_PWR_CON			0x0210 /* 8173 */
>
> We can not reuse the register defines in this case. We may need to name
> the registers with its IC name, such as MT8173_SPM_VDE_PWR_CON and
> MT6755_VDE_PWR_CON. But it will increase the maintain effort. That's why
> I prefer to remove register defines if we implement multiple SoC's
> scpsys in a single file.
>
>

Well type 2 for me is no problem at all. As stated in my last mail, 
mt6755 would get the SoC name in the define (as a postfix preferably).
I don't think that this will make a lot of pain regarding maintaining 
it. Even less if we have the defines in alphabetic order.

I we see in the future that this converts to a mess, we always can get 
rid of the defines quite easily.

Regards,
Matthias

  reply	other threads:[~2016-02-03  9:00 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20  6:08 [PATCH v4 0/4] Mediatek MT2701 SCPSYS power domain support James Liao
2016-01-20  6:08 ` James Liao
2016-01-20  6:08 ` James Liao
     [not found] ` <1453270097-53853-1-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-01-20  6:08   ` [PATCH v4 1/4] soc: mediatek: Refine scpsys to support multiple platform James Liao
2016-01-20  6:08     ` James Liao
2016-01-20  6:08     ` James Liao
     [not found]     ` <1453270097-53853-2-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-01-20  9:14       ` Yingjoe Chen
2016-01-20  9:14         ` Yingjoe Chen
2016-01-20  9:14         ` Yingjoe Chen
2016-01-21  5:27         ` James Liao
2016-01-21  5:27           ` James Liao
2016-01-21  5:27           ` James Liao
2016-01-31 11:51       ` Matthias Brugger
2016-01-31 11:51         ` Matthias Brugger
2016-01-31 11:51         ` Matthias Brugger
     [not found]         ` <56ADF556.6070402-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-02  6:56           ` James Liao
2016-02-02  6:56             ` James Liao
2016-02-02  6:56             ` James Liao
2016-02-02 10:44             ` Matthias Brugger
2016-02-02 10:44               ` Matthias Brugger
2016-02-02 10:44               ` Matthias Brugger
     [not found]               ` <56B0889A.1010305-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-03  5:22                 ` James Liao
2016-02-03  5:22                   ` James Liao
2016-02-03  5:22                   ` James Liao
2016-02-03  9:00                   ` Matthias Brugger [this message]
2016-02-03  9:00                     ` Matthias Brugger
2016-02-03  9:00                     ` Matthias Brugger
     [not found]                     ` <56B1C19F.9070300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-02-15  9:09                       ` James Liao
2016-02-15  9:09                         ` James Liao
2016-02-15  9:09                         ` James Liao
2016-01-20  6:08   ` [PATCH v4 2/4] soc: mediatek: Init MT8173 scpsys driver earlier James Liao
2016-01-20  6:08     ` James Liao
2016-01-20  6:08     ` James Liao
2016-01-20  6:08   ` [PATCH v4 3/4] soc: mediatek: Add MT2701 power dt-bindings James Liao
2016-01-20  6:08     ` James Liao
2016-01-20  6:08     ` James Liao
     [not found]     ` <1453270097-53853-4-git-send-email-jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
2016-01-20  9:29       ` Yingjoe Chen
2016-01-20  9:29         ` Yingjoe Chen
2016-01-20  9:29         ` Yingjoe Chen
2016-01-20 16:35         ` Rob Herring
2016-01-20 16:35           ` Rob Herring
2016-01-21  5:22           ` James Liao
2016-01-21  5:22             ` James Liao
2016-01-21  5:22             ` James Liao
2016-01-20  6:08   ` [PATCH v4 4/4] soc: mediatek: Add MT2701 scpsys driver James Liao
2016-01-20  6:08     ` James Liao
2016-01-20  6:08     ` James Liao

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=56B1C19F.9070300@gmail.com \
    --to=matthias.bgg-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org \
    --cc=kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@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.