[with Christoph's correct email address]
On Tue, May 10, 2022 at 09:07:00AM +0100, Robin Murphy wrote:
> On 2022-05-10 08:23, Shameerali Kolothum Thodi wrote:
> > Hi Joerg/Robin,
> >
> > I think this series is now ready to be merged. Could you please let
> > me know if there is anything missing.
On Tue, May 10, 2022 at 09:07:00AM +0100, Robin Murphy wrote:
> On 2022-05-10 08:23, Shameerali Kolothum Thodi wrote:
> > Hi Joerg/Robin,
> >
> > I think this series is now ready to be merged. Could you please let
> > me know if there is anything missing.
>
> Fine by me - these patches have had e
> with it.
>
> Signed-off-by: Shameer Kolothum
> ---
> drivers/acpi/arm64/iort.c | 290 ++
> include/linux/iommu.h | 8 ++
> 2 files changed, 298 insertions(+)
Reviewed-by: Lorenzo Pieralisi
> diff --git a/drivers/acpi/arm64/iort.c b/
uent patches.
>
> Signed-off-by: Shameer Kolothum
> ---
> drivers/acpi/arm64/iort.c | 23 +++
> drivers/iommu/dma-iommu.c | 2 +-
> include/linux/acpi_iort.h | 4 ++--
> 3 files changed, 18 insertions(+), 11 deletions(-)
Reviewed-by: Lorenzo Pieralisi
On Mon, Apr 04, 2022 at 01:41:59PM +0100, Shameer Kolothum wrote:
> IORT rev E.d introduces more details into the RMR node Flags
> field. Add temporary definitions to describe and access these
> Flags field until ACPICA header is updated to support E.d.
>
> This patch can be reverted once the incl
cpi/arm64/iort.c | 29 +
> include/linux/acpi_iort.h | 8
> 2 files changed, 37 insertions(+)
Reviewed-by: Lorenzo Pieralisi
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 1147387cfddb..fb2b0163c27d 100644
> ---
| 3 +
> include/linux/acpi_iort.h | 4 +
> 3 files changed, 282 insertions(+)
Very minor style comment below, regardless:
Reviewed-by: Lorenzo Pieralisi # for ACPI
IORT
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 63acc3c5b275..1147387cfd
On Mon, Apr 04, 2022 at 01:42:01PM +0100, Shameer Kolothum wrote:
> At present iort_iommu_msi_get_resv_regions() returns the number of
> MSI reserved regions on success and there are no users for this.
> The reserved region list will get populated anyway for platforms
> that require the HW MSI regi
On Mon, Mar 14, 2022 at 11:43:51AM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Mar 2022 at 11:37, Eric Auger wrote:
> >
> > Hi Robin
> >
> > On 3/11/22 11:34 AM, Robin Murphy wrote:
> > > On 2022-03-11 08:19, Eric Auger wrote:
> > >> Hi guys,
> > >>
> > >> On 2/21/22 4:43 PM, Shameer Kolothum wrote:
On Mon, Feb 21, 2022 at 03:43:36PM +, Shameer Kolothum wrote:
> The helper functions here parse through the IORT RMR nodes and
> populate a reserved region list corresponding to a given iommu
> and device(optional). These also go through the ID mappings of
> the RMR node and retrieves all the
On Mon, Feb 21, 2022 at 03:43:38PM +, Shameer Kolothum wrote:
> Add helper functions (iort_iommu_get/put_rmrs()) that
> retrieves/releases RMR memory descriptors associated
> with a given IOMMU. This will be used by IOMMU drivers
> to set up necessary mappings.
>
> Invoke it from the generic i
On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote:
> On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote:
> >
> > On 2021-10-09 08:06, Jon Nettleton wrote:
> > [...]
> > >>> + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) {
> > >>> + type = IOMMU_RESV_DIREC
On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote:
[...]
> +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node)
> +{
> + struct acpi_iort_node *smmu;
> + struct acpi_iort_rmr *rmr;
> + struct acpi_iort_rmr_desc *rmr_desc;
> + u32 map_count =
generic helper iommu_dma_get_rmrs().
>
> Signed-off-by: Shameer Kolothum
> ---
> drivers/acpi/arm64/iort.c | 38 ++
> drivers/iommu/dma-iommu.c | 4
> include/linux/acpi_iort.h | 7 +++
> 3 files changed, 49 insertions(+)
Reviewed-by
On Thu, May 13, 2021 at 02:45:43PM +0100, Shameer Kolothum wrote:
> Add support for parsing RMR node information from ACPI.
> Find associated stream id and smmu node info from the
> RMR node and populate a linked list with RMR memory
> descriptors.
"Add support for parsing RMR node information fro
On Thu, May 13, 2021 at 02:45:45PM +0100, Shameer Kolothum wrote:
> Add a helper function that retrieves RMR memory descriptors
> associated with a given IOMMU. This will be used by IOMMU
> drivers to setup necessary mappings.
>
> Now that we have this, invoke it from the generic helper
"Add a he
er
> ---
> drivers/acpi/arm64/iort.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 3912a1f6058e..0828f70cb782 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/
On Tue, Mar 23, 2021 at 06:51:44PM +, Kaneda, Erik wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi
> > Sent: Tuesday, March 23, 2021 8:54 AM
> > To: Kaneda, Erik
> > Cc: Shameerali Kolothum Thodi ;
> > linux-arm-ker...@lists
ux-a...@vger.kernel.org; iommu@lists.linux-
> > foundation.org; de...@acpica.org; Lorenzo Pieralisi
> > ; Moore, Robert
> > Cc: Linuxarm ; steven.pr...@arm.com;
> > sami.muja...@arm.com; robin.mur...@arm.com; wanghuiqiang
> >
> > Subject: [Devel] Re: [RFC P
On Wed, 10 Feb 2021 09:13:13 -0700, Jon Derrick wrote:
> The Intel Volume Management Device acts similar to a PCI-to-PCI bridge in that
> it changes downstream devices' requester-ids to its own. As VMD supports PCIe
> devices, it has its own MSI-X table and transmits child device MSI-X by
> remappi
On Thu, Mar 18, 2021 at 10:07:38AM +0100, j...@8bytes.org wrote:
> On Wed, Mar 17, 2021 at 07:14:17PM +, Derrick, Jonathan wrote:
> > Gentle reminder, for v5.13 ?
>
> This should go through the PCI tree, Bjorn?
I will start queuing code next week, noted.
Thanks,
Lorenzo
_
e_sizes_init()
>
> arch/arm64/mm/init.c | 3 ++-
> drivers/acpi/arm64/iort.c | 52 +++
> include/linux/acpi_iort.h | 4 +++
> 3 files changed, 58 insertions(+), 1 deletion(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/arch/arm64/m
On Wed, Oct 14, 2020 at 09:12:09PM +0200, Nicolas Saenz Julienne wrote:
[...]
> +unsigned int __init acpi_iort_get_zone_dma_size(void)
> +{
> + struct acpi_table_iort *iort;
> + struct acpi_iort_node *node, *end;
> + acpi_status status;
> + u8 limit = 32;
> + int i;
> +
> +
On Fri, Oct 09, 2020 at 11:13:59AM +0200, Ard Biesheuvel wrote:
> On Fri, 9 Oct 2020 at 10:36, Nicolas Saenz Julienne
> wrote:
> >
> > On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
> > > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig wrote:
> > > > On Thu, Oct 08, 2020 at 12:05:25PM +0
[+Christoph]
On Tue, Sep 29, 2020 at 12:18:49PM -0600, Alex Williamson wrote:
> On Tue, 29 Sep 2020 09:18:22 +0200
> Auger Eric wrote:
>
> > Hi all,
> >
> > [also correcting some outdated email addresses + adding Lorenzo in cc]
> >
> > On 9/29/20 12:42 AM, Alex Williamson wrote:
> > > On Mon,
On Mon, Sep 07, 2020 at 11:29:06AM -0700, Florian Fainelli wrote:
>
>
> On 9/7/2020 10:43 AM, Jim Quinlan wrote:
> > On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi
> > wrote:
> > >
> > > On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote:
> >
> > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote:
> > > Hi,
> > >
> > > On 8/24/2020 12:30 PM, Jim Quinlan wrote:
> > >>
> > >> Patchset Summary:
> > >>
On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
[...]
> And I can't figure out what's special about tegra, rcar, and xilinx
> that makes them need it as well. Is there something I could grep for
> to identify them? Is there a way to convert them so they don't need
> it?
I think
Hi all,
following up the LPC20 blog announcement:
https://www.linuxplumbersconf.org/blog/2020/vfio-iommu-pci-microconference-accepted-into-2020-linux-plumbers-conference/
The call for topics for the VFIO/IOMMU/PCI microconference at LPC20 is
now open, the LPC20 entry below provides a list of pos
On Wed, Jul 15, 2020 at 10:13:26AM +0100, Lorenzo Pieralisi wrote:
> On Thu, Jul 09, 2020 at 10:35:14AM +0100, Lorenzo Pieralisi wrote:
> > On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> > > Some HW devices are created as child devices of proprietary busses,
On Fri, Jun 19, 2020 at 09:20:01AM +0100, Lorenzo Pieralisi wrote:
> This series is a v2 of a previous posting:
>
> v1 -> v2
>
> - Removed _rid() wrappers
> - Fixed !CONFIG_ACPI compilation issue
> - Converted of_pci_iommu_init() to use of_iommu_configure_de
On Thu, Jul 09, 2020 at 10:52:52AM +, Makarand Pawagi wrote:
[...]
> > fsl_mc_bus_probe(struct platform_device *pdev)
> > >> struct fsl_mc_io *mc_io = NULL;
> > >> int container_id;
> > >> phys_addr_t mc_portal_phys_addr;
> > >> - u32 mc_portal_size;
> >
On Fri, Jun 19, 2020 at 09:20:04AM +0100, Lorenzo Pieralisi wrote:
> There is nothing PCI specific in iort_msi_map_rid().
>
> Rename the function using a bus protocol agnostic name,
> iort_msi_map_id(), and convert current callers to it.
>
> Signed-off-by: Lorenzo Pieralisi
On Thu, Jul 09, 2020 at 10:35:14AM +0100, Lorenzo Pieralisi wrote:
> On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> > Some HW devices are created as child devices of proprietary busses,
> > that have a bus specific policy defining how the child devices
> &g
On Fri, Jun 19, 2020 at 09:20:06AM +0100, Lorenzo Pieralisi wrote:
> Some HW devices are created as child devices of proprietary busses,
> that have a bus specific policy defining how the child devices
> wires representing the devices ID are translated into IOMMU and
> IRQ controller
On Thu, Jul 02, 2020 at 04:22:00PM +0800, Hanjun Guo wrote:
> Hi Robin,
>
> On 2020/7/2 0:12, Robin Murphy wrote:
> > On 2020-06-30 14:04, Hanjun Guo wrote:
> > > On 2020/6/30 18:24, Lorenzo Pieralisi wrote:
> > > > On Tue, Jun 30, 2020 a
On Wed, Jul 01, 2020 at 07:55:28PM +0300, Laurentiu Tudor wrote:
>
>
> On 6/19/2020 11:20 AM, Lorenzo Pieralisi wrote:
> > From: Makarand Pawagi
> >
> > Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
> > extract memory and other resou
On Tue, Jun 30, 2020 at 11:06:41AM +0800, Hanjun Guo wrote:
[...]
> > For devices that aren't described in the DSDT - IORT translations
> > are determined by their ACPI parent device. Do you see/Have you
> > found any issue with this approach ?
>
> The spec says "Describes the IO relationships b
On Mon, Jun 29, 2020 at 12:24:43PM +0800, Hanjun Guo wrote:
> Hi Lorenzo,
>
> On 2020/6/19 16:20, Lorenzo Pieralisi wrote:
> > When the iort_match_node_callback is invoked for a named component
> > the match should be executed upon a device with an ACPI companion.
> &g
From: Makarand Pawagi
Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
extract memory and other resources.
Interrupt (GIC ITS) information is extracted from the MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table is parsed to configure DMA.
Signed-off-by:
.
Signed-off-by: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Rob Herring
Cc: Marc Zyngier
---
drivers/of/irq.c | 28 ++--
drivers/pci/msi.c | 2 +-
include/linux/of_irq.h | 8
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/of
From: Diana Craciun
of_msi_map_get_device_domain() is PCI specific but it need not be and
can be easily changed to be bus agnostic in order to be used by other
busses by adding an IRQ domain bus token as an input parameter.
Signed-off-by: Diana Craciun
Signed-off-by: Lorenzo Pieralisi
Acked
From: Diana Craciun
The DPRC driver is not taking into account the msi-map property
and assumes that the icid is the same as the stream ID. Although
this assumption is correct, generalize the code to include a
translation between icid and streamID.
Furthermore do not just copy the MSI domain fro
.
By adding an ID parameter to acpi_dma_configure(), the IORT
code can map the child device ID to an IOMMU stream ID through
the IORT named component representing the bus in/out ID mappings.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Joerg Roedel
Cc: Robin Murphy
Cc: Marc Zyngier
---
drivers/iommu/of_iommu.c | 4 ++--
drivers/of/base.c| 42
drivers/of/irq.c | 2 +-
include/linux/of.h | 4 ++--
4 files c
device->bus PCI bus pointer will do.
Remove this useless code.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 3 ---
1 file changed, 3 deletions(-)
From: Laurentiu Tudor
The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.
Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
msi-map property.
In addition, deprecate msi-parent property which no longer makes sense
now that we su
allow the bus layer to provide the
device input id parameter - that is retrieved/assigned in bus
specific code and firmware.
Augment of_dma_configure() to add an optional input_id parameter,
leaving current functionality unchanged.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Robin
iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq_domain_bus_token input to it.
Make it PCI agnostic by also renaming the requestor ID input
to a more generic ID name.
Signed-off-by: Lorenzo Pieralisi
ing for fsl-mc bus
Lorenzo Pieralisi (8):
ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for
NC
ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
ACPI/IORT: Remove useless PCI bus walk
ACPI/IORT:
against the named component entry to check whether
there is a match and therefore an IORT node describing the in/out ID
translation for the device has been found.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "R
There is nothing PCI specific in iort_msi_map_rid().
Rename the function using a bus protocol agnostic name,
iort_msi_map_id(), and convert current callers to it.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Bjorn Helgaas
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
On Mon, Feb 17, 2020 at 12:08:48PM +, John Garry wrote:
> > >
> > > Right, and even worse is that it relies on the port driver even
> > > existing at all.
> > >
> > > All this iommu group assignment should be taken outside device
> > > driver probe paths.
> > >
> > > However we could still c
On Thu, May 21, 2020 at 05:17:27PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > There is nothing PCI bus specific in the of_msi_map_rid()
> > implementation other than the requester ID tag for the input
> > ID space.
On Thu, May 21, 2020 at 05:02:20PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > Devices sitting on proprietary busses have a device ID space that
> > is owned by the respective bus and related firmware bindings. In order
&
On Thu, May 21, 2020 at 04:47:19PM -0600, Rob Herring wrote:
> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
> wrote:
> >
> > There is nothing PCI specific (other than the RID - requester ID)
> > in the of_map_rid() implementation, so the same function can be
> &g
On Fri, May 22, 2020 at 05:32:02AM +, Makarand Pawagi wrote:
[...]
> > Subject: Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc
> >
> > Hi Lorenzo,
> >
> > On 5/21/2020 4:00 PM, Lorenzo Pieralisi wrote:
> > > From: Diana Craciun
> >
unction so that we can leave the existing
(and legitimate) callers unchanged.
No functionality change intended.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Joerg Roedel
Cc: Robin Murphy
Cc: Marc Zyngier
---
drivers/iommu/of_iommu.c | 2 +-
drivers/of/base.c
device->bus PCI bus pointer will do.
Remove this useless code.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "Rafael J. Wysocki"
---
drivers/acpi/arm64/iort.c | 3 ---
1 file changed, 3 deletions(-)
There is nothing PCI specific in iort_msi_map_rid(). Make it
a generic function, iort_msi_map_id() and provide a stub
for iort_msi_map_rid() on top of it to keep current users
unchanged.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
.
By adding an ID parameter to acpi_dma_configure(), the IORT
code can map the child device ID to an IOMMU stream id through
the IORT named component representing the bus in/out ID mappings.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc
From: Diana Craciun
Add ACPI support in the fsl-mc driver. Driver parses MC DSDT table to
extract memory and other resources.
Interrupt (GIC ITS) information is extracted from the MADT table
by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c.
IORT table is parsed to configure DMA.
Signed-off-by: M
for fsl-mc bus
Lorenzo Pieralisi (8):
ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for
NC
ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
ACPI/IORT: Remove useless PCI bus walk
ACPI/IORT: Add
of_msi_map_rid() in place to keep
existing PCI code mapping requester ID syntactically unchanged.
No functional change intended.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Marc Zyngier
---
drivers/of/irq.c | 28 ++--
include/linux/of_irq.h | 14
From: Diana Craciun
of_msi_map_get_device_domain() is PCI specific but it need not be and
can be easily changed to be bus agnostic in order to be used by other
busses by adding an IRQ domain bus token as an input parameter.
Signed-off-by: Diana Craciun
Signed-off-by: Lorenzo Pieralisi
Cc
iort_get_device_domain() is PCI specific but it need not be,
since it can be used to retrieve IRQ domain nexus of any kind
by adding an irq_domain_bus_token input to it.
Make it PCI agnostic by also renaming the requestor ID input
to a more generic ID name.
Signed-off-by: Lorenzo Pieralisi
Cc
against the named component entry to check whether
there is a match and therefore an IORT node describing the in/out ID
translation for the device has been found.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Hanjun Guo
Cc: Sudeep Holla
Cc: Catalin Marinas
Cc: Robin Murphy
Cc: "R
From: Laurentiu Tudor
The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.
Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
msi-map property.
Signed-off-by: Laurentiu Tudor
Cc: Rob Herring
---
.../devicetree/bindings/misc/
From: Diana Craciun
The DPRC driver is not taking into account the msi-map property
and assumes that the icid is the same as the stream ID. Although
this assumption is correct, generalize the code to include a
translation between icid and streamID.
Furthermore do not just copy the MSI domain fro
allow the bus layer to provide the
device input id parameter - that is retrieved/assigned in bus
specific code and firmware.
Augment of_dma_configure() to add an optional input_id parameter,
leaving current functionality unchanged.
Signed-off-by: Lorenzo Pieralisi
Cc: Rob Herring
Cc: Robin
On Thu, Apr 23, 2020 at 09:56:54AM +, Makarand Pawagi wrote:
[...]
> > > At a first glance, looks like this could very well fix the ACPI
> > > scenario, but I have some unclarities on the approach:
> > > * are we going to rely in DT and ACPI generic layers even if these
> > > devices are no
On Wed, Apr 15, 2020 at 06:44:37PM +0300, Laurentiu Tudor wrote:
>
>
> On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote:
> > On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
> >> Hi Lorenzo,
> >>
> >> On 3/25/2020 2:51 PM, Lorenzo Pieralisi
On Wed, Apr 15, 2020 at 05:42:03AM +, Makarand Pawagi wrote:
>
>
> > -Original Message-
> > From: Lorenzo Pieralisi
> > Sent: Tuesday, April 14, 2020 8:02 PM
> > To: Laurentiu Tudor
> > Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-fou
On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote:
> Hi Lorenzo,
>
> On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote:
> > On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
> >> From: Laurentiu Tudor
> >>
> >> The device
On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote:
> From: Laurentiu Tudor
>
> The devices on this bus are not discovered by way of device tree
> but by queries to the firmware. It makes little sense to trick the
> generic of layer into thinking that these devices are of rel
On Wed, Jan 22, 2020 at 03:12:59PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 21, 2020 at 06:37:47AM -0700, Jon Derrick wrote:
> > The current DMA alias implementation requires the aliased device be on
> > the same PCI bus as the requester ID. This introduces an arch-specific
> > mechanism to point
On Sun, Jan 19, 2020 at 11:25:23PM +0100, Christoph Hellwig wrote:
> This series looks good to me (modulo the one minor nitpick which isn't
> all that important):
>
> Reviewed-by: Christoph Hellwig
Hi Bjorn,
are you picking this up ? I can merge it too but since it is mostly
x86 changes I recko
ick
> ---
> drivers/pci/controller/Kconfig | 1 -
> drivers/pci/controller/vmd.c | 150
> -----
> 2 files changed, 151 deletions(-)
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kc
On Mon, Jan 13, 2020 at 12:01:13PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 13, 2020 at 05:13:38PM +, Derrick, Jonathan wrote:
> > On Mon, 2020-01-13 at 12:08 +, Lorenzo Pieralisi wrote:
> > > On Fri, Jan 10, 2020 at 10:21:08AM -0700, Jon Derrick wrote:
> > &g
On Fri, Jan 10, 2020 at 10:21:08AM -0700, Jon Derrick wrote:
> v2 Set:
> https://lore.kernel.org/linux-iommu/1578580256-3483-1-git-send-email-jonathan.derr...@intel.com/T/#t
> v1 Set:
> https://lore.kernel.org/linux-iommu/20200107134125.gd30...@8bytes.org/T/#t
>
> VMD currently works with VT-d e
> drivers/iommu/arm-smmu-v3.c | 1 +
> drivers/iommu/arm-smmu.c| 1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
I think it is best if Will picks this up and add it to the
series that modularize the SMMU drivers:
Acked-by: Lorenzo Pieralisi
> diff --git a/drivers/acp
On Fri, Nov 01, 2019 at 02:26:05PM -0700, Saravana Kannan wrote:
> On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi
> wrote:
> >
> > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
> >
> > [...]
> >
> > > > > I'm als
On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote:
[...]
> > > I'm also wondering about ACPI support.
> >
> > I'd love to add ACPI support too, but I have zero knowledge of ACPI.
> > I'd be happy to help anyone who wants to add ACPI support that allows
> > ACPI to add device
Hi,
following the official LPC19 VFIO/IOMMU/PCI microconference acceptance
notification:
https://www.linuxplumbersconf.org/blog/2019/vfio-iommu-pci-microconference-accepted-into-2019-linux-plumbers-conference/
I am sending out a call for sessions proposals open to all developers
interested/invol
On Thu, Mar 28, 2019 at 05:59:48PM +0100, Marc Gonzalez wrote:
> Hello everyone,
>
> After a lot of poking, I am finally able to use the AR8151 ethernet on the
> APQ8098 board.
> The magic bits are the iommu-map prop and the PCIE20_PARF_BDF_TRANSLATE_N
> setup.
>
> The WIP thread is archived he
>
> > 0x0 - 0x8000,
> > 0x1 - 0x8,
> > 0x10 - 0x80 and
> > 0x100 - 0x.
> >
> > are not allowed to be used as inbound addresses.
> >
> > Based-on-patch-by: Oza Pawandeep
> > Signe
On Fri, May 03, 2019 at 07:35:31PM +0530, Srinath Mannam wrote:
> This patch set will reserve IOVA addresses for DMA memory holes.
>
> The IPROC host controller allows only a few ranges of physical address
> as inbound PCI addresses which are listed through dma-ranges DT property.
> Added dma_rang
Please provide your inputs if any more changes required. Thank you,
>
> Regards,
> Srinath.
>
> On Thu, May 2, 2019 at 7:45 PM Robin Murphy wrote:
> >
> > On 02/05/2019 14:06, Lorenzo Pieralisi wrote:
> > > On Thu, May 02, 2019 at 12:27:02PM +0100,
On Thu, May 02, 2019 at 12:27:02PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 02/05/2019 12:01, Lorenzo Pieralisi wrote:
> > On Wed, May 01, 2019 at 11:06:25PM +0530, Srinath Mannam wrote:
> > > dma_ranges field of PCI host bridge structure has resource entries
On Wed, May 01, 2019 at 11:06:25PM +0530, Srinath Mannam wrote:
> dma_ranges field of PCI host bridge structure has resource entries in
> sorted order of address range given through dma-ranges DT property. This
> list is the accessible DMA address range. So that this resource list will
> be process
On Fri, Apr 12, 2019 at 08:43:35AM +0530, Srinath Mannam wrote:
> IPROC host has the limitation that it can use only those address ranges
> given by dma-ranges property as inbound address. So that the memory
> address holes in dma-ranges should be reserved to allocate as DMA address.
>
> Inbound a
On Wed, May 01, 2019 at 02:20:56PM +0100, Robin Murphy wrote:
> On 2019-05-01 1:55 pm, Bjorn Helgaas wrote:
> > On Wed, May 01, 2019 at 12:30:38PM +0100, Lorenzo Pieralisi wrote:
> > > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote:
> > > > Few SOCs h
On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote:
> Few SOCs have limitation that their PCIe host can't allow few inbound
> address ranges. Allowed inbound address ranges are listed in dma-ranges
> DT property and this address ranges are required to do IOVA mapping.
> Remaining addres
robably
> want to store this bit at the host bridge or SMMU rather than in each
> endpoint.
>
> Signed-off-by: Jean-Philippe Brucker
> ---
> drivers/acpi/arm64/iort.c | 11 +++
> include/linux/iommu.h | 4
> 2 files changed, 15 insertions(+)
For the IORT
On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote:
> Add configuration to support IPROC PCIe host controller outbound memory
> window mapping with SOC address range inside 4GB boundary, which is 32 bit
> AXI address.
I do not understand what this means, explain it to me and rewrite th
On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote:
> In the current implementation, config read output data 0x0001 is
> assumed as CRS completion. But sometimes 0x0001 can be a valid data.
>
> IPROC PCIe host controller has a register to show config read request
> status flags
On Tue, Nov 20, 2018 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> On Friday, November 16, 2018 11:57:38 AM CET Lorenzo Pieralisi wrote:
> > On Thu, Nov 15, 2018 at 07:33:54PM +, mario.limoncie...@dell.com wrote:
> > >
> > >
> > > > -Original Mes
On Thu, Nov 15, 2018 at 07:33:54PM +, mario.limoncie...@dell.com wrote:
>
>
> > -Original Message-
> > From: Mika Westerberg
> > Sent: Thursday, November 15, 2018 1:01 PM
> > To: Lorenzo Pieralisi
> > Cc: Lukas Wunner; iommu@lists.linux
On Thu, Nov 15, 2018 at 02:16:27PM +0200, Mika Westerberg wrote:
> On Thu, Nov 15, 2018 at 01:07:36PM +0100, Lukas Wunner wrote:
> > On Thu, Nov 15, 2018 at 01:37:37PM +0200, Mika Westerberg wrote:
> > > On Thu, Nov 15, 2018 at 11:13:56AM +, Lorenzo Pieralisi wrote:
>
On Thu, Nov 15, 2018 at 12:22:39PM +0200, Mika Westerberg wrote:
> On Tue, Nov 13, 2018 at 11:45:36AM +0000, Lorenzo Pieralisi wrote:
> > On Tue, Nov 13, 2018 at 01:27:00PM +0200, Mika Westerberg wrote:
> >
> > [...]
> >
> > > > To be frank the concept (a
1 - 100 of 372 matches
Mail list logo
