Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Tue, Nov 26, 2019 at 05:40:26PM +0100, Christoph Hellwig wrote: > On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: > > Hello Christoph, > > > > The PCI TV card works with your patch! I was able to patch your Git kernel > > with the patch above. > > > > I haven't found any error messages in the dmesg yet. > > Thanks. Unfortunately this is a bit of a hack as we need to set > the mask based on runtime information like the magic FSL PCIe window. > Let me try to draft something better up, and thanks already for testing > this one! Maybe we'll simply force bottom up allocation before calling swiotlb_init()? Anyway, it's the last memblock allocation. diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 62f74b1b33bd..771e6cf7e2b9 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -286,14 +286,15 @@ void __init mem_init(void) /* * book3s is limited to 16 page sizes due to encoding this in * a 4-bit field for slices. */ BUILD_BUG_ON(MMU_PAGE_COUNT > 16); #ifdef CONFIG_SWIOTLB + memblock_set_bottom_up(true); swiotlb_init(0); #endif high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); set_max_mapnr(max_pfn); memblock_free_all(); -- Sincerely yours, Mike. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 0/7] Raspberry Pi 4 PCIe support
On Tue, Nov 26, 2019 at 10:19:38AM +0100, Nicolas Saenz Julienne wrote: > This series aims at providing support for Raspberry Pi 4's PCIe > controller, which is also shared with the Broadcom STB family of > devices. > Jim Quinlan (3): > dt-bindings: PCI: Add bindings for brcmstb's PCIe device > PCI: brcmstb: add Broadcom STB PCIe host controller driver > PCI: brcmstb: add MSI capability Please update these subjects to match the others, i.e., capitalize "Add". Also, I think "Add MSI capability" really means "Add support for MSI ..."; in PCIe terms the "MSI Capability" is a structure in config space and it's there whether the OS supports it or not. No need to repost just for this. > Nicolas Saenz Julienne (4): > linux/log2.h: Add roundup/rounddown_pow_two64() family of functions > ARM: dts: bcm2711: Enable PCIe controller > MAINTAINERS: Add brcmstb PCIe controller > arm64: defconfig: Enable Broadcom's STB PCIe controller ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
On 2019-11-26 6:51 pm, Nicolas Saenz Julienne wrote: On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote: On 25/11/2019 7:44 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: Just as an FYI, this introduces a warning on arm32 allyesconfig for me: I think the dma_limit argument to iommu_dma_alloc_iova should be a u64 and/or we need to use min_t and open code the zero exception. Robin, Nicolas - any opinions? Yeah, given that it's always held a mask I'm not entirely sure why it was ever a dma_addr_t rather than a u64. Unless anyone else is desperate to do it I'll get a cleanup patch ready for rc1. Sounds good to me too Robin, since I started the mess, I'll be happy to do it if it helps offloading some work from you. No worries - your change only exposed my original weird decision ;) On second look the patch was literally a trivial one-liner, so I've written it up already. Cheers, Robin. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 09/14] iommu/arm-smmu: Prevent forced unbinding of Arm SMMU drivers
On Tue, Nov 26, 2019 at 1:13 AM John Garry wrote: > > On 21/11/2019 11:49, Will Deacon wrote: > > Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation, > > since it will likely lead to catastrophic failure for any DMA devices > > mastering through the SMMU being unbound. When the driver then attempts > > to "handle" the fatal faults, it's very easy to trip over dead data > > structures, leading to use-after-free. > > > > On John's machine, he reports that the machine was "unusable" due to > > loss of the storage controller following a forced unbind of the SMMUv3 > > driver: > > > >| # cd ./bus/platform/drivers/arm-smmu-v3 > >| # echo arm-smmu-v3.0.auto > unbind > >| hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found! > >| platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x0146 > >| [hwprod 0x0146, hwcons 0x] > > > > Prevent this forced unbinding of the drivers by setting > > "suppress_bind_attrs" > > to true. > > This seems a reasonable approach for now. > > BTW, I'll give this series a spin this week, which again looks to be > your iommu/module branch, excluding the new IORT patch. Is this on a platform where of_devlink creates device links between the iommu device and its suppliers? I'm guessing no? Because device links should for unbinding of all the consumers before unbinding the supplier. Looks like it'll still allow the supplier to unbind if the consumers don't allow unbinding. Is that the case here? -Saravana ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit
On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote: > On 25/11/2019 7:44 am, Christoph Hellwig wrote: > > On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: > > > Just as an FYI, this introduces a warning on arm32 allyesconfig for me: > > > > I think the dma_limit argument to iommu_dma_alloc_iova should be a u64 > > and/or we need to use min_t and open code the zero exception. > > > > Robin, Nicolas - any opinions? > > Yeah, given that it's always held a mask I'm not entirely sure why it > was ever a dma_addr_t rather than a u64. Unless anyone else is desperate > to do it I'll get a cleanup patch ready for rc1. Sounds good to me too Robin, since I started the mess, I'll be happy to do it if it helps offloading some work from you. Regards, Nicolas signature.asc Description: This is a digitally signed message part ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v4] iommu: fix KASAN use-after-free in iommu_insert_resv_region
In case the new region gets merged into another one, the nr
list node is freed. Checking its type while completing the
merge algorithm leads to a use-after-free. Use new->type
instead.
Fixes: 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region()
implementation")
Signed-off-by: Eric Auger
Reported-by: Qian Cai
Reviewed-by: Jerry Snitselaar
Cc: Stable #v5.3+
---
v3 -> v4:
- s/nr/new in the comment
- Added Jerry's R-b
v2 -> v3:
- directly use new->type
v1 -> v2:
- remove spurious new line
---
drivers/iommu/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d658c7c6a2ab..dea1069334a4 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -312,8 +312,8 @@ int iommu_insert_resv_region(struct iommu_resv_region *new,
list_for_each_entry_safe(iter, tmp, regions, list) {
phys_addr_t top_end, iter_end = iter->start + iter->length - 1;
- /* no merge needed on elements of different types than @nr */
- if (iter->type != nr->type) {
+ /* no merge needed on elements of different types than @new */
+ if (iter->type != new->type) {
list_move_tail(&iter->list, &stack);
continue;
}
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 2/2] PCI: Add DMA alias quirk for PLX PEX NTB
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
This patch aliases all possible devfn's to the NTB device so that any
transaction coming in is governed by the mappings for the NTB.
Reviewed-by: Logan Gunthorpe
Signed-off-by: James Sewart
---
drivers/pci/quirks.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 320255e5e8f8..1ed230f739a4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5315,6 +5315,21 @@ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+/*
+ * PLX NTB uses devfn proxy IDs to move TLPs between NT endpoints. These IDs
+ * are used to forward responses to the originator on the other side of the
+ * NTB. Alias all possible IDs to the NTB to permit access when the IOMMU is
+ * turned on.
+ */
+static void quirk_plx_ntb_dma_alias(struct pci_dev *pdev)
+{
+ pci_info(pdev, "Setting PLX NTB proxy ID aliases\n");
+ /* PLX NTB may use all 256 devfns */
+ pci_add_dma_alias_range(pdev, 0, 256);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b0, quirk_plx_ntb_dma_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b1, quirk_plx_ntb_dma_alias);
+
/*
* On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
* not always reset the secondary Nvidia GPU between reboots if the system
--
2.24.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 1/2] PCI: Add helper pci_add_dma_alias_range
pci_add_dma_alias_range can be used to create a dma alias for range of
devfns.
Reviewed-by: Logan Gunthorpe
Signed-off-by: James Sewart
---
drivers/pci/pci.c | 30 +++---
include/linux/pci.h | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a97e2571a527..68339309c0f4 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5854,6 +5854,18 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
return 0;
}
+int _pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
+{
+ if (!dev->dma_alias_mask)
+ dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
+ if (!dev->dma_alias_mask) {
+ pci_warn(dev, "Unable to allocate DMA alias mask\n");
+ return -ENOMEM;
+ }
+ bitmap_set(dev->dma_alias_mask, devfn_from, len);
+ return 0;
+}
+
/**
* pci_add_dma_alias - Add a DMA devfn alias for a device
* @dev: the PCI device for which alias is added
@@ -5875,18 +5887,22 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
*/
void pci_add_dma_alias(struct pci_dev *dev, u8 devfn)
{
- if (!dev->dma_alias_mask)
- dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
- if (!dev->dma_alias_mask) {
- pci_warn(dev, "Unable to allocate DMA alias mask\n");
+ if (_pci_add_dma_alias_range(dev, devfn, 1) != 0)
return;
- }
-
- set_bit(devfn, dev->dma_alias_mask);
pci_info(dev, "Enabling fixed DMA alias to %02x.%d\n",
PCI_SLOT(devfn), PCI_FUNC(devfn));
}
+void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
+{
+ int devfn_to = devfn_from + len - 1;
+
+ if (_pci_add_dma_alias_range(dev, devfn_from, len) != 0)
+ return;
+ pci_info(dev, "Enabling fixed DMA alias for devfn range from %02x.%d to
%02x.%d\n",
+PCI_SLOT(devfn_from), PCI_FUNC(devfn_from),
PCI_SLOT(devfn_to), PCI_FUNC(devfn_to));
+}
+
bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2)
{
return (dev1->dma_alias_mask &&
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1a6cf19eac2d..6765f3d0102b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2324,6 +2324,7 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct
pci_dev *pdev)
#endif
void pci_add_dma_alias(struct pci_dev *dev, u8 devfn);
+void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len);
bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2);
int pci_for_each_dma_alias(struct pci_dev *pdev,
int (*fn)(struct pci_dev *pdev,
--
2.24.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] PCI: Add DMA alias quirk for PLX PEX NTB
> +int _pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
This should be mrked static. Also single underscore prefixes are rather
unusual in Linux. Either use two or use a more descriptive name.
> @@ -5875,18 +5887,21 @@ int pci_set_vga_state(struct pci_dev *dev, bool
> decode,
> */
> void pci_add_dma_alias(struct pci_dev *dev, u8 devfn)
> {
> - if (!dev->dma_alias_mask)
> - dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
> - if (!dev->dma_alias_mask) {
> - pci_warn(dev, "Unable to allocate DMA alias mask\n");
> + if (_pci_add_dma_alias_range(dev, devfn, 1) != 0)
> return;
> - }
> -
> - set_bit(devfn, dev->dma_alias_mask);
> pci_info(dev, "Enabling fixed DMA alias to %02x.%d\n",
>PCI_SLOT(devfn), PCI_FUNC(devfn));
> }
>
> +void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
> +{
> + int devfn_to = devfn_from + len - 1;
> + if (_pci_add_dma_alias_range(dev, devfn_from, len) != 0)
> + return;
> + pci_info(dev, "Enabling fixed DMA alias for devfn range from %02x.%d to
> %02x.%d\n",
> + PCI_SLOT(devfn_from), PCI_FUNC(devfn_from),
> PCI_SLOT(devfn_to), PCI_FUNC(devfn_to));
> +}
This adds a non-string constant line over 80 chars that should be fixed
up.
But can't you just add the len argument (which really should be
nr_devfns or so) to pci_add_dma_alias and switch the 8 existing
callers over?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: fix KASAN use-after-free in iommu_insert_resv_region
On Tue Nov 26 19, Eric Auger wrote:
In case the new region gets merged into another one, the nr
list node is freed. Checking its type while completing the
merge algorithm leads to a use-after-free. Use new->type
instead.
Fixes: 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region()
implementation")
Signed-off-by: Eric Auger
Reported-by: Qian Cai
Cc: Stable #v5.3+
Minor nit, but should the comment above list_for_each_entry_safe get
updated as well? Other than that, lgtm.
Reviewed-by: Jerry Snitselaar
---
v2 -> v3:
- directly use new->type
v1 -> v2:
- remove spurious new line
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d658c7c6a2ab..285ad4a4c7f2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -313,7 +313,7 @@ int iommu_insert_resv_region(struct iommu_resv_region *new,
phys_addr_t top_end, iter_end = iter->start + iter->length - 1;
/* no merge needed on elements of different types than @nr */
- if (iter->type != nr->type) {
+ if (iter->type != new->type) {
list_move_tail(&iter->list, &stack);
continue;
}
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] PCI: Add DMA alias quirk for PLX PEX NTB
The PLX PEX NTB forwards DMA transactions using Requester ID's that
don't exist as PCI devices. The devfn for a transaction is used as an
index into a lookup table storing the origin of a transaction on the
other side of the bridge.
Add helper pci_add_dma_alias_range that can alias a range of devfns in
dma_alias_mask.
This patch aliases all possible devfn's to the NTB device so that any
transaction coming in is governed by the mappings for the NTB.
Signed-off-by: James Sewart
---
drivers/pci/pci.c| 29 ++---
drivers/pci/quirks.c | 15 +++
include/linux/pci.h | 1 +
3 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a97e2571a527..f502af1b5d10 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5854,6 +5854,18 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
return 0;
}
+int _pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
+{
+ if (!dev->dma_alias_mask)
+ dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
+ if (!dev->dma_alias_mask) {
+ pci_warn(dev, "Unable to allocate DMA alias mask\n");
+ return -ENOMEM;
+ }
+ bitmap_set(dev->dma_alias_mask, devfn_from, len);
+ return 0;
+}
+
/**
* pci_add_dma_alias - Add a DMA devfn alias for a device
* @dev: the PCI device for which alias is added
@@ -5875,18 +5887,21 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
*/
void pci_add_dma_alias(struct pci_dev *dev, u8 devfn)
{
- if (!dev->dma_alias_mask)
- dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
- if (!dev->dma_alias_mask) {
- pci_warn(dev, "Unable to allocate DMA alias mask\n");
+ if (_pci_add_dma_alias_range(dev, devfn, 1) != 0)
return;
- }
-
- set_bit(devfn, dev->dma_alias_mask);
pci_info(dev, "Enabling fixed DMA alias to %02x.%d\n",
PCI_SLOT(devfn), PCI_FUNC(devfn));
}
+void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
+{
+ int devfn_to = devfn_from + len - 1;
+ if (_pci_add_dma_alias_range(dev, devfn_from, len) != 0)
+ return;
+ pci_info(dev, "Enabling fixed DMA alias for devfn range from %02x.%d to
%02x.%d\n",
+PCI_SLOT(devfn_from), PCI_FUNC(devfn_from),
PCI_SLOT(devfn_to), PCI_FUNC(devfn_to));
+}
+
bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2)
{
return (dev1->dma_alias_mask &&
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 320255e5e8f8..1ed230f739a4 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5315,6 +5315,21 @@ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
+/*
+ * PLX NTB uses devfn proxy IDs to move TLPs between NT endpoints. These IDs
+ * are used to forward responses to the originator on the other side of the
+ * NTB. Alias all possible IDs to the NTB to permit access when the IOMMU is
+ * turned on.
+ */
+static void quirk_plx_ntb_dma_alias(struct pci_dev *pdev)
+{
+ pci_info(pdev, "Setting PLX NTB proxy ID aliases\n");
+ /* PLX NTB may use all 256 devfns */
+ pci_add_dma_alias_range(pdev, 0, 256);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b0, quirk_plx_ntb_dma_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b1, quirk_plx_ntb_dma_alias);
+
/*
* On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
* not always reset the secondary Nvidia GPU between reboots if the system
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1a6cf19eac2d..6765f3d0102b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2324,6 +2324,7 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct
pci_dev *pdev)
#endif
void pci_add_dma_alias(struct pci_dev *dev, u8 devfn);
+void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len);
bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2);
int pci_for_each_dma_alias(struct pci_dev *pdev,
int (*fn)(struct pci_dev *pdev,
--
2.24.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2] PCI: Add DMA alias quirk for PLX PEX NTB
On 2019-11-26 10:03 a.m., James Sewart wrote:
> The PLX PEX NTB forwards DMA transactions using Requester ID's that
> don't exist as PCI devices. The devfn for a transaction is used as an
> index into a lookup table storing the origin of a transaction on the
> other side of the bridge.
>
> Add helper pci_add_dma_alias_range that can alias a range of devfns in
> dma_alias_mask.
>
> This patch aliases all possible devfn's to the NTB device so that any
> transaction coming in is governed by the mappings for the NTB.
>
> Signed-off-by: James Sewart
Looks good to me, save a nit below; and you may want to split this into
two patches: one that introduces the new interface and one that uses it.
Reviewed-by: Logan Gunthorpe
> ---
> drivers/pci/pci.c| 29 ++---
> drivers/pci/quirks.c | 15 +++
> include/linux/pci.h | 1 +
> 3 files changed, 38 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index a97e2571a527..f502af1b5d10 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -5854,6 +5854,18 @@ int pci_set_vga_state(struct pci_dev *dev, bool decode,
> return 0;
> }
>
> +int _pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
> +{
> + if (!dev->dma_alias_mask)
> + dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
> + if (!dev->dma_alias_mask) {
> + pci_warn(dev, "Unable to allocate DMA alias mask\n");
> + return -ENOMEM;
> + }
> + bitmap_set(dev->dma_alias_mask, devfn_from, len);
> + return 0;
> +}
> +
> /**
> * pci_add_dma_alias - Add a DMA devfn alias for a device
> * @dev: the PCI device for which alias is added
> @@ -5875,18 +5887,21 @@ int pci_set_vga_state(struct pci_dev *dev, bool
> decode,
> */
> void pci_add_dma_alias(struct pci_dev *dev, u8 devfn)
> {
> - if (!dev->dma_alias_mask)
> - dev->dma_alias_mask = bitmap_zalloc(U8_MAX, GFP_KERNEL);
> - if (!dev->dma_alias_mask) {
> - pci_warn(dev, "Unable to allocate DMA alias mask\n");
> + if (_pci_add_dma_alias_range(dev, devfn, 1) != 0)
> return;
> - }
> -
> - set_bit(devfn, dev->dma_alias_mask);
> pci_info(dev, "Enabling fixed DMA alias to %02x.%d\n",
>PCI_SLOT(devfn), PCI_FUNC(devfn));
> }
>
> +void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len)
> +{
> + int devfn_to = devfn_from + len - 1;
Nit: there should be a blank line between the variable declarations and
the code in the functions.
> + if (_pci_add_dma_alias_range(dev, devfn_from, len) != 0)
> + return;
> + pci_info(dev, "Enabling fixed DMA alias for devfn range from %02x.%d to
> %02x.%d\n",
> + PCI_SLOT(devfn_from), PCI_FUNC(devfn_from),
> PCI_SLOT(devfn_to), PCI_FUNC(devfn_to));
> +}
> +
> bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2)
> {
> return (dev1->dma_alias_mask &&
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 320255e5e8f8..1ed230f739a4 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5315,6 +5315,21 @@ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */
> SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */
> SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */
>
> +/*
> + * PLX NTB uses devfn proxy IDs to move TLPs between NT endpoints. These IDs
> + * are used to forward responses to the originator on the other side of the
> + * NTB. Alias all possible IDs to the NTB to permit access when the IOMMU is
> + * turned on.
> + */
> +static void quirk_plx_ntb_dma_alias(struct pci_dev *pdev)
> +{
> + pci_info(pdev, "Setting PLX NTB proxy ID aliases\n");
> + /* PLX NTB may use all 256 devfns */
> + pci_add_dma_alias_range(pdev, 0, 256);
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b0, quirk_plx_ntb_dma_alias);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_PLX, 0x87b1, quirk_plx_ntb_dma_alias);
> +
> /*
> * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does
> * not always reset the secondary Nvidia GPU between reboots if the system
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 1a6cf19eac2d..6765f3d0102b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2324,6 +2324,7 @@ static inline struct eeh_dev *pci_dev_to_eeh_dev(struct
> pci_dev *pdev)
> #endif
>
> void pci_add_dma_alias(struct pci_dev *dev, u8 devfn);
> +void pci_add_dma_alias_range(struct pci_dev *dev, u8 devfn_from, int len);
> bool pci_devs_are_dma_aliases(struct pci_dev *dev1, struct pci_dev *dev2);
> int pci_for_each_dma_alias(struct pci_dev *pdev,
> int (*fn)(struct pci_dev *pdev,
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: > Hello Christoph, > > The PCI TV card works with your patch! I was able to patch your Git kernel > with the patch above. > > I haven't found any error messages in the dmesg yet. Thanks. Unfortunately this is a bit of a hack as we need to set the mask based on runtime information like the magic FSL PCIe window. Let me try to draft something better up, and thanks already for testing this one! ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
On Tue, Nov 26, 2019 at 10:19:39AM +0100, Nicolas Saenz Julienne wrote: > Some users need to make sure their rounding function accepts and returns > 64bit long variables regardless of the architecture. Sadly > roundup/rounddown_pow_two() takes and returns unsigned longs. Create a > new generic 64bit variant of the function and cleanup rougue custom > implementations. Is it possible to create general roundup/rounddown_pow_two() which will work correctly for any type of variables, instead of creating special variant for every type? Thanks ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based on the bus dma mask limit, which is rather
interesting. swiotlb_init uses memblock_alloc_low to allocate the
buffer, and I'll need some help from Mike and the powerpc maintainers
to figure out how that select where to allocate the buffer from, and
how we can move it to a lower address. My gut feeling would be to try
to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably
without needing too much arch specific magic.
Presuming the problem is relevant for all CoreNet boards something like
this could work:
diff --git a/arch/powerpc/include/asm/dma.h b/arch/powerpc/include/asm/dma.h
index 1b4f0254868f..7c6cfeeaff52 100644
--- a/arch/powerpc/include/asm/dma.h
+++ b/arch/powerpc/include/asm/dma.h
@@ -347,5 +347,11 @@ extern int isa_dma_bridge_buggy;
#define isa_dma_bridge_buggy (0)
#endif
+#ifdef CONFIG_CORENET_GENERIC
+extern phys_addr_t ppc_dma_phys_limit;
+#define ARCH_LOW_ADDRESS_LIMIT (ppc_dma_phys_limit - 1)
+#endif
+
+
#endif /* __KERNEL__ */
#endif/* _ASM_POWERPC_DMA_H */
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index fe0606439b5a..346b436b6d3f 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -126,3 +126,7 @@ void __init mpc85xx_qe_par_io_init(void)
}
}
#endif
+
+#ifdef CONFIG_CORENET_GENERIC
+phys_addr_t ppc_dma_phys_limit = 0xUL;
+#endif
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 7ee2c6628f64..673bcbdc7c75 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -64,7 +64,7 @@ void __init corenet_gen_setup_arch(void)
mpc85xx_smp_init();
swiotlb_detect_4g();
-
+ ppc_dma_phys_limit = 0x0fffUL;
pr_info("%s board\n", ppc_md.name);
mpc85xx_qe_init();
Hello Mike,
My PCI TV card works also with your patch! Before I had to add "#include
" to the file "arch/powerpc/platforms/85xx/corenet_generic.c"
because of the following error:
--
CC arch/powerpc/platforms/85xx/corenet_generic.o
CC ipc/util.o
CC ipc/msgutil.o
arch/powerpc/platforms/85xx/corenet_generic.c: In function
‘corenet_gen_setup_arch’:
arch/powerpc/platforms/85xx/corenet_generic.c:77:2: error:
‘ppc_dma_phys_limit’ undeclared (first use in this function); did you
mean ‘cpu_to_phys_id’?
ppc_dma_phys_limit = 0x0fffUL;
^~
cpu_to_phys_id
arch/powerpc/platforms/85xx/corenet_generic.c:77:2: note: each
undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:265: recipe for target
'arch/powerpc/platforms/85xx/corenet_generic.o' failed
make[3]: *** [arch/powerpc/platforms/85xx/corenet_generic.o] Error 1
scripts/Makefile.build:509: recipe for target
'arch/powerpc/platforms/85xx' failed
make[2]: *** [arch/powerpc/platforms/85xx] Error 2
scripts/Makefile.build:509: recipe for target 'arch/powerpc/platforms'
failed
make[1]: *** [arch/powerpc/platforms] Error 2
Makefile:1652: recipe for target 'arch/powerpc' failed
make: *** [arch/powerpc] Error 2
--
After that I was able to compile the latest Git kernel with your patch.
Thanks,
Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: Hello Christoph, Please find attached the dmesg of your Git kernel. Thanks. It looks like on your platform the swiotlb buffer isn't actually addressable based on the bus dma mask limit, which is rather interesting. swiotlb_init uses memblock_alloc_low to allocate the buffer, and I'll need some help from Mike and the powerpc maintainers to figure out how that select where to allocate the buffer from, and how we can move it to a lower address. My gut feeling would be to try to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably without needing too much arch specific magic. As a quick hack can you try this patch on top of the tree from Friday? diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f491690d54c6..e3f95c362922 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) #define MEMBLOCK_LOW_LIMIT 0 #ifndef ARCH_LOW_ADDRESS_LIMIT -#define ARCH_LOW_ADDRESS_LIMIT 0xUL +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL #endif phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, Hello Christoph, The PCI TV card works with your patch! I was able to patch your Git kernel with the patch above. I haven't found any error messages in the dmesg yet. Thank you! Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3] iommu: fix KASAN use-after-free in iommu_insert_resv_region
In case the new region gets merged into another one, the nr
list node is freed. Checking its type while completing the
merge algorithm leads to a use-after-free. Use new->type
instead.
Fixes: 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region()
implementation")
Signed-off-by: Eric Auger
Reported-by: Qian Cai
Cc: Stable #v5.3+
---
v2 -> v3:
- directly use new->type
v1 -> v2:
- remove spurious new line
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d658c7c6a2ab..285ad4a4c7f2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -313,7 +313,7 @@ int iommu_insert_resv_region(struct iommu_resv_region *new,
phys_addr_t top_end, iter_end = iter->start + iter->length - 1;
/* no merge needed on elements of different types than @nr */
- if (iter->type != nr->type) {
+ if (iter->type != new->type) {
list_move_tail(&iter->list, &stack);
continue;
}
--
2.20.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 09/14] iommu/arm-smmu: Prevent forced unbinding of Arm SMMU drivers
On 21/11/2019 11:49, Will Deacon wrote:
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
since it will likely lead to catastrophic failure for any DMA devices
mastering through the SMMU being unbound. When the driver then attempts
to "handle" the fatal faults, it's very easy to trip over dead data
structures, leading to use-after-free.
On John's machine, he reports that the machine was "unusable" due to
loss of the storage controller following a forced unbind of the SMMUv3
driver:
| # cd ./bus/platform/drivers/arm-smmu-v3
| # echo arm-smmu-v3.0.auto > unbind
| hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found!
| platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x0146
| [hwprod 0x0146, hwcons 0x]
Prevent this forced unbinding of the drivers by setting "suppress_bind_attrs"
to true.
This seems a reasonable approach for now.
BTW, I'll give this series a spin this week, which again looks to be
your iommu/module branch, excluding the new IORT patch.
Cheers,
John
Link:
https://lore.kernel.org/lkml/06dfd385-1af0-3106-4cc5-6a5b8e864...@huawei.com
Reported-by: John Garry
Signed-off-by: Will Deacon
---
drivers/iommu/arm-smmu-v3.c | 5 +++--
drivers/iommu/arm-smmu.c| 7 ---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 2ad8e2ca0583..3fd75abce3bb 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -3700,8 +3700,9 @@ MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
static struct platform_driver arm_smmu_driver = {
.driver = {
- .name = "arm-smmu-v3",
- .of_match_table = of_match_ptr(arm_smmu_of_match),
+ .name = "arm-smmu-v3",
+ .of_match_table = of_match_ptr(arm_smmu_of_match),
+ .suppress_bind_attrs= true,
},
.probe = arm_smmu_device_probe,
.remove = arm_smmu_device_remove,
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 53bbe0663b9e..d6c83bd69555 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2237,9 +2237,10 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
static struct platform_driver arm_smmu_driver = {
.driver = {
- .name = "arm-smmu",
- .of_match_table = of_match_ptr(arm_smmu_of_match),
- .pm = &arm_smmu_pm_ops,
+ .name = "arm-smmu",
+ .of_match_table = of_match_ptr(arm_smmu_of_match),
+ .pm = &arm_smmu_pm_ops,
+ .suppress_bind_attrs= true,
},
.probe = arm_smmu_device_probe,
.remove = arm_smmu_device_remove,
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v3 1/7] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
Some users need to make sure their rounding function accepts and returns
64bit long variables regardless of the architecture. Sadly
roundup/rounddown_pow_two() takes and returns unsigned longs. Create a
new generic 64bit variant of the function and cleanup rougue custom
implementations.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v2:
- Use u64
- Rename function to roundup/down_pow_two_u64()
- Use 1ULL instead of 1UL
- Include function usage in of/device.c and acpi/arm64/iort.c
drivers/acpi/arm64/iort.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +-
drivers/of/device.c | 2 +-
.../pci/controller/cadence/pcie-cadence-ep.c | 7 +--
drivers/pci/controller/cadence/pcie-cadence.c | 7 +--
drivers/pci/controller/pcie-rockchip-ep.c | 9 ++--
include/linux/log2.h | 52 +++
kernel/dma/direct.c | 3 +-
8 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 33f71983e001..4809d3757d71 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -1090,7 +1090,7 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr,
u64 *dma_size)
* firmware.
*/
end = dmaaddr + size - 1;
- mask = DMA_BIT_MASK(ilog2(end) + 1);
+ mask = roundup_pow_of_two_u64(end) - 1;
dev->bus_dma_limit = end;
dev->coherent_dma_mask = mask;
*dev->dma_mask = mask;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
index 024788549c25..ba5368e221f3 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
@@ -33,6 +33,7 @@
#include
#include
+#include
#include "mlx4_en.h"
@@ -252,7 +253,7 @@ static u32 freq_to_shift(u16 freq)
{
u32 freq_khz = freq * 1000;
u64 max_val_cycles = freq_khz * 1000 * MLX4_EN_WRAP_AROUND_SEC;
- u64 max_val_cycles_rounded = 1ULL << fls64(max_val_cycles - 1);
+ u64 max_val_cycles_rounded = roundup_pow_of_two_u64(max_val_cycles);
/* calculate max possible multiplier in order to fit in 64bit */
u64 max_mul = div64_u64(ULLONG_MAX, max_val_cycles_rounded);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index e9127db7b067..418d7d014af1 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -149,7 +149,7 @@ int of_dma_configure(struct device *dev, struct device_node
*np, bool force_dma)
* set by the driver.
*/
end = dma_addr + size - 1;
- mask = DMA_BIT_MASK(ilog2(end) + 1);
+ mask = roundup_pow_of_two_u64(end) - 1;
dev->coherent_dma_mask &= mask;
*dev->dma_mask &= mask;
/* ...but only set bus limit if we found valid dma-ranges earlier */
diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c
b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 1c173dad67d1..f6e37eb67c68 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "pcie-cadence.h"
@@ -61,11 +62,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
/* BAR size is 2^(aperture + 7) */
sz = max_t(size_t, epf_bar->size, CDNS_PCIE_EP_MIN_APERTURE);
- /*
-* roundup_pow_of_two() returns an unsigned long, which is not suited
-* for 64bit values.
-*/
- sz = 1ULL << fls64(sz - 1);
+ sz = roundup_pow_of_two_u64(sz);
aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
diff --git a/drivers/pci/controller/cadence/pcie-cadence.c
b/drivers/pci/controller/cadence/pcie-cadence.c
index cd795f6fc1e2..2ddda5ac60c4 100644
--- a/drivers/pci/controller/cadence/pcie-cadence.c
+++ b/drivers/pci/controller/cadence/pcie-cadence.c
@@ -4,6 +4,7 @@
// Author: Cyrille Pitchen
#include
+#include
#include "pcie-cadence.h"
@@ -11,11 +12,7 @@ void cdns_pcie_set_outbound_region(struct cdns_pcie *pcie,
u8 fn,
u32 r, bool is_io,
u64 cpu_addr, u64 pci_addr, size_t size)
{
- /*
-* roundup_pow_of_two() returns an unsigned long, which is not suited
-* for 64bit values.
-*/
- u64 sz = 1ULL << fls64(size - 1);
+ u64 sz = roundup_pow_of_two_u64(size);
int nbits = ilog2(sz);
u32 addr0, addr1, desc0, desc1;
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c
b/drivers/pci/controller/pcie-rockchip-ep.c
index d743b0a48988..343f9683b540 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -16,6 +16,7
[PATCH v3 0/7] Raspberry Pi 4 PCIe support
This series aims at providing support for Raspberry Pi 4's PCIe controller, which is also shared with the Broadcom STB family of devices. There was a previous attempt to upstream this some years ago[1] but was blocked as most STB PCIe integrations have a sparse DMA mapping[2] which is something currently not supported by the kernel. Luckily this is not the case for the Raspberry Pi 4. Note that the driver code is to be based on top of Rob Herring's series simplifying inbound and outbound range parsing. [1] https://patchwork.kernel.org/cover/10605933/ [2] https://patchwork.kernel.org/patch/10605957/ --- Changes since v2: - Redo register access in driver avoiding indirection while keeping the naming intact - Add patch editing ARM64's config - Last MSI cleanups, notably removing MSIX flag - Got rid of all _RB writes - Got rid of all of_data - Overall churn removal - Address the rest of Andrew's comments Changes since v1: - add generic rounddown/roundup_pow_two64() patch - Add MAINTAINERS patch - Fix Kconfig - Cleanup probe, use up to date APIs, exit on MSI failure - Get rid of linux,pci-domain and other unused constructs - Use edge triggered setup for MSI - Cleanup MSI implementation - Fix multiple cosmetic issues - Remove supend/resume code Jim Quinlan (3): dt-bindings: PCI: Add bindings for brcmstb's PCIe device PCI: brcmstb: add Broadcom STB PCIe host controller driver PCI: brcmstb: add MSI capability Nicolas Saenz Julienne (4): linux/log2.h: Add roundup/rounddown_pow_two64() family of functions ARM: dts: bcm2711: Enable PCIe controller MAINTAINERS: Add brcmstb PCIe controller arm64: defconfig: Enable Broadcom's STB PCIe controller .../bindings/pci/brcm,stb-pcie.yaml | 97 ++ MAINTAINERS |4 + arch/arm/boot/dts/bcm2711.dtsi| 41 + arch/arm64/configs/defconfig |1 + drivers/acpi/arm64/iort.c |2 +- drivers/net/ethernet/mellanox/mlx4/en_clock.c |3 +- drivers/of/device.c |2 +- drivers/pci/controller/Kconfig|9 + drivers/pci/controller/Makefile |1 + .../pci/controller/cadence/pcie-cadence-ep.c |7 +- drivers/pci/controller/cadence/pcie-cadence.c |7 +- drivers/pci/controller/pcie-brcmstb.c | 1012 + drivers/pci/controller/pcie-rockchip-ep.c |9 +- include/linux/log2.h | 52 + kernel/dma/direct.c |3 +- 15 files changed, 1230 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml create mode 100644 drivers/pci/controller/pcie-brcmstb.c -- 2.24.0 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
