Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] soc: starfive: wrong regmap stride and val_bits in
jh7110-hdmi-subsystem
--
commit 7b3e8ed6b5c2397fee05f3afbf224c172c611228
Author: Michal Wilczynski [off-list ref]
soc: starfive: Add jh7110-hdmi-subsystem driver
This commit adds a platform driver for the StarFive JH7110 HDMI subsystem
that initializes a shared MMIO regmap and populates the child HDMI PHY and
controller devices.
quoted hunk ↗ jump to hunk
diff --git a/drivers/soc/starfive/jh7110-hdmi-subsystem.c b/drivers/soc/starfive/jh7110-hdmi-subsystem.c
new file mode 100644
index 0000000000000..b01dc66450f51
--- /dev/null
+++ b/drivers/soc/starfive/jh7110-hdmi-subsystem.c
[ ... ]
quoted hunk ↗ jump to hunk
+static const struct regmap_config starfive_hdmi_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 8,
+ .max_register = 0x3fff,
+};
[Severity: Medium]
Should starfive_hdmi_regmap_config set .val_bits = 32, .reg_stride = 4, and
.max_register = 0x3ffc to match the 4-byte register layout expected by the
child drivers?
Both the HDMI controller and PHY drivers address this shared regmap at
4-byte-strided offsets (offset * 4 and reg * 4), and the controller's own
inno_hdmi_regmap_config uses 32-bit values with a 4-byte stride:
drivers/gpu/drm/bridge/inno-hdmi.c:
static const struct regmap_config inno_hdmi_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
};
static inline u8 hdmi_readb(struct inno_hdmi *hdmi, u16 offset)
{
u32 val;
if (regmap_read(hdmi->regmap, offset * 4, &val))
return 0;
return val;
}
With .val_bits = 8 and .reg_stride left at its default of 1, regmap_mmio
uses readb()/writeb() instead of 32-bit MMIO accessors, does not check
4-byte register alignment, and steps through 0x0000..0x3fff byte-by-byte in
regmap debugfs, issuing unaligned byte reads to the upper three bytes of
every 32-bit register word.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-jh7110-clean-send-v7-0-68f7ea9913db@samsung.com?part=15