Hi guys,
I have some questions about dmar_init_reserved_ranges(). On systems
where CPU physical address space is not identity-mapped to PCI bus
address space, e.g., where the PCI host bridge windows have _TRA
offsets, I'm not sure we're doing the right thing.
Assume we have a PCI host bridge wit
On Thu, Dec 22, 2016 at 05:27:14PM +0100, Joerg Roedel wrote:
> Hi Bjorn,
>
> On Mon, Dec 19, 2016 at 03:20:44PM -0600, Bjorn Helgaas wrote:
> > I have some questions about dmar_init_reserved_ranges(). On systems
> > where CPU physical address space is not identity-mapped t
Hi Ashok,
On Thu, Dec 22, 2016 at 03:45:08PM -0800, Raj, Ashok wrote:
> Hi Bjorn
>
> None in the platform group say they know about this. So i'm fairly sure
> we don't do that on Intel hardware (x86).
I'm pretty sure there was once an x86 prototype for which PCI bus
addresses were not identical
On Mon, Dec 19, 2016 at 03:20:44PM -0600, Bjorn Helgaas wrote:
> Hi guys,
>
> I have some questions about dmar_init_reserved_ranges(). On systems
> where CPU physical address space is not identity-mapped to PCI bus
> address space, e.g., where the PCI host bridge windows have _TRA
On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
> From: Laurent Pinchart
>
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
>
> The lack of a registered IOMMU can be caused
On Mon, Jan 23, 2017 at 09:48:11PM +0530, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after
> the device's iommu is probed, the notifier trick required to handle the
> early setup of dma_ops before the iommu group gets created is not
> required. So remov
On Mon, Jan 23, 2017 at 09:48:12PM +0530, Sricharan R wrote:
> From: Robin Murphy
>
> Now that the appropriate ordering is enforced via profe-deferral of
s/profe-deferral/probe-deferral/
> masters in core code, rip it all out and bask in the simplicity.
>
> Acked-by: Will Deacon
> Signed-off-
CPI based platform/amba/pci bus devices.
>
> Signed-off-by: Sricharan R
Acked-by: Bjorn Helgaas (drivers/pci part)
> ---
> [V6 .. V7]
> * Updated the subject and commit log as per comments
>
> [V5 .. V6]
> * Squashed in patch 10 for configuring the dm
On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/
[+cc Joerg, iommu list]
On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
> On 2/22/2017 1:44 PM, Bjorn Helgaas wrote:
> > There is no way for a driver to say "I only need this memory BAR and
> > not the other ones." The reason is because the PCI_COMMAND_ME
rm_smmu_enable_ats() ("[RFC PATCH 04/30] iommu/arm-smmu-v3: Add
support for PCI ATS"), right?
If you remove the #ifdef, we'll call pci_enable_ats(), and it will
fail if !pdev->ats_cap.
Acked-by: Bjorn Helgaas
> ---
> include/linux/pci.h | 26 +--
from amd_iommu into the PCI subsystem,
> renaming it to something more consistent with the spec, and introducing
> another obscure acronym to make it all fit.
Maybe mention the acronym itelf and spell it out here?
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
e for ATS.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/ats.c | 23 +++
> include/linux/pci.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index 331376e9bb8b.
On Mon, Mar 06, 2017 at 12:04:39PM +0100, Joerg Roedel wrote:
> On Wed, Feb 22, 2017 at 05:39:44PM -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, iommu list]
> >
> > On Wed, Feb 22, 2017 at 03:44:53PM -0500, Sinan Kaya wrote:
> > > On 2/22/2017 1:44 PM, Bjorn Helgaas
Hi Jayachandran,
On Mon, Apr 03, 2017 at 01:15:04PM +, Jayachandran C wrote:
> The Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the PCI
> topology is slightly unusual. For a multi-node system, it looks like:
>
> [node level PCI bridges - one per node]
> [SoC PCI devices w
[+cc Joerg]
On Tue, Apr 11, 2017 at 07:10:48AM +, Jayachandran C wrote:
> On Mon, Apr 10, 2017 at 08:28:47PM -0500, Bjorn Helgaas wrote:
> > Hi Jayachandran,
> >
> > On Mon, Apr 03, 2017 at 01:15:04PM +, Jayachandran C wrote:
> > > The Cavium ThunderX2 arm6
[+cc David]
I forgot to mention that I'm also hoping for an ack from David, since
he's listed as the maintainer of the ThunderX drivers.
On Mon, Apr 03, 2017 at 01:15:02PM +, Jayachandran C wrote:
> Hi Bjorn, Alex,
>
> Sending this again (with a trivial fix to author name), please review.
>
On Apr 11, 2017 8:48 AM, "Bjorn Helgaas" wrote:
[+cc David]
I forgot to mention that I'm also hoping for an ack from David, since
he's listed as the maintainer of the ThunderX drivers.
Never mind this, Jon pointed out that ThunderX2 is different than
ThunderX. Sorry for t
On Tue, Apr 11, 2017 at 03:27:02PM +, Jayachandran C wrote:
> On Tue, Apr 11, 2017 at 08:41:25AM -0500, Bjorn Helgaas wrote:
> > [+cc Joerg]
> >
> > On Tue, Apr 11, 2017 at 07:10:48AM +, Jayachandran C wrote:
> > > On Mon, Apr 10, 2017 at 08:28:47PM -0500, B
On Wed, Apr 12, 2017 at 06:10:34PM +, Jayachandran C wrote:
> On Wed, Apr 12, 2017 at 11:21:18AM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2017 at 03:27:02PM +, Jayachandran C wrote:
> > > On Tue, Apr 11, 2017 at 08:41:25AM -0500, Bjorn Helgaas wrote:
On Wed, Apr 12, 2017 at 08:41:20PM +, Jayachandran C wrote:
> On Wed, Apr 12, 2017 at 02:11:38PM -0500, Bjorn Helgaas wrote:
> > On Wed, Apr 12, 2017 at 06:10:34PM +, Jayachandran C wrote:
> > > On Wed, Apr 12, 2017 at 11:21:18AM -0500, Bjorn Helgaas wrote:
> > >
I tentatively applied both patches to pci/host-thunder for v4.12.
However, I am concerned about the topology here:
On Thu, Apr 13, 2017 at 08:30:45PM +, Jayachandran C wrote:
> On Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the
> PCI topology is slightly unusual. For a mult
On Fri, Apr 21, 2017 at 05:05:41PM +, Jayachandran C wrote:
> On Fri, Apr 21, 2017 at 10:48:15AM -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 17, 2017 at 12:47 PM, Jayachandran C
> > wrote:
> > > On Fri, Apr 14, 2017 at 09:00:06PM -0500, Bjorn Helgaas wrote:
> &g
On Wed, May 17, 2017 at 05:00:07PM +0530, Sricharan R wrote:
> Now with iommu probe deferral, we return -EPROBE_DEFER
> for master's that are connected to an iommu which is not
s/master's/masters/
s/iommu/IOMMU/ in your English text (changelogs and comments). That seems
to be the convention, bas
On Tue, May 16, 2017 at 10:52:05AM +0530, Oza Pawandeep wrote:
> current device framework and OF framework integration assumes
s/current/The current/
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure
On Tue, May 16, 2017 at 10:52:06AM +0530, Oza Pawandeep wrote:
> this patch reserves the IOVA for PCI masters.
> ARM64 based SOCs may have scattered memory banks.
> such as iproc based SOC has
>
> <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
> <0x0008 0x8000 0x3 0x8000>, /* 14
On Wed, May 10, 2017 at 11:39:02AM -0700, Ashok Raj wrote:
> From: CQ Tang
>
> Requires: https://patchwork.kernel.org/patch/9593891
I'm not sure what the status of the patch above is. I acked it, but it's
part of a 30-patch IOMMU series, so I expect it to be merged via an IOMMU
tree.
In any ca
On Tue, May 23, 2017 at 03:33:22PM -0500, Bjorn Helgaas wrote:
> On Wed, May 10, 2017 at 11:39:02AM -0700, Ashok Raj wrote:
> > From: CQ Tang
> >
> > Requires: https://patchwork.kernel.org/patch/9593891
>
> I'm not sure what the status of the patch above is. I a
ored. This patch saves PASID features
> and PRI reqs cached.
>
> To: Bjorn Helgaas
> To: Joerg Roedel
> To: linux-...@vger.kernel.org
> To: linux-ker...@vger.kernel.org
> Cc: Jean-Phillipe Brucker
> Cc: David Woodhouse
> Cc: iommu@lists.linux-foundation.org
>
On Tue, May 30, 2017 at 09:25:49AM -0700, Ashok Raj wrote:
> From: CQ Tang
>
> Requires: https://patchwork.kernel.org/patch/9593891
>
>
> After a FLR, pci-states need to be restored. This patch saves PASID features
> and PRI reqs cached.
>
> To: Bjorn Helgaas
>
On Tue, May 30, 2017 at 09:25:47AM -0700, Ashok Raj wrote:
> Resending Jean's patch so it can be included earlier than his large
> SVM commits. Original patch https://patchwork.kernel.org/patch/9593891
> was ack'ed by Bjorn. Let's commit these separately since we need
> functionality earlier.
>
>
On Wed, Jan 16, 2013 at 3:38 PM, Stephen Hemminger
wrote:
> I see this on boot in dmesg
>
> [0.574494] DMAR: No ATSR found
> [0.574549] IOMMU 0 0xfed9: using Queued invalidation
> [0.574550] IOMMU 1 0xfed91000: using Queued invalidation
> [0.574554] IOMMU: Setting RMRR:
> [
On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> (AMD IOMMU, and AER) implement module specific definitions for PCI_BUS()
> and AMD_IOMMU driver
On Mon, Feb 25, 2013 at 9:37 AM, Shuah Khan wrote:
> On Wed, 2013-02-20 at 18:19 -0700, Bjorn Helgaas wrote:
>> On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
>> > pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
>> > it doesn't have
On Mon, Feb 11, 2013 at 4:00 PM, Shuah Khan wrote:
> pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> (AMD IOMMU, and AER) implement module specific definitions for PCI_BUS()
> and AMD_IOMMU driver
On Wed, Feb 27, 2013 at 5:06 PM, Shuah Khan wrote:
> pci defines PCI_DEVFN(), PCI_SLOT(), and PCI_FUNC() interfaces, however,
> it doesn't have interfaces to return PCI bus and PCI device id. Drivers
> (AMD IOMMU, and AER) have module specific definitions for PCI_BUS() and
> AMD_IOMMU driver also
On Tue, Mar 26, 2013 at 3:59 PM, Joerg Roedel wrote:
> Hi Bjorn,
>
> On Tue, Mar 26, 2013 at 03:41:07PM -0600, Bjorn Helgaas wrote:
>> Since some of these touch drivers/iommu, it'd be good if you acked
>> them again, Joerg. I know you acked them before, but there have b
As such, it would be good to
> give them a reminder that their systems are vulnurable to this problem.
>
> Signed-off-by: Neil Horman
> CC: Prarit Bhargava
> CC: Don Zickus
> CC: Don Dutile
> CC: Bjorn Helgaas
> CC: Asit Mallick
> CC: linux-...@vger.kernel.org
>
>
On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> On Wed, 2013-04-03 at 17:53 -0600, Bjorn Helgaas wrote:
>> > );
>> > > +
>> > > + if ((revision == 0x13) && irq_re
On Thu, Apr 4, 2013 at 9:39 AM, Neil Horman wrote:
> On Thu, Apr 04, 2013 at 08:57:06AM -0600, Bjorn Helgaas wrote:
>> On Thu, Apr 4, 2013 at 8:50 AM, Neil Horman wrote:
>> > On Thu, Apr 04, 2013 at 03:27:29PM +0100, David Woodhouse wrote:
>> >> On Wed, 2013-04-03
On Thu, Mar 7, 2013 at 7:35 PM, Andrew Cooks wrote:
> This patch creates a quirk to allow the Intel IOMMU to be enabled for devices
> that use incorrect tags during DMA. It is similar to the quirk for Ricoh
> devices, but allows mapping multiple functions and mapping of 'ghost'
> functions that do
On Thu, Apr 4, 2013 at 11:51 AM, Neil Horman wrote:
> Oh, you want the bug report that I'm fixing this against? Sure, I can do
> that.
> I thought you wanted me to include a url in the WARN_TAINT, with which user
> could report occurances of this bug. Yeah, the bug that this is reported in
>
On Wed, Feb 06, 2013 at 08:58:41AM -0700, Alex Williamson wrote:
> On Wed, 2013-02-06 at 07:49 -0800, Stephen Hemminger wrote:
> > On Mon, 04 Feb 2013 15:41:24 -0700
> > Alex Williamson wrote:
> >
> > > On Mon, 2013-02-04 at 13:28 -0700, Alex Williamson wrote:
> > > > On Mon, 2013-02-04 at 10:36
On Wed, Apr 10, 2013 at 6:01 PM, Alex Williamson
wrote:
> On Wed, 2013-04-10 at 16:36 -0600, Bjorn Helgaas wrote:
>> On Wed, Feb 06, 2013 at 08:58:41AM -0700, Alex Williamson wrote:
>> > On Wed, 2013-02-06 at 07:49 -0800, Stephen Hemminger wrote:
>> > > On M
On Mon, Apr 15, 2013 at 8:58 AM, Joerg Roedel wrote:
> On Mon, Apr 15, 2013 at 12:42:00AM +0530, Varun Sethi wrote:
>> swap_pci_ref function is used by the IOMMU API code for swapping pci device
>> pointers, while determining the iommu group for the device.
>> Currently this function was being imp
On Mon, Apr 15, 2013 at 1:12 PM, Alex Williamson
wrote:
> On Thu, 2013-04-11 at 11:23 -0600, Bjorn Helgaas wrote:
>> On Wed, Apr 10, 2013 at 6:01 PM, Alex Williamson
>> wrote:
>> > On Wed, 2013-04-10 at 16:36 -0600, Bjorn Helgaas wrote:
>> >> On Wed, Fe
On Fri, May 10, 2013 at 3:18 PM, Alex Williamson
wrote:
> These will replace pci_find_upstream_pcie_bridge, which is difficult
> to use and rather specific to intel-iommu usage. A quirked
> pci_is_pcie_bridge function is provided to work around non-compliant
> PCIe-to-PCI bridges such as those fo
On Sun, May 26, 2013 at 11:53:14PM +0800, Jiang Liu wrote:
> Enhance iommu drviers to use hotplug-safe iterators to walk
> PCI buses.
>
> Signed-off-by: Jiang Liu
> Cc: Joerg Roedel
> Cc: Ingo Molnar
> Cc: Donald Dutile
> Cc: Hannes Reinecke
> Cc: "Li, Zhen-Hua"
> Cc: iommu@lists.linux-found
On Thu, Jun 20, 2013 at 10:15 AM, Joerg Roedel wrote:
> On Thu, Jun 20, 2013 at 09:44:51AM -0600, Alex Williamson wrote:
>> On Thu, 2013-06-20 at 15:59 +0200, Joerg Roedel wrote:
>> > On Tue, May 28, 2013 at 12:40:20PM -0600, Alex Williamson wrote:
>> > > + if (!pci_is_root_bus(pdev->bus)) {
>> >
On Wed, Jun 26, 2013 at 12:45 PM, Alex Williamson
wrote:
> On Tue, 2013-06-25 at 22:20 -0600, Bjorn Helgaas wrote:
>> On Thu, Jun 20, 2013 at 10:15 AM, Joerg Roedel wrote:
>> > On Thu, Jun 20, 2013 at 09:44:51AM -0600, Alex Williamson wrote:
>> >> On Thu, 2013-06-2
is that since the IOMMU
driver wants to perform some action for each possible requester ID the
IOMMU might see, PCI could provide an iterator
("pci_for_each_requester_id()") to do that.
Bjorn
commit afad51492c6672b96c2b0735600d5695e30f7180
Author: Bjorn Helgaas
Date: Wed Jul 3 16:04:
On Mon, Jul 08, 2013 at 02:49:16PM -0600, Alex Williamson wrote:
> On Mon, 2013-07-08 at 13:34 -0600, Bjorn Helgaas wrote:
> > On Mon, Jul 08, 2013 at 11:07:20AM -0600, Alex Williamson wrote:
> > > Joerg,
> > >
> > > Where do we stand on this series?
On Tue, Jul 9, 2013 at 12:27 PM, Alex Williamson
wrote:
> On Mon, 2013-07-08 at 15:51 -0600, Bjorn Helgaas wrote:
>> On Mon, Jul 08, 2013 at 02:49:16PM -0600, Alex Williamson wrote:
>> > On Mon, 2013-07-08 at 13:34 -0600, Bjorn Helgaas wrote:
>> > > On Mon, Jul 08,
[+cc Joerg, David, iommu list]
On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck wrote:
> I started seeing this problem after updating the BIOS trying fix another
> issue,
> though I may have missed it earlier.
>
> I understand this is a BIOS bug. Would be great if someone can pass this on
> to Inte
On Tue, Jul 16, 2013 at 8:21 PM, Myron Stowe wrote:
> Linux Plumbers has approved an ACPI/PM, PCI microconference. The
> overview page is here:
>
> http://wiki.linuxplumbersconf.org/2013:pci_subsystem
>
> We would like to start receiving volunteers for presenting topics of
> interest. There is a
t; quirks at each step.
"requestee" doesn't make sense to me. The "-ee" suffix added to a verb
normally makes a noun that refers to the object of the action. So
"requestee" sounds like it means something like "target" or "responder,"
but that
On Tue, Jul 23, 2013 at 5:21 PM, Alex Williamson
wrote:
> On Tue, 2013-07-23 at 16:35 -0600, Bjorn Helgaas wrote:
>> On Thu, Jul 11, 2013 at 03:03:27PM -0600, Alex Williamson wrote:
>> > This provides interfaces for drivers to discover the visible PCIe
>> > requester
On Wed, Jul 24, 2013 at 12:12:28PM -0600, Alex Williamson wrote:
> On Wed, 2013-07-24 at 10:47 -0600, Bjorn Helgaas wrote:
> > On Tue, Jul 23, 2013 at 5:21 PM, Alex Williamson
> > wrote:
> > > On Tue, 2013-07-23 at 16:35 -0600, Bjorn Helgaas wrote:
> > >> On T
On Wed, Jul 24, 2013 at 12:29 AM, Takao Indoh
wrote:
> Sorry for letting this discussion slide, I was busy on other works:-(
> Anyway, the summary of previous discussion is:
> - My patch adds new initcall(fs_initcall) to reset all PCIe endpoints on
> boot. This expects PCI enumeration is done be
On Wed, Jul 24, 2013 at 04:42:03PM -0400, Don Dutile wrote:
> On 07/23/2013 06:35 PM, Bjorn Helgaas wrote:
> >On Thu, Jul 11, 2013 at 03:03:27PM -0600, Alex Williamson wrote:
> >>This provides interfaces for drivers to discover the visible PCIe
> >>requester ID for a de
On Thu, Jul 25, 2013 at 02:25:04PM -0400, Don Dutile wrote:
> On 07/25/2013 01:19 PM, Bjorn Helgaas wrote:
> >On Wed, Jul 24, 2013 at 04:42:03PM -0400, Don Dutile wrote:
> >>On 07/23/2013 06:35 PM, Bjorn Helgaas wrote:
> >>>On Thu, Jul 11, 2013 at 03:03:27P
On Thu, Jul 25, 2013 at 11:56:56AM -0600, Alex Williamson wrote:
> On Wed, 2013-07-24 at 17:24 -0600, Bjorn Helgaas wrote:
> > On Wed, Jul 24, 2013 at 12:12:28PM -0600, Alex Williamson wrote:
> > > On Wed, 2013-07-24 at 10:47 -0600, Bjorn Helgaas wrote:
> > > > O
On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh wrote:
> (2013/07/26 2:00), Bjorn Helgaas wrote:
>> On Wed, Jul 24, 2013 at 12:29 AM, Takao Indoh
>> wrote:
>>> Sorry for letting this discussion slide, I was busy on other works:-(
>>> Anyway, the summary of previ
On Mon, Jul 29, 2013 at 10:06 AM, Alex Williamson
wrote:
> On Fri, 2013-07-26 at 15:54 -0600, Bjorn Helgaas wrote:
>> On Thu, Jul 25, 2013 at 11:56:56AM -0600, Alex Williamson wrote:
>> The "most closely associated device" idea seems confusing to
>> describe and th
On Tue, Jul 30, 2013 at 12:09 AM, Takao Indoh
wrote:
> (2013/07/29 23:17), Bjorn Helgaas wrote:
>> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh
>> wrote:
>>> (2013/07/26 2:00), Bjorn Helgaas wrote:
>>>> My point about IOMMU and PCI initialization order
[+cc Rafael, linux-acpi]
On Tue, Jul 30, 2013 at 6:35 PM, Takao Indoh wrote:
> On x86, currently IOMMU initialization run *after* PCI enumeration, but
> what you are talking about is that it should be changed so that x86
> IOMMU initialization is done *before* PCI enumeration like sparc, right?
On Mon, Jul 29, 2013 at 4:32 PM, Alex Williamson
wrote:
> On Mon, 2013-07-29 at 15:02 -0600, Bjorn Helgaas wrote:
>> On Mon, Jul 29, 2013 at 10:06 AM, Alex Williamson
>> wrote:
>> > On Fri, 2013-07-26 at 15:54 -0600, Bjorn Helgaas wrote:
>> >> On Thu, Ju
On Thu, Sep 19, 2013 at 12:59:17PM +0530, Bharat Bhushan wrote:
> This patch adds interface to get following information
> - Number of MSI regions (which is number of MSI banks for powerpc).
> - Get the region address range: Physical page which have the
> address/addresses used for generat
On Thu, Oct 3, 2013 at 11:19 PM, Bhushan Bharat-R65777
wrote:
>> I don't know enough about VFIO to understand why these new interfaces are
>> needed. Is this the first VFIO IOMMU driver? I see vfio_iommu_spapr_tce.c
>> and
>> vfio_iommu_type1.c but I don't know if they're comparable to the Fre
>> - u32 msiir_offset; /* Offset of MSIIR, relative to start of CCSR */
>> + dma_addr_t msiir; /* MSIIR Address in CCSR */
>
> Are you sure dma_addr_t is right here, versus phys_addr_t? It implies
> that it's the output of the DMA API, but I don't think the DMA API is
> used in the MSI dri
On Sun, Oct 13, 2013 at 02:02:32AM +0530, Varun Sethi wrote:
> Factor out PCI specific code in the PAMU driver.
>
> Signed-off-by: Varun Sethi
> ---
> drivers/iommu/fsl_pamu_domain.c | 81
> +++
> 1 file changed, 40 insertions(+), 41 deletions(-)
>
> diff
On Tue, Nov 05, 2013 at 04:24:58PM +0800, Yijing Wang wrote:
> Currently, DMAR driver save target pci devices pointers for drhd/rmrr/atsr
> in (pci_dev *) array. This is not safe, because pci devices maybe
> hot added or removed during system running. They will have new pci_dev *
> pointer. So if t
On Thu, Nov 7, 2013 at 8:40 PM, Yijing Wang wrote:
> HI Bjorn,
>Thanks for your review and comments very much!
>
>>> +list_for_each_entry(dmar_dev, head, list)
>>> +if (dmar_dev->segment == pci_domain_nr(dev->bus)
>>> +&& dmar_dev->bus == dev
On Tue, Nov 19, 2013 at 10:47:05AM +0530, Bharat Bhushan wrote:
> In Aperture type of IOMMU (like FSL PAMU), VFIO-iommu system need to know
> the MSI region to map its window in h/w. This patch just defines the
> required weak functions only and will be used by followup patches.
>
> Signed-off-by:
[+cc Alex]
On Sun, Dec 8, 2013 at 7:26 AM, Antonio Quartulli
wrote:
> On 29/05/12 10:56, Antonio Quartulli wrote:
>> On Tue, May 29, 2012 at 10:35:53 +0200, Joerg Roedel wrote:
>>> Hi Antonio,
>>>
>>> On Sat, May 26, 2012 at 09:09:52AM -0600, Bjorn Helgaas w
227132710.71906...@nehalam.linuxnetplumber.net
[2]
https://lkml.kernel.org/r/20140130192011.25426.45702.st...@bhelgaas-glaptop.roam.corp.google.com
---
Bjorn Helgaas (4):
misc: mic: Add include of
mei: Add include of
iommu/amd: Add include of
PCI: Remove unused SR-I
We currently include in , but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.
Signed-off-by: Bjorn Helgaas
---
drivers/misc/mic/card/mic_device.h |1 +
drivers/misc/mic/host/mic_device.h |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers
We currently include in , but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.
Signed-off-by: Bjorn Helgaas
---
drivers/misc/mei/hw-me.h |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/mei/hw-me.h b/drivers/misc/mei/hw-me.h
We currently include in , but I'm about to
remove that from linux/pci.h, so add explicit includes where needed.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/amd_iommu_types.h |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/
.
This is based on Stephen Hemminger's patch (see link below), but goes a bit
further.
Link:
http://lkml.kernel.org/r/20131227132710.71906...@nehalam.linuxnetplumber.net
Signed-off-by: Bjorn Helgaas
CC: Stephen Hemminger
---
Documentation/PCI/pci-iov-howto.txt |4 -
dr
On Wed, Feb 19, 2014 at 1:29 AM, Winkler, Tomas wrote:
>
>
>>
>> We currently include in , but I'm about to
>> remove that from linux/pci.h, so add explicit includes where needed.
>>
>> Signed-off-by: Bjorn Helgaas
>> ---
>> drivers/misc
On Tue, Feb 18, 2014 at 1:59 PM, Bjorn Helgaas wrote:
> This is v2 of my rework of part of Stephen's patch [1]. My v1 posting,
> with a little discussion, is here [2].
>
> This removes SR-IOV migration support, which seems to be unused.
>
> Changes since v1:
>
[+cc George]
On Fri, Aug 2, 2013 at 10:59 AM, Alex Williamson
wrote:
> ...
> Great! I'm still trying to figure out how to handle the quirk around
> Intel PCI-to-PCI bridge on the root complex as just another quirk. I
> respin another version once I have that worked out. Thanks,
Is anything ha
On Thu, Apr 3, 2014 at 8:51 PM, Alex Williamson
wrote:
> On Thu, 2014-04-03 at 15:48 -0600, Bjorn Helgaas wrote:
>> [+cc George]
>>
>> On Fri, Aug 2, 2013 at 10:59 AM, Alex Williamson
>> wrote:
>> > ...
>> > Great! I'm still trying to figure ou
[+cc Joerg, iommu list]
On Wed, Apr 9, 2014 at 6:19 PM, Davidlohr Bueso wrote:
> On Wed, 2014-04-09 at 16:50 -0700, James Bottomley wrote:
>> On Wed, 2014-04-09 at 16:40 -0700, Davidlohr Bueso wrote:
>> > On Wed, 2014-04-09 at 16:10 -0700, James Bottomley wrote:
>> > > On Wed, 2014-04-09 at 16:08
On Thu, Apr 10, 2014 at 2:46 AM, Woodhouse, David
wrote:
>> > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear
>> > > >> > > > > dmar: DRHD: handling fault status reg 602
>> > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
>> > > >> > > > > 7f61e0
[subject changed]
On Thu, Apr 10, 2014 at 2:45 PM, wrote:
> On Wed, Apr 09, 2014 at 11:32:37PM -0700, Davidlohr Bueso wrote:
>> On Wed, 2014-04-09 at 22:03 -0600, Bjorn Helgaas wrote:
>> > [+cc Joerg, iommu list]
>> >
>> > On Wed, Apr 9, 2014 at 6:19 PM, D
On Tue, Apr 22, 2014 at 03:07:28PM +0800, Jiang Liu wrote:
> Finally enhance pci_root driver to support DMAR device hotplug when
> hot-plugging PCI host bridges.
>
> Signed-off-by: Jiang Liu
> ---
> drivers/acpi/pci_root.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(
On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> The driver_override field allows us to specify the driver for a device
> rather than relying on the driver to provide a positive match of the
> device. This shortcuts the existing process of looking up the vendor
> and device ID, a
On Thu, May 22, 2014 at 05:07:55PM -0600, Alex Williamson wrote:
> Several Marvell devices and a JMicron device have a similar DMA
> requester ID problem to Ricoh, except they use function 1 as the
> PCIe requester ID. Add a quirk for these to populate the DMA
> function alias bitmap.
What's the
On Thu, May 22, 2014 at 05:08:01PM -0600, Alex Williamson wrote:
> Several PCIe-to-PCI bridges fail to provide a PCIe capability, causing
> us to handle them as conventional PCI devices. In some cases, this
> may be correct, in others it's not. Add a dev_flag bit to identify
> devices to be handl
ack
> them.
I put 1-7 on a pci/iommu branch for v3.16. I'm happy to include the rest,
too, given acks from Joerg and David. Or if they prefer to take them all,
which might be easier than coordinating two trees, especially since there's
PCI stuff at the beginning and end, here's my
On Tue, May 20, 2014 at 08:53:21AM -0600, Alex Williamson wrote:
> The driver_override field allows us to specify the driver for a device
> rather than relying on the driver to provide a positive match of the
> device. This shortcuts the existing process of looking up the vendor
> and device ID, a
> iommu/vt-d: match segment number when searching for dev_iotlb capable
> devices
> iommu/vt-d: use correct domain id to flush virtual machine domains
> iommu/vt-d: introduce helper functions to improve code readability
> iommu/vt-d: introduce helper functions to make code symmetric for
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
> There are PCI devices that require a particular value written
> to the Multiple Message Enable (MME) register while aligned on
> power of 2 boundary value of actually used MSI vectors 'nvec'
> is a lesser of that MME value:
>
>
On Fri, Jul 4, 2014 at 2:58 AM, Alexander Gordeev wrote:
> On Thu, Jul 03, 2014 at 09:20:52AM +, David Laight wrote:
>> From: Bjorn Helgaas
>> > On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
>> > > There are PCI devices that require a part
On Fri, Jul 4, 2014 at 2:57 AM, Alexander Gordeev wrote:
> On Wed, Jul 02, 2014 at 02:22:01PM -0600, Bjorn Helgaas wrote:
>> On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
>> > There are PCI devices that require a particular value written
>> > to
On Tue, Jul 8, 2014 at 6:26 AM, Alexander Gordeev wrote:
> On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote:
>> >> Can you quantify the benefit of this? Can't a device already use
>> >> MSI-X to request exactly the number of vectors it can use?
On Thu, Jul 10, 2014 at 4:11 AM, Alexander Gordeev wrote:
> On Wed, Jul 09, 2014 at 10:06:48AM -0600, Bjorn Helgaas wrote:
>> Out of curiosity, do you have a pointer to this? It looks like it
>
> I.e. ICH8 chapter 12.1.30 or ICH10 chapter 14.1.27
>
>> uses one vector per
On Fri, Jul 11, 2014 at 12:19 AM, Jiang Liu wrote:
> Finally enhance pci_root driver to support DMAR device hotplug when
> hot-plugging PCI host bridges.
>
> Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
I assume you'll merge this along with the rest of the series via
1 - 100 of 448 matches
Mail list logo
