Re: [PATCH v2] tty: hvc: dcc: Detect JTAG connection only on CPU core 0

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] tty: hvc_dcc: commit message contradicts caching sequence implementation
--

commit 5ac910cf6c31d8b744bac3d1aa1c60fcaa2dafb2
Author: Jiannan Du <shatyuka@qq.com>

tty: hvc: dcc: Detect JTAG connection only on CPU core 0

This commit attempts to fix a potential SMP issue where the JTAG connection
check could occur on a different CPU than core 0. It simplifies the check by
caching the result from one initcall and reusing it in a later initcall.

> Multiple checks are unnecessary: nobody is going to plug/unplug JTAG
> during kernel boot and expect it to work. Cache the return value of
> hvc_dcc_check() from device_initcall and reuse the cached value during
> console_initcall. This avoids complex SMP-related code and ensures the
> result is always from core 0.

[Severity: Medium]
Does the commit message have the sequence reversed?

The commit message explicitly claims to cache the return value from
device_initcall and reuse it during console_initcall. However, the
implementation does the exact opposite.

In drivers/tty/hvc/hvc_dcc.c, hvc_dcc_console_init() (a console_initcall) calls
hvc_dcc_check() and stores the result in dcc_core0_available:

	dcc_core0_available = hvc_dcc_check();
	if (!dcc_core0_available)
		return -ENODEV;

Then, hvc_dcc_init() (a device_initcall, which runs later) reuses this cached
value without calling hvc_dcc_check() again:

	if (!dcc_core0_available)
		return -ENODEV;

The code appears correct since console_initcall runs before device_initcall,
but the commit message misrepresents the boot sequence ordering, which makes
verifying the SMP safety claims confusing.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_A0A4CA13FA8B0F7ABF62EE438764D032F205@qq.com?part=1