Received-SPF: pass (google.com: domain of linux-kernel+bounces-38642-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 25 Jan 2024 13:22:57 +0000
From: Conor Dooley <conor.dooley@microchip.com>
To: Vladimir Oltean <olteanv@gmail.com>
CC: Conor Dooley <conor@kernel.org>, Philippe Schenker <dev@pschenker.ch>,
	<netdev@vger.kernel.org>, Paolo Abeni <pabeni@redhat.com>, Conor Dooley
	<conor+dt@kernel.org>, Woojung Huh <woojung.huh@microchip.com>,
	<linux-kernel@vger.kernel.org>, <UNGLinuxDriver@microchip.com>, Marek Vasut
	<marex@denx.de>, Florian Fainelli <f.fainelli@gmail.com>,
	<devicetree@vger.kernel.org>, Eric Dumazet <edumazet@google.com>, "David S .
 Miller" <davem@davemloft.net>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@linaro.org>, Jakub Kicinski <kuba@kernel.org>,
	"Andrew Lunn" <andrew@lunn.ch>, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH net-next v1 1/2] dt-bindings: net: dsa: Add KSZ8567
 switch support
Message-ID: <20240125-neurotic-bouncing-82df9cfc2fa3@wendy>
References: <20240123135014.614858-1-dev@pschenker.ch>
 <20240123-ripening-tabby-b97785375990@spud>
 <b2e232de11cee47a5932fccc2d151a9c7c276784.camel@pschenker.ch>
 <20240123-atlas-dart-7e955e7e24e5@spud>
 <979b1e77b5bb62463d52e7b9d3f9ca1415f4006a.camel@pschenker.ch>
 <20240123-carpool-avatar-c1e51ab3cc32@spud>
 <20240125095719.2nu3u3auwdcmouaw@skbuf>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="RBdbisQWjGXr+kKp"
Content-Disposition: inline
In-Reply-To: <20240125095719.2nu3u3auwdcmouaw@skbuf>

--RBdbisQWjGXr+kKp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 25, 2024 at 11:57:19AM +0200, Vladimir Oltean wrote:
> Hi Conor,
>=20
> On Tue, Jan 23, 2024 at 06:37:55PM +0000, Conor Dooley wrote:
> > On Tue, Jan 23, 2024 at 06:30:16PM +0100, Philippe Schenker wrote:
> > > > > Hi Conor, Thanks for your message!
> > > > >=20
> > > > > I need the compatible to make sure the correct ID of the switch is
> > > > > being set in the driver as well as its features.
> > > >=20
> > > > Are the features of this switch such that a driver for another ksz
> > > > switch would not work (even in a limited capacity) with the 8567?
> > > > Things like the register map changing or some feature being removed
> > > > are
> > > > examples of why it may not work.
> > >=20
> > > Yes the ksz dsa driver is made so that it checks the ID of the attach=
ed
> > > chip and refuses to work if it doesn't match. [1]
> >=20
> > That sounds counter productive to be honest. Why does the driver not
> > trust that the dt is correct? I saw this recently in some IIO drivers,
> > but it was shot down for this sort of reason.
>=20
> If the hardware provides device ID registers, what is the best practice
> in reconciling them with the compatible string?
>=20
> I see 2 extreme cases. Ethernet PHY devices seem to blindly trust the
> PHY ID from the "ethernet-phy-idXXXX.XXXX" compatible string, and phylib
> won't read the PHY ID from the standard MDIO registers when this is prese=
nt.
> Whereas PCI seems to completely disregard the vendor ID and device ID
> from the "pciXXXX,XXXX" compatible string of function OF nodes. Both
> these subsystems have the "compatible" string optional.

The software is free to do either, even if the compatible is a mandatory
property. Which is the right thing to do varies though. In your first
example, the compatible might be used because the standard MDIO
registers do not provide that function for whatever reason and therefore
cannot be read. Or there might be some shenzen market ripoff of another
device that it claims to be in its ID registers but has some
incompatible difference in the programming model.

In general though, if a device can self identify, I would be inclined to
value the self identification over that provided by the devicetree.

My comments here were because of the default in the switch statement
that rejects probe if the ID is unknown as it excludes the use of
fallback compatibles.

In this particular case, and maybe some historical reasons prevent this
that I am unaware of, I would read the ID of the device and if that is
an ID that the driver is aware of, treat that as the truth. As far as I
can tell from my quick look, the driver does this.

The first potential mismatch then is where the ID is, but does not match
what the DT claims the device is. As I said, I'd be inclined to trust
the self identification here, but I can at least understand rejection of
probe. Again from a quick look, the driver seems to trust the self
identification.

If the driver don't recognise the ID then I would treat the device as if
it is what the match data says it is, so that fallback compatibles would
work. This is the case that this driver does not allow.

> I could see an advantage in using a precise device ID in the compatible
> string, rather than just one from which the _location_ of the device ID
> can be deduced, because the precise compatible string allows for much
> finer grained static analysis in the schema for the device. In case of a
> switch, that is the number of ports, supported interface modes for each
> port, etc. With an imprecise device ID, you don't know what you really
> get until you boot the board.

That is true, I think it is pretty desirable (although admittedly I am
rather biased) to add specific compatibles for validation reasons even
if the drivers make no use of them. Generally new bindings for such
cases require a fair bit of justification, but its harder to stop the
proliferation of existing cases, without retrofitting specific
compatibles to the dts users (in addition to the generic one), and
disallowing the generic compatible in isolation.

> > And despite the email, I have nothing to do with these switches, I am
> > just a sucker that signed up to review dt-bindings...
>=20
> Same here, just a sucker with some switches and not many clues about
> other things :)

--RBdbisQWjGXr+kKp
Content-Type: application/pgp-signature; name="signature.asc"

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

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZbJgsQAKCRB4tDGHoIJi
0g40AQDGGJiI9eFtvksB9tc8NzEdF65pooUYjZujzYiwNOQE6gD/Q054FlhO3uQS
kX6APqtvzO1BU5Eu/HPGNXZEN1sazgE=
=1g+r
-----END PGP SIGNATURE-----

--RBdbisQWjGXr+kKp--