Received-SPF: pass (google.com: domain of linux-kernel+bounces-198266-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Sun, 02 Jun 2024 14:53:02 +0100
Message-ID: <87ikyr30zl.wl-maz@kernel.org>
From: Marc Zyngier <maz@kernel.org>
To: yu harry <harry.yu185@gmail.com>
Cc: corbet@lwn.net,
	catalin.marinas@arm.com,
	will@kernel.org,
	tglx@linutronix.de,
	linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] irqchip/gic-v3: Add Allwinner sunxi001 erratum workaround
In-Reply-To: <CAAmx-DzLh7TYub-PDSX+A7h6KuPYAr9WeBFmhknPjxAr2dPBnA@mail.gmail.com>
References: <20240602071058.6405-1-harry.yu185@gmail.com>
	<86o78jlms2.wl-maz@kernel.org>
	<CAAmx-DzLh7TYub-PDSX+A7h6KuPYAr9WeBFmhknPjxAr2dPBnA@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2
 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Precedence: bulk
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, 02 Jun 2024 14:23:43 +0100,
yu harry <harry.yu185@gmail.com> wrote:
>=20
> On Sun, Jun 2, 2024 at 5:25=E2=80=AFPM Marc Zyngier <maz@kernel.org> wrot=
e:
> >
> > On Sun, 02 Jun 2024 08:10:58 +0100,
> > "harry.yu185" <harry.yu185@gmail.com> wrote:
> > >
> > > Allwinner A523 GIC600 integration does not support the
> > > sharability feature. So assigned Erratum ID #sunxi001 for this
> > > issue.
> > >
> > > That the 0x0201643b ID is not Allwinner specific and thus
> > > there is an extra of_machine_is_compatible() check.
> > >
> > > Note, because more than one soc may have this problem, the 'sunxi'
> > > name is used instead of a fixed soc name like A523.
> > >
> > > Signed-off-by: harry.yu185 <harry.yu185@gmail.com>
> >
> > No, this is all already handled by the driver already (since 6.6).
> >
> > Please fix your DT to include the "dma-noncoherent" property in the
> > GIC and ITS nodes, which should paper over the integration bug.
> >
> > Thanks,
> >
> >         M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
>=20
> Thank you for your reply,
> the method you said may not be suitable, because this SOC
> also needs RDIST_FLAGS_FORCE_NON_SHAREABLE,
> just like RK3588, but it is different from the RK3588 version.

Who is talking of RK3588? Have you read what I wrote? Have you
actually looked at what these attributes do?

For context, here's what you're proposing:

+static bool __maybe_unused its_enable_sunxi001(void *data)
+{
+	struct its_node *its =3D data;
+
+	if (!of_machine_is_compatible("arm,sun55iw3p1"))
+		return false;
+
+	its->flags |=3D ITS_FLAGS_FORCE_NON_SHAREABLE;
+	gic_rdists->flags |=3D RDIST_FLAGS_FORCE_NON_SHAREABLE;
+
+	return true;
+}
+

"dma-noncoherent" on the GIC node provides:

static bool rd_set_non_coherent(void *data)
{
	struct gic_chip_data *d =3D data;

	d->rdists.flags |=3D RDIST_FLAGS_FORCE_NON_SHAREABLE;
	return true;
}

"dma-noncoherent" on the ITS node provides:

static bool its_set_non_coherent(void *data)
{
	struct its_node *its =3D data;

	its->flags |=3D ITS_FLAGS_FORCE_NON_SHAREABLE;
	return true;
}

So please do explain how the combination of the two isn't equivalent
to your patch. How does it fail to provide the required workaround?

	M.

--=20
Without deviation from the norm, progress is not possible.