From: Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Linux DeviceTree
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Samsung SOC
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Prathyush <prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Linux Kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Sachin Kamat
<sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Sylwester Nawrocki
<s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Antonios Motakis
<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Linux ARM Kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Rahul Sharma
<rahul.sharma-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
Date: Tue, 18 Mar 2014 16:09:50 +0100 [thread overview]
Message-ID: <532861BE.7020601@samsung.com> (raw)
In-Reply-To: <20140318185605.0380c8dfe6559c06183092e5-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On 18.03.2014 10:56, Cho KyongHo wrote:
> On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
>> Hi KyongHo,
>>
>> On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
>>> -static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
>>> +static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
>>
>> If you are changing the names anyway, it would be probably a good idea
>> to reduce code obfuscation a bit and drop the underscores from
>> beginnings of function names. Also I'd suggest keeping the "exynos_" prefix.
>
> Thanks for the suggestion.
> __exynos_sysmmu_disable is splitted into 2 functions: __sysmmu_disable
> and __sysmmu_disable_nocount.
> I agree with you that it is good idea to reduce code obfuscation but
> I don't think dropping beginning underscores of function names reduces
> obfuscation.
>
Well, if you are ending up with a function like
__sysmmu_enable_nocount() below with every line starting with two
underscores, do you think this improves code readability?
Of course this is a minor issue, but let's keep some code quality level
in Linux kernel.
>>
>>> {
>>> - unsigned long flags;
>>> - bool disabled = false;
>>> -
>>> - write_lock_irqsave(&data->lock, flags);
[snip]
Here's the function mentioned above:
>>> +
>>> +static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
>>> +{
>>> + __master_clk_enable(data);
>>> + __sysmmu_clk_enable(data);
>>> +
>>> + __raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __sysmmu_init_config(data);
>>> +
>>> + __sysmmu_set_ptbase(data->sfrbase, data->pgtable);
>>> +
>>> + __raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __master_clk_disable(data);
>>> +}
>>> +
[snip]
>>>
>>> @@ -629,7 +700,7 @@ err_pgtable:
>>> static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>> {
>>> struct exynos_iommu_domain *priv = domain->priv;
>>> - struct sysmmu_drvdata *data;
>>> + struct exynos_iommu_owner *owner;
>>> unsigned long flags;
>>> int i;
>>>
>>> @@ -637,11 +708,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>>
>>> spin_lock_irqsave(&priv->lock, flags);
>>>
>>> - list_for_each_entry(data, &priv->clients, node) {
>>> - while (!exynos_sysmmu_disable(data->dev))
>>> + list_for_each_entry(owner, &priv->clients, client) {
>>> + while (!exynos_sysmmu_disable(owner->dev))
>>> ; /* until System MMU is actually disabled */
>>
>> What about using list_for_each_entry_safe() and calling list_del_init()
>> here directly?
>>
>
> That require another variable to be defined.
Is it a problem?
> I just wanted to avoid that because I think it is prettier.
> Moreover, list_del_init() below the empty while() clause may make
> the source code readers misunderstood..
This raises another question, why the loop above is even needed.
exynos_sysmmu_disable() should make sure that SYSMMU is actually
disabled, without any need for looping like this.
>>> }
>>>
>>> + while (!list_empty(&priv->clients))
>>> + list_del_init(priv->clients.next);
>>> +
>>> spin_unlock_irqrestore(&priv->lock, flags);
>>>
>>> for (i = 0; i < NUM_LV1ENTRIES; i++)
[snip]
>>> +static int sysmmu_hook_driver_register(struct notifier_block *nb,
>>> + unsigned long val,
>>> + void *p)
>>> +{
>>> + struct device *dev = p;
>>> +
>>> + switch (val) {
>>> + case BUS_NOTIFY_BIND_DRIVER:
>>> + {
>>> + struct exynos_iommu_owner *owner;
>>
>> Please move this variable to the top of the function and drop the braces
>> around case blocks.
>
> I don't think it is required because this function is modified
> by the following patches.
OK, if so, and similar issue is not present after further patches.
>
>>
>>> +
>>> + /* No System MMU assigned. See exynos_sysmmu_probe(). */
>>> + if (dev->archdata.iommu == NULL)
>>> + break;
>>
>> This looks strange... (see below)
>>
>> Also this looks racy. There are no guarantees about device probing
>> order, so you may end up with master devices being probed before the
>> IOMMUs. Deferred probing should be used to handle this correctly.
>
> System MMU driver must be probed earlier than the drivers of master devices
> because the drivers may want to use System MMU for their initial task.
As I said, there are no guarantees about platform device probe order in
Linux kernel. Code must be designed to check whether required
dependencies are met and if not, deferred probing must be used.
>>
>>> +
>>> + owner = devm_kzalloc(dev, sizeof(*owner), GFP_KERNEL);
>>> + if (!owner) {
>>> + dev_err(dev, "No Memory for exynos_iommu_owner\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + owner->dev = dev;
>>> + INIT_LIST_HEAD(&owner->client);
>>> + owner->sysmmu = dev->archdata.iommu;
>>> +
>>> + dev->archdata.iommu = owner;
>>
>> I don't understand what is happening here in this case statement. There
>> is already something assigned to dev->archdata.iommu, but this code
>> reassigns something else to this field. This means that you attempt to
>> use the same field to store pointers to objects of different types,
>> which I believe is broken, because you have no way to check what kind of
>> object is currently pointed by such (void *) pointer.
>>
>
> exynos_sysmmu_probe() assigns the device descriptor of the probing System MMU
> to archdata.iommu of its master device. The assignment is just a marker that
> the device is a master device of a System MMU.
> If dev->archdata.iommu has a value in the case of BUS_NOTIFY_BIND_DRIVER,
> the 'dev' is a master devices of a System MMU. Then sysmmu_hook_driver_register()
> assigns the data structure to handle System MMU to dev->archdata.iommu.
Which is wrong (or even if you don't consider it wrong, it is ugly),
because one (void *) pointer in the same object is used to store
pointers to two completely different types.
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: t.figa@samsung.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
Date: Tue, 18 Mar 2014 16:09:50 +0100 [thread overview]
Message-ID: <532861BE.7020601@samsung.com> (raw)
In-Reply-To: <20140318185605.0380c8dfe6559c06183092e5@samsung.com>
On 18.03.2014 10:56, Cho KyongHo wrote:
> On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
>> Hi KyongHo,
>>
>> On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
>>> -static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
>>> +static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
>>
>> If you are changing the names anyway, it would be probably a good idea
>> to reduce code obfuscation a bit and drop the underscores from
>> beginnings of function names. Also I'd suggest keeping the "exynos_" prefix.
>
> Thanks for the suggestion.
> __exynos_sysmmu_disable is splitted into 2 functions: __sysmmu_disable
> and __sysmmu_disable_nocount.
> I agree with you that it is good idea to reduce code obfuscation but
> I don't think dropping beginning underscores of function names reduces
> obfuscation.
>
Well, if you are ending up with a function like
__sysmmu_enable_nocount() below with every line starting with two
underscores, do you think this improves code readability?
Of course this is a minor issue, but let's keep some code quality level
in Linux kernel.
>>
>>> {
>>> - unsigned long flags;
>>> - bool disabled = false;
>>> -
>>> - write_lock_irqsave(&data->lock, flags);
[snip]
Here's the function mentioned above:
>>> +
>>> +static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
>>> +{
>>> + __master_clk_enable(data);
>>> + __sysmmu_clk_enable(data);
>>> +
>>> + __raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __sysmmu_init_config(data);
>>> +
>>> + __sysmmu_set_ptbase(data->sfrbase, data->pgtable);
>>> +
>>> + __raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __master_clk_disable(data);
>>> +}
>>> +
[snip]
>>>
>>> @@ -629,7 +700,7 @@ err_pgtable:
>>> static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>> {
>>> struct exynos_iommu_domain *priv = domain->priv;
>>> - struct sysmmu_drvdata *data;
>>> + struct exynos_iommu_owner *owner;
>>> unsigned long flags;
>>> int i;
>>>
>>> @@ -637,11 +708,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>>
>>> spin_lock_irqsave(&priv->lock, flags);
>>>
>>> - list_for_each_entry(data, &priv->clients, node) {
>>> - while (!exynos_sysmmu_disable(data->dev))
>>> + list_for_each_entry(owner, &priv->clients, client) {
>>> + while (!exynos_sysmmu_disable(owner->dev))
>>> ; /* until System MMU is actually disabled */
>>
>> What about using list_for_each_entry_safe() and calling list_del_init()
>> here directly?
>>
>
> That require another variable to be defined.
Is it a problem?
> I just wanted to avoid that because I think it is prettier.
> Moreover, list_del_init() below the empty while() clause may make
> the source code readers misunderstood..
This raises another question, why the loop above is even needed.
exynos_sysmmu_disable() should make sure that SYSMMU is actually
disabled, without any need for looping like this.
>>> }
>>>
>>> + while (!list_empty(&priv->clients))
>>> + list_del_init(priv->clients.next);
>>> +
>>> spin_unlock_irqrestore(&priv->lock, flags);
>>>
>>> for (i = 0; i < NUM_LV1ENTRIES; i++)
[snip]
>>> +static int sysmmu_hook_driver_register(struct notifier_block *nb,
>>> + unsigned long val,
>>> + void *p)
>>> +{
>>> + struct device *dev = p;
>>> +
>>> + switch (val) {
>>> + case BUS_NOTIFY_BIND_DRIVER:
>>> + {
>>> + struct exynos_iommu_owner *owner;
>>
>> Please move this variable to the top of the function and drop the braces
>> around case blocks.
>
> I don't think it is required because this function is modified
> by the following patches.
OK, if so, and similar issue is not present after further patches.
>
>>
>>> +
>>> + /* No System MMU assigned. See exynos_sysmmu_probe(). */
>>> + if (dev->archdata.iommu == NULL)
>>> + break;
>>
>> This looks strange... (see below)
>>
>> Also this looks racy. There are no guarantees about device probing
>> order, so you may end up with master devices being probed before the
>> IOMMUs. Deferred probing should be used to handle this correctly.
>
> System MMU driver must be probed earlier than the drivers of master devices
> because the drivers may want to use System MMU for their initial task.
As I said, there are no guarantees about platform device probe order in
Linux kernel. Code must be designed to check whether required
dependencies are met and if not, deferred probing must be used.
>>
>>> +
>>> + owner = devm_kzalloc(dev, sizeof(*owner), GFP_KERNEL);
>>> + if (!owner) {
>>> + dev_err(dev, "No Memory for exynos_iommu_owner\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + owner->dev = dev;
>>> + INIT_LIST_HEAD(&owner->client);
>>> + owner->sysmmu = dev->archdata.iommu;
>>> +
>>> + dev->archdata.iommu = owner;
>>
>> I don't understand what is happening here in this case statement. There
>> is already something assigned to dev->archdata.iommu, but this code
>> reassigns something else to this field. This means that you attempt to
>> use the same field to store pointers to objects of different types,
>> which I believe is broken, because you have no way to check what kind of
>> object is currently pointed by such (void *) pointer.
>>
>
> exynos_sysmmu_probe() assigns the device descriptor of the probing System MMU
> to archdata.iommu of its master device. The assignment is just a marker that
> the device is a master device of a System MMU.
> If dev->archdata.iommu has a value in the case of BUS_NOTIFY_BIND_DRIVER,
> the 'dev' is a master devices of a System MMU. Then sysmmu_hook_driver_register()
> assigns the data structure to handle System MMU to dev->archdata.iommu.
Which is wrong (or even if you don't consider it wrong, it is ugly),
because one (void *) pointer in the same object is used to store
pointers to two completely different types.
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <t.figa@samsung.com>
To: Cho KyongHo <pullip.cho@samsung.com>
Cc: Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
Linux DeviceTree <devicetree@vger.kernel.org>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
Antonios Motakis <a.motakis@virtualopensystems.com>,
Grant Grundler <grundler@chromium.org>,
Joerg Roedel <joro@8bytes.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Prathyush <prathyush.k@samsung.com>,
Rahul Sharma <rahul.sharma@samsung.com>,
Sachin Kamat <sachin.kamat@linaro.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Varun Sethi <Varun.Sethi@freescale.com>
Subject: Re: [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions
Date: Tue, 18 Mar 2014 16:09:50 +0100 [thread overview]
Message-ID: <532861BE.7020601@samsung.com> (raw)
In-Reply-To: <20140318185605.0380c8dfe6559c06183092e5@samsung.com>
On 18.03.2014 10:56, Cho KyongHo wrote:
> On Fri, 14 Mar 2014 13:59:00 +0100, Tomasz Figa wrote:
>> Hi KyongHo,
>>
>> On 14.03.2014 06:08, Cho KyongHo wrote:
[snip]
>>> -static bool __exynos_sysmmu_disable(struct sysmmu_drvdata *data)
>>> +static void __sysmmu_disable_nocount(struct sysmmu_drvdata *data)
>>
>> If you are changing the names anyway, it would be probably a good idea
>> to reduce code obfuscation a bit and drop the underscores from
>> beginnings of function names. Also I'd suggest keeping the "exynos_" prefix.
>
> Thanks for the suggestion.
> __exynos_sysmmu_disable is splitted into 2 functions: __sysmmu_disable
> and __sysmmu_disable_nocount.
> I agree with you that it is good idea to reduce code obfuscation but
> I don't think dropping beginning underscores of function names reduces
> obfuscation.
>
Well, if you are ending up with a function like
__sysmmu_enable_nocount() below with every line starting with two
underscores, do you think this improves code readability?
Of course this is a minor issue, but let's keep some code quality level
in Linux kernel.
>>
>>> {
>>> - unsigned long flags;
>>> - bool disabled = false;
>>> -
>>> - write_lock_irqsave(&data->lock, flags);
[snip]
Here's the function mentioned above:
>>> +
>>> +static void __sysmmu_enable_nocount(struct sysmmu_drvdata *data)
>>> +{
>>> + __master_clk_enable(data);
>>> + __sysmmu_clk_enable(data);
>>> +
>>> + __raw_writel(CTRL_BLOCK, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __sysmmu_init_config(data);
>>> +
>>> + __sysmmu_set_ptbase(data->sfrbase, data->pgtable);
>>> +
>>> + __raw_writel(CTRL_ENABLE, data->sfrbase + REG_MMU_CTRL);
>>> +
>>> + __master_clk_disable(data);
>>> +}
>>> +
[snip]
>>>
>>> @@ -629,7 +700,7 @@ err_pgtable:
>>> static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>> {
>>> struct exynos_iommu_domain *priv = domain->priv;
>>> - struct sysmmu_drvdata *data;
>>> + struct exynos_iommu_owner *owner;
>>> unsigned long flags;
>>> int i;
>>>
>>> @@ -637,11 +708,14 @@ static void exynos_iommu_domain_destroy(struct iommu_domain *domain)
>>>
>>> spin_lock_irqsave(&priv->lock, flags);
>>>
>>> - list_for_each_entry(data, &priv->clients, node) {
>>> - while (!exynos_sysmmu_disable(data->dev))
>>> + list_for_each_entry(owner, &priv->clients, client) {
>>> + while (!exynos_sysmmu_disable(owner->dev))
>>> ; /* until System MMU is actually disabled */
>>
>> What about using list_for_each_entry_safe() and calling list_del_init()
>> here directly?
>>
>
> That require another variable to be defined.
Is it a problem?
> I just wanted to avoid that because I think it is prettier.
> Moreover, list_del_init() below the empty while() clause may make
> the source code readers misunderstood..
This raises another question, why the loop above is even needed.
exynos_sysmmu_disable() should make sure that SYSMMU is actually
disabled, without any need for looping like this.
>>> }
>>>
>>> + while (!list_empty(&priv->clients))
>>> + list_del_init(priv->clients.next);
>>> +
>>> spin_unlock_irqrestore(&priv->lock, flags);
>>>
>>> for (i = 0; i < NUM_LV1ENTRIES; i++)
[snip]
>>> +static int sysmmu_hook_driver_register(struct notifier_block *nb,
>>> + unsigned long val,
>>> + void *p)
>>> +{
>>> + struct device *dev = p;
>>> +
>>> + switch (val) {
>>> + case BUS_NOTIFY_BIND_DRIVER:
>>> + {
>>> + struct exynos_iommu_owner *owner;
>>
>> Please move this variable to the top of the function and drop the braces
>> around case blocks.
>
> I don't think it is required because this function is modified
> by the following patches.
OK, if so, and similar issue is not present after further patches.
>
>>
>>> +
>>> + /* No System MMU assigned. See exynos_sysmmu_probe(). */
>>> + if (dev->archdata.iommu == NULL)
>>> + break;
>>
>> This looks strange... (see below)
>>
>> Also this looks racy. There are no guarantees about device probing
>> order, so you may end up with master devices being probed before the
>> IOMMUs. Deferred probing should be used to handle this correctly.
>
> System MMU driver must be probed earlier than the drivers of master devices
> because the drivers may want to use System MMU for their initial task.
As I said, there are no guarantees about platform device probe order in
Linux kernel. Code must be designed to check whether required
dependencies are met and if not, deferred probing must be used.
>>
>>> +
>>> + owner = devm_kzalloc(dev, sizeof(*owner), GFP_KERNEL);
>>> + if (!owner) {
>>> + dev_err(dev, "No Memory for exynos_iommu_owner\n");
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + owner->dev = dev;
>>> + INIT_LIST_HEAD(&owner->client);
>>> + owner->sysmmu = dev->archdata.iommu;
>>> +
>>> + dev->archdata.iommu = owner;
>>
>> I don't understand what is happening here in this case statement. There
>> is already something assigned to dev->archdata.iommu, but this code
>> reassigns something else to this field. This means that you attempt to
>> use the same field to store pointers to objects of different types,
>> which I believe is broken, because you have no way to check what kind of
>> object is currently pointed by such (void *) pointer.
>>
>
> exynos_sysmmu_probe() assigns the device descriptor of the probing System MMU
> to archdata.iommu of its master device. The assignment is just a marker that
> the device is a master device of a System MMU.
> If dev->archdata.iommu has a value in the case of BUS_NOTIFY_BIND_DRIVER,
> the 'dev' is a master devices of a System MMU. Then sysmmu_hook_driver_register()
> assigns the data structure to handle System MMU to dev->archdata.iommu.
Which is wrong (or even if you don't consider it wrong, it is ugly),
because one (void *) pointer in the same object is used to store
pointers to two completely different types.
Best regards,
Tomasz
next prev parent reply other threads:[~2014-03-18 15:09 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-14 5:08 [PATCH v11 17/27] iommu/exynos: remove calls to Runtime PM API functions Cho KyongHo
2014-03-14 5:08 ` Cho KyongHo
2014-03-14 5:08 ` Cho KyongHo
[not found] ` <20140314140843.ba055f28dd7ed59c46088029-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-14 12:59 ` Tomasz Figa
2014-03-14 12:59 ` Tomasz Figa
2014-03-14 12:59 ` Tomasz Figa
2014-03-18 9:56 ` Cho KyongHo
2014-03-18 9:56 ` Cho KyongHo
[not found] ` <20140318185605.0380c8dfe6559c06183092e5-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-18 15:09 ` Tomasz Figa [this message]
2014-03-18 15:09 ` Tomasz Figa
2014-03-18 15:09 ` Tomasz Figa
[not found] ` <532861BE.7020601-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-19 1:03 ` Cho KyongHo
2014-03-19 1:03 ` Cho KyongHo
2014-03-19 1:03 ` Cho KyongHo
[not found] ` <20140319100304.5e26fa43ccdfc29178b058e1-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-19 13:12 ` Tomasz Figa
2014-03-19 13:12 ` Tomasz Figa
2014-03-19 13:12 ` Tomasz Figa
[not found] ` <532997D7.6090608-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-19 16:54 ` Grant Grundler
2014-03-19 16:54 ` Grant Grundler
2014-03-19 16:54 ` Grant Grundler
2014-03-20 11:55 ` Cho KyongHo
2014-03-20 11:55 ` Cho KyongHo
2014-03-19 17:03 ` Grant Grundler
2014-03-19 17:03 ` Grant Grundler
2014-03-19 17:03 ` Grant Grundler
[not found] ` <CANEJEGuYz28dGT+264CYtG+Tk6htOq=u-t4PWMtsij32X0vJFA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-19 17:30 ` Tomasz Figa
2014-03-19 17:30 ` Tomasz Figa
2014-03-19 17:30 ` Tomasz Figa
[not found] ` <5329D426.9020706-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-19 18:37 ` Grant Grundler
2014-03-19 18:37 ` Grant Grundler
2014-03-19 18:37 ` Grant Grundler
[not found] ` <CANEJEGtCdMmWXwpoky8USLOBw7jAt1bRw8or-mDK7twxAzhWpA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-19 18:51 ` Tomasz Figa
2014-03-19 18:51 ` Tomasz Figa
2014-03-19 18:51 ` Tomasz Figa
[not found] ` <5329E729.4020201-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-03-20 12:07 ` Cho KyongHo
2014-03-20 12:07 ` Cho KyongHo
2014-03-20 12:07 ` Cho KyongHo
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=532861BE.7020601@samsung.com \
--to=t.figa-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=rahul.sharma-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@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.