Re: [PATCH v2] serial: qcom-geni: Fix port_ida handling for console and probe errors
From: Aniket RANDIVE
Date: Mon Aug 31 2026 - 13:42:44 EST
On 8/31/2026 5:08 PM, Konrad Dybcio wrote:
On 8/31/26 1:12 PM, Aniket Randive wrote:
The console port uses a fixed line number and is not allocated from
port_ida. However, qcom_geni_serial_remove() unconditionally frees the
line number for all ports, including the console port.
Skip ida_free() for console ports so that only IDs allocated from
port_ida are returned.
Also release allocated IDs from the common probe error path. Currently,
IDs are freed only on the wake-IRQ failure path, causing leaks when
probe fails after a successful allocation. Move the ida_free() call to
the common error path and guard it for console ports.
Route resources_init() failures through the common error path so the
allocated line number is released correctly.
Allocate the port structure before calling ida_alloc_range() in
get_port_from_line(). This prevents IDs from being left allocated when
memory allocation fails.
Signed-off-by: Aniket Randive <aniket.randive@xxxxxxxxxxxxxxxx>
---
Changes in v2:
- Route port->dev_data->resources_init() failures through the common
error path so allocated line numbers are not leaked.
I asked GPT what it thinks again and this time it found that this
will cause a double calling of dev_pm_domain_detach_list(), which
will mess up the refcounting..
I think the fix here is to drop the manual detaches since the common
helper uses a devres-managed version of attach.
Thanks for catching this.
Looking closer, this appears to be a separate issue from the port_ida fixes in this patch. The dev_pm_domain_detach_list() problem already exists in the current error path and is not introduced by this change.
Since this involves power-domain cleanup rather than port_ida handling, I'd prefer to address it in a separate follow-up patch to keep this fix focused and easier to review.
Is it OK to keep this patch limited to the port_ida fixes and handle the power-domain cleanup separately?
Thanks,
Aniket
Konrad