Using the kernel param earlyprintk=xdbc,keep without proper hardware
setup leads to this:

	[ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
	...
	[ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host
	...
	[ ] calling  kmemleak_late_init+0x0/0xa0 @ 1
	[ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919)
	[ ] kmemleak: Automatic memory scanning thread started
	[ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs
	[ ] calling  check_early_ioremap_leak+0x0/0x70 @ 1
	[ ] ------------[ cut here ]------------
	[ ] Debug warning: early ioremap leak of 1 areas detected.
	    please boot with early_ioremap_debug and report the dmesg.
	[ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70

When early_xdbc_setup_hardware() fails, make sure to call
early_iounmap() since xdbc_init() won't handle it.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
---
 drivers/usb/early/xhci-dbc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 341408410ed93..41118bba91978 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -681,6 +681,10 @@ int __init early_xdbc_setup_hardware(void)
 
 		xdbc.table_base = NULL;
 		xdbc.out_buf = NULL;
+
+		early_iounmap(xdbc.xhci_base, xdbc.xhci_length);
+		xdbc.xhci_base = NULL;
+		xdbc.xhci_length = 0;
 	}
 
 	return ret;

On Fri, Jun 27, 2025 at 02:47:47PM -0700, Lucas De Marchi wrote:
> Using the kernel param earlyprintk=xdbc,keep without proper hardware
> setup leads to this:
> 
> 	[ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
> 	...
> 	[ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host
> 	...
> 	[ ] calling  kmemleak_late_init+0x0/0xa0 @ 1
> 	[ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919)
> 	[ ] kmemleak: Automatic memory scanning thread started
> 	[ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs
> 	[ ] calling  check_early_ioremap_leak+0x0/0x70 @ 1
> 	[ ] ------------[ cut here ]------------
> 	[ ] Debug warning: early ioremap leak of 1 areas detected.
> 	    please boot with early_ioremap_debug and report the dmesg.
> 	[ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70
> 
> When early_xdbc_setup_hardware() fails, make sure to call
> early_iounmap() since xdbc_init() won't handle it.
> 
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
>  drivers/usb/early/xhci-dbc.c | 4 ++++
>  1 file changed, 4 insertions(+)

What commit id does this fix?

thanks,

greg k-h

On Sat, Jun 28, 2025 at 04:47:17PM +0200, Greg Kroah-Hartman wrote:
>On Fri, Jun 27, 2025 at 02:47:47PM -0700, Lucas De Marchi wrote:
>> Using the kernel param earlyprintk=xdbc,keep without proper hardware
>> setup leads to this:
>>
>> 	[ ] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>> 	...
>> 	[ ] xhci_dbc:early_xdbc_setup_hardware: failed to setup the connection to host
>> 	...
>> 	[ ] calling  kmemleak_late_init+0x0/0xa0 @ 1
>> 	[ ] kmemleak: Kernel memory leak detector initialized (mem pool available: 14919)
>> 	[ ] kmemleak: Automatic memory scanning thread started
>> 	[ ] initcall kmemleak_late_init+0x0/0xa0 returned 0 after 417 usecs
>> 	[ ] calling  check_early_ioremap_leak+0x0/0x70 @ 1
>> 	[ ] ------------[ cut here ]------------
>> 	[ ] Debug warning: early ioremap leak of 1 areas detected.
>> 	    please boot with early_ioremap_debug and report the dmesg.
>> 	[ ] WARNING: CPU: 11 PID: 1 at mm/early_ioremap.c:90 check_early_ioremap_leak+0x4e/0x70
>>
>> When early_xdbc_setup_hardware() fails, make sure to call
>> early_iounmap() since xdbc_init() won't handle it.
>>
>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>>  drivers/usb/early/xhci-dbc.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>
>What commit id does this fix?

by inspection it seems this bug was always there since this was
introduced, so:

Fixes: aeb9dd1de98c ("usb/early: Add driver for xhci debug capability")
Cc: <stable@vger.kernel.org>

It didn't seem a very important fix to propagate to stable, but I just
noticed it applies cleanly on all versions back to 5.4.

thanks
Lucas De Marchi

>
>thanks,
>
>greg k-h