[LTP] tpci: refactor kernel module

[linuxtestproject.agent@gmail.com]

Hi Andrea,

On Thu, Aug 6, 2026, Andrea Cervesato wrote:
> tpci: refactor kernel module

--- [PATCH 2/2] ---

> +	for (int i = 0; i < PCI_TCASES_NUM; ++i) {
> +		if (i == PCI_DISABLE)
> +			continue;

Could the successful PCI_ENABLE and PCI_RESOURCES calls be balanced on all
exit paths instead of unconditionally skipping PCI_DISABLE?

In Linux 7.2, pci_enable_device() increments pci_dev.enable_cnt even when
the device is already enabled, and pci_disable_device() must be called once
for each successful enable. These two test cases therefore leak at least two
enable references per run with -d, and more with -i. Unloading the test module
does not restore that system-wide PCI state.

> +		if (!is_target && is_destructive_test(i))
> +			continue;
> +
> +		SAFE_FILE_PRINTF(DEV_TCASE, "%d", i);

Could PCI_RESOURCES guarantee that the target's original driver is rebound
before this destructive case is enabled?

test_assign_resources() releases the driver before pci_assign_resource(), but
only calls device_attach() when assignment returns zero. It also ignores a
zero or negative device_attach() result and treats -EBUSY from assignment as
TPASS. An assignment or reprobe failure can therefore leave the selected
device unbound after the test, and module cleanup does not restore it.

> Merge kernel module with the current test inside the same folder and
> refactor tpci test using new API.
>
> Now test has a -d option to select device for operating destructive
> tests on target.

Could the commit message explain why the directory merge, API conversion,
and selective destructive execution are needed? The current body only
restates what the patch changes.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer