From: David Daney <ddaney@caviumnetworks.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: <linux-arm-kernel@lists.infradead.org>,
David Daney <ddaney.cavm@gmail.com>,
<linux-kernel@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>, <linux-pci@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>, <devicetree@vger.kernel.org>,
Marc Zyngier <marc.zyngier@arm.com>,
"David Daney" <david.daney@cavium.com>
Subject: Re: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.
Date: Fri, 18 Sep 2015 10:00:32 -0700 [thread overview]
Message-ID: <55FC4330.10302@caviumnetworks.com> (raw)
In-Reply-To: <3066583.BWDZlYWxXU@wuerfel>
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
> On Thursday 17 September 2015 15:41:33 David Daney wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> The on-chip devices all have fixed bars. So, fix them up.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>
> You should be able to just mark the BARs as fixed in DT
In the case of ACPI, there is no DT. So we would need a different
solution for ACPI. What would you recommend for ACPI?
Also, can you point me to the OF device tree specification where it
tells how to specify PCI BAR addresses, I would especially be interested
in knowing how to specify fixed SRIOV BAR addresses in the device tree.
Thanks,
David Daney
> and not need
> this hack.
Yes, it is a bit of a hack. That is why I put it in its own file, and
only try to hack up PCI devices that exactly match the vendor and device
ids that need fixing.
IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle
this would be much more intrusive.
For the record: The PCI Enhanced Allocation (EA) capability (approved
by PCI SIG on 23 October 2014) is the proper way to handle this going
forward. However, this is not yet implemented in the SoCs that this
patch addresses. Our plan is to implement the EA capability in the core
PCI code, so that we do not need to keep adding devices to this fixup code.
David Daney
WARNING: multiple messages have this Message-ID (diff)
From: ddaney@caviumnetworks.com (David Daney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.
Date: Fri, 18 Sep 2015 10:00:32 -0700 [thread overview]
Message-ID: <55FC4330.10302@caviumnetworks.com> (raw)
In-Reply-To: <3066583.BWDZlYWxXU@wuerfel>
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
> On Thursday 17 September 2015 15:41:33 David Daney wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> The on-chip devices all have fixed bars. So, fix them up.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>
> You should be able to just mark the BARs as fixed in DT
In the case of ACPI, there is no DT. So we would need a different
solution for ACPI. What would you recommend for ACPI?
Also, can you point me to the OF device tree specification where it
tells how to specify PCI BAR addresses, I would especially be interested
in knowing how to specify fixed SRIOV BAR addresses in the device tree.
Thanks,
David Daney
> and not need
> this hack.
Yes, it is a bit of a hack. That is why I put it in its own file, and
only try to hack up PCI devices that exactly match the vendor and device
ids that need fixing.
IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle
this would be much more intrusive.
For the record: The PCI Enhanced Allocation (EA) capability (approved
by PCI SIG on 23 October 2014) is the proper way to handle this going
forward. However, this is not yet implemented in the SoCs that this
patch addresses. Our plan is to implement the EA capability in the core
PCI code, so that we do not need to keep adding devices to this fixup code.
David Daney
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
David Daney <ddaney.cavm@gmail.com>,
linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
devicetree@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.
Date: Fri, 18 Sep 2015 10:00:32 -0700 [thread overview]
Message-ID: <55FC4330.10302@caviumnetworks.com> (raw)
In-Reply-To: <3066583.BWDZlYWxXU@wuerfel>
On 09/18/2015 12:19 AM, Arnd Bergmann wrote:
> On Thursday 17 September 2015 15:41:33 David Daney wrote:
>> From: David Daney <david.daney@cavium.com>
>>
>> The on-chip devices all have fixed bars. So, fix them up.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>
> You should be able to just mark the BARs as fixed in DT
In the case of ACPI, there is no DT. So we would need a different
solution for ACPI. What would you recommend for ACPI?
Also, can you point me to the OF device tree specification where it
tells how to specify PCI BAR addresses, I would especially be interested
in knowing how to specify fixed SRIOV BAR addresses in the device tree.
Thanks,
David Daney
> and not need
> this hack.
Yes, it is a bit of a hack. That is why I put it in its own file, and
only try to hack up PCI devices that exactly match the vendor and device
ids that need fixing.
IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle
this would be much more intrusive.
For the record: The PCI Enhanced Allocation (EA) capability (approved
by PCI SIG on 23 October 2014) is the proper way to handle this going
forward. However, this is not yet implemented in the SoCs that this
patch addresses. Our plan is to implement the EA capability in the core
PCI code, so that we do not need to keep adding devices to this fixup code.
David Daney
next prev parent reply other threads:[~2015-09-18 17:00 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 22:41 [PATCH 0/3] PCI: Add support for Cavium ThunderX RC and on-SoC devices David Daney
2015-09-17 22:41 ` David Daney
2015-09-17 22:41 ` David Daney
2015-09-17 22:41 ` [PATCH 1/3] PCI: Allow quirks to override SRIOV BARs David Daney
2015-09-17 22:41 ` David Daney
2015-09-17 22:41 ` [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs David Daney
2015-09-17 22:41 ` David Daney
2015-09-18 7:19 ` Arnd Bergmann
2015-09-18 7:19 ` Arnd Bergmann
2015-09-18 17:00 ` David Daney [this message]
2015-09-18 17:00 ` David Daney
2015-09-18 17:00 ` David Daney
2015-09-18 19:45 ` Arnd Bergmann
2015-09-18 19:45 ` Arnd Bergmann
2015-09-19 1:00 ` David Daney
2015-09-19 1:00 ` David Daney
2015-09-19 1:00 ` David Daney
2015-09-22 13:19 ` Bjorn Helgaas
2015-09-22 13:19 ` Bjorn Helgaas
2015-09-22 13:19 ` Bjorn Helgaas
2015-09-23 16:24 ` David Daney
2015-09-23 16:24 ` David Daney
2015-09-23 16:24 ` David Daney
2015-09-22 15:39 ` Lorenzo Pieralisi
2015-09-22 15:39 ` Lorenzo Pieralisi
2015-09-22 19:33 ` Arnd Bergmann
2015-09-22 19:33 ` Arnd Bergmann
2015-09-17 22:41 ` [PATCH 3/3] PCI: generic: Add support for Cavium ThunderX PCIe root complexes David Daney
2015-09-17 22:41 ` David Daney
2015-09-22 16:05 ` Lorenzo Pieralisi
2015-09-22 16:05 ` Lorenzo Pieralisi
2015-09-22 16:13 ` David Daney
2015-09-22 16:13 ` David Daney
2015-09-22 16:40 ` Lorenzo Pieralisi
2015-09-22 16:40 ` Lorenzo Pieralisi
2015-09-22 16:56 ` David Daney
2015-09-22 16:56 ` David Daney
2015-09-22 18:52 ` Will Deacon
2015-09-22 18:52 ` Will Deacon
2015-09-22 19:02 ` David Daney
2015-09-22 19:02 ` David Daney
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=55FC4330.10302@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--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.