Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] soc: starfive: unsafe 8-bit regmap MMIO accesses for 32-bit HDMI IP --
commit 0e53205c6430272fda82936e32d4dd11694a8847 Author: Michal Wilczynski <[email protected]> soc: starfive: Add jh7110-hdmi-subsystem driver This commit adds the parent driver for the monolithic JH7110 HDMI IP block. It binds to the starfive,jh7110-hdmi-subsystem node, maps the shared register block, creates a regmap, and populates child devices. > diff --git a/drivers/soc/starfive/jh7110-hdmi-subsystem.c > b/drivers/soc/starfive/jh7110-hdmi-subsystem.c > new file mode 100644 > index 0000000000000..e64a222630459 > --- /dev/null > +++ b/drivers/soc/starfive/jh7110-hdmi-subsystem.c [ ... ] > +#include <linux/module.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> > +#include <linux/platform_device.h> > +#include <linux/regmap.h> > + > +static const struct regmap_config starfive_hdmi_regmap_config = { > + .reg_bits = 32, > + .val_bits = 8, [Severity: High] Does configuring .val_bits = 8 cause the regmap-mmio backend to select 8-bit memory accessors (writeb()/readb())? On many 32-bit APB/AHB bus fabrics, issuing byte-wide memory transactions to 32-bit IP registers triggers synchronous external aborts (bus errors leading to a kernel panic) or results in partial register corruption. This can be triggered autonomously when the child drivers probe and attempt to read or write HDMI registers via the shared regmap. Since the fallback MMIO implementation in the inno-hdmi child driver uses readl_relaxed() and writel_relaxed(), it appears the IP natively expects 32-bit physical accesses. Should .val_bits = 32 be used here to guarantee regmap-mmio maps to safe 32-bit physical accessors? > + .max_register = 0x3fff, > +}; > + > +static int starfive_hdmi_subsys_probe(struct platform_device *pdev) [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=12
