s/iommu/IOMMU/ in subject
On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote:
> Using the iommu-map binding, endpoints in a given PCI domain can be
> managed by different IOMMUs. Some virtual machines may allow a subset of
> endpoints to bypass the IOMMU. In some case the IOMMU
t;fwnode appropriately").
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/of.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 2f5015bdb256..8026417fab38 100644
> --- a
Hi Mika,
On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote:
> Recent systems with Thunderbolt ports may support IOMMU natively.
This sentence doesn't make sense to me. There's no logical connection
between having an IOMMU and having a Thunderbolt port.
> This means that the platfo
On Tue, Nov 27, 2018 at 10:54:26AM +0200, Mika Westerberg wrote:
> On Mon, Nov 26, 2018 at 06:17:11PM -0600, Bjorn Helgaas wrote:
> > Hi Mika,
>
> Hi,
>
> > On Mon, Nov 26, 2018 at 02:15:23PM +0300, Mika Westerberg wrote:
> > > Recent systems with Thunderbolt
driver has
> allocated for it.
>
> While at it, add a comment on top of prp_guids array explaining the
> possible caveat resulting when these GUIDs are treated equivalent.
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identify
gt; ---
> drivers/acpi/scan.c | 5 +
> drivers/base/platform.c | 3 +--
> drivers/pci/pci-driver.c | 3 +--
Acked-by: Bjorn Helgaas# drivers/pci part
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index b
e only downside is
> that we will create two dma-debug entries for each mapping if
> CONFIG_DMA_DEBUG is enabled.
>
> Signed-off-by: Christoph Hellwig
You cc'd the VMD maintainers already, and I have no objection to this
from a PCI core point of view, so:
Acked-by: Bjorn Helgaas
; installing dummy DMA ops instead of just skipping setup entirely. This
> will then free up the dev->dma_ops == NULL case for some valuable
> fastpath optimisations.
>
> CC: Rafael J. Wysocki
> CC: Len Brown
> CC: Greg Kroah-Hartman
> CC: Bjorn Helgaas
> Signed-off-
On Fri, Jan 18, 2019 at 09:53:20AM +0530, Srinath Mannam wrote:
> Add changes related to IPROC PCIe RC IP new features.
>
> This patch set is based on Linux-5.0-rc2.
>
> Srinath Mannam (3):
> PCI: iproc: Add feature to set order mode
Since this apparently refers to a PCIe feature, the subject
On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote:
> Order mode in RX header of incoming pcie packets can be override to
> strict or loose order based on requirement.
> Sysfs entry is provided to set dynamic and default order modes of upstream
> traffic.
s/pcie/PCIe/
If this is two p
On Fri, Jan 18, 2019 at 09:53:22AM +0530, Srinath Mannam wrote:
> In the current implementation, config read of 0x0001 data
> is assumed as CRS completion. but sometimes 0x0001 can be
> a valid data.
> IPROC PCIe RC has a register to show config request status flags
> like SC, UR, CRS and C
On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote:
> On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote:
> > On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote:
> > > Order mode in RX header of incoming pcie packets can be override to
> > > str
On Fri, Jan 25, 2019 at 03:13:38PM +0530, Srinath Mannam wrote:
> On Fri, Jan 25, 2019 at 1:01 AM Bjorn Helgaas wrote:
> > On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote:
> > > On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote:
> > > > On Fri, Ja
ntroduced later in this series.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Bjorn Helgaas
I assume you'll merge this along with the rest of the series, so:
Acked-by: Bjorn Helgaas
Minor question and typo below.
> ---
> drivers/pci/msi.c | 51 +
On Thu, Jan 31, 2019 at 03:52:09PM -0700, Logan Gunthorpe wrote:
> On 2019-01-31 3:39 p.m., Bjorn Helgaas wrote:
> >> diff --git a/include/linux/msi.h b/include/linux/msi.h
> >> index 784fb52b9900..6458ab049852 100644
> >> --- a/include/linux/msi.h
> >>
Hi Kuppuswamy,
Previous changes to ats.c used subject lines starting with just
"PCI:".
I think it does make sense to include "ATS", but please do it in
the way we do it for other PCI features, e.g.,
PCI/ATS: Add pci_ats_page_aligned() interface
On Thu, Feb 07, 2019 at 10:41:13AM -0800,
sathy
"PCI/ATS: Add pci_pggrp_rsp_need_pasid() interface"
On Thu, Feb 07, 2019 at 10:37:58AM -0800,
sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Add a new function to return the status of PRG response PASID
> required bit in PRI status register. This func
49064-19019-1-git-send-email-liudongdo...@huawei.com
---
Bjorn Helgaas (7):
iommu: Use dev_printk() when possible
iommu/amd: Use dev_printk() when possible
iommu/vt-d: Use dev_printk() when possible
iommu/vt-d: Remove unnecessary local variable initializations
iommu
From: Bjorn Helgaas
Use dev_printk() when possible so the IOMMU messages are more consistent
with other messages related to the device.
E.g., I think these messages related to surprise hotplug:
pciehp :80:10.0:pcie004: Slot(36): Link Down
iommu: Removing device :87:00.0 from group
From: Bjorn Helgaas
Use dev_printk() when possible so the IOMMU messages are more consistent
with other messages related to the device.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/amd_iommu.c | 25 +++--
drivers/iommu/amd_iommu_init.c | 20
From: Bjorn Helgaas
domain_remove_dev_info() takes a struct dmar_domain * argument, but doesn't
use it. Remove it. No functional change intended.
The last use of this argument was removed by 127c761598f7 ("iommu/vt-d:
Pass device_domain_info to __dmar_remove_one_dev_info").
From: Bjorn Helgaas
Simplify control flow by returning immediately when we know the result.
No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/intel-iommu.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a
From: Bjorn Helgaas
A local variable initialization is a hint that the variable will be used in
an unusual way. If the initialization is unnecessary, that hint becomes a
distraction.
Remove unnecessary initializations. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers
From: Bjorn Helgaas
The "Domain 0 is reserved, so dont process it" comment suggests that a NULL
pointer corresponds to domain 0. I don't think that's true, and in any
case, every caller supplies a non-NULL domain pointer that has already been
dereferenced, so the test is
From: Bjorn Helgaas
Use dev_printk() when possible so the IOMMU messages are more consistent
with other messages related to the device.
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/intel-iommu.c | 54 +++
1 file changed, 24 insertions(+), 30
On Sun, Feb 10, 2019 at 8:00 PM Lu Baolu wrote:
>
> Hi,
>
> On 2/9/19 6:06 AM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > A local variable initialization is a hint that the variable will be used in
> > an unusual way. If the initialization
ch IOMMUs to determine whether
devices can use the ATS service.
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Keith Busch
> Suggested-by: Ashok Raj
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
With typos addressed (more below),
Acked-by: Bjorn Helga
the PASID support of the device.
>
> Cc: Ashok Raj
> Cc: Jacob Pan
> Cc: Keith Busch
> Suggested-by: Ashok Raj
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
With typos (also below) addressed,
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/ats.c
Hi Logan,
Drive-by nits:
On Thu, Mar 21, 2019 at 06:06:44PM -0600, Logan Gunthorpe wrote:
> Introduce the module parameter 'use_msi' which, when set uses
s/set/set,/
> MSI interrupts instead of doorbells for each queue pair (QP). T
> he parameter is only available if NTB MSI support is configur
On Thu, Mar 21, 2019 at 06:06:38PM -0600, Logan Gunthorpe wrote:
> This patch introduces the "Logical Port Number" which is similar to the
> "Port Number" in that it enumerates the ports in the system.
>
> The original (or Physical) "Port Number" can be any number used by the
> hardware to uniqule
On Thu, Feb 13, 2020 at 05:50:40PM +0100, Jean-Philippe Brucker wrote:
> Each vendor has their own way of describing whether a host bridge
> supports ATS. The Intel and AMD ACPI tables selectively enable or
> disable ATS per device or sub-tree, while Arm has a single bit for each
> host bridge. F
Subject could be simply "PCI/ATS: Export PRI functions"
On Mon, Feb 24, 2020 at 07:24:00PM +0100, Jean-Philippe Brucker wrote:
> The SMMUv3 driver uses pci_{enable,disable}_pri() and related
> functions. Export those functions to allow the driver to be built as a
> module.
>
RI stubs, and avoid
> adding more #ifdefs to the SMMU driver.
>
> Cc: Bjorn Helgaas
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> include/linux/pci-ats.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/pci-ats.h
nstead of having the
assignment be a side-effect, e.g.,
bridge->ats_supported = of_pci_host_ats_supported(bridge);
If that works for you,
Acked-by: Bjorn Helgaas
> platform_set_drvdata(pdev, bridge->bus);
> return 0;
> }
> --
> 2.25.1
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Mar 11, 2020 at 01:44:59PM +0100, Jean-Philippe Brucker wrote:
> When initializing a PCI root bridge, copy its "ATS supported" attribute
> into the root bridge.
>
> Acked-by: Hanjun Guo
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/acpi/arm64/iort.c | 27 +++
re description states that ATS isn't supported by the host
> bridge.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/ats.c | 30 +-
> include/linux/pci-ats.h | 3 +++
> 2 files changed, 32 insertio
On Wed, Mar 11, 2020 at 01:44:57PM +0100, Jean-Philippe Brucker wrote:
> Each vendor has their own way of describing whether a host bridge
> supports ATS. The Intel and AMD ACPI tables selectively enable or
> disable ATS per device or sub-tree, while Arm has a single bit for each
> host bridge. F
On Mon, Feb 24, 2020 at 05:58:41PM +0100, Jean-Philippe Brucker wrote:
> The Arm SMMUv3 driver uses pci_{enable,disable}_pasid() and related
> functions. Export them to allow the driver to be built as a module.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
>
ormation is consistent, platforms can provide both a
> device-tree and a built-in topology, and the IOMMU infrastructure is
> able to deal with multiple DMA configuration methods.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pci-driver.c | 5
pported() helper also returns whether
> ATS was globally disabled with pci=noats, and could later include more
> things, for example whether the whole PCIe hierarchy down to the
> endpoint supports ATS.
>
> Signed-off-by: Jean-Philippe Brucker
Acked-by: Bjorn Hel
On Tue, May 19, 2020 at 04:33:58PM -0400, Jim Quinlan wrote:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted; the
ken as an input parameter.
>
> Signed-off-by: Diana Craciun
> Signed-off-by: Lorenzo Pieralisi
> Cc: Bjorn Helgaas
> Cc: Rob Herring
> Cc: Marc Zyngier
Acked-by: Bjorn Helgaas# pci/msi.c
> ---
> drivers/of/irq.c | 8 +---
> drivers/pci/msi.c | 2 +
so renaming the requestor ID input
> to a more generic ID name.
>
> Signed-off-by: Lorenzo Pieralisi
> Cc: Will Deacon
> Cc: Hanjun Guo
> Cc: Bjorn Helgaas
> Cc: Sudeep Holla
> Cc: Catalin Marinas
> Cc: Robin Murphy
> Cc: "Rafael J. Wysocki"
>
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are actually on the AMBA bus,
> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
> is allocated, instead o
On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > Is this slowdown significant? We already iterate over every device
> > when applying PCI_FIXUP_FINAL quirks, so if we used the existing
> >
.3 Network controller: Intel Corporation Device 9df0 (rev 30)
> Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
>
> This permits assigning this device to a guest VM.
>
> Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
> Signed-off
On Mon, Jun 01, 2020 at 03:56:55PM -0600, Alex Williamson wrote:
> On Mon, 1 Jun 2020 14:40:23 -0700
> "Raj, Ashok" wrote:
>
> > On Mon, Jun 01, 2020 at 04:25:19PM -0500, Bjorn Helgaas wrote:
> > > On Thu, May 28, 2020 at 01:57:42PM -0700, Ashok Raj wrote:
>
On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
> On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
> > On Thu, May 28, 2020 at 09:33:44AM +0200, Joerg Roedel wrote:
> > > On Wed, May 27, 2020 at 01:18:42PM -0500, Bjorn Helgaas wrote:
> > > > Is this slowdown si
On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
> > On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote:
> > > On 2020/6/2 上午1:41, Bjorn Helgaas wrote:
> > > > On Thu, May 28, 2020 at 09:33:
On Tue, Jun 09, 2020 at 11:15:06AM +0200, Arnd Bergmann wrote:
> On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao wrote:
> > On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
> > > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> > >> On 2020/6/6 上午7:19, Bjorn
On Thu, Jun 11, 2020 at 10:54:45AM +0800, Zhangfei Gao wrote:
> On 2020/6/10 上午12:49, Bjorn Helgaas wrote:
> > On Tue, Jun 09, 2020 at 11:15:06AM +0200, Arnd Bergmann wrote:
> > > On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao
> > > wrote:
> > > > O
On Sat, Jun 13, 2020 at 10:30:56PM +0800, Zhangfei Gao wrote:
> On 2020/6/11 下午9:44, Bjorn Helgaas wrote:
> > +++ b/drivers/iommu/iommu.c
> > > > > > > > > > @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device
> > > > > > > > &
On Tue, Mar 6, 2012 at 12:13 AM, Yinghai Lu wrote:
> When do pci remove/rescan on system that have more iommus, got
>
> [ 894.089745] Set context mapping for c4:00.0
> [ 894.110890] mpt2sas3: Allocated physical memory: size(4293 kB)
> [ 894.112556] mpt2sas3: Current Controller Queue Depth(1883)
On Fri, Mar 9, 2012 at 12:06 AM, Yinghai Lu wrote:
> On Thu, Mar 8, 2012 at 5:06 PM, Bjorn Helgaas wrote:
>> On Tue, Mar 6, 2012 at 12:13 AM, Yinghai Lu wrote:
>>> When do pci remove/rescan on system that have more iommus, got
>>>
>>> [ 894.089
On Fri, Mar 9, 2012 at 10:32 AM, Yinghai Lu wrote:
> On Fri, Mar 9, 2012 at 9:25 AM, Bjorn Helgaas wrote:
>>
>> Well, it looks like you can change both save_dev_dmaru() *and*
>> get_dev_dmaru() to take a struct pci_dev *. I assumed that would be
>> obvious.
>
>
r_write_config_dword(struct pci_dev *dev, int where, u32
> val);
If you repost this, can you remove the externs when you move these
declarations? I know the file's currently a random mix, but we might
as well make a tiny improvement.
Looks fine to me otherwise, and if you don't h
On Fri, May 11, 2012 at 4:56 PM, Alex Williamson
wrote:
> In a PCIe environment, transactions aren't always required to
> reach the root bus before being re-routed. Peer-to-peer DMA
> may actually not be seen by the IOMMU in these cases. For
> IOMMU groups, we want to provide IOMMU drivers a way
On Mon, May 14, 2012 at 4:49 PM, Alex Williamson
wrote:
> On Mon, 2012-05-14 at 16:02 -0600, Bjorn Helgaas wrote:
>> On Fri, May 11, 2012 at 4:56 PM, Alex Williamson
>> wrote:
>> > In a PCIe environment, transactions aren't always required to
>> > reach the
> I tried to work through some examples to develop some intuition about this:
Sorry, gmail inserted line breaks that ruined this picture. Here's a
URL for it:
http://www.asciiflow.com/#3736558963405980039
___
iommu mailing list
iommu@lists.linux-founda
This adds a request_mem_region() for the DRHD registers. The AMD
code has similar code in iommu_map_mmio_space().
This helps avoid address conflicts when assigning PCI BARs.
---
Bjorn Helgaas (2):
resources: set type of new resource returned by __request_region()
iommu: Request
Previously we returned a new struct resource with only IORESOURCE_BUSY
set (and possibly IORESOURCE_MUXED or IORESOURCE_EXCLUSIVE), but no
MEM/IO/etc. bits set. The new resource should inherit the type of
its parent.
Signed-off-by: Bjorn Helgaas
---
kernel/resource.c |3 ++-
1 files
esent, so a
BIOS change is also necessary. But the driver should claim the space
it uses in any event.
Reference: https://bugzilla.novell.com/show_bug.cgi?id=760440
Signed-off-by: Bjorn Helgaas
---
drivers/iommu/dmar.c| 41 -
include/linux/intel-io
On Mon, May 21, 2012 at 7:04 AM, Joerg Roedel wrote:
> On Fri, May 18, 2012 at 05:18:32PM -0600, Bjorn Helgaas wrote:
>> Previously we returned a new struct resource with only IORESOURCE_BUSY
>> set (and possibly IORESOURCE_MUXED or IORESOURCE_EXCLUSIVE), but no
>> MEM/IO/et
On Sat, May 26, 2012 at 2:25 AM, Antonio Quartulli wrote:
> Hello,
>
> I'm getting this warning with linux-3.4.0. My laptop is a DELL E5420.
> Please tell me if you need further testing/debug.
Hi Antonio,
Thanks for the report. Is this a regression? If so, what's the most
recent kernel that wo
On Mon, Jun 11, 2012 at 8:26 AM, Alex Williamson
wrote:
> v3:
> - Small change to device specific ACS check to allow quirk to
> support yes/no/pass type functionality. (no change to other
> patches and no trickle down through IOMMU series)
>
> Bjorn, what's needed to get these in? Thanks,
S
On Mon, Jun 11, 2012 at 8:37 AM, Alex Williamson
wrote:
> On Wed, 2012-06-06 at 13:05 +0200, Joerg Roedel wrote:
>> On Wed, May 30, 2012 at 02:18:29PM -0600, Alex Williamson wrote:
>> > v2:
>> > - Trickle down changes from pci_get_dma_source() to better handle
>> > PCI device reference countin
On Tue, Jun 12, 2012 at 12:20 AM, Joerg Roedel wrote:
> Hi Bjorn,
>
> On Mon, Jun 11, 2012 at 06:59:25PM -0600, Bjorn Helgaas wrote:
>> On Mon, Jun 11, 2012 at 8:26 AM, Alex Williamson
>> wrote:
>> > v3:
>> > - Small change to device specific ACS check
[+cc Jeff, linux-ide, David, Joerg, iommu]
On Thu, Nov 29, 2012 at 7:39 PM, Robert Hancock wrote:
> On Thu, Nov 29, 2012 at 12:16 PM, Bjorn Helgaas wrote:
>> On Thu, Nov 29, 2012 at 1:55 AM, Justin Piszcz
>> wrote:
>>>
>>>
>>> -Orig
On Fri, Sep 05, 2014 at 06:09:45PM +0800, Yijing Wang wrote:
> This series is based Bjorn's pci-next branch + Alexander Gordeev's two patches
> "Remove arch_msi_check_device()" link: https://lkml.org/lkml/2014/7/12/41
>
> Currently, there are a lot of weak arch functions in MSI code.
> Thierry Red
On Fri, Sep 19, 2014 at 01:18:55PM +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
> Reviewed-by: Yijing Wang
I assume this will be merged via a non-PCI tree, so:
[+cc Joerg, Suravee, Jay, iommu list, linux-pci]
On Wed, Oct 15, 2014 at 5:44 PM, Kallol Biswas wrote:
> Resending, as message got bounced for html content.
>
> Hi,
> PCIe has introduced PASID TLP Prefix. There are two ECNs on this.
>
> It seems t
[-cc Bill, +cc Zhen-Hua, Eric, Tom, Jerry]
Hi Joerg,
I was looking at Zhen-Hua's recent patches, trying to figure out if I
need to do anything with them. Resetting devices in the old kernel
seems like a non-starter. Resetting devices in the new kernel, ...,
well, maybe. It seems ugly, and it s
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, ZhenHua wrote:
>> I tested on the latest stable version 3.17, it works well.
>>
>> On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
>>> On a HP system with Intel vt-d supported and m
On Wed, Oct 22, 2014 at 10:54 AM, Alexander Duyck
wrote:
> On 10/21/2014 07:47 PM, Bjorn Helgaas wrote:
>> [+cc Joerg, Eric, Tom, David, iommu list]
>>
>> On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh
>> wrote:
>>> (2014/10/14 18:34), Li, ZhenHua wrote:
>&g
On Wed, Oct 22, 2014 at 7:21 AM, Joerg Roedel wrote:
> Hi Bjorn,
>
> On Tue, Oct 21, 2014 at 08:16:46PM -0600, Bjorn Helgaas wrote:
>> I was looking at Zhen-Hua's recent patches, trying to figure out if I
>> need to do anything with them. Resetting devices in the old
On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
This needs slightly more detail. You're using the MSI chip framework
"instead of arch MSI functi
On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
> Commit 0e4ccb1505a9 ("PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()")
> introduced two __weak arch functions arch_msix_mask_irq() and
> arch_msi_mask_irq() to work around a bug when running xen in x86.
> These two functions made m
On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
> Save msi chip in pci_sys_data instead of assign
> msi chip to every pci bus in .add_bus().
>
> Signed-off-by: Yijing Wang
> ---
> drivers/pci/host/pci-tegra.c | 13 +++--
> 1 files changed, 3 insertions(+), 10 deletions(-)
On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
> Saving msi chip in pci_sys_data can make pci bus and
> devices don't need to know msi chip detail, it also
> make pci enumeration code be decoupled from msi chip.
> In fact, all pci devices under the same pci hostbridge
> share same msi
On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
> MSI chip will be saved in pci_sys_data, now we can
> clean up pcibios_add_bus() and pcibios_remove_bus()
> in arm, and use pci_find_msi_chip() to get msi chip
> in core MSI code.
>
> Signed-off-by: Yijing Wang
> ---
> arch/arm/includ
On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
> Now msi chip is saved in pci_sys_data in arm,
> we could clean the bus->msi assignment in
> pci core.
>
> Signed-off-by: Yijing Wang
> CC: Thierry Reding
> CC: Thomas Petazzoni
> ---
> drivers/pci/probe.c |1 -
> 1 files change
On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote:
> Now there are a lot of weak arch functions in MSI code.
> Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm,
> that's a better solution than overriding lots of existing weak arch
> functionsin.
> This series u
Hi Antonios,
On Mon, Oct 27, 2014 at 12:07 PM, Antonios Motakis
wrote:
> The virqfd functionality that is used by VFIO_PCI to implement interrupt
> masking and unmasking via an eventfd, is generic enough and can be reused
> by another driver. Move it to a separate file in order to allow the code
On Mon, Oct 27, 2014 at 12:08 PM, Antonios Motakis
wrote:
> The virqfd_enable and virqfd_disable functions are now global. Add the
> vfio_ prefix to those functions.
Wouldn't it be better to change the name *before* making them global?
Bjorn
___
iommu
redundant checks in IRQ remapping drivers, PCI MSI core
> already guarattees these.
guarantees
> Signed-off-by: Jiang Liu
Acked-by: Bjorn Helgaas
> ---
> drivers/iommu/irq_remapping.c |8
> drivers/pci/msi.c | 40 +++
[+cc Alex, add a subject]
On Fri, Nov 14, 2014 at 6:49 PM, Allan, Bruce W wrote:
> Let's try this again as plain text...
>
> For a PCIe device with SR-IOV support enabled (e.g. the PF device ID is
> 0xf001 at :07:00.0 and the 16 VFs have device ID 0xf002 at :07:01.0
> through :07:02
s/unsued/unused/ in subject (here and other patches).
"Clean up" is slightly ambiguous; it could mean either "make better" or
"remove." "Remove unused code" would be less ambiguous.
On Tue, Nov 25, 2014 at 03:49:42PM +0800, Jiang Liu wrote:
> Now we have converted to hierarchy irqdomain, so clea
[+to David, +cc iommu list, Joerg]
On Sun, Dec 14, 2014 at 7:44 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=89751
>
> Bug ID: 89751
>Summary: Allocating domain for fallback device failed
>Product: Drivers
>Version: 2.5
> Kernel Ver
[+cc Alex, linux-pci, iommu]
On Thu, Dec 25, 2014 at 12:13 PM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=90311
>
> Bug ID: 90311
>Summary: Hibernate failure with intel_iommu
>Product: Drivers
>Version: 2.5
> Kernel Version: 3.18.1
>
On Wed, Jan 7, 2015 at 5:05 PM, Murali Karicheri wrote:
> On 01/07/2015 01:49 PM, Murali Karicheri wrote:
>>
>> PCI devices on Keystone doesn't have correct dma_pfn_offset set. This
>> patch
>> add capability to set the dma configuration such as dma-mask,
>> dma_pfn_offset,
>> and dma ops etc usin
On Fri, Nov 21, 2014 at 03:08:27PM -0700, Alex Williamson wrote:
> I'd like to make vfio-pci capable of manipulating the device exposed
> to the user such that if the host can only support a single MSI
> vector then we hide the fact that the device itself may actually be
> able to support more. Wh
_dma_configure() to update
> the device dma configuration.
>
> Cc: Joerg Roedel
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: Will Deacon
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Suravee Suthikulpanit
>
> Signed-off-by: Murali Karic
Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: Will Deacon
> Cc: Russell King
> Cc: Arnd Bergmann
> Cc: Suravee Suthikulpanit
>
> Signed-off-by: Murali Karicheri
> ---
> drivers/of/of_pci.c| 39 +++
> include/linux/of_pci.h |
On Mon, Jan 26, 2015 at 5:25 PM, Murali Karicheri wrote:
> On 01/23/2015 06:41 PM, Bjorn Helgaas wrote:
>>
>> On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
>>>
>>> Add of_pci_dma_configure() to allow updating the dma configuration
>>>
On Tue, Jan 27, 2015 at 12:14 PM, Murali Karicheri wrote:
> On 01/26/2015 06:59 PM, Bjorn Helgaas wrote:
>>
>> On Mon, Jan 26, 2015 at 5:25 PM, Murali Karicheri
>> wrote:
>>>
>>> On 01/23/2015 06:41 PM, Bjorn Helgaas wrote:
>>>>
>>>>
On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri wrote:
> On 02/06/2015 10:15 AM, Catalin Marinas wrote:
>>
>> On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
>>>
>>> This patch add an important capability to PCI driver on Keystone. I hope
>>> to
>>> have this merged to the upstr
On Mon, Feb 23, 2015 at 4:08 PM, Murali Karicheri wrote:
> On 02/11/2015 11:58 AM, Murali Karicheri wrote:
>>
>> On 02/11/2015 11:54 AM, Murali Karicheri wrote:
>>>
>>> On 02/06/2015 01:36 PM, Murali Karicheri wrote:
>>>>
>>>> On 02/06/2015
d rejected it for good reasons. I just missed that discussion.
> This patch use the new helper function of_pci_dma_configure() to update
> the device dma configuration.
>
> Cc: Joerg Roedel
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Will Deacon
> Cc: Russell King
> Cc:
ainst initial RFC.
> - Added a helper function to get the OF node of the parent
> - Added an API in of_pci.c to update DMA configuration of the pci
>device.
>
> Cc: Joerg Roedel
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> C
n the DMA
> configuration for the slave PCI device.
>
> Tested-by: Suravee Suthikulpanit (AMD Seattle)
> Signed-off-by: Murali Karicheri
> Signed-off-by: Bjorn Helgaas
> Reviewed-by: Catalin Marinas
> Acked-by: Will Deacon
> CC: Joerg Roedel
> CC: Grant Likely
> CC: Rob
101 - 200 of 448 matches
Mail list logo
