tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0 Add linux-next specific
files for 20220706
Error/Warning reports:
https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com
Error/Warning
On 7/6/2022 5:26 PM, Will Deacon wrote:
On Thu, May 26, 2022 at 09:44:03AM +0530, Sai Prakash Ranjan wrote:
TLB sync timeouts can be due to various reasons such as TBU power down
or pending TCU/TBU invalidation/sync and so on. Debugging these often
require dumping of some implementation defined
On Wed, Jul 06, 2022 at 09:50:27PM +0200, Andrea Parri (Microsoft) wrote:
> @@ -305,6 +306,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> ret = page_address(page);
> if (dma_set_decrypted(dev, ret, size))
> goto out_free_pages;
> +#
On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote:
> > Any comments or additional testing? It would be really great to get
> > this off the table.
>
> For the USB bits:
>
> Acked-by: Greg Kroah-Hartman
So giv
> From: Lu Baolu
> Sent: Wednesday, July 6, 2022 10:55 AM
>
> The disable_dmar_iommu() is called when IOMMU initialization fails or
> the IOMMU is hot-removed from the system. In both cases, there is no
> need to clear the IOMMU translation data structures for devices.
>
> On the initialization
On 2022/7/7 09:01, Tian, Kevin wrote:
From: Lu Baolu
Sent: Saturday, July 2, 2022 9:56 AM
-out_unlock:
+ set_bit(num, iommu->domain_ids);
+ info->refcnt = 1;
+ info->did= num;
+ info->iommu = iommu;
+ domain->nid = iommu->node;
One nit. this line should be
> From: Baolu Lu
> Sent: Sunday, July 3, 2022 12:34 PM
>
> On 2022/7/1 15:58, Tian, Kevin wrote:
> >> From: Lu Baolu Sent: Wednesday, June 29,
> >> 2022 3:47 PM
> >>
> >> The disable_dmar_iommu() is called when IOMMU initialization fails
> >> or the IOMMU is hot-removed from the system. In both
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> The Intel IOMMU hot-add process starts from dmar_device_hotplug(). It
> uses the global dmar_global_lock to synchronize all the hot-add and
> hot-remove paths. In the hot-add path, the new IOMMU data structures
> are allocated firstly by
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> -out_unlock:
> + set_bit(num, iommu->domain_ids);
> + info->refcnt= 1;
> + info->did = num;
> + info->iommu = iommu;
> + domain->nid = iommu->node;
One nit. this line should be removed as it's incor
> From: Lu Baolu
> Sent: Saturday, July 2, 2022 9:56 AM
>
> Switch dmar unit sequence id allocation and release from bitmap to IDA
> interface.
>
> Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
___
iommu mailing list
iommu@lists.linux-foundation.o
The variable will come in handy to enable dma_direct_{alloc,free}()
for Hyper-V AMD SEV-SNP Isolated VMs.
Rename swiotlb_unencrypted_base to dma_unencrypted_base to indicate
that the notion is not restricted to SWIOTLB.
No functional change.
Suggested-by: Michael Kelley
Signed-off-by: Andrea Pa
In Hyper-V AMD SEV-SNP Isolated VMs, the virtual address returned by
dma_direct_alloc() must map above dma_unencrypted_base because the
memory is shared with the hardware device and must not be encrypted.
Modify dma_direct_alloc() to do the necessary remapping. In
dma_direct_free(), use the (unmo
Through swiotlb_unencrypted_base.
P.S. I'm on vacation for the next couple of weeks starting next Monday;
Dexuan/Michael should be able to address review feedback in that period.
Andrea Parri (Microsoft) (2):
swiotlb,dma-direct: Move swiotlb_unencrypted_base to direct.c
dma-direct: Fix dma_d
On 2022-07-06 01:04, Greg Kroah-Hartman wrote:
> On Wed, Jul 06, 2022 at 08:51:27AM +0200, Christoph Hellwig wrote:
>> On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote:
>>> The current version does it through a char device, but that requires
>>> creating a simple_fs and anon_inode
On Sat, Jun 25, 2022 at 08:51:58PM +0800, Lu Baolu wrote:
> Hi folks,
>
> This is a follow-up series of changes proposed by this patch:
>
> https://lore.kernel.org/linux-iommu/20220615183650.32075-1-steve.w...@hpe.com/
>
> It removes several static arrays of size DMAR_UNITS_SUPPORTED and sets
>
Hi,
I have started looking at this set.
On Mon, Jun 06, 2022 at 07:55:54PM +0800, Yicong Yang wrote:
> Document the introduction and usage of HiSilicon PTT device driver.
>
> Signed-off-by: Yicong Yang
> Reviewed-by: Jonathan Cameron
> ---
> Documentation/trace/hisi-ptt.rst | 307
On Tue, 14 Jun 2022 16:01:35 -0700, Emma Anholt wrote:
> Required for turning on per-process page tables for the GPU.
>
>
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/2] iommu: arm-smmu-impl: Add 8250 display compatible to the client list.
https://git.kernel.org/will/c/3482c0b
On 2022-05-26 05:14, Sai Prakash Ranjan wrote:
TLB sync timeouts can be due to various reasons such as TBU power down
or pending TCU/TBU invalidation/sync and so on. Debugging these often
require dumping of some implementation defined registers to know the
status of TBU/TCU operations and some of
On 06/07/2022 14:00, Tinghan Shen wrote:
> Hi Krzysztof,
>
> After discussing your message with our power team,
> we realized that we need your help to ensure we fully understand you.
>
> On Mon, 2022-07-04 at 14:38 +0200, Krzysztof Kozlowski wrote:
>> On 04/07/2022 12:00, Tinghan Shen wrote:
>>
On 06/07/2022 15:48, Matthias Brugger wrote:
>
>
> On 04/07/2022 14:36, Krzysztof Kozlowski wrote:
>> On 04/07/2022 12:00, Tinghan Shen wrote:
>>> The max clock items for the dts node with compatible
>>> 'mediatek,mt8195-smi-sub-common' should be 3.
>>>
>>> However, the dtbs_check of such node wi
On 06/07/2022 15:41, Matthias Brugger wrote:
>
>
> On 04/07/2022 14:38, Krzysztof Kozlowski wrote:
>> On 04/07/2022 12:00, Tinghan Shen wrote:
>>> Add power domains controller node for mt8195.
>>>
>>> Signed-off-by: Weiyi Lu
>>> Signed-off-by: Tinghan Shen
>>> ---
>>> arch/arm64/boot/dts/medi
On Sun, 3 Jul 2022 at 13:47, David Virag wrote:
>
> On Sun, 2022-07-03 at 00:48 +0300, Sam Protsenko wrote:
> [...]
> > Hi Marek,
> >
> > As I understand, you have some board with SysMMU v7, which is not VM
> > capable (judging from the patches you shared earlier). Could you
> > please somehow ver
On 04/07/2022 14:36, Krzysztof Kozlowski wrote:
On 04/07/2022 12:00, Tinghan Shen wrote:
The max clock items for the dts node with compatible
'mediatek,mt8195-smi-sub-common' should be 3.
However, the dtbs_check of such node will get following message,
arch/arm64/boot/dts/mediatek/mt8195-evb
On Wed, Jul 06, 2022 at 02:40:44PM +0100, John Garry wrote:
> On 30/06/2022 13:08, John Garry wrote:
>
> Hi Christoph,
>
> Can you please consider picking up this series? A few things to note
> beforehand:
>
> - I changed to only apply the mapping limit to SAS hosts in this version. I
> would nee
On 04/07/2022 14:38, Krzysztof Kozlowski wrote:
On 04/07/2022 12:00, Tinghan Shen wrote:
Add power domains controller node for mt8195.
Signed-off-by: Weiyi Lu
Signed-off-by: Tinghan Shen
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 327 +++
1 file changed, 327 inse
On 30/06/2022 13:08, John Garry wrote:
Hi Christoph,
Can you please consider picking up this series? A few things to note
beforehand:
- I changed to only apply the mapping limit to SAS hosts in this
version. I would need a fresh ack from Martin for those SCSI parts, but
wanted to make sure
t results in the identical error message.
>
> My guess is that the probe attempt of blk-ctrl is delayed now till gpc
> probes (because of the device links getting created with the
> fwnode_dev_initialized() fix), but by the time gpc probe finishes, the
> power domains aren't regi
On Wed, Jul 06, 2022 at 01:03:44PM +0100, John Garry wrote:
> On 06/07/2022 13:00, Will Deacon wrote:
> > On Mon, Apr 04, 2022 at 07:27:10PM +0800, John Garry wrote:
> > > Function iommu_group_store_type() supports changing the default domain
> > > of an IOMMU group.
> > >
> > > Many conditions ne
On Thu, Apr 07, 2022 at 03:52:53PM +0800, Leizhen (ThunderTown) wrote:
> On 2022/4/4 19:27, John Garry wrote:
> > Some low-level drivers may request DMA mappings whose IOVA length exceeds
> > that of the current rcache upper limit.
> >
> > This means that allocations for those IOVAs will never be
On Mon, Apr 04, 2022 at 07:27:11PM +0800, John Garry wrote:
> Some low-level drivers may request DMA mappings whose IOVA length exceeds
> that of the current rcache upper limit.
>
> This means that allocations for those IOVAs will never be cached, and
> always must be allocated and freed from the
On 06/07/2022 13:00, Will Deacon wrote:
On Mon, Apr 04, 2022 at 07:27:10PM +0800, John Garry wrote:
Function iommu_group_store_type() supports changing the default domain
of an IOMMU group.
Many conditions need to be satisfied and steps taken for this action to be
successful.
Satisfying these
On Mon, Apr 04, 2022 at 07:27:10PM +0800, John Garry wrote:
> Function iommu_group_store_type() supports changing the default domain
> of an IOMMU group.
>
> Many conditions need to be satisfied and steps taken for this action to be
> successful.
>
> Satisfying these conditions and steps will be
Hi Krzysztof,
After discussing your message with our power team,
we realized that we need your help to ensure we fully understand you.
On Mon, 2022-07-04 at 14:38 +0200, Krzysztof Kozlowski wrote:
> On 04/07/2022 12:00, Tinghan Shen wrote:
> > Add power domains controller node for mt8195.
> >
>
On Thu, May 26, 2022 at 09:44:03AM +0530, Sai Prakash Ranjan wrote:
> TLB sync timeouts can be due to various reasons such as TBU power down
> or pending TCU/TBU invalidation/sync and so on. Debugging these often
> require dumping of some implementation defined registers to know the
> status of TBU
Rename 'device_id' as 'sbdf' and extend it to 32bit so that we can
pass PCI segment ID to ppr_notifier(). Also pass PCI segment ID to
pci_get_domain_bus_and_slot() instead of default value.
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 2 +-
drivers/iommu/amd/iommu.c
Rename struct device_state.devid variable to struct device_state.sbdf
and extend it to 32-bit to include the 16-bit PCI segment ID via
the helper function get_pci_sbdf_id().
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iomm
Print pci segment ID along with bdf. Useful for debugging.
Co-developed-by: Suravee Suthikulpaint
Signed-off-by: Suravee Suthikulpaint
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/init.c | 10 +-
drivers/iommu/amd/iommu.c | 36 ++--
2 files changed
From: Suravee Suthikulpanit
By default, PCI segment is zero and can be omitted. To support system
with non-zero PCI segment ID, modify the parsing functions to allow
PCI segment ID.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
.../admin-g
On Thu, Jun 30, 2022 at 05:29:24PM +0800, yf.w...@mediatek.com wrote:
> This patchset adds MediaTek TTBR up to 35bit support for single normal zone.
>
> Changes in v12:
> - Update [PATCH 1/2]: remove GENMASK(31, 7)
> - Update [PATCH 2/2]: remove MMU_PT_ADDR_MASK definition.
For both patches:
Ack
From: Suravee Suthikulpanit
Upcoming AMD systems can have multiple PCI segments. Hence pass PCI
segment ID to pci_get_domain_bus_and_slot() instead of '0'.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 6 --
From: Suravee Suthikulpanit
Extend current device ID variables to 32-bit to include the 16-bit
segment ID when parsing device information from IVRS table to initialize
each IOMMU.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu
From: Suravee Suthikulpanit
Current get_device_id() only provide 16-bit PCI device ID (i.e. BDF).
With multiple PCI segment support, we need to extend the helper function
to include PCI segment ID.
So, introduce a new helper function get_device_sbdf_id() to replace
the current get_pci_device_id(
Fix amd_iommu_flush_dte_all() and amd_iommu_flush_tlb_all() to flush
upto last_bdf only.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --
From: Suravee Suthikulpanit
Replace them with per PCI segment device table.
Also remove dev_table_size, alias_table_size, amd_iommu_last_bdf
variables.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 15
From: Suravee Suthikulpanit
To include a pointer to per PCI segment device table.
Also include struct amd_iommu as one of the function parameter to
amd_iommu_apply_erratum_63() since it is needed when setting up DTE.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Sur
From: Suravee Suthikulpanit
Include struct amd_iommu_pci_seg as a function parameter since
we need to access per PCI segment device table.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/init.c | 27
From: Suravee Suthikulpanit
Start using per PCI segment device table instead of global
device table.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/a
From: Suravee Suthikulpanit
Start using per PCI segment device table instead of global
device table.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/amd/iom
From: Suravee Suthikulpanit
Start using per PCI segment device table instead of global
device table.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd/iommu
From: Suravee Suthikulpanit
Start using per PCI segment data structures instead of global data
structures.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/dr
Then, remove the global amd_iommu_rlookup_table and rlookup_table_size.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 5 -
drivers/iommu/amd/init.c| 23 ++-
From: Suravee Suthikulpanit
Pass amd_iommu structure as one of the parameter to these functions
as its needed to retrieve variable tables inside these functions.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/iommu.c | 26
From: Suravee Suthikulpanit
Pass amd_iommu structure as one of the parameter to amd_irte_ops functions
since its needed to activate/deactivate the iommu.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 6 ++--
drivers/iommu/amd/iommu
From: Suravee Suthikulpanit
Add a pointer to struct amd_iommu to amd_ir_data structure, which
can be used to correlate interrupt remapping data to a per-PCI-segment
interrupt remapping table.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
d
From: Suravee Suthikulpanit
To allow IOMMU rlookup using both PCI segment and device ID.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/iommu.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff -
From: Suravee Suthikulpanit
Use rlookup_amd_iommu() helper function which will give per PCI
segment rlookup_table.
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/iommu.c | 64 +++
1 file changed, 38 insertions(+), 26
Then, remove the global irq_lookup_table.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 2 --
drivers/iommu/amd/init.c| 19 ---
drivers/iommu/amd/iommu.c | 36
It will replace global "rlookup_table_size" variable.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 3 +++
drivers/iommu/amd/init.c| 11 ++-
2 files changed, 9 insertions(+)
On Sun, Jun 12, 2022 at 11:22:13AM +0200, Luca Weiss wrote:
> Document the compatible used for IOMMU on the msm8953 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> Changes from v1:
> - new patch
>
> Documentation/devicetree/bindings/iommu/qcom,iommu.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> d
It will replace global "alias_table_size" variable.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 3 +++
drivers/iommu/amd/init.c| 5 +++--
2 files changed, 6 insertions(+), 2 deleti
With multiple pci segment support, number of BDF supported by each
segment may differ. Hence introduce per segment device table size
which depends on last_bdf. This will replace global
"device_table_size" variable.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signe
Current code uses global "amd_iommu_last_bdf" to track the last bdf
supported by the system. This value is used for various memory
allocation, device data flushing, etc.
Introduce per PCI segment last_bdf which will be used to track last bdf
supported by the given PCI segment and use this value fo
Newer AMD systems can support multiple PCI segments. In order to support
multiple PCI segments IVMD table in IVRS structure is enhanced to
include pci segment id. Update ivmd_header structure to include "pci_seg".
Also introduce per PCI segment unity map list. It will replace global
amd_iommu_unit
From: Suravee Suthikulpanit
This will replace global alias table (amd_iommu_alias_table).
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 7 +
drivers/iommu/amd/init.c| 41 ++
From: Suravee Suthikulpanit
It will remove global old_dev_tbl_cpy. Also update copy_device_table()
copy device table for all PCI segments.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu_types.h | 6 ++
drivers/
This will replace global dev_data_list.
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 3 +++
drivers/iommu/amd/init.c| 1 +
drivers/iommu/amd/iommu.c | 21 ++-
This will replace global irq lookup table (irq_lookup_table).
Co-developed-by: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Vasant Hegde
---
drivers/iommu/amd/amd_iommu_types.h | 6 ++
drivers/iommu/amd/init.c| 27 +++
2 fil
From: Suravee Suthikulpanit
This will replace global rlookup table (amd_iommu_rlookup_table).
Add helper functions to set/get rlookup table for the given device.
Also add macros to get seg/devid from sbdf.
Co-developed-by: Vasant Hegde
Signed-off-by: Vasant Hegde
Signed-off-by: Suravee Suthiku
From: Suravee Suthikulpanit
Introduce per PCI segment device table. All IOMMUs within the segment
will share this device table. This will replace global device
table i.e. amd_iommu_dev_table.
Also introduce helper function to get the device table for the given IOMMU.
Co-developed-by: Vasant Heg
Newer AMD systems can support multiple PCI segments, where each segment
contains one or more IOMMU instances. However, an IOMMU instance can only
support a single PCI segment.
Current code assumes that system contains only one pci segment (segment 0)
and creates global data structures such as devi
struct iommu_dev_data contains member "pdev" to point to pci_dev. This is
valid for only PCI devices and for other devices this will be NULL. This
causes unnecessary "pdev != NULL" check at various places.
Replace "struct pci_dev" member with "struct device" and use to_pci_dev()
to get pci device
Hi Joerg,
As discussed in other thread, I have updated "From:" tag and
resending patchset. No changes in the actual patch content.
This patchset is based on top on "iommu/x86/amd" branch.
Base commit : 0d10fe75911787 ("iommu/amd: Use try_cmpxchg64 in ")
Newer AMD systems can suppor
On Fri, Jul 01, 2022 at 02:20:08AM -0400, Bo Liu wrote:
> As iommu_device_sysfs_add() can fail, we should check the return value.
>
> Signed-off-by: Bo Liu
> ---
> drivers/iommu/amd/init.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
Applied, thanks.
On Sun, Jul 03, 2022 at 07:44:50PM +0800, Feng Tang wrote:
> kmalloc will round up the request size to power of 2, and current
> iova_magazine's size is 1032 (1024+8) bytes, so each instance
> allocated will get 2048 bytes from kmalloc, causing around 1KB
> waste.
>
> Change IOVA_MAG_SIZE from 128
On Sat, Jun 25, 2022 at 09:34:29PM +0800, Lu Baolu wrote:
> Hi Joerg,
>
> One fix is queued for v5.19. It aims to fix:
>
> - RID2PASID setup/teardown failures for pci alias devices
>
> Please consider it for the iommu/fix branch.
>
> Best regards,
> Lu Baolu
>
> Lu Baolu (1):
> iommu/vt-d: F
On Thu, Jun 23, 2022 at 11:36:29AM +0200, Marek Szyprowski wrote:
> drivers/iommu/exynos-iommu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfou
On Tue, Jun 21, 2022 at 04:14:24PM +0100, Robin Murphy wrote:
> Robin Murphy (3):
> iommu: Use dev_iommu_ops() for probe_finalize
> iommu: Make .release_device optional
> iommu: Clean up release_device checks
Applied to core branch, thanks.
___
iom
On 2022-07-06 09:38, Alexey Kardashevskiy wrote:
On 28/04/2022 23:18, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary. This also
leaves the custom initcall effectively doing nothing but register
the driver, which no longer needs to happen early either, so convert
it
On Tue, Jun 28, 2022 at 07:59:39AM +, Shameerali Kolothum Thodi wrote:
> Now that we have all the required acks, could you please pick this series via
> IOMMU tree?
Applied to core branch, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.o
On Fri, Jun 24, 2022 at 02:12:28PM +0800, Baolu Lu wrote:
> It makes sense as far as I am aware. By putting IOMMUs in pass-through
> mode, there will be no run-time costs and things could be simplified a
> lot.
>
> Besides the refactoring efforts, we still need this quick fix so that
> the fix cou
From: Joerg Roedel
The IOMMU mailing list has moved to io...@lists.linux.dev
and the old list should bounce by now. Remove it from the
MAINTAINERS file.
Signed-off-by: Joerg Roedel
---
MAINTAINERS | 11 ---
1 file changed, 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6
On 7/6/2022 5:02 PM, Christoph Hellwig wrote:
On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote:
Swiotlb_init() is called in the mem_init() of different architects and
memblock free pages are released to the buddy allocator just after
calling swiotlb_init() via memblock_free_all().
Ye
On Tue, Jun 28, 2022 at 02:35:51PM +0530, Vasant Hegde wrote:
> Sorry. I didn't get last statement ("device identity maps DMA requests
> without PASID").
> Can you please elaborate?
When using v1 page-tables, each device supporting ATS/PRI/PASID needs to
be direct-mapped, because the v1 page-tabl
On Tue, Jun 28, 2022 at 01:23:52PM +0530, Vasant Hegde wrote:
> I think it will complicate the parsing logic. We do have `amd_iommu=off`
> option.
> How are we going to handle `amd_iommu=off,[pgtable_v1/v2]` ?
In that case everything except 'off' will be ignored. The driver might
set its interna
On Wed, Jul 06, 2022 at 04:57:33PM +0800, Tianyu Lan wrote:
> Swiotlb_init() is called in the mem_init() of different architects and
> memblock free pages are released to the buddy allocator just after
> calling swiotlb_init() via memblock_free_all().
Yes.
> The mem_init() is called before smp_in
On 7/6/2022 4:00 PM, Christoph Hellwig wrote:
On Fri, Jul 01, 2022 at 01:02:21AM +0800, Tianyu Lan wrote:
Can we reorder that initialization? Because I really hate having
to have an arch hook in every architecture.
How about using "flags" parameter of swiotlb_init() to pass area number
or add
On 28/04/2022 23:18, Robin Murphy wrote:
Stop calling bus_set_iommu() since it's now unnecessary. This also
leaves the custom initcall effectively doing nothing but register
the driver, which no longer needs to happen early either, so convert
it to builtin_platform_driver().
Signed-off-by: Ro
On Fri, Jul 01, 2022 at 01:02:21AM +0800, Tianyu Lan wrote:
> > Can we reorder that initialization? Because I really hate having
> > to have an arch hook in every architecture.
>
> How about using "flags" parameter of swiotlb_init() to pass area number
> or add new parameter for area number?
>
>
On Wed, Jul 06, 2022 at 08:51:27AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 05, 2022 at 12:16:45PM -0600, Logan Gunthorpe wrote:
> > The current version does it through a char device, but that requires
> > creating a simple_fs and anon_inode for teardown on driver removal, plus
> > a bunch of
89 matches
Mail list logo
