The pull request you sent on Fri, 24 Jun 2022 15:56:14 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/iommu-fixes-v5.19-rc3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bc3b8977e3747ab8aa54a0760dce5cdfa37ad4d6
Thank you!
--
On Fri, Jun 24, 2022 at 06:59:35PM +0100, Robin Murphy wrote:
> Use the new interface to check the capabilities for our device
> specifically.
>
> Reviewed-by: Lu Baolu
> Signed-off-by: Robin Murphy
> ---
> drivers/vfio/vfio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Fri, Jun 24, 2022 at 06:51:44PM +0100, Robin Murphy wrote:
> Since IOMMU groups are mandatory for drivers to support, it stands to
> reason that any device which has been successfully added to a group
> must be on a bus supported by that IOMMU driver, and therefore a domain
> viable for any
On Fri, Jun 24, 2022 at 03:28:33PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 23, 2022 at 01:00:27PM -0700, Nicolin Chen wrote:
> > The domain->ops validation was added, as a precaution, for mixed-driver
> > systems.
> >
> > Per Robin's remarks,
> > * While bus_set_iommu() still exists, the core
On Fri, Jun 24, 2022 at 07:31:47PM +0100, Robin Murphy wrote:
> > > Oh, physical platforms with mixed IOMMUs definitely exist already. The
> > > main
> > > point is that while bus_set_iommu still exists, the core code effectively
> > > *does* prevent multiple drivers from registering - even in
On 2022-06-24 14:16, Jason Gunthorpe wrote:
On Wed, Jun 22, 2022 at 08:54:45AM +0100, Robin Murphy wrote:
On 2022-06-16 23:23, Nicolin Chen wrote:
On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
The domain->ops validation was added, as a precaution, for mixed-driver
systems.
On Thu, Jun 23, 2022 at 01:00:27PM -0700, Nicolin Chen wrote:
> The domain->ops validation was added, as a precaution, for mixed-driver
> systems.
>
> Per Robin's remarks,
> * While bus_set_iommu() still exists, the core code prevents multiple
> drivers from registering, so we can't really run
On Fri, Jun 24, 2022 at 06:35:49PM +0800, Yong Wu wrote:
> > > It's not used in VFIO context. "return 0" just satisfy the iommu
> > > framework to go ahead. and yes, here we only allow the shared
> > > "mapping-domain" (All the devices share a domain created
> > > internally).
What part of the
Use the new interface to check the capabilities for our device
specifically.
Reviewed-by: Lu Baolu
Signed-off-by: Robin Murphy
---
drivers/vfio/vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 61e71c1154be..4c06b571eaba
Since IOMMU groups are mandatory for drivers to support, it stands to
reason that any device which has been successfully added to a group
must be on a bus supported by that IOMMU driver, and therefore a domain
viable for any device in the group must be viable for all devices in
the group. This
On Tue, 21 Jun 2022 18:10:14 +0300, Mikko Perttunen wrote:
> From: Thierry Reding
>
> Convert the Tegra host1x controller bindings from the free-form text
> format to json-schema.
>
> This also adds the missing display-hub DT bindings that were not
> previously documented.
>
> Reviewed-by: Rob
On Fri, Jun 24, 2022 at 5:52 PM Arnd Bergmann wrote:
> Arnd Bergmann (3):
> scsi: BusLogic remove bus_to_virt
> scsi: dpt_i2o: remove obsolete driver
The dpt_i2o removal is overly large and got dropped by some of the
mailing lists,
if anyone wants to see the full patch, it did make it
On Fri, Apr 22, 2022 at 02:24:34PM +0800, Mark-PK Tsai wrote:
> Release dma coherent memory before rvdev is free in
> rproc_rvdev_release().
>
> Below is the kmemleak report:
> unreferenced object 0xff8051c1a980 (size 128):
> comm "sh", pid 4895, jiffies 4295026604 (age 15481.896s)
> hex
On 6/24/22 09:52, Arnd Bergmann wrote:
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit
On Fri, 24 Jun 2022 16:12:55 +0100
Robin Murphy wrote:
> On 2022-06-24 15:28, Alex Williamson wrote:
> > On Fri, 24 Jun 2022 11:18:36 -0300
> > Jason Gunthorpe wrote:
> >
> >> On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
> >>> On Thu, 23 Jun 2022 22:50:30 -0300
> >>>
From: Arnd Bergmann
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver to
From: Arnd Bergmann
The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old
> -Original Message-
> From: Steven Price [mailto:steven.pr...@arm.com]
> Sent: 17 June 2022 13:42
> To: Shameerali Kolothum Thodi ;
> linux-arm-ker...@lists.infradead.org; linux-a...@vger.kernel.org;
> iommu@lists.linux-foundation.org
> Cc: Linuxarm ; lorenzo.pieral...@arm.com;
>
On Fri, Jun 24, 2022 at 5:38 PM Khalid Aziz wrote:
> On 6/23/22 08:47, Arnd Bergmann wrote:
>
> Driver works with this change. next_inbox is the correct pointer to pass.
Ok, great! I'll add a 'Tested-by' line then. I was already in the process of
preparing a v3 patch set, will send out the fixed
On 6/23/22 08:47, Arnd Bergmann wrote:
Can you test it again with this patch on top?
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index d057abfcdd5c..9e67f2ee25ee 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2554,8 +2554,14 @@ static void
On 2022-06-24 15:28, Alex Williamson wrote:
On Fri, 24 Jun 2022 11:18:36 -0300
Jason Gunthorpe wrote:
On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
On Thu, 23 Jun 2022 22:50:30 -0300
Jason Gunthorpe wrote:
On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson
On Fri, Jun 24, 2022 at 08:28:31AM -0600, Alex Williamson wrote:
> > > That's essentially what I'm suggesting, the vfio_group is passed as an
> > > opaque pointer which type1 can use for a
> > > vfio_group_for_each_vfio_device() type call. Thanks,
> >
> > I don't want to add a whole
On 2022-06-24 14:28, Joerg Roedel wrote:
On Thu, Jun 23, 2022 at 12:41:00PM +0100, Robin Murphy wrote:
On 2022-06-23 12:33, Joerg Roedel wrote:
On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
Thanks for your bravery!
It already starts, with that patch I am getting:
On Fri, Jun 24, 2022 at 06:41:02AM -0700, Jerry Snitselaar wrote:
> On Fri, Jun 24, 2022 at 09:43:30AM +0800, Baolu Lu wrote:
> > On 2022/6/24 09:14, Jerry Snitselaar wrote:
> > > On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> > > > On 2022/6/24 01:02, Jerry Snitselaar wrote:
> > > >
On Fri, 24 Jun 2022 11:18:36 -0300
Jason Gunthorpe wrote:
> On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
> > On Thu, 23 Jun 2022 22:50:30 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson wrote:
> > >
> > > > > >>
On Fri, Jun 24, 2022 at 08:11:59AM -0600, Alex Williamson wrote:
> On Thu, 23 Jun 2022 22:50:30 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson wrote:
> >
> > > > >> +struct vfio_device *vfio_device_get_from_iommu(struct iommu_group
> > > > >>
On Tue, Jun 21, 2022 at 08:09:20PM +0100, Robin Murphy wrote:
> Quick consensus then: does anyone have a particular preference between
> changing the .attach_group signature vs. adding a helper based on
> vfio_group_get_from_iommu() for type1 to call from within its callback? They
> seem about
On Thu, 23 Jun 2022 22:50:30 -0300
Jason Gunthorpe wrote:
> On Thu, Jun 23, 2022 at 05:00:44PM -0600, Alex Williamson wrote:
>
> > > >> +struct vfio_device *vfio_device_get_from_iommu(struct iommu_group
> > > >> *iommu_group)
> > > >> +{
> > > >> + struct vfio_group *group =
> > > >>
Hi Linus,
The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e:
Linux 5.19-rc3 (2022-06-19 15:06:47 -0500)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
tags/iommu-fixes-v5.19-rc3
for you to fetch changes up to
On Fri, Jun 24, 2022 at 09:43:30AM +0800, Baolu Lu wrote:
> On 2022/6/24 09:14, Jerry Snitselaar wrote:
> > On Fri, Jun 24, 2022 at 08:55:08AM +0800, Baolu Lu wrote:
> > > On 2022/6/24 01:02, Jerry Snitselaar wrote:
> > > > Hi Baolu & Dave,
> > > >
> > > > I noticed last night that on a Sapphire
On Mon, Jun 20, 2022 at 05:49:13AM +, nobuhiro1.iwama...@toshiba.co.jp
wrote:
> Hi,
>
> Thanks for your review.
>
> > -Original Message-
> > From: Jason Gunthorpe
> > Sent: Thursday, May 26, 2022 3:27 AM
> > To: Baolu Lu
> > Cc: iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ)
> > ; Joerg Roedel
On Thu, Jun 23, 2022 at 12:41:00PM +0100, Robin Murphy wrote:
> On 2022-06-23 12:33, Joerg Roedel wrote:
> > On Wed, Jun 22, 2022 at 02:12:39PM +0100, Robin Murphy wrote:
> > > Thanks for your bravery!
> >
> > It already starts, with that patch I am getting:
> >
> > xhci_hcd :02:00.0:
On Fri, Jun 24, 2022 at 05:59:39AM -0700, Christoph Hellwig wrote:
> Shouldn't this also remove the old list given it has only a few days
> to live?
No, the new list is not yet archived on lore. There will be a hard
switch of the archive on July 5th, and after that the old list can be
removed.
On Wed, Jun 22, 2022 at 08:54:45AM +0100, Robin Murphy wrote:
> On 2022-06-16 23:23, Nicolin Chen wrote:
> > On Thu, Jun 16, 2022 at 06:40:14AM +, Tian, Kevin wrote:
> >
> > > > The domain->ops validation was added, as a precaution, for mixed-driver
> > > > systems. However, at this moment
On Fri, Jun 24, 2022 at 02:51:39PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The IOMMU mailing list will move from lists.linux-foundation.org to
> lists.linux.dev. The hard switch of the archive will happen on July
> 5th, but add the new list now already so that people start using the
From: Joerg Roedel
The IOMMU mailing list will move from lists.linux-foundation.org to
lists.linux.dev. The hard switch of the archive will happen on July
5th, but add the new list now already so that people start using the
list when sending patches. After July 5th the old list will disappear.
On Fri, 2022-06-24 at 06:16 +, Tian, Kevin wrote:
> > From: Yong Wu
> > Sent: Friday, June 24, 2022 1:39 PM
> >
> > On Thu, 2022-06-23 at 19:44 -0700, Nicolin Chen wrote:
> > > On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> > > > External email: Use caution opening links or
On Thu, Jun 23, 2022 at 11:30:06PM -0700, Christoph Hellwig wrote:
> iommu@lists.linux-foundation.org is also listed for various other
> MAINTAINERS entries. Can you please send a list to update all of them
> to Linus ASAP, including for 5.19 and -stable?
Right, will do, thanks for the heads-up.
Add support for the M4Us found in the MT6795 Helio X10 SoC.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Yong Wu
---
drivers/iommu/mtk_iommu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index
Xperia M5 (codename "Holly") smartphone.
Changes in v4:
- Retitled mtk_iommu commits to iommu/mediatek as suggested by Yong Wu
- Removed unused M4U_LARB5_ID definition
- Rebased on next-20220624 and
https://patchwork.kernel.org/project/linux-mediatek/list/?series=650969
Cha
In preparation for adding support for MT6795, add a new flag named
TF_PORT_TO_ADDR_MT8173 and use that instead of checking for m4u_plat
type in mtk_iommu_hw_init() to avoid seeing a long list of m4u_plat
checks there in the future.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Yong Wu
Add bindings for the MediaTek Helio X10 (MT6795) IOMMU/M4U.
Signed-off-by: AngeloGioacchino Del Regno
Acked-by: Rob Herring
---
.../bindings/iommu/mediatek,iommu.yaml| 4 +
include/dt-bindings/memory/mt6795-larb-port.h | 95 +++
2 files changed, 99 insertions(+)
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz wrote:
> Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:
> >
> > All architecture-independent users of virt_to_bus() and bus_to_virt()
> > have been fixed to use the dma mapping interfaces or have been
> > removed now. This means the definitions on
在 2022/6/24 14:54, Baolu Lu 写道:
On 2022/6/24 14:02, Ethan Zhao wrote:
在 2022/6/23 14:57, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent device will encounter the
On 2022/6/24 14:02, Ethan Zhao wrote:
在 2022/6/23 14:57, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent device will encounter the "DMAR: Setup RID2PASID
failed"
> From: Lu Baolu
> Sent: Thursday, June 23, 2022 2:57 PM
>
> The IOMMU driver shares the pasid table for PCI alias devices. When the
> RID2PASID entry of the shared pasid table has been filled by the first
> device, the subsequent device will encounter the "DMAR: Setup RID2PASID
> failed"
On Wed, Jun 22, 2022 at 10:26:01AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The IOMMU mailing list will move from lists.linux-foundation.org to
> lists.linux.dev. The hard switch of the archive will happen on July
> 5th, but add the new list now already so that people start using the
> From: Yong Wu
> Sent: Friday, June 24, 2022 1:39 PM
>
> On Thu, 2022-06-23 at 19:44 -0700, Nicolin Chen wrote:
> > On Fri, Jun 24, 2022 at 09:35:49AM +0800, Baolu Lu wrote:
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On 2022/6/24 04:00, Nicolin Chen wrote:
>
Hi Joerg,
On 2022/6/24 13:45, Joerg Roedel wrote:
Hi Baolu,
On Wed, May 25, 2022 at 09:40:26AM +0800, Baolu Lu wrote:
How do you like it? If you agree, I can queue it in my next pull request
for fixes.
Would it help to tie DMAR and IOMMU components together, so that
selecting DMAR for IRQ
Hi，
在 2022/6/23 14:57, Lu Baolu 写道:
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent device will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has
51 matches
Mail list logo
