Received-SPF: pass (google.com: domain of linux-kernel+bounces-163074-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Mon, 29 Apr 2024 22:33:18 +0100
From: Conor Dooley <conor@kernel.org>
To: Witold Sadowski <wsadowski@marvell.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org" <krzysztof.kozlowski+dt@linaro.org>,
	"conor+dt@kernel.org" <conor+dt@kernel.org>,
	"pthombar@cadence.com" <pthombar@cadence.com>
Subject: Re: [EXTERNAL] Re: [PATCH v3 2/5] spi: cadence: Add MRVL overlay
 bindings documentation for Cadence XSPI
Message-ID: <20240429-quickstep-hypnotic-5b8d1fbeb920@spud>
References: <20240329194849.25554-1-wsadowski@marvell.com>
 <20240418011353.1764672-1-wsadowski@marvell.com>
 <20240418011353.1764672-3-wsadowski@marvell.com>
 <20240418-sacrament-cornea-fd6fd569827e@spud>
 <CO6PR18MB4098C815325699975B1BD794B01B2@CO6PR18MB4098.namprd18.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="NS8/Unwlppg/0VLi"
Content-Disposition: inline
In-Reply-To: <CO6PR18MB4098C815325699975B1BD794B01B2@CO6PR18MB4098.namprd18.prod.outlook.com>


--NS8/Unwlppg/0VLi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 29, 2024 at 02:47:23PM +0000, Witold Sadowski wrote:
> > ----------------------------------------------------------------------
> > On Wed, Apr 17, 2024 at 06:13:49PM -0700, Witold Sadowski wrote:
> > > Add new bindings for v2 Marvell xSPI overlay:
> > > mrvl,xspi-nor  compatible string
> > > New compatible string to distinguish between orginal and modified xSPI
> > > block
> > >
> > > PHY configuration registers
> > > Allow to change orginal xSPI PHY configuration values. If not set, and
> > > Marvell overlay is enabled, safe defaults will be written into xSPI
> > > PHY
> > >
> > > Optional base for xfer register set
> > > Additional reg field to allocate xSPI Marvell overlay XFER block
> > >
> > > Signed-off-by: Witold Sadowski <wsadowski@marvell.com>
> > > ---
> > >  .../devicetree/bindings/spi/cdns,xspi.yaml    | 92 +++++++++++++++++=
+-
> > >  1 file changed, 91 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> > > b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> > > index eb0f92468185..0e608245b136 100644
> > > --- a/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> > > +++ b/Documentation/devicetree/bindings/spi/cdns,xspi.yaml
> > > @@ -20,23 +20,82 @@ allOf:
> > >
> > >  properties:
> > >    compatible:
> > > -    const: cdns,xspi-nor
> > > +    oneOf:
> > > +      - description: Vanilla Cadence xSPI controller
> > > +        items:
> > > +          - const: cdns,xspi-nor
> >=20
> > The "items: isn't required here is it? Can't you just have
> >     oneOf:
> >       - description: Vanilla Cadence xSPI controller
> >         const: cdns,xspi-nor
> >       - description: Cadence xSPI controller with v2 Marvell overlay
> >         const: mrvl,xspi-nor
> > if you don't want to use an enum?
>=20
> It works without items, but I will try also with enums.
>=20
> >=20
> > > +      - description: Cadence xSPI controller with v2 Marvell overlay
> > > +        items:
> > > +          - const: mrvl,xspi-nor
> >=20
> >=20
> > "mrvl" is deprecated, please use "marvell". You're also missing a soc-
> > specific compatible here, I doubt there's only going to be one device f=
rom
> > marvell with an xspi controller ever.
>=20
> The intention is to add overlay on top of existing IP block to gain some
> More features from it. So if there will be different SoC with same xSPI
> IP, we can simply use that property, as internal SoC structure will be th=
e same.
> On the other hand, if there will be used different IP to handle SPI opera=
tions
> It should use different driver. Also, I do not expect that new version of=
 the
> Overlay will be developed to handle different IP.

I'm struggling to understand what you mean here by "overlay". Ordinarily
I'd expect someone to meant a dt-overlay, but you're talking about IP
blocks, so this sounds like hardware modifications.
I am also a bit confused by the claim that the "internal SoC structure
will be the same". Usually different SoCs have different internal
structures, even when they re-use IP cores. If they have the same internal
structure then they're not really different SoCs, just different
packages! I think what you're saying here is that you intend using the
"mrvl,xspi-nor" compatible for multiple SoCs that all contain the same
modified versions of the Cadence IP, not different packages for the same
SoC?

Confusing wording aside, using the same generic compatible for different
SoCs is what I trying to avoid. I don't mind there being a fallback
compatible that's generic, but I want to see specific compatibles here
for the individual SoCs.

If you did actually mean that only the packaging is different between
the devices, then I don't think you need specific compatibles for each
different package, but you should have one for the SoC itself IMO.

Cheers,
Conor.

--NS8/Unwlppg/0VLi
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZjASHgAKCRB4tDGHoIJi
0oBbAQC0NnLRyKZEwSK5e9IOCYKDjpAqEH62W74ppfZV2hNxXgEAtffEVFSZIFTk
1/X/2d+rKYdrMFt0jyi7ka5Aad0dogA=
=PTs9
-----END PGP SIGNATURE-----

--NS8/Unwlppg/0VLi--