summaryrefslogtreecommitdiffstats
path: root/drivers/platform/surface/surface_gpe.c
diff options
context:
space:
mode:
authorAlexis Lothoré <alexis.lothore@bootlin.com>2025-04-23 09:12:10 +0200
committerPaolo Abeni <pabeni@redhat.com>2025-04-24 11:50:20 +0200
commit7b7491372f8ec2d8c08da18e5d629e55f41dda89 (patch)
tree310a8c48347ddec0e77a3a00b59420730a532c74 /drivers/platform/surface/surface_gpe.c
parent73fa4597bdc035437fbcd84d6be32bd39f1f2149 (diff)
downloadlinux-7b7491372f8ec2d8c08da18e5d629e55f41dda89.tar.gz
linux-7b7491372f8ec2d8c08da18e5d629e55f41dda89.tar.bz2
linux-7b7491372f8ec2d8c08da18e5d629e55f41dda89.zip
net: stmmac: fix multiplication overflow when reading timestamp
The current way of reading a timestamp snapshot in stmmac can lead to integer overflow, as the computation is done on 32 bits. The issue has been observed on a dwmac-socfpga platform returning chaotic timestamp values due to this overflow. The corresponding multiplication is done with a MUL instruction, which returns 32 bit values. Explicitly casting the value to 64 bits replaced the MUL with a UMLAL, which computes and returns the result on 64 bits, and so returns correctly the timestamps. Prevent this overflow by explicitly casting the intermediate value to u64 to make sure that the whole computation is made on u64. While at it, apply the same cast on the other dwmac variant (GMAC4) method for snapshot retrieval. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423-stmmac_ts-v2-2-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'drivers/platform/surface/surface_gpe.c')
0 files changed, 0 insertions, 0 deletions