From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
linaro-acpi@lists.linaro.org, will.deacon@arm.com,
herbert@gondor.apana.org.au, al.stone@linaro.org,
linux-acpi@vger.kernel.org,
Murali Karicheri <m-karicheri2@ti.com>,
msalter@redhat.com, grant.likely@linaro.org,
hanjun.guo@linaro.org, thomas.lendacky@amd.com,
Rob Herring <robh+dt@kernel.org>,
bhelgaas@google.com, netdev@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org, leo.duran@amd.com,
linux-crypto@vger.kernel.org, lenb@kernel.org,
David Woodhouse <dwmw2@infradead.org>,
davem@davemloft.net
Subject: Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency
Date: Wed, 20 May 2015 07:00:25 -0500 [thread overview]
Message-ID: <555C7759.3040304@amd.com> (raw)
In-Reply-To: <20150520093401.GC25313@e104818-lin.cambridge.arm.com>
On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
>> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
>>> On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
>>>> On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit wrote:
>>>>> +/**
>>>>> + * pci_dma_configure - Setup DMA configuration
>>>>> + * @pci_dev: ptr to pci_dev struct of the PCI device
>>>>> + *
>>>>> + * Function to update PCI devices's DMA configuration using the same
>>>>> + * info from the OF node or ACPI node of host bridge's parent (if any).
>>>>> + */
>>>>> +static void pci_dma_configure(struct pci_dev *pci_dev)
>>>>> +{
>>>>> + struct device *dev = &pci_dev->dev;
>>>>> + struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>>>> + struct device *host = bridge->parent;
>>>>> + struct acpi_device *adev;
>>>>> +
>>>>> + if (!host)
>>>>> + return;
>>>>> +
>>>>> + if (acpi_disabled) {
>>>>> + of_dma_configure(dev, host->of_node);
>>>>
>>>> I'd rather do
>>>>
>>>> if (IS_ENABLED(CONFIG_OF) && host->of_node) {
>>>> of_dma_configure(dev, host->of_node);
>>>
>>> Nitpick: do we need the CONFIG_OF check? If disabled, I don't think
>>> anyone would set host->of_node.
>>
>> If of_dma_configure() is defined in a file that is built conditionally
>> based on CONFIG_OF, you need it.
>
> We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> we would need #ifndef here. I already replied, I think for other
> architectures we need this check to avoid a useless host->of_node test.
>
It seems that there are several places that have similar check. Would it
be good to convert this into a macro? Something like:
#define OF_NODE_ENABLED(dev) (IS_ENABLED(CONFIG_OF) && dev->of_node)
Thanks all for the review feedback.
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
To: Catalin Marinas <catalin.marinas@arm.com>, Arnd Bergmann <arnd@arndb.de>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linaro-acpi@lists.linaro.org>, <will.deacon@arm.com>,
<herbert@gondor.apana.org.au>, <al.stone@linaro.org>,
<linux-acpi@vger.kernel.org>,
Murali Karicheri <m-karicheri2@ti.com>, <msalter@redhat.com>,
<grant.likely@linaro.org>, <hanjun.guo@linaro.org>,
<thomas.lendacky@amd.com>, Rob Herring <robh+dt@kernel.org>,
<bhelgaas@google.com>, <netdev@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
<linux-kernel@vger.kernel.org>, <leo.duran@amd.com>,
<linux-crypto@vger.kernel.org>, <lenb@kernel.org>,
David Woodhouse <dwmw2@infradead.org>, <davem@davemloft.net>
Subject: Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency
Date: Wed, 20 May 2015 07:00:25 -0500 [thread overview]
Message-ID: <555C7759.3040304@amd.com> (raw)
In-Reply-To: <20150520093401.GC25313@e104818-lin.cambridge.arm.com>
On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
>> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
>>> On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
>>>> On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit wrote:
>>>>> +/**
>>>>> + * pci_dma_configure - Setup DMA configuration
>>>>> + * @pci_dev: ptr to pci_dev struct of the PCI device
>>>>> + *
>>>>> + * Function to update PCI devices's DMA configuration using the same
>>>>> + * info from the OF node or ACPI node of host bridge's parent (if any).
>>>>> + */
>>>>> +static void pci_dma_configure(struct pci_dev *pci_dev)
>>>>> +{
>>>>> + struct device *dev = &pci_dev->dev;
>>>>> + struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>>>> + struct device *host = bridge->parent;
>>>>> + struct acpi_device *adev;
>>>>> +
>>>>> + if (!host)
>>>>> + return;
>>>>> +
>>>>> + if (acpi_disabled) {
>>>>> + of_dma_configure(dev, host->of_node);
>>>>
>>>> I'd rather do
>>>>
>>>> if (IS_ENABLED(CONFIG_OF) && host->of_node) {
>>>> of_dma_configure(dev, host->of_node);
>>>
>>> Nitpick: do we need the CONFIG_OF check? If disabled, I don't think
>>> anyone would set host->of_node.
>>
>> If of_dma_configure() is defined in a file that is built conditionally
>> based on CONFIG_OF, you need it.
>
> We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> we would need #ifndef here. I already replied, I think for other
> architectures we need this check to avoid a useless host->of_node test.
>
It seems that there are several places that have similar check. Would it
be good to convert this into a macro? Something like:
#define OF_NODE_ENABLED(dev) (IS_ENABLED(CONFIG_OF) && dev->of_node)
Thanks all for the review feedback.
Suravee
WARNING: multiple messages have this Message-ID (diff)
From: suravee.suthikulpanit@amd.com (Suravee Suthikulanit)
To: linux-arm-kernel@lists.infradead.org
Subject: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency
Date: Wed, 20 May 2015 07:00:25 -0500 [thread overview]
Message-ID: <555C7759.3040304@amd.com> (raw)
In-Reply-To: <20150520093401.GC25313@e104818-lin.cambridge.arm.com>
On 5/20/2015 4:34 AM, Catalin Marinas wrote:
> On Wed, May 20, 2015 at 11:27:54AM +0200, Arnd Bergmann wrote:
>> On Wednesday 20 May 2015 10:24:15 Catalin Marinas wrote:
>>> On Sat, May 16, 2015 at 01:59:00AM +0200, Rafael J. Wysocki wrote:
>>>> On Friday, May 15, 2015 04:23:11 PM Suravee Suthikulpanit wrote:
>>>>> +/**
>>>>> + * pci_dma_configure - Setup DMA configuration
>>>>> + * @pci_dev: ptr to pci_dev struct of the PCI device
>>>>> + *
>>>>> + * Function to update PCI devices's DMA configuration using the same
>>>>> + * info from the OF node or ACPI node of host bridge's parent (if any).
>>>>> + */
>>>>> +static void pci_dma_configure(struct pci_dev *pci_dev)
>>>>> +{
>>>>> + struct device *dev = &pci_dev->dev;
>>>>> + struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>>>> + struct device *host = bridge->parent;
>>>>> + struct acpi_device *adev;
>>>>> +
>>>>> + if (!host)
>>>>> + return;
>>>>> +
>>>>> + if (acpi_disabled) {
>>>>> + of_dma_configure(dev, host->of_node);
>>>>
>>>> I'd rather do
>>>>
>>>> if (IS_ENABLED(CONFIG_OF) && host->of_node) {
>>>> of_dma_configure(dev, host->of_node);
>>>
>>> Nitpick: do we need the CONFIG_OF check? If disabled, I don't think
>>> anyone would set host->of_node.
>>
>> If of_dma_configure() is defined in a file that is built conditionally
>> based on CONFIG_OF, you need it.
>
> We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise
> we would need #ifndef here. I already replied, I think for other
> architectures we need this check to avoid a useless host->of_node test.
>
It seems that there are several places that have similar check. Would it
be good to convert this into a macro? Something like:
#define OF_NODE_ENABLED(dev) (IS_ENABLED(CONFIG_OF) && dev->of_node)
Thanks all for the review feedback.
Suravee
next prev parent reply other threads:[~2015-05-20 12:00 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 21:23 [V4 PATCH 0/6] ACPI: Introduce support for _CCA object Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` [V4 PATCH 1/6] ACPI / scan: Parse _CCA and setup device coherency Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 23:53 ` Rafael J. Wysocki
2015-05-15 23:53 ` Rafael J. Wysocki
2015-05-18 22:38 ` Suravee Suthikulanit
2015-05-18 22:38 ` Suravee Suthikulanit
2015-05-18 22:38 ` Suravee Suthikulanit
2015-05-19 0:28 ` Rafael J. Wysocki
2015-05-19 0:28 ` Rafael J. Wysocki
2015-05-20 10:01 ` Catalin Marinas
2015-05-20 10:01 ` Catalin Marinas
2015-05-20 11:52 ` Suravee Suthikulanit
2015-05-20 11:52 ` Suravee Suthikulanit
2015-05-20 11:52 ` Suravee Suthikulanit
2015-05-20 12:04 ` [Linaro-acpi] " Arnd Bergmann
2015-05-20 12:04 ` Arnd Bergmann
2015-05-21 13:01 ` Catalin Marinas
2015-05-21 13:01 ` Catalin Marinas
2015-05-21 13:24 ` Arnd Bergmann
2015-05-21 13:24 ` Arnd Bergmann
2015-05-15 21:23 ` [V4 PATCH 2/6] arm64 : Introduce support for ACPI _CCA object Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-16 11:48 ` Paul Bolle
2015-05-16 11:48 ` Paul Bolle
2015-05-16 16:50 ` Suravee Suthikulpanit
2015-05-16 16:50 ` Suravee Suthikulpanit
2015-05-16 16:50 ` Suravee Suthikulpanit
2015-05-20 10:03 ` Catalin Marinas
2015-05-20 10:03 ` Catalin Marinas
2015-05-20 11:51 ` Suravee Suthikulanit
2015-05-20 11:51 ` Suravee Suthikulanit
2015-05-20 11:51 ` Suravee Suthikulanit
2015-05-15 21:23 ` [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 23:59 ` Rafael J. Wysocki
2015-05-15 23:59 ` Rafael J. Wysocki
2015-05-16 15:12 ` Suthikulpanit, Suravee
2015-05-16 15:12 ` Suthikulpanit, Suravee
2015-05-16 15:12 ` Suthikulpanit, Suravee
2015-05-20 9:24 ` Catalin Marinas
2015-05-20 9:24 ` Catalin Marinas
2015-05-20 9:27 ` Arnd Bergmann
2015-05-20 9:27 ` Arnd Bergmann
2015-05-20 9:34 ` Catalin Marinas
2015-05-20 9:34 ` Catalin Marinas
2015-05-20 12:00 ` Suravee Suthikulanit [this message]
2015-05-20 12:00 ` Suravee Suthikulanit
2015-05-20 12:00 ` Suravee Suthikulanit
2015-05-20 12:02 ` [Linaro-acpi] " Arnd Bergmann
2015-05-20 12:02 ` Arnd Bergmann
2015-05-20 20:46 ` Russell King - ARM Linux
2015-05-20 20:46 ` Russell King - ARM Linux
2015-05-20 9:31 ` Catalin Marinas
2015-05-20 9:31 ` Catalin Marinas
2015-05-16 12:41 ` Bjorn Helgaas
2015-05-16 12:41 ` Bjorn Helgaas
2015-05-16 15:14 ` Suthikulpanit, Suravee
2015-05-16 15:14 ` Suthikulpanit, Suravee
2015-05-16 15:14 ` Suthikulpanit, Suravee
2015-05-16 15:14 ` Suthikulpanit, Suravee
2015-05-15 21:23 ` [V4 PATCH 4/6] device property: Introduces device_dma_is_coherent() Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-20 10:28 ` Will Deacon
2015-05-20 10:28 ` Will Deacon
2015-05-20 10:28 ` Will Deacon
2015-05-20 21:32 ` Suravee Suthikulanit
2015-05-20 21:32 ` Suravee Suthikulanit
2015-05-20 21:32 ` Suravee Suthikulanit
2015-05-15 21:23 ` [V4 PATCH 5/6] crypto: ccp - Unify coherency checking logic with device_dma_is_coherent() Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` [V4 PATCH 6/6] amd-xgbe: " Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
2015-05-15 21:23 ` Suravee Suthikulpanit
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=555C7759.3040304@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=al.stone@linaro.org \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=herbert@gondor.apana.org.au \
--cc=lenb@kernel.org \
--cc=leo.duran@amd.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m-karicheri2@ti.com \
--cc=msalter@redhat.com \
--cc=netdev@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.