Re: [PATCH net-next] net: dsa: sja1105: use detected device id instead of DT one on mismatch

From: Florian Fainelli <f.fainelli@gmail.com>
To: David Miller <davem@davemloft.net>, olteanv@gmail.com
Cc: netdev@vger.kernel.org, andrew@lunn.ch, vivien.didelot@gmail.com
Subject: Re: [PATCH net-next] net: dsa: sja1105: use detected device id instead of DT one on mismatch
Date: Tue, 4 Aug 2020 20:01:46 -0700	[thread overview]
Message-ID: <3d3de571-fcd3-7885-628a-432980d4999d@gmail.com> (raw)
In-Reply-To: <20200804.155950.60471933904505919.davem@davemloft.net>

On 8/4/2020 3:59 PM, David Miller wrote:
> From: Vladimir Oltean <olteanv@gmail.com>
> Date: Mon,  3 Aug 2020 19:48:23 +0300
> 
>> Although we can detect the chip revision 100% at runtime, it is useful
>> to specify it in the device tree compatible string too, because
>> otherwise there would be no way to assess the correctness of device tree
>> bindings statically, without booting a board (only some switch versions
>> have internal RGMII delays and/or an SGMII port).
>>
>> But for testing the P/Q/R/S support, what I have is a reworked board
>> with the SJA1105T replaced by a pin-compatible SJA1105Q, and I don't
>> want to keep a separate device tree blob just for this one-off board.
>> Since just the chip has been replaced, its RGMII delay setup is
>> inherently the same (meaning: delays added by the PHY on the slave
>> ports, and by PCB traces on the fixed-link CPU port).
>>
>> For this board, I'd rather have the driver shout at me, but go ahead and
>> use what it found even if it doesn't match what it's been told is there.
>>
>> [    2.970826] sja1105 spi0.1: Device tree specifies chip SJA1105T but found SJA1105Q, please fix it!
>> [    2.980010] sja1105 spi0.1: Probed switch chip: SJA1105Q
>> [    3.005082] sja1105 spi0.1: Enabled switch tagging
>>
>> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> 
> Andrew/Florian, do we really want to set a precedence for doing this
> kind of fallback in our drivers?

Not a big fan of it, and the justification is a little bit weak IMHO,
especially since one could argue that the boot agent providing the FDT
could do that check and present an appropriate compatible string to the
kernel.

That said, there is nothing obviously wrong about this proposal and at
the end of the day, what people care about is that the right model gets
picked up, whether that happens solely via compatibility strings or run
time detection can be left to the discretion of the driver.

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian