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

[Vladimir Oltean <olteanv@gmail.com>]

On Tue, Aug 04, 2020 at 08:01:46PM -0700, Florian Fainelli wrote:
> 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.

I'll admit I'm not a huge fan either, but what you're suggesting is
basically to move the whole problem one level lower (somebody would
still have to be aware about the device id mismatch). I _was_ going to
eventually patch the U-Boot driver to adapt to the real device id too,
but only for its own use of networking. I am an even smaller fan of
having to do a fdt fixup from U-Boot, then I'd have to rely on that
always being there to do its job properly.

I've been using this board with a local fdt blob for more than one year
now, but it's inconvenient for me to have custom tftp commands for this
one board only. I hope I'm not setting for a behavior that might be
abused, tbh I don't really see how. At the end of the day though, I
don't see why the driver would have to be as punishing as to refuse to
probe when it can, warning is more than enough.

Thanks,
-Vladimir