Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/i915: typo in xe3plpd_lt_hdmi_10g0 PLL table causes write to register 0x0000 --
commit 42b740d6bfd04d2cc3cafcf973149a0f98931b3a Author: Suraj Kandpal <[email protected]> drm/i915/ltphy: Add PLL tables for HDMI FRL Add HDMI FRL Tables for LT PHY i.e for the rates of 3G, 6G, 8G, 10G and 12G. > diff --git a/drivers/gpu/drm/i915/display/intel_lt_phy.c > b/drivers/gpu/drm/i915/display/intel_lt_phy.c > index 86492651b01d5..61bad87eefec2 100644 > --- a/drivers/gpu/drm/i915/display/intel_lt_phy.c > +++ b/drivers/gpu/drm/i915/display/intel_lt_phy.c [ ... ] > +static const struct intel_lt_phy_pll_state xe3plpd_lt_hdmi_10g0 = { > + .config = { > + 0x1d, [Severity: High] Is this config value a typo? The progression in other FRL tables appears to increment by 8 for the top nibble (3G=0x85, 6G=0x8d, 8G=0x95, 12G=0xa5). Should this be 0x9d instead of 0x1d? > + 0x2d, > + 0x0, > + }, > + .addr_msb = { > + 0x85, > + 0x85, > + 0x85, > + 0x85, > + 0x86, > + 0x86, > + 0x86, > + 0x86, > + 0x86, > + 0x00, [Severity: High] Is 0x00 the intended value for addr_msb[9]? When combined with addr_lsb[9], this will cause the configuration data to be written to hardware register 0x0000. It looks like it might be a typo for 0x86. > + 0x86, > + 0x86, > + 0x86, > + }, > + .addr_lsb = { > + 0x10, > + 0x0c, > + 0x14, > + 0xe4, > + 0x0c, > + 0x10, > + 0x14, > + 0x18, > + 0x48, > + 0x00, [Severity: High] Could this 0x00 value for addr_lsb[9] also be a typo? This completes the invalid register address 0x0000. Writing the corresponding data payload { 0x27, 0x8, 0x0, 0x0 } to register 0x0000 could overwrite unrelated hardware state, and failing to program the intended register (likely 0x8640) might prevent successful link training for 10Gbps HDMI FRL. > + 0x4c, > + 0x24, > + 0x44, > + }, -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=19
