From: Bjorn Helgaas <bhelgaas@google.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: rjw@rjwysocki.net, lenb@kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, hanjun.guo@linaro.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma
Date: Mon, 14 Sep 2015 11:34:11 -0500 [thread overview]
Message-ID: <20150914163411.GL829@google.com> (raw)
In-Reply-To: <1440597279-11802-3-git-send-email-Suravee.Suthikulpanit@amd.com>
On Wed, Aug 26, 2015 at 08:54:37PM +0700, Suravee Suthikulpanit wrote:
> The original name of acpi_check_dma() function does not clearly tell what
> exactly it is checking. Also, returning two boolean values (one to indicate
> device is DMA capability, and the other to inidicate device coherency
s/inidicate/indicate/
> attribute) can be confusing.
>
> So, in order to simplify the function, this patch renames acpi_check_dma()
> to acpi_check_dma_coherency() to clearly indicate the purpose of this
> function, and only returns an integer where -1 means DMA not supported,
> 1 means coherent DMA, and 0 means non-coherent DMA.
I think acpi_check_dma_coherency() is better, but only slightly. It
still doesn't give a hint about the *sense* of the return value. I
think it'd be easier to read if there were two functions, e.g.,
int acpi_dma_supported(struct acpi_device *adev)
{
if (!adev)
return 0;
if (adev->flags.cca_seen)
return 1;
/*
* Per ACPI 6.0 sec 6.2.17, assume devices can do cache-coherent
* DMA on "Intel platforms". Presumably that includes all x86 and
* ia64, and other arches will set CONFIG_ACPI_CCA_REQUIRED=y.
*/
if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
return 1;
return 0;
}
int acpi_dma_is_coherent(struct acpi_device *adev)
{
if (!acpi_dma_supported(adev))
return 0;
return adev->flags.coherent_dma;
}
struct platform_device *acpi_create_platform_device(...)
{
...
if (acpi_dma_supported(adev))
pdevinfo.dma_mask = DMA_BIT_MASK(32);
int acpi_bind_one(...)
{
...
if (acpi_dma_supported(acpi_dev))
arch_setup_dma_ops(dev, 0, 0, NULL, retval);
bool device_dma_is_coherent(...)
{
...
return acpi_dma_is_coherent(ACPI_COMPANION(dev)):
> Also, this patch moves the function into drivers/acpi/scan.c since
> it is easier to follow the logic in the acpi_init_coherency() in the
> same file here.
>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Will Deacon <will.deacon@arm.com>
> ---
> drivers/acpi/acpi_platform.c | 7 ++++++-
> drivers/acpi/glue.c | 6 +++---
> drivers/acpi/scan.c | 39 +++++++++++++++++++++++++++++++++++++++
> drivers/base/property.c | 10 +++++++---
> include/acpi/acpi_bus.h | 36 ++----------------------------------
> include/linux/acpi.h | 4 ++--
> 6 files changed, 59 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 06a67d5..0b17a78 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -103,7 +103,12 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
> pdevinfo.res = resources;
> pdevinfo.num_res = count;
> pdevinfo.fwnode = acpi_fwnode_handle(adev);
> - pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0;
> +
> + if (acpi_check_dma_coherency(adev) < 0)
> + pdevinfo.dma_mask = 0;
> + else
> + pdevinfo.dma_mask = DMA_BIT_MASK(32);
> +
> pdev = platform_device_register_full(&pdevinfo);
> if (IS_ERR(pdev))
> dev_err(&adev->dev, "platform device creation failed: %ld\n",
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index b9657af..9be7f0f 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -168,7 +168,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> struct list_head *physnode_list;
> unsigned int node_id;
> int retval = -EINVAL;
> - bool coherent;
>
> if (has_acpi_companion(dev)) {
> if (acpi_dev) {
> @@ -225,8 +224,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> if (!has_acpi_companion(dev))
> ACPI_COMPANION_SET(dev, acpi_dev);
>
> - if (acpi_check_dma(acpi_dev, &coherent))
> - arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> + retval = acpi_check_dma_coherency(acpi_dev);
> + if (retval >= 0)
> + arch_setup_dma_ops(dev, 0, 0, NULL, retval);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index ec25635..1d68289 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -2182,6 +2182,45 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
> kfree(pnp->unique_id);
> }
>
> +/**
> + * acpi_check_dma_coherency - Check DMA coherency for the specified device.
> + * @adev: The pointer to acpi device to check coherency attribute
> + *
> + * Return -ENOTSUPP if DMA is not supported. Otherwise, return 1 if the
> + * device support coherent DMA, or 0 for non-coherent DMA.
> + */
> +int acpi_check_dma_coherency(struct acpi_device *adev)
> +{
> + int ret = -ENOTSUPP;
> +
> + if (!adev)
> + return ret;
There's no need for the local "ret". You can "return -ENOTSUPP" here and
below, which is easier to read than looking back to see where "ret" was
defined and whether it was modified after being initialized.
> +
> + /**
> + * Currently, we only support _CCA=1 (i.e. coherent_dma=1)
> + * This should be equivalent to specifying dma-coherent for
> + * a device in OF.
> + *
> + * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1),
> + * we have two choices:
> + * 1. Do not support and disable DMA.
I know you didn't write this comment, but do we actually *disable* DMA in
the sense of turning off PCI bus mastering or calling an ACPI method that
disables DMA by this device? I suspect we just don't set up DMA ops and
masks for this device.
> + * 2. Support but rely on arch-specific cache maintenance for
> + * non-coherenje DMA operations.
s/Support but/Support DMA but/ ?
s/non-coherenje/non-coherent/
> + * Currently, we implement case 2 above.
> + *
> + * For the case when _CCA is missing (i.e. cca_seen=0) and
> + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
> + * and fallback to arch-specific default handling.
> + *
> + * See acpi_init_coherency() for more info.
> + */
> + if (!adev->flags.cca_seen && IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
> + return ret;
> +
> + return adev->flags.coherent_dma;
> +}
> +EXPORT_SYMBOL_GPL(acpi_check_dma_coherency);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f3f6d16..cd45dfc 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -525,10 +525,14 @@ bool device_dma_is_coherent(struct device *dev)
> {
> bool coherent = false;
>
> - if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> coherent = of_dma_is_coherent(dev->of_node);
> - else
> - acpi_check_dma(ACPI_COMPANION(dev), &coherent);
> + } else {
> + int ret = acpi_check_dma_coherency(ACPI_COMPANION(dev));
> +
> + if (ret >= 0)
> + coherent = ret;
> + }
>
> return coherent;
> }
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 7ecb8e4..baf43ea 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -382,40 +382,6 @@ struct acpi_device {
> void (*remove)(struct acpi_device *);
> };
>
> -static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
> -{
> - bool ret = false;
> -
> - if (!adev)
> - return ret;
> -
> - /**
> - * Currently, we only support _CCA=1 (i.e. coherent_dma=1)
> - * This should be equivalent to specifyig dma-coherent for
> - * a device in OF.
> - *
> - * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1),
> - * There are two cases:
> - * case 1. Do not support and disable DMA.
> - * case 2. Support but rely on arch-specific cache maintenance for
> - * non-coherence DMA operations.
> - * Currently, we implement case 2 above.
> - *
> - * For the case when _CCA is missing (i.e. cca_seen=0) and
> - * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
> - * and fallback to arch-specific default handling.
> - *
> - * See acpi_init_coherency() for more info.
> - */
> - if (adev->flags.coherent_dma ||
> - (adev->flags.cca_seen && IS_ENABLED(CONFIG_ARM64))) {
> - ret = true;
> - if (coherent)
> - *coherent = adev->flags.coherent_dma;
> - }
> - return ret;
> -}
> -
> static inline bool is_acpi_node(struct fwnode_handle *fwnode)
> {
> return fwnode && fwnode->type == FWNODE_ACPI;
> @@ -640,6 +606,8 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev)
> return adev->power.states[ACPI_STATE_D3_COLD].flags.valid;
> }
>
> +int acpi_check_dma_coherency(struct acpi_device *adev);
> +
> #else /* CONFIG_ACPI */
>
> static inline int register_acpi_bus_type(void *bus) { return 0; }
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index d2445fa..d350c9e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -562,9 +562,9 @@ static inline int acpi_device_modalias(struct device *dev,
> return -ENODEV;
> }
>
> -static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
> +static inline int acpi_check_dma_coherency(struct acpi_device *adev)
> {
> - return false;
> + return -ENOTSUPP;
> }
>
> #define ACPI_PTR(_ptr) (NULL)
> --
> 2.1.0
>
WARNING: multiple messages have this Message-ID (diff)
From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma
Date: Mon, 14 Sep 2015 11:34:11 -0500 [thread overview]
Message-ID: <20150914163411.GL829@google.com> (raw)
In-Reply-To: <1440597279-11802-3-git-send-email-Suravee.Suthikulpanit@amd.com>
On Wed, Aug 26, 2015 at 08:54:37PM +0700, Suravee Suthikulpanit wrote:
> The original name of acpi_check_dma() function does not clearly tell what
> exactly it is checking. Also, returning two boolean values (one to indicate
> device is DMA capability, and the other to inidicate device coherency
s/inidicate/indicate/
> attribute) can be confusing.
>
> So, in order to simplify the function, this patch renames acpi_check_dma()
> to acpi_check_dma_coherency() to clearly indicate the purpose of this
> function, and only returns an integer where -1 means DMA not supported,
> 1 means coherent DMA, and 0 means non-coherent DMA.
I think acpi_check_dma_coherency() is better, but only slightly. It
still doesn't give a hint about the *sense* of the return value. I
think it'd be easier to read if there were two functions, e.g.,
int acpi_dma_supported(struct acpi_device *adev)
{
if (!adev)
return 0;
if (adev->flags.cca_seen)
return 1;
/*
* Per ACPI 6.0 sec 6.2.17, assume devices can do cache-coherent
* DMA on "Intel platforms". Presumably that includes all x86 and
* ia64, and other arches will set CONFIG_ACPI_CCA_REQUIRED=y.
*/
if (!IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
return 1;
return 0;
}
int acpi_dma_is_coherent(struct acpi_device *adev)
{
if (!acpi_dma_supported(adev))
return 0;
return adev->flags.coherent_dma;
}
struct platform_device *acpi_create_platform_device(...)
{
...
if (acpi_dma_supported(adev))
pdevinfo.dma_mask = DMA_BIT_MASK(32);
int acpi_bind_one(...)
{
...
if (acpi_dma_supported(acpi_dev))
arch_setup_dma_ops(dev, 0, 0, NULL, retval);
bool device_dma_is_coherent(...)
{
...
return acpi_dma_is_coherent(ACPI_COMPANION(dev)):
> Also, this patch moves the function into drivers/acpi/scan.c since
> it is easier to follow the logic in the acpi_init_coherency() in the
> same file here.
>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
> Suggested-by: Rafael J. Wysocki <rjw@rjwysocki.net>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: Will Deacon <will.deacon@arm.com>
> ---
> drivers/acpi/acpi_platform.c | 7 ++++++-
> drivers/acpi/glue.c | 6 +++---
> drivers/acpi/scan.c | 39 +++++++++++++++++++++++++++++++++++++++
> drivers/base/property.c | 10 +++++++---
> include/acpi/acpi_bus.h | 36 ++----------------------------------
> include/linux/acpi.h | 4 ++--
> 6 files changed, 59 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 06a67d5..0b17a78 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -103,7 +103,12 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
> pdevinfo.res = resources;
> pdevinfo.num_res = count;
> pdevinfo.fwnode = acpi_fwnode_handle(adev);
> - pdevinfo.dma_mask = acpi_check_dma(adev, NULL) ? DMA_BIT_MASK(32) : 0;
> +
> + if (acpi_check_dma_coherency(adev) < 0)
> + pdevinfo.dma_mask = 0;
> + else
> + pdevinfo.dma_mask = DMA_BIT_MASK(32);
> +
> pdev = platform_device_register_full(&pdevinfo);
> if (IS_ERR(pdev))
> dev_err(&adev->dev, "platform device creation failed: %ld\n",
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index b9657af..9be7f0f 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -168,7 +168,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> struct list_head *physnode_list;
> unsigned int node_id;
> int retval = -EINVAL;
> - bool coherent;
>
> if (has_acpi_companion(dev)) {
> if (acpi_dev) {
> @@ -225,8 +224,9 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
> if (!has_acpi_companion(dev))
> ACPI_COMPANION_SET(dev, acpi_dev);
>
> - if (acpi_check_dma(acpi_dev, &coherent))
> - arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> + retval = acpi_check_dma_coherency(acpi_dev);
> + if (retval >= 0)
> + arch_setup_dma_ops(dev, 0, 0, NULL, retval);
>
> acpi_physnode_link_name(physical_node_name, node_id);
> retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index ec25635..1d68289 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -2182,6 +2182,45 @@ void acpi_free_pnp_ids(struct acpi_device_pnp *pnp)
> kfree(pnp->unique_id);
> }
>
> +/**
> + * acpi_check_dma_coherency - Check DMA coherency for the specified device.
> + * @adev: The pointer to acpi device to check coherency attribute
> + *
> + * Return -ENOTSUPP if DMA is not supported. Otherwise, return 1 if the
> + * device support coherent DMA, or 0 for non-coherent DMA.
> + */
> +int acpi_check_dma_coherency(struct acpi_device *adev)
> +{
> + int ret = -ENOTSUPP;
> +
> + if (!adev)
> + return ret;
There's no need for the local "ret". You can "return -ENOTSUPP" here and
below, which is easier to read than looking back to see where "ret" was
defined and whether it was modified after being initialized.
> +
> + /**
> + * Currently, we only support _CCA=1 (i.e. coherent_dma=1)
> + * This should be equivalent to specifying dma-coherent for
> + * a device in OF.
> + *
> + * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1),
> + * we have two choices:
> + * 1. Do not support and disable DMA.
I know you didn't write this comment, but do we actually *disable* DMA in
the sense of turning off PCI bus mastering or calling an ACPI method that
disables DMA by this device? I suspect we just don't set up DMA ops and
masks for this device.
> + * 2. Support but rely on arch-specific cache maintenance for
> + * non-coherenje DMA operations.
s/Support but/Support DMA but/ ?
s/non-coherenje/non-coherent/
> + * Currently, we implement case 2 above.
> + *
> + * For the case when _CCA is missing (i.e. cca_seen=0) and
> + * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
> + * and fallback to arch-specific default handling.
> + *
> + * See acpi_init_coherency() for more info.
> + */
> + if (!adev->flags.cca_seen && IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED))
> + return ret;
> +
> + return adev->flags.coherent_dma;
> +}
> +EXPORT_SYMBOL_GPL(acpi_check_dma_coherency);
> +
> static void acpi_init_coherency(struct acpi_device *adev)
> {
> unsigned long long cca = 0;
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index f3f6d16..cd45dfc 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
> @@ -525,10 +525,14 @@ bool device_dma_is_coherent(struct device *dev)
> {
> bool coherent = false;
>
> - if (IS_ENABLED(CONFIG_OF) && dev->of_node)
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> coherent = of_dma_is_coherent(dev->of_node);
> - else
> - acpi_check_dma(ACPI_COMPANION(dev), &coherent);
> + } else {
> + int ret = acpi_check_dma_coherency(ACPI_COMPANION(dev));
> +
> + if (ret >= 0)
> + coherent = ret;
> + }
>
> return coherent;
> }
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 7ecb8e4..baf43ea 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -382,40 +382,6 @@ struct acpi_device {
> void (*remove)(struct acpi_device *);
> };
>
> -static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
> -{
> - bool ret = false;
> -
> - if (!adev)
> - return ret;
> -
> - /**
> - * Currently, we only support _CCA=1 (i.e. coherent_dma=1)
> - * This should be equivalent to specifyig dma-coherent for
> - * a device in OF.
> - *
> - * For the case when _CCA=0 (i.e. coherent_dma=0 && cca_seen=1),
> - * There are two cases:
> - * case 1. Do not support and disable DMA.
> - * case 2. Support but rely on arch-specific cache maintenance for
> - * non-coherence DMA operations.
> - * Currently, we implement case 2 above.
> - *
> - * For the case when _CCA is missing (i.e. cca_seen=0) and
> - * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
> - * and fallback to arch-specific default handling.
> - *
> - * See acpi_init_coherency() for more info.
> - */
> - if (adev->flags.coherent_dma ||
> - (adev->flags.cca_seen && IS_ENABLED(CONFIG_ARM64))) {
> - ret = true;
> - if (coherent)
> - *coherent = adev->flags.coherent_dma;
> - }
> - return ret;
> -}
> -
> static inline bool is_acpi_node(struct fwnode_handle *fwnode)
> {
> return fwnode && fwnode->type == FWNODE_ACPI;
> @@ -640,6 +606,8 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev)
> return adev->power.states[ACPI_STATE_D3_COLD].flags.valid;
> }
>
> +int acpi_check_dma_coherency(struct acpi_device *adev);
> +
> #else /* CONFIG_ACPI */
>
> static inline int register_acpi_bus_type(void *bus) { return 0; }
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index d2445fa..d350c9e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -562,9 +562,9 @@ static inline int acpi_device_modalias(struct device *dev,
> return -ENODEV;
> }
>
> -static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
> +static inline int acpi_check_dma_coherency(struct acpi_device *adev)
> {
> - return false;
> + return -ENOTSUPP;
> }
>
> #define ACPI_PTR(_ptr) (NULL)
> --
> 2.1.0
>
next prev parent reply other threads:[~2015-09-14 16:34 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-26 13:54 [PATCH V3 0/4] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` [PATCH V3 1/4] Honor ACPI _CCA attribute setting Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-09-14 16:34 ` Bjorn Helgaas [this message]
2015-09-14 16:34 ` Bjorn Helgaas
2015-10-13 15:52 ` Suravee Suthikulpanit
2015-10-13 15:52 ` Suravee Suthikulpanit
2015-10-13 15:52 ` Suravee Suthikulpanit
2015-10-13 23:53 ` Suravee Suthikulanit
2015-10-13 23:53 ` Suravee Suthikulanit
2015-10-13 23:53 ` Suravee Suthikulanit
2015-10-20 2:17 ` Bjorn Helgaas
2015-10-20 2:17 ` Bjorn Helgaas
2015-10-20 12:53 ` Suravee Suthikulpanit
2015-10-20 12:53 ` Suravee Suthikulpanit
2015-10-20 12:53 ` Suravee Suthikulpanit
2015-08-26 13:54 ` [PATCH V3 3/4] PCI: OF: Move of_pci_dma_configure() to pci_dma_configure() Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` [PATCH V3 4/4] PCI: ACPI: Add support for PCI device DMA coherency Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-08-26 13:54 ` Suravee Suthikulpanit
2015-09-09 12:16 ` [PATCH V3 0/4] PCI: ACPI: Setting up DMA coherency for PCI device from _CCA attribute Suthikulpanit, Suravee
2015-09-09 12:16 ` Suthikulpanit, Suravee
2015-09-09 12:16 ` Suthikulpanit, Suravee
2015-09-09 20:38 ` Rafael J. Wysocki
2015-09-09 20:38 ` Rafael J. Wysocki
2015-09-10 2:48 ` Suthikulpanit, Suravee
2015-09-10 2:48 ` Suthikulpanit, Suravee
2015-09-10 2:48 ` Suthikulpanit, Suravee
2015-10-12 19:51 ` Suravee Suthikulpanit
2015-10-12 19:51 ` Suravee Suthikulpanit
2015-10-12 19:51 ` Suravee Suthikulpanit
2015-10-12 20:27 ` Rafael J. Wysocki
2015-10-12 20:27 ` Rafael J. Wysocki
2015-10-12 20:02 ` Suravee Suthikulpanit
2015-10-12 20:02 ` Suravee Suthikulpanit
2015-10-12 20:02 ` Suravee Suthikulpanit
2015-09-10 9:15 ` Hanjun Guo
2015-09-10 9:15 ` Hanjun Guo
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=20150914163411.GL829@google.com \
--to=bhelgaas@google.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=catalin.marinas@arm.com \
--cc=hanjun.guo@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=will.deacon@arm.com \
/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.