RE: [PATCH 2/9] iommu/ipmmu-vmsa: Hook up R8A774E1 DT matching code
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Date: 2020-07-16 04:42:30
Also in:
dmaengine, linux-devicetree, linux-gpio, linux-iommu, linux-renesas-soc, lkml
Hi Geert-san,
From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 9:40 PM Hi Shimoda-san, On Tue, Jul 14, 2020 at 1:42 PM Yoshihiro Shimoda [off-list ref] wrote:quoted
quoted
From: Geert Uytterhoeven, Sent: Tuesday, July 14, 2020 5:42 PM On Tue, Jul 14, 2020 at 10:30 AM Lad, Prabhakar [off-list ref] wrote:quoted
On Tue, Jul 14, 2020 at 9:09 AM Geert Uytterhoeven [off-list ref] wrote:quoted
On Mon, Jul 13, 2020 at 11:35 PM Lad PrabhakarAlso the recent patch to add "r8a77961" just adds to soc_rcar_gen3_whitelist.Oops, commit 17fe16181639801b ("iommu/renesas: Add support for r8a77961") did it wrong, too.Thank you for the point it out. We should add r8a77961 to the soc_rcar_gen3[]. However, I don't know why I could not realize this issue... So, I investigated this a little and then, IIUC, glob_match() which soc_device_match() uses seems to return true, if *pat = "r8a7796" and *str = "r8a77961".Are you sure about this?
I'm very sorry. I completely misunderstood the glob_match() behavior. And, now I understood why the current code can use IPMMU on r8a77961... # Since the first soc_device_match() will return false, ipmmu_slave_whitelist() # will return true and then the ipmmu_of_xlate() will be succeeded.
quoted hunk ↗ jump to hunk
I enabled CONFIG_GLOB_SELFTEST, and globtest succeeded. It does test glob_match("a", "aa"), which is a similar test. To be 100% sure, I added:--- a/lib/globtest.c +++ b/lib/globtest.c@@ -59,6 +59,7 @@ static char const glob_tests[] __initconst = "1" "a\0" "a\0" "0" "a\0" "b\0" "0" "a\0" "aa\0" + "0" "r8a7796\0" "r8a77961\0" "0" "a\0" "\0" "1" "\0" "\0" "0" "\0" "a\0"and it still succeeded.
I'm very sorry to waste your time about this... Best regards, Yoshihiro Shimoda