Received-SPF: pass (google.com: domain of linux-kernel+bounces-73591-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 20 Feb 2024 19:25:28 +0000
From: Conor Dooley <conor@kernel.org>
To: claudiu beznea <claudiu.beznea@tuxon.dev>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Mihai.Sain@microchip.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	Nicolas.Ferre@microchip.com, andre.przywara@arm.com,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Cristian.Birsan@microchip.com,
	Balakrishnan Sambath <balakrishnan.s@microchip.com>
Subject: Re: [PATCH v3 2/3] ARM: dts: microchip: sama7g5: Add flexcom 10 node
Message-ID: <20240220-lapel-diaper-0914f6da3beb@spud>
References: <20240215091524.14732-1-mihai.sain@microchip.com>
 <20240215091524.14732-3-mihai.sain@microchip.com>
 <20240215-lustily-flick-69cb48b123c3@spud>
 <PH8PR11MB6804E9353A8EEBD2B829D8B3824C2@PH8PR11MB6804.namprd11.prod.outlook.com>
 <20240216075609e58aeee4@mail.local>
 <cfafd563-1387-4775-bcb0-434ce3774827@tuxon.dev>
 <20240216-eleven-exposure-dde558e63aaf@wendy>
 <0798f21e-1ab6-4fd2-b7e3-18f35163fad1@tuxon.dev>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="yzTjB1umydcFT1/o"
Content-Disposition: inline
In-Reply-To: <0798f21e-1ab6-4fd2-b7e3-18f35163fad1@tuxon.dev>


--yzTjB1umydcFT1/o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 19, 2024 at 08:45:45PM +0200, claudiu beznea wrote:
>=20
>=20
> On 16.02.2024 11:35, Conor Dooley wrote:
> > On Fri, Feb 16, 2024 at 10:24:13AM +0200, claudiu beznea wrote:
> >> On 16.02.2024 09:56, Alexandre Belloni wrote:
> >>> On 16/02/2024 06:58:10+0000, Mihai.Sain@microchip.com wrote:
> >>>>> diff --git a/arch/arm/boot/dts/microchip/sama7g5.dtsi b/arch/arm/bo=
ot/dts/microchip/sama7g5.dtsi
> >>>>> index 269e0a3ca269..c030b318985a 100644
> >>>>> --- a/arch/arm/boot/dts/microchip/sama7g5.dtsi
> >>>>> +++ b/arch/arm/boot/dts/microchip/sama7g5.dtsi
> >>>>> @@ -958,6 +958,30 @@ i2c9: i2c@600 {
> >>>>>  			};
> >>>>>  		};
> >>>>> =20
> >>>>> +		flx10: flexcom@e2820000 {
> >>>>> +			compatible =3D "atmel,sama5d2-flexcom";
> >>>>
> >>>> My comment here was ignored:
> >>>> https://lore.kernel.org/all/20240214-robe-pregnancy-a1b056c9fe14@spu=
d/
> >>>>
> >>>> The SAMA7G5 has the same flexcom controller as SAMA5D2 MPU.
> >>>>
> >>>
> >>> Still, it needs its own compatible plus a fallback to
> >>> atmel,sama5d2-flexcom
> >>
> >> I agree with this. Though, flexcom documentation is subject to YAML
> >> conversion (a patch has been re-posted these days [1] and *maybe* it w=
ill
> >> be integrated this time). And there are multiple SoC DTs that need to =
be
> >> updated with their own flexcom compatible (lan966x, sam9x60, sama7g5).
> >>
> >> To avoid conflicting with the work at [1] and postponing this series w=
e may
> >> do the update after the [1] is done.
> >>
> >> Let me know your thoughts. Either way is fine by me.
> >=20
> > I'd be inclined to say that if we are gonna take a shortcut here, then
> > this patch should add a specific compatible so that when the yaml
> > conversion goes through you'll get a warning about this being
> > undocumented rather than silence.
>=20
> All the flexcom nodes from all flexcom capable SoCs (including SAMA7G5)
> have the same compatible introduced by Mihai.
>=20
> I don't like the idea of updating only the DTSes, either update all DTSes
> and documentation or do it as it is already done (with sama5d2 compatible=
).
>=20
> >=20
> > A resend on the flexcom patch is required though, the rebase was not
> > done correctly, so maybe Balakrishnan could "atmel,sama7g5-flexcom"
> > add with a fallback to "atmel,sama5d2-flexcom" while they're fixing
> > it up?
>=20
> I agree, and DTSes should also be updated along with documentation.

I'm biased, I'll almost never disagree with updating things to use
soc-specific compatibles...

> With this we can go forward with this patch and avoid conflicting with wo=
rk
> that is currently in progress for flexcom.

I forgot to actually CC Balakrishnan, but Nicolas fortunately forwarded
it to them. They're added now though to make sure they see this.

--yzTjB1umydcFT1/o
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZdT8qAAKCRB4tDGHoIJi
0uYYAQCNNsmFlZfOvfTXCNDKZbuo0f1s3OpLcxwZv3bxHuakpwD/Q395wy39LoTo
OfiPp3KJWQDtXxuRp23mobPwznUIswQ=
=5pi2
-----END PGP SIGNATURE-----

--yzTjB1umydcFT1/o--