lists.openwall.net   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, 04 Aug 2020 15:59:50 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     olteanv@...il.com
Cc:     netdev@...r.kernel.org, andrew@...n.ch, f.fainelli@...il.com,
        vivien.didelot@...il.com
Subject: Re: [PATCH net-next] net: dsa: sja1105: use detected device id
 instead of DT one on mismatch

From: Vladimir Oltean <olteanv@...il.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@...il.com>

Andrew/Florian, do we really want to set a precedence for doing this
kind of fallback in our drivers?

Thanks.

Powered by blists - more mailing lists