linux-kernel - Re: [PATCH] drm/rockchip: Use dev_err

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ba9a49d5-132f-4be8-9f64-4904c91e26be@kernel.org>
Date: Thu, 22 May 2025 10:45:08 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Heiko Stübner <heiko@...ech.de>,
 long.yunjian@....com.cn, hjc@...k-chips.com
Cc: andy.yan@...k-chips.com, maarten.lankhorst@...ux.intel.com,
 mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com, simona@...ll.ch,
 dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 fang.yumeng@....com.cn, mou.yi@....com.cn, xu.lifeng1@....com.cn,
 ouyang.maochun@....com.cn
Subject: Re: [PATCH] drm/rockchip: Use dev_err_probe() to simplify code

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.yunjian@....com.cn wrote:
>>> From: Yumeng Fang <fang.yumeng@....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