All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Will Deacon <will@kernel.org>, Jiaxing Hu <huhuvmb88@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux.dev, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/rockchip: implement .flush_iotlb_all
Date: Fri, 10 Jul 2026 15:42:46 +0200	[thread overview]
Message-ID: <12654012.zAa99ISigo@diego> (raw)
In-Reply-To: <20260710111508.917486-1-huhuvmb88@gmail.com>

Hi,

Am Freitag, 10. Juli 2026, 13:15:08 Mitteleuropäische Sommerzeit schrieb Jiaxing Hu:
> On Fri, 10 Jul 2026, Will Deacon wrote:
> > So I think this is the wrong direction. We should try harder to remove
> > the function rather than add new implementations of it. I'm assuming
> > you're only adding it for some out-of-tree code that calls it?
> 
> Yes, that's right. The only caller is the out-of-tree RK3576 NPU
> (accel/rocket) bring-up I mentioned in the commit message. There's no
> in-tree rk_iommu user, since the in-tree consumers all invalidate through
> .unmap and none of them call iommu_flush_iotlb_all().

accel/rocket is in mainline, so I guess the interesting question is, why
are you expecting your changes to be (stay?) out of tree?

When you show your changes - even as a RFC - on the lists you might get
helpful comments - like the ones here for the iommu change.
That might also prevent you from going too far in a suboptimal direction
and thus could save time.

Additionally, you would show you're working on that, so that could
prevent someone else starting a duplicate of your work -  or at least
pool resources.

There are a bunch of people working on the RK3576 for different projects
so there is a pretty high chance of getting valuable feedback.
(like what happened with this patch ;-) )


Heiko




WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Will Deacon <will@kernel.org>, Jiaxing Hu <huhuvmb88@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux.dev, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu/rockchip: implement .flush_iotlb_all
Date: Fri, 10 Jul 2026 15:42:46 +0200	[thread overview]
Message-ID: <12654012.zAa99ISigo@diego> (raw)
In-Reply-To: <20260710111508.917486-1-huhuvmb88@gmail.com>

Hi,

Am Freitag, 10. Juli 2026, 13:15:08 Mitteleuropäische Sommerzeit schrieb Jiaxing Hu:
> On Fri, 10 Jul 2026, Will Deacon wrote:
> > So I think this is the wrong direction. We should try harder to remove
> > the function rather than add new implementations of it. I'm assuming
> > you're only adding it for some out-of-tree code that calls it?
> 
> Yes, that's right. The only caller is the out-of-tree RK3576 NPU
> (accel/rocket) bring-up I mentioned in the commit message. There's no
> in-tree rk_iommu user, since the in-tree consumers all invalidate through
> .unmap and none of them call iommu_flush_iotlb_all().

accel/rocket is in mainline, so I guess the interesting question is, why
are you expecting your changes to be (stay?) out of tree?

When you show your changes - even as a RFC - on the lists you might get
helpful comments - like the ones here for the iommu change.
That might also prevent you from going too far in a suboptimal direction
and thus could save time.

Additionally, you would show you're working on that, so that could
prevent someone else starting a duplicate of your work -  or at least
pool resources.

There are a bunch of people working on the RK3576 for different projects
so there is a pretty high chance of getting valuable feedback.
(like what happened with this patch ;-) )


Heiko




_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2026-07-10 13:43 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10  6:05 [PATCH] iommu/rockchip: implement .flush_iotlb_all Jiaxing Hu
2026-07-10  6:05 ` Jiaxing Hu
2026-07-10 10:59 ` Will Deacon
2026-07-10 10:59   ` Will Deacon
2026-07-10 12:11   ` Robin Murphy
2026-07-10 12:11     ` Robin Murphy
2026-07-10 11:15 ` Jiaxing Hu
2026-07-10 11:15   ` Jiaxing Hu
2026-07-10 13:42   ` Heiko Stübner [this message]
2026-07-10 13:42     ` Heiko Stübner
2026-07-10 21:11   ` Jiaxing Hu
2026-07-10 21:11     ` Jiaxing Hu
2026-07-10 21:23 ` Jiaxing Hu
2026-07-10 21:23   ` Jiaxing Hu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12654012.zAa99ISigo@diego \
    --to=heiko@sntech.de \
    --cc=huhuvmb88@gmail.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.