On 16/05/2025 11:58, Heiko Stübner wrote: > Am Donnerstag, 15. Mai 2025, 17:54:20 Mitteleuropäische Sommerzeit schrieb > Krzysztof Kozlowski: >> On 15/05/2025 14:35, long.yunj...@zte.com.cn wrote: >>> From: Yumeng Fang <fang.yum...@zte.com.cn> >>> >>> In the probe path, dev_err() can be replaced with dev_err_probe() >> >> That's not probe path. I am not sure if you really understand this code. > > I think that is somewhat debateable. > > dw_hdmi_rockchip_bind() is part of the rockchip-drm component device, > so part of its probe-path. Also I think just the presence of EPROBE_DEFER > which causes the device to re-try probing later is a nice indicator that the
No, that's not true. You can call every API like regulator_get from any context and you will get EPROBE_DEFER. This will not be a probe path. There are multiple cases of such drivers, I saw such patch even day ago. > code in question is _a_ probe path. (and usage of EPROBE_DEFER is an > established pattern to make that component device re-try probing later) > > And the parse_dt function itself is part of that path too. I quickly glanced and this was not obvious. The commit msg is poor here and does not explain that component_bind is ALWAYS probe path (unless it is clear for DRM folks). Best regards, Krzysztof
