Re: [PATCH] fbdev: omapfb: Fix __be32 sparse warning in panel_enabled()
From: Helge Deller <deller@gmx.de>
Date: 2026-08-22 10:23:45
Also in:
dri-devel, linux-omap, sashiko-reviews
CC'ing the linux-omap mailing list, in the hope someone with omap knowledge can judge if the sashiko AI bot is right with his analysis that acx565akm_transfer() might be wrong on big-endian systems? On 8/22/26 11:58, sashiko-bot@kernel.org wrote:
quoted hunk
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Hardcoded little-endian assumption when transmitting the command byte breaks the driver on big-endian architectures. ----- Patch [1]: [PATCH] fbdev: omapfb: Fix __be32 sparse warning in panel_enabled() ---commit a9e06be56fc1b74d7c6e76133e9ea1c25675a615 Author: Helge Deller [off-list ref] Subject: fbdev: omapfb: Fix __be32 sparse warning in panel_enabled() This commit resolves a sparse warning in panel_enabled() by explicitly reading the display status into a __be32 variable. It then converts this value to CPU endianness using __be32_to_cpu() before checking the bits. Closes: https://lore.kernel.org/oe-kbuild-all/202608211811.lps93xao-lkp@intel.com/ (local)quoted
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c index 8f430d9e80549..0202ca8cbfc23 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c@@ -210,12 +210,13 @@ static void set_display_state(struct panel_drv_data *ddata, int enabled) static int panel_enabled(struct panel_drv_data *ddata) { + __be32 disp_status_be; u32 disp_status; int enabled; acx565akm_read(ddata, MIPID_CMD_READ_DISP_STATUS, - (u8 *)&disp_status, 4);[Severity: High] This is a pre-existing issue, but while looking at endianness fixes in this file, does acx565akm_transfer() have a similar issue on big-endian architectures? When acx565akm_read() calls acx565akm_transfer(), it passes the command as an int: drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c:acx565akm_transfer() { ... cmd &= 0xff; x->tx_buf = &cmd; x->bits_per_word = 9; x->len = 2; ... } Because bits_per_word > 8, the SPI controller reads the buffer as a 16-bit integer. Taking the address of a 32-bit int on a little-endian system yields the command byte in the lowest bits. However, on big-endian systems, &cmd points to the most significant bytes (which are 0x00). Will the SPI controller end up transmitting 0x0000 instead of the requested command on big-endian architectures?quoted
- disp_status = __be32_to_cpu(disp_status); + (u8 *)&disp_status_be, 4); + disp_status = __be32_to_cpu(disp_status_be); enabled = (disp_status & (1 << 17)) && (disp_status & (1 << 10)); dev_dbg(&ddata->spi->dev, "LCD panel %senabled by bootloader (status 0x%04x)\n", enabled ? "" : "not ", disp_status);