Re: fwnode_for_each_child_node() and OF backend discrepancy

From: Vladimir Oltean <olteanv@gmail.com>
To: Michael Walle <michael@walle.cc>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Horatiu Vultur <horatiu.vultur@microchip.com>
Subject: Re: fwnode_for_each_child_node() and OF backend discrepancy
Date: Wed, 29 Jun 2022 00:59:13 +0300	[thread overview]
Message-ID: <20220628215913.d3oicaa6qkkgpdph@skbuf> (raw)
In-Reply-To: <9e58f421c27121977d11381530757a6e@walle.cc>

On Tue, Jun 28, 2022 at 03:47:59PM +0200, Michael Walle wrote:
> Horatiu, can we determine the actual number of ports (or maybe
> determine if its a LAN9668 or a LAN9662) from the hardware itself
> in an easy way? That way we wouldn't need a new compatible string,
> but could use the generic "lan966x" one.

Never seen a lan966x switch, but if it's anything like the Ocelot-1
family, you should be able to determine the port count by reading the
out-of-reset value of any register that contains a port mask which has
all ones by default (any of the PGIDs in the multicast/flooding
destinations range, or the VLAN table port masks for any VLAN ID).

Or you can read the size of the packet buffer and infer from that which
switch model it is, based on a driver hardcoded lookup table. I fully
expect a switch with fewer ports to have smaller packet buffer. See
ocelot_detect_features() for an example of registers I am talking about.
Maybe lan966x has something similar.

Of course these are just band aids and it would still be good to modify
the device trees with the proper
	compatible = "microchip,lan9668-switch", "microchip,lan966x-switch";
rather than rely on educated guesswork (which is still guesswork, after all).