Re: [PATCH net-next v8 09/11] r8152: split r8157_hw_phy_cfg into RTL8157 and RTL8159 variants

[sashiko-bot@kernel.org]

> r8157_hw_phy_cfg() served both RTL8157 (VER_16) and RTL8159
> (VER_17_QFN68/QFN100) via a tp->version switch inside a single
> function, but per the datasheet RTL8159's PHY tuning differs from
> RTL8157's in more than the per-version blocks already captured.
> 
> Split it into r8157_hw_phy_cfg() (VER_16 only) and a new
> r8159_hw_phy_cfg() (VER_17_QFN68/QFN100), each with its own copy of
> the shared prologue/epilogue. rtl_ops_init() assigns each one to its
> own chips only. Per the datasheet, RTL8159 diverges from RTL8157 in
> this split in several ways:
> 
> - RTL8159 doesn't need EEE disabled before reprogramming PHY
>   parameters, so r8159_hw_phy_cfg() drops the rtl_eee_enable(tp,
>   false) call that r8157_hw_phy_cfg() keeps.
> - Since EEE isn't forced off up front, r8159_hw_phy_cfg() ends with
> [ ... ]
> mirroring the existing sram_set_bits()/sram_clr_bits(), and use the
> named OCP_POWER_CFG/EN_10M_PLLOFF/EN_ALDPS_PLLOFF macros in place of
> the raw "ocp_reg_set_bits(tp, 0xa430, BIT(0) | BIT(1))".
> 
> Signed-off-by: Chih Kai Hsu <hsu.chih.kai@realtek.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110032416.16968-1-nic_swsd@realtek.com?part=9