All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.