lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 4 Aug 2020 20:01:46 -0700
From:   Florian Fainelli <>
To:     David Miller <>,
Subject: Re: [PATCH net-next] net: dsa: sja1105: use detected device id
 instead of DT one on mismatch

On 8/4/2020 3:59 PM, David Miller wrote:
> From: Vladimir Oltean <>
> 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 <>
> 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

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 <>

Powered by blists - more mailing lists