All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	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>,
	Jeremy Linton <Jeremy.Linton@arm.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma
Date: Tue, 20 Oct 2015 07:53:27 -0500	[thread overview]
Message-ID: <56263947.2090805@amd.com> (raw)
In-Reply-To: <20151020021735.GA20869@localhost>

Hi Bjorn/Rafael,

Let me redo the patch with enum then. At least, that's more clear to 
everyone.

Thanks,

Suravee

On 10/19/15 21:17, Bjorn Helgaas wrote:
> On Tue, Oct 13, 2015 at 06:53:28PM -0500, Suravee Suthikulanit wrote:
>> Bjorn / Rafael,
>>
>> On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote:
>>>
>>> On 09/14/2015 09:34 AM, Bjorn Helgaas wrote:
>>>> [..]
>>>> 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.,
>>>
>>> I have been going back-and-forth between the current version, and the
>>> two-function-approach in the past. I can definitely go with this route
>>> if you would prefer. Although, if acpi_dma_is_coherent() == 0, it would
>>> be ambiguous whether DMA is not supported or non-coherent DMA is
>>> supported. Then, we would need to call acpi_dma_is_supported() to find
>>> out. So, that's okay with you?
>>
>> Thinking about this again, I still think having one API (which can
>> tell whether DMA is supported or not, and if so whether it is
>> coherent or non-coherent) would be the least confusing and least
>> error prone.
>>
>> What if we would just have:
>>
>>      enum dev_dma_type acpi_get_dev_dma_type(struct acpi_device *adev);
>>
>> where:
>>      enum dev_dma_type {
>>          DEV_DMA_NOT_SUPPORTED,
>>          DEV_DMA_NON_COHERENT,
>>          DEV_DMA_COHERENT,
>>      };
>>
>> This would probably mean that we should modify
>> drivers/base/property.c to replace:
>>      bool device_dma_is_coherent()
>> to:
>>      enum dev_dma_type device_get_dma_type()
>>
>> We used to discuss the enum approach in the past
>> (https://lkml.org/lkml/2015/8/25/868). But we only considered at the
>> ACPI level at the time. Actually, this should also reflect in the
>> property.c.
>>
>> At this point, only drivers/crypto/ccp/ccp-platform.c and
>> drivers/net/ethernet/amd/xgbe/xgbe-main.c are calling the
>> device_dma_is_coherent(). So, it should be easy to change this API.
>
> OK, I'm fine with either the enum or Rafael's 0/1/-ENOTSUPP idea.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>, <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>,
	Jeremy Linton <Jeremy.Linton@arm.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma
Date: Tue, 20 Oct 2015 07:53:27 -0500	[thread overview]
Message-ID: <56263947.2090805@amd.com> (raw)
In-Reply-To: <20151020021735.GA20869@localhost>

Hi Bjorn/Rafael,

Let me redo the patch with enum then. At least, that's more clear to 
everyone.

Thanks,

Suravee

On 10/19/15 21:17, Bjorn Helgaas wrote:
> On Tue, Oct 13, 2015 at 06:53:28PM -0500, Suravee Suthikulanit wrote:
>> Bjorn / Rafael,
>>
>> On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote:
>>>
>>> On 09/14/2015 09:34 AM, Bjorn Helgaas wrote:
>>>> [..]
>>>> 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.,
>>>
>>> I have been going back-and-forth between the current version, and the
>>> two-function-approach in the past. I can definitely go with this route
>>> if you would prefer. Although, if acpi_dma_is_coherent() == 0, it would
>>> be ambiguous whether DMA is not supported or non-coherent DMA is
>>> supported. Then, we would need to call acpi_dma_is_supported() to find
>>> out. So, that's okay with you?
>>
>> Thinking about this again, I still think having one API (which can
>> tell whether DMA is supported or not, and if so whether it is
>> coherent or non-coherent) would be the least confusing and least
>> error prone.
>>
>> What if we would just have:
>>
>>      enum dev_dma_type acpi_get_dev_dma_type(struct acpi_device *adev);
>>
>> where:
>>      enum dev_dma_type {
>>          DEV_DMA_NOT_SUPPORTED,
>>          DEV_DMA_NON_COHERENT,
>>          DEV_DMA_COHERENT,
>>      };
>>
>> This would probably mean that we should modify
>> drivers/base/property.c to replace:
>>      bool device_dma_is_coherent()
>> to:
>>      enum dev_dma_type device_get_dma_type()
>>
>> We used to discuss the enum approach in the past
>> (https://lkml.org/lkml/2015/8/25/868). But we only considered at the
>> ACPI level at the time. Actually, this should also reflect in the
>> property.c.
>>
>> At this point, only drivers/crypto/ccp/ccp-platform.c and
>> drivers/net/ethernet/amd/xgbe/xgbe-main.c are calling the
>> device_dma_is_coherent(). So, it should be easy to change this API.
>
> OK, I'm fine with either the enum or Rafael's 0/1/-ENOTSUPP idea.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

WARNING: multiple messages have this Message-ID (diff)
From: Suravee.Suthikulpanit@amd.com (Suravee Suthikulpanit)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma
Date: Tue, 20 Oct 2015 07:53:27 -0500	[thread overview]
Message-ID: <56263947.2090805@amd.com> (raw)
In-Reply-To: <20151020021735.GA20869@localhost>

Hi Bjorn/Rafael,

Let me redo the patch with enum then. At least, that's more clear to 
everyone.

Thanks,

Suravee

On 10/19/15 21:17, Bjorn Helgaas wrote:
> On Tue, Oct 13, 2015 at 06:53:28PM -0500, Suravee Suthikulanit wrote:
>> Bjorn / Rafael,
>>
>> On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote:
>>>
>>> On 09/14/2015 09:34 AM, Bjorn Helgaas wrote:
>>>> [..]
>>>> 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.,
>>>
>>> I have been going back-and-forth between the current version, and the
>>> two-function-approach in the past. I can definitely go with this route
>>> if you would prefer. Although, if acpi_dma_is_coherent() == 0, it would
>>> be ambiguous whether DMA is not supported or non-coherent DMA is
>>> supported. Then, we would need to call acpi_dma_is_supported() to find
>>> out. So, that's okay with you?
>>
>> Thinking about this again, I still think having one API (which can
>> tell whether DMA is supported or not, and if so whether it is
>> coherent or non-coherent) would be the least confusing and least
>> error prone.
>>
>> What if we would just have:
>>
>>      enum dev_dma_type acpi_get_dev_dma_type(struct acpi_device *adev);
>>
>> where:
>>      enum dev_dma_type {
>>          DEV_DMA_NOT_SUPPORTED,
>>          DEV_DMA_NON_COHERENT,
>>          DEV_DMA_COHERENT,
>>      };
>>
>> This would probably mean that we should modify
>> drivers/base/property.c to replace:
>>      bool device_dma_is_coherent()
>> to:
>>      enum dev_dma_type device_get_dma_type()
>>
>> We used to discuss the enum approach in the past
>> (https://lkml.org/lkml/2015/8/25/868). But we only considered at the
>> ACPI level at the time. Actually, this should also reflect in the
>> property.c.
>>
>> At this point, only drivers/crypto/ccp/ccp-platform.c and
>> drivers/net/ethernet/amd/xgbe/xgbe-main.c are calling the
>> device_dma_is_coherent(). So, it should be easy to change this API.
>
> OK, I'm fine with either the enum or Rafael's 0/1/-ENOTSUPP idea.
>
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2015-10-20 12:53 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
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 [this message]
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=56263947.2090805@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=Jeremy.Linton@arm.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=hanjun.guo@linaro.org \
    --cc=helgaas@kernel.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=thomas.lendacky@amd.com \
    --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.