[PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Umang Jain]

early_ioremap() checks and fail, if the memory size exceeds the fixed
boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
the correct maximum memory size is passed to early_ioremap() in the
driver.

Without this check and page size being 4K(4096), enabling xhci-dbc
on steamdeck seems to issue the warning:

steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
steamdeck kernel: ------------[ cut here ]------------
ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
steamdeck kernel: Modules linked in:
steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
steamdeck kernel: Call Trace:
steamdeck kernel:  <TASK>
steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
steamdeck kernel:  ? do_early_param+0x44/0x70
steamdeck kernel:  ? parse_args+0x233/0x420
steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
steamdeck kernel:  ? parse_early_options+0x29/0x30
steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
steamdeck kernel:  ? parse_early_param+0x64/0xc0
steamdeck kernel:  ? setup_arch+0x542/0xbc0
steamdeck kernel:  ? _printk+0x6b/0x90
steamdeck kernel:  ? start_kernel+0x66/0x9a0
steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
steamdeck kernel:  ? common_startup_64+0x13e/0x141
steamdeck kernel:  </TASK>
steamdeck kernel: ---[ end trace 0000000000000000 ]---

Signed-off-by: Umang Jain <uajain@igalia.com>
---
 drivers/usb/early/xhci-dbc.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41118bba9197..699a9ac6d6c3 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
 
 	sz64 = 1ULL << __ffs64(sz64);
 
+	/*
+	 * Check that size does not exceed fixed boot-time mappings
+	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
+	 * and not map memory in those cases.
+	 */
+	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
+		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
+
 	/* Check if the mem space is enabled: */
 	byte = read_pci_config_byte(bus, dev, func, PCI_COMMAND);
 	if (!(byte & PCI_COMMAND_MEMORY)) {
-- 
2.53.0

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Greg Kroah-Hartman]

On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
> early_ioremap() checks and fail, if the memory size exceeds the fixed
> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
> the correct maximum memory size is passed to early_ioremap() in the
> driver.
> 
> Without this check and page size being 4K(4096), enabling xhci-dbc
> on steamdeck seems to issue the warning:
> 
> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
> steamdeck kernel: ------------[ cut here ]------------
> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
> steamdeck kernel: Modules linked in:
> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
> steamdeck kernel: Call Trace:
> steamdeck kernel:  <TASK>
> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
> steamdeck kernel:  ? do_early_param+0x44/0x70
> steamdeck kernel:  ? parse_args+0x233/0x420
> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
> steamdeck kernel:  ? parse_early_options+0x29/0x30
> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
> steamdeck kernel:  ? parse_early_param+0x64/0xc0
> steamdeck kernel:  ? setup_arch+0x542/0xbc0
> steamdeck kernel:  ? _printk+0x6b/0x90
> steamdeck kernel:  ? start_kernel+0x66/0x9a0
> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
> steamdeck kernel:  ? common_startup_64+0x13e/0x141
> steamdeck kernel:  </TASK>
> steamdeck kernel: ---[ end trace 0000000000000000 ]---
> 
> Signed-off-by: Umang Jain <uajain@igalia.com>
> ---
>  drivers/usb/early/xhci-dbc.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
> index 41118bba9197..699a9ac6d6c3 100644
> --- a/drivers/usb/early/xhci-dbc.c
> +++ b/drivers/usb/early/xhci-dbc.c
> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>  
>  	sz64 = 1ULL << __ffs64(sz64);
>  
> +	/*
> +	 * Check that size does not exceed fixed boot-time mappings
> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
> +	 * and not map memory in those cases.
> +	 */
> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;

You are bounding the size here, but does this mean that the hardware
itself is just broken and should be fixed up to properly report the
correct size?  Does this hardware actually have a debug controller?

And what changed to cause this to start complaining?  Does it fix a
specific commit?  This hardware has been around for a long time, did we
mess something up in the kernel for it recently?

thanks,

greg k-h

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Umang Jain]

Hi Greg,

On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>> early_ioremap() checks and fail, if the memory size exceeds the fixed
>> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>> the correct maximum memory size is passed to early_ioremap() in the
>> driver.
>> 
>> Without this check and page size being 4K(4096), enabling xhci-dbc
>> on steamdeck seems to issue the warning:
>> 
>> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>> steamdeck kernel: ------------[ cut here ]------------
>> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>> steamdeck kernel: Modules linked in:
>> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>> steamdeck kernel: Call Trace:
>> steamdeck kernel:  <TASK>
>> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>> steamdeck kernel:  ? do_early_param+0x44/0x70
>> steamdeck kernel:  ? parse_args+0x233/0x420
>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>> steamdeck kernel:  ? parse_early_options+0x29/0x30
>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>> steamdeck kernel:  ? _printk+0x6b/0x90
>> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>> steamdeck kernel:  </TASK>
>> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>> 
>> Signed-off-by: Umang Jain <uajain@igalia.com>
>> ---
>>  drivers/usb/early/xhci-dbc.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index 41118bba9197..699a9ac6d6c3 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>>  
>>  	sz64 = 1ULL << __ffs64(sz64);
>>  
>> +	/*
>> +	 * Check that size does not exceed fixed boot-time mappings
>> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>> +	 * and not map memory in those cases.
>> +	 */
>> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
> 
> You are bounding the size here, but does this mean that the hardware
> itself is just broken and should be fixed up to properly report the
> correct size?  Does this hardware actually have a debug controller?

Hmm, to answer your first question as far as I have read, the size is
inferred from PCI config with base address. My understanding here is
that
for early xhci debugging - the page mappings are fixed, so we need to
bound the size for early_ioremap().

The second answer is, yes the hardware has debug controller. We can
configure it after boot
and it works with USB3.1 Superspeed cable with host:

(on target)
(A+)(root@steamdeck ~)# echo enable  >
/sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
(A+)(root@steamdeck ~)# dmesg | grep DbC
[  366.276124] xhci_hcd 0000:04:00.3: DbC connected
[  366.637223] xhci_hcd 0000:04:00.3: DbC configured

(on host)
[114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
xhci_hcd
[114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
idProduct=0010, bcdDevice= 0.10
[114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[114288.662945] usb 4-2: Product: Linux USB Debug Target
[114288.662953] usb 4-2: Manufacturer: Linux Foundation
[114288.662960] usb 4-2: SerialNumber: 0001
[114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
[114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
 

> 
> And what changed to cause this to start complaining?  Does it fix a
> specific commit?  This hardware has been around for a long time, did we
> mess something up in the kernel for it recently?

This fix/patch is only for early xdbc. As mentioned above, it can be
used/configured after boot.
So yes, the hardware has been around but I don't think that early xdbc
capability was investigated at any point in time. I don't see recents
commits early xhci as well so maybe it was hidden all this time.

Thanks,
Umang

> 
> thanks,
> 
> greg k-h

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Greg Kroah-Hartman]

On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
> Hi Greg,
> 
> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
> > On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
> >> early_ioremap() checks and fail, if the memory size exceeds the fixed
> >> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
> >> the correct maximum memory size is passed to early_ioremap() in the
> >> driver.
> >> 
> >> Without this check and page size being 4K(4096), enabling xhci-dbc
> >> on steamdeck seems to issue the warning:
> >> 
> >> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
> >> steamdeck kernel: ------------[ cut here ]------------
> >> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
> >> steamdeck kernel: Modules linked in:
> >> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
> >> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
> >> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
> >> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
> >> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
> >> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
> >> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
> >> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
> >> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
> >> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
> >> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
> >> steamdeck kernel: Call Trace:
> >> steamdeck kernel:  <TASK>
> >> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
> >> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
> >> steamdeck kernel:  ? do_early_param+0x44/0x70
> >> steamdeck kernel:  ? parse_args+0x233/0x420
> >> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
> >> steamdeck kernel:  ? parse_early_options+0x29/0x30
> >> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
> >> steamdeck kernel:  ? parse_early_param+0x64/0xc0
> >> steamdeck kernel:  ? setup_arch+0x542/0xbc0
> >> steamdeck kernel:  ? _printk+0x6b/0x90
> >> steamdeck kernel:  ? start_kernel+0x66/0x9a0
> >> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
> >> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
> >> steamdeck kernel:  ? common_startup_64+0x13e/0x141
> >> steamdeck kernel:  </TASK>
> >> steamdeck kernel: ---[ end trace 0000000000000000 ]---
> >> 
> >> Signed-off-by: Umang Jain <uajain@igalia.com>
> >> ---
> >>  drivers/usb/early/xhci-dbc.c | 8 ++++++++
> >>  1 file changed, 8 insertions(+)
> >> 
> >> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
> >> index 41118bba9197..699a9ac6d6c3 100644
> >> --- a/drivers/usb/early/xhci-dbc.c
> >> +++ b/drivers/usb/early/xhci-dbc.c
> >> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
> >>  
> >>  	sz64 = 1ULL << __ffs64(sz64);
> >>  
> >> +	/*
> >> +	 * Check that size does not exceed fixed boot-time mappings
> >> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
> >> +	 * and not map memory in those cases.
> >> +	 */
> >> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
> >> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
> > 
> > You are bounding the size here, but does this mean that the hardware
> > itself is just broken and should be fixed up to properly report the
> > correct size?  Does this hardware actually have a debug controller?
> 
> Hmm, to answer your first question as far as I have read, the size is
> inferred from PCI config with base address. My understanding here is
> that
> for early xhci debugging - the page mappings are fixed, so we need to
> bound the size for early_ioremap().

So the device is providing the wrong size here?  Why is this an issue
only for this hardware and not other hardware?

> The second answer is, yes the hardware has debug controller. We can
> configure it after boot
> and it works with USB3.1 Superspeed cable with host:
> 
> (on target)
> (A+)(root@steamdeck ~)# echo enable  >
> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
> (A+)(root@steamdeck ~)# dmesg | grep DbC
> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
> 
> (on host)
> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
> xhci_hcd
> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
> idProduct=0010, bcdDevice= 0.10
> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [114288.662945] usb 4-2: Product: Linux USB Debug Target
> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
> [114288.662960] usb 4-2: SerialNumber: 0001
> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>  
> 
> > 
> > And what changed to cause this to start complaining?  Does it fix a
> > specific commit?  This hardware has been around for a long time, did we
> > mess something up in the kernel for it recently?
> 
> This fix/patch is only for early xdbc. As mentioned above, it can be
> used/configured after boot.
> So yes, the hardware has been around but I don't think that early xdbc
> capability was investigated at any point in time. I don't see recents
> commits early xhci as well so maybe it was hidden all this time.

Ok, but it is good to figure out what is "wrong" here that this hardware
is causing this warning to happen, yet other hardware does not.  Either
the kernel has always been wrong (totally a possibility), or this
hardware is reporting invalid ranges.  Figuring out which is true would
be good to figure out here.

thanks,

greg k-h

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Umang Jain]

On 2026-05-20 12:42, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
>> Hi Greg,
>> 
>> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
>> > On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>> >> early_ioremap() checks and fail, if the memory size exceeds the fixed
>> >> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>> >> the correct maximum memory size is passed to early_ioremap() in the
>> >> driver.
>> >> 
>> >> Without this check and page size being 4K(4096), enabling xhci-dbc
>> >> on steamdeck seems to issue the warning:
>> >> 
>> >> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>> >> steamdeck kernel: ------------[ cut here ]------------
>> >> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>> >> steamdeck kernel: Modules linked in:
>> >> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>> >> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>> >> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>> >> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>> >> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>> >> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>> >> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>> >> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>> >> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>> >> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>> >> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> >> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>> >> steamdeck kernel: Call Trace:
>> >> steamdeck kernel:  <TASK>
>> >> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>> >> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>> >> steamdeck kernel:  ? do_early_param+0x44/0x70
>> >> steamdeck kernel:  ? parse_args+0x233/0x420
>> >> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>> >> steamdeck kernel:  ? parse_early_options+0x29/0x30
>> >> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>> >> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>> >> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>> >> steamdeck kernel:  ? _printk+0x6b/0x90
>> >> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>> >> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>> >> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>> >> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>> >> steamdeck kernel:  </TASK>
>> >> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>> >> 
>> >> Signed-off-by: Umang Jain <uajain@igalia.com>
>> >> ---
>> >>  drivers/usb/early/xhci-dbc.c | 8 ++++++++
>> >>  1 file changed, 8 insertions(+)
>> >> 
>> >> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> >> index 41118bba9197..699a9ac6d6c3 100644
>> >> --- a/drivers/usb/early/xhci-dbc.c
>> >> +++ b/drivers/usb/early/xhci-dbc.c
>> >> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>> >>  
>> >>  	sz64 = 1ULL << __ffs64(sz64);
>> >>  
>> >> +	/*
>> >> +	 * Check that size does not exceed fixed boot-time mappings
>> >> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>> >> +	 * and not map memory in those cases.
>> >> +	 */
>> >> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>> >> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
>> > 
>> > You are bounding the size here, but does this mean that the hardware
>> > itself is just broken and should be fixed up to properly report the
>> > correct size?  Does this hardware actually have a debug controller?
>> 
>> Hmm, to answer your first question as far as I have read, the size is
>> inferred from PCI config with base address. My understanding here is
>> that
>> for early xhci debugging - the page mappings are fixed, so we need to
>> bound the size for early_ioremap().
> 
> So the device is providing the wrong size here?  Why is this an issue
> only for this hardware and not other hardware?
> 
>> The second answer is, yes the hardware has debug controller. We can
>> configure it after boot
>> and it works with USB3.1 Superspeed cable with host:
>> 
>> (on target)
>> (A+)(root@steamdeck ~)# echo enable  >
>> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
>> (A+)(root@steamdeck ~)# dmesg | grep DbC
>> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
>> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
>> 
>> (on host)
>> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
>> xhci_hcd
>> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
>> idProduct=0010, bcdDevice= 0.10
>> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>> [114288.662945] usb 4-2: Product: Linux USB Debug Target
>> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
>> [114288.662960] usb 4-2: SerialNumber: 0001
>> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
>> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>>  
>> 
>> > 
>> > And what changed to cause this to start complaining?  Does it fix a
>> > specific commit?  This hardware has been around for a long time, did we
>> > mess something up in the kernel for it recently?
>> 
>> This fix/patch is only for early xdbc. As mentioned above, it can be
>> used/configured after boot.
>> So yes, the hardware has been around but I don't think that early xdbc
>> capability was investigated at any point in time. I don't see recents
>> commits early xhci as well so maybe it was hidden all this time.
> 
> Ok, but it is good to figure out what is "wrong" here that this hardware
> is causing this warning to happen, yet other hardware does not.  Either
> the kernel has always been wrong (totally a possibility), or this
> hardware is reporting invalid ranges.  Figuring out which is true would
> be good to figure out here.

Oh yes definitely.

I, although don't have any order hardware so I will look around. I
haven't investigated the ranges yet, so I will investigate that too. My
logic initially was that it's the "early boot" that is forcing a
pages/size capping so we need to fit there. 
From __early_ioremap() in mm/early_ioremap.c

...
	/*
	 * Mappings have to fit in the FIX_BTMAP area.
	 */
	nrpages = size >> PAGE_SHIFT;
	if (WARN_ON(nrpages > NR_FIX_BTMAPS))
		return NULL;

...


> 
> thanks,
> 
> greg k-h

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Mathias Nyman]

On 20/05/2026 15.54, Umang Jain wrote:
> On 2026-05-20 12:42, Greg Kroah-Hartman wrote:
>> On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
>>> Hi Greg,
>>>
>>> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
>>>> On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>>>>> early_ioremap() checks and fail, if the memory size exceeds the fixed
>>>>> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>>>>> the correct maximum memory size is passed to early_ioremap() in the
>>>>> driver.
>>>>>
>>>>> Without this check and page size being 4K(4096), enabling xhci-dbc
>>>>> on steamdeck seems to issue the warning:
>>>>>
>>>>> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>>>>> steamdeck kernel: ------------[ cut here ]------------
>>>>> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>>>>> steamdeck kernel: Modules linked in:
>>>>> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>>>>> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>>>>> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>>>>> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>>>>> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>>>>> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>>>>> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>>>>> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>>>>> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>>>>> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>>>>> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>>>>> steamdeck kernel: Call Trace:
>>>>> steamdeck kernel:  <TASK>
>>>>> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>>>>> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>>>>> steamdeck kernel:  ? do_early_param+0x44/0x70
>>>>> steamdeck kernel:  ? parse_args+0x233/0x420
>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>> steamdeck kernel:  ? parse_early_options+0x29/0x30
>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>>>>> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>>>>> steamdeck kernel:  ? _printk+0x6b/0x90
>>>>> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>>>>> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>>>>> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>>>>> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>>>>> steamdeck kernel:  </TASK>
>>>>> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>>>>>
>>>>> Signed-off-by: Umang Jain <uajain@igalia.com>
>>>>> ---
>>>>>   drivers/usb/early/xhci-dbc.c | 8 ++++++++
>>>>>   1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>>>>> index 41118bba9197..699a9ac6d6c3 100644
>>>>> --- a/drivers/usb/early/xhci-dbc.c
>>>>> +++ b/drivers/usb/early/xhci-dbc.c
>>>>> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>>>>>   
>>>>>   	sz64 = 1ULL << __ffs64(sz64);
>>>>>   
>>>>> +	/*
>>>>> +	 * Check that size does not exceed fixed boot-time mappings
>>>>> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>>>>> +	 * and not map memory in those cases.
>>>>> +	 */
>>>>> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>>>>> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
>>>>
>>>> You are bounding the size here, but does this mean that the hardware
>>>> itself is just broken and should be fixed up to properly report the
>>>> correct size?  Does this hardware actually have a debug controller?
>>>
>>> Hmm, to answer your first question as far as I have read, the size is
>>> inferred from PCI config with base address. My understanding here is
>>> that
>>> for early xhci debugging - the page mappings are fixed, so we need to
>>> bound the size for early_ioremap().
>>
>> So the device is providing the wrong size here?  Why is this an issue
>> only for this hardware and not other hardware?
>>
>>> The second answer is, yes the hardware has debug controller. We can
>>> configure it after boot
>>> and it works with USB3.1 Superspeed cable with host:
>>>
>>> (on target)
>>> (A+)(root@steamdeck ~)# echo enable  >
>>> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
>>> (A+)(root@steamdeck ~)# dmesg | grep DbC
>>> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
>>> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
>>>
>>> (on host)
>>> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
>>> xhci_hcd
>>> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
>>> idProduct=0010, bcdDevice= 0.10
>>> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [114288.662945] usb 4-2: Product: Linux USB Debug Target
>>> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
>>> [114288.662960] usb 4-2: SerialNumber: 0001
>>> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
>>> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>>>   
>>>
>>>>
>>>> And what changed to cause this to start complaining?  Does it fix a
>>>> specific commit?  This hardware has been around for a long time, did we
>>>> mess something up in the kernel for it recently?
>>>
>>> This fix/patch is only for early xdbc. As mentioned above, it can be
>>> used/configured after boot.
>>> So yes, the hardware has been around but I don't think that early xdbc
>>> capability was investigated at any point in time. I don't see recents
>>> commits early xhci as well so maybe it was hidden all this time.
>>
>> Ok, but it is good to figure out what is "wrong" here that this hardware
>> is causing this warning to happen, yet other hardware does not.  Either
>> the kernel has always been wrong (totally a possibility), or this
>> hardware is reporting invalid ranges.  Figuring out which is true would
>> be good to figure out here.
> 
> Oh yes definitely.
> 
> I, although don't have any order hardware so I will look around. I
> haven't investigated the ranges yet, so I will investigate that too. My
> logic initially was that it's the "early boot" that is forcing a
> pages/size capping so we need to fit there.
>  From __early_ioremap() in mm/early_ioremap.c
> 
> ...
> 	/*
> 	 * Mappings have to fit in the FIX_BTMAP area.
> 	 */
> 	nrpages = size >> PAGE_SHIFT;
> 	if (WARN_ON(nrpages > NR_FIX_BTMAPS))
> 		return NULL;
> 
> ...
> 

Sometimes a xHC controller report a larger size than early ioremap supports.
This is because xHC from different vendors supports different extended
capabilities, both standard ones like DbC and vendor specific ones, all at 
vendor chosen offsets.

To find offset of a extended capability we need to walk the extended 
capability list. If we limit the size here in software then we need to very 
carefully walk the capability list, making sure we don't go over that limit.

There was some debugging done here in this thread

https://lore.kernel.org/linux-usb/4e6d9b62-b9d0-4a05-99a9-143899547664@linux.intel.com/

Thanks
Mathias

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Umang Jain]

Hi Mathias,

Thanks for the reply.

On 2026-05-25 21:01, Mathias Nyman wrote:
> On 20/05/2026 15.54, Umang Jain wrote:
>> On 2026-05-20 12:42, Greg Kroah-Hartman wrote:
>>> On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
>>>> Hi Greg,
>>>>
>>>> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
>>>>> On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>>>>>> early_ioremap() checks and fail, if the memory size exceeds the fixed
>>>>>> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>>>>>> the correct maximum memory size is passed to early_ioremap() in the
>>>>>> driver.
>>>>>>
>>>>>> Without this check and page size being 4K(4096), enabling xhci-dbc
>>>>>> on steamdeck seems to issue the warning:
>>>>>>
>>>>>> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>>>>>> steamdeck kernel: ------------[ cut here ]------------
>>>>>> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>>>>>> steamdeck kernel: Modules linked in:
>>>>>> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>>>>>> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>>>>>> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>>>>>> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>>>>>> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>>>>>> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>>>>>> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>>>>>> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>>>>>> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>>>>>> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>>>>>> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>>>>>> steamdeck kernel: Call Trace:
>>>>>> steamdeck kernel:  <TASK>
>>>>>> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>>>>>> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>>>>>> steamdeck kernel:  ? do_early_param+0x44/0x70
>>>>>> steamdeck kernel:  ? parse_args+0x233/0x420
>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>> steamdeck kernel:  ? parse_early_options+0x29/0x30
>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>>>>>> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>>>>>> steamdeck kernel:  ? _printk+0x6b/0x90
>>>>>> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>>>>>> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>>>>>> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>>>>>> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>>>>>> steamdeck kernel:  </TASK>
>>>>>> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>>>>>>
>>>>>> Signed-off-by: Umang Jain <uajain@igalia.com>
>>>>>> ---
>>>>>>   drivers/usb/early/xhci-dbc.c | 8 ++++++++
>>>>>>   1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>>>>>> index 41118bba9197..699a9ac6d6c3 100644
>>>>>> --- a/drivers/usb/early/xhci-dbc.c
>>>>>> +++ b/drivers/usb/early/xhci-dbc.c
>>>>>> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>>>>>>     	sz64 = 1ULL << __ffs64(sz64);
>>>>>>   +	/*
>>>>>> +	 * Check that size does not exceed fixed boot-time mappings
>>>>>> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>>>>>> +	 * and not map memory in those cases.
>>>>>> +	 */
>>>>>> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>>>>>> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
>>>>>
>>>>> You are bounding the size here, but does this mean that the hardware
>>>>> itself is just broken and should be fixed up to properly report the
>>>>> correct size?  Does this hardware actually have a debug controller?
>>>>
>>>> Hmm, to answer your first question as far as I have read, the size is
>>>> inferred from PCI config with base address. My understanding here is
>>>> that
>>>> for early xhci debugging - the page mappings are fixed, so we need to
>>>> bound the size for early_ioremap().
>>>
>>> So the device is providing the wrong size here?  Why is this an issue
>>> only for this hardware and not other hardware?
>>>
>>>> The second answer is, yes the hardware has debug controller. We can
>>>> configure it after boot
>>>> and it works with USB3.1 Superspeed cable with host:
>>>>
>>>> (on target)
>>>> (A+)(root@steamdeck ~)# echo enable  >
>>>> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
>>>> (A+)(root@steamdeck ~)# dmesg | grep DbC
>>>> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
>>>> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
>>>>
>>>> (on host)
>>>> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
>>>> xhci_hcd
>>>> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
>>>> idProduct=0010, bcdDevice= 0.10
>>>> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>> [114288.662945] usb 4-2: Product: Linux USB Debug Target
>>>> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
>>>> [114288.662960] usb 4-2: SerialNumber: 0001
>>>> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
>>>> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>>>>   
>>>>>
>>>>> And what changed to cause this to start complaining?  Does it fix a
>>>>> specific commit?  This hardware has been around for a long time, did we
>>>>> mess something up in the kernel for it recently?
>>>>
>>>> This fix/patch is only for early xdbc. As mentioned above, it can be
>>>> used/configured after boot.
>>>> So yes, the hardware has been around but I don't think that early xdbc
>>>> capability was investigated at any point in time. I don't see recents
>>>> commits early xhci as well so maybe it was hidden all this time.
>>>
>>> Ok, but it is good to figure out what is "wrong" here that this hardware
>>> is causing this warning to happen, yet other hardware does not.  Either
>>> the kernel has always been wrong (totally a possibility), or this
>>> hardware is reporting invalid ranges.  Figuring out which is true would
>>> be good to figure out here.
>> 
>> Oh yes definitely.
>> 
>> I, although don't have any order hardware so I will look around. I
>> haven't investigated the ranges yet, so I will investigate that too. My
>> logic initially was that it's the "early boot" that is forcing a
>> pages/size capping so we need to fit there.
>>  From __early_ioremap() in mm/early_ioremap.c
>> 
>> ...
>> 	/*
>> 	 * Mappings have to fit in the FIX_BTMAP area.
>> 	 */
>> 	nrpages = size >> PAGE_SHIFT;
>> 	if (WARN_ON(nrpages > NR_FIX_BTMAPS))
>> 		return NULL;
>> 
>> ...
>> 
> 
> Sometimes a xHC controller report a larger size than early ioremap supports.
> This is because xHC from different vendors supports different extended
> capabilities, both standard ones like DbC and vendor specific ones, all at vendor chosen offsets.
> 

That's a very useful information and I didn't really realise that there
are vendor specific DbC information that could be read out for
early-xhci dbg capability.

The size reported for 2 controllers are : 1MB (See output of in the end)

> To find offset of a extended capability we need to walk the extended capability list. If we limit the size here in software then we need to very carefully walk the capability list, making sure we don't go over that limit.

True. However, I am wondering how would be go about mapping all the
extended capability list for early dbc? Or should we do it even (stick
to the standard dbc and skip the vendor specific ones) because
early_ioremap() is already fixed to 512 boot-time mappings. Do you have
any opinion on this problem?

```
(1)(A+)(root@steamdeck ~)# lspci -vv -d ::0c03:30
04:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] VanGogh USB2
(prog-if 30 [XHCI])
	Subsystem: Valve Software Device 1776
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 31
	Region 0: Memory at 80200000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [64] Express (v2) Endpoint, IntMsgNum 0
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W
TEE-IO-
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s
<64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
		LnkCtl:	ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 8GT/s, Width x16
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR-
			 10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+,
MaxEETLPPrefixes 1
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS- TPHComp- ExtTPHComp-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
			 AtomicOpsCtl: ReqEn-
			 IDOReq- IDOCompl- LTR- EmergencyPowerReductionReq-
			 10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-
EqualizationPhase1-
			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
			 Retimer- 2Retimers- CrosslinkRes: unsupported
	Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
		Vector table: BAR=0 offset=000fe000
		PBA: BAR=0 offset=000ff000
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

04:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] VanGogh USB1
(prog-if 30 [XHCI])
	Subsystem: Valve Software Device 1776
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 40
	Region 0: Memory at 80300000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [64] Express (v2) Endpoint, IntMsgNum 0
		DevCap:	MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1
unlimited
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W
TEE-IO-
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 512 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s
<64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
		LnkCtl:	ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 8GT/s, Width x16
			TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR-
			 10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+,
MaxEETLPPrefixes 1
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS- TPHComp- ExtTPHComp-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
			 AtomicOpsCtl: ReqEn-
			 IDOReq- IDOCompl- LTR- EmergencyPowerReductionReq-
			 10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
		LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-
EqualizationPhase1-
			 EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
			 Retimer- 2Retimers- CrosslinkRes: unsupported
	Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
		Vector table: BAR=0 offset=000fe000
		PBA: BAR=0 offset=000ff000
	Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1
Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

```

> 
> There was some debugging done here in this thread
> 
> https://lore.kernel.org/linux-usb/4e6d9b62-b9d0-4a05-99a9-143899547664@linux.intel.com/
> 
> Thanks
> Mathias

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Umang Jain]

Hi,

Followup question on this:

On 2026-05-25 21:01, Mathias Nyman wrote:
> On 20/05/2026 15.54, Umang Jain wrote:
>> On 2026-05-20 12:42, Greg Kroah-Hartman wrote:
>>> On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
>>>> Hi Greg,
>>>>
>>>> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
>>>>> On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>>>>>> early_ioremap() checks and fail, if the memory size exceeds the fixed
>>>>>> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>>>>>> the correct maximum memory size is passed to early_ioremap() in the
>>>>>> driver.
>>>>>>
>>>>>> Without this check and page size being 4K(4096), enabling xhci-dbc
>>>>>> on steamdeck seems to issue the warning:
>>>>>>
>>>>>> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>>>>>> steamdeck kernel: ------------[ cut here ]------------
>>>>>> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>>>>>> steamdeck kernel: Modules linked in:
>>>>>> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>>>>>> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>>>>>> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>>>>>> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>>>>>> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>>>>>> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>>>>>> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>>>>>> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>>>>>> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>>>>>> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>>>>>> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>>>>>> steamdeck kernel: Call Trace:
>>>>>> steamdeck kernel:  <TASK>
>>>>>> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>>>>>> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>>>>>> steamdeck kernel:  ? do_early_param+0x44/0x70
>>>>>> steamdeck kernel:  ? parse_args+0x233/0x420
>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>> steamdeck kernel:  ? parse_early_options+0x29/0x30
>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>>>>>> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>>>>>> steamdeck kernel:  ? _printk+0x6b/0x90
>>>>>> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>>>>>> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>>>>>> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>>>>>> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>>>>>> steamdeck kernel:  </TASK>
>>>>>> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>>>>>>
>>>>>> Signed-off-by: Umang Jain <uajain@igalia.com>
>>>>>> ---
>>>>>>   drivers/usb/early/xhci-dbc.c | 8 ++++++++
>>>>>>   1 file changed, 8 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>>>>>> index 41118bba9197..699a9ac6d6c3 100644
>>>>>> --- a/drivers/usb/early/xhci-dbc.c
>>>>>> +++ b/drivers/usb/early/xhci-dbc.c
>>>>>> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>>>>>>     	sz64 = 1ULL << __ffs64(sz64);
>>>>>>   +	/*
>>>>>> +	 * Check that size does not exceed fixed boot-time mappings
>>>>>> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>>>>>> +	 * and not map memory in those cases.
>>>>>> +	 */
>>>>>> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>>>>>> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
>>>>>
>>>>> You are bounding the size here, but does this mean that the hardware
>>>>> itself is just broken and should be fixed up to properly report the
>>>>> correct size?  Does this hardware actually have a debug controller?
>>>>
>>>> Hmm, to answer your first question as far as I have read, the size is
>>>> inferred from PCI config with base address. My understanding here is
>>>> that
>>>> for early xhci debugging - the page mappings are fixed, so we need to
>>>> bound the size for early_ioremap().
>>>
>>> So the device is providing the wrong size here?  Why is this an issue
>>> only for this hardware and not other hardware?
>>>
>>>> The second answer is, yes the hardware has debug controller. We can
>>>> configure it after boot
>>>> and it works with USB3.1 Superspeed cable with host:
>>>>
>>>> (on target)
>>>> (A+)(root@steamdeck ~)# echo enable  >
>>>> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
>>>> (A+)(root@steamdeck ~)# dmesg | grep DbC
>>>> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
>>>> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
>>>>
>>>> (on host)
>>>> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
>>>> xhci_hcd
>>>> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
>>>> idProduct=0010, bcdDevice= 0.10
>>>> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>> [114288.662945] usb 4-2: Product: Linux USB Debug Target
>>>> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
>>>> [114288.662960] usb 4-2: SerialNumber: 0001
>>>> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
>>>> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>>>>   
>>>>>
>>>>> And what changed to cause this to start complaining?  Does it fix a
>>>>> specific commit?  This hardware has been around for a long time, did we
>>>>> mess something up in the kernel for it recently?
>>>>
>>>> This fix/patch is only for early xdbc. As mentioned above, it can be
>>>> used/configured after boot.
>>>> So yes, the hardware has been around but I don't think that early xdbc
>>>> capability was investigated at any point in time. I don't see recents
>>>> commits early xhci as well so maybe it was hidden all this time.
>>>
>>> Ok, but it is good to figure out what is "wrong" here that this hardware
>>> is causing this warning to happen, yet other hardware does not.  Either
>>> the kernel has always been wrong (totally a possibility), or this
>>> hardware is reporting invalid ranges.  Figuring out which is true would
>>> be good to figure out here.
>> 
>> Oh yes definitely.
>> 
>> I, although don't have any order hardware so I will look around. I
>> haven't investigated the ranges yet, so I will investigate that too. My
>> logic initially was that it's the "early boot" that is forcing a
>> pages/size capping so we need to fit there.
>>  From __early_ioremap() in mm/early_ioremap.c
>> 
>> ...
>> 	/*
>> 	 * Mappings have to fit in the FIX_BTMAP area.
>> 	 */
>> 	nrpages = size >> PAGE_SHIFT;
>> 	if (WARN_ON(nrpages > NR_FIX_BTMAPS))
>> 		return NULL;
>> 
>> ...
>> 
> 
> Sometimes a xHC controller report a larger size than early ioremap supports.
> This is because xHC from different vendors supports different extended
> capabilities, both standard ones like DbC and vendor specific ones, all at vendor chosen offsets.
> 
> To find offset of a extended capability we need to walk the extended capability list. If we limit the size here in software then we need to very carefully walk the capability list, making sure we don't go over that limit.

The offset part is fine, but if I am reading the spec correctly [1] the
dbc information size is just the "56 bytes" ?

Should we only map 56 bytes in early_ioremap() ? After finding the
offset?

[1]: Table 7-2 xHCI Extended Capability Codes (Page 517)
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf



> 
> There was some debugging done here in this thread
> 
> https://lore.kernel.org/linux-usb/4e6d9b62-b9d0-4a05-99a9-143899547664@linux.intel.com/
> 
> Thanks
> Mathias

Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()

[Mathias Nyman]

On 5/27/26 16:22, Umang Jain wrote:
> Hi Mathias,
> 
> Thanks for the reply.
> 
> On 2026-05-25 21:01, Mathias Nyman wrote:
>> On 20/05/2026 15.54, Umang Jain wrote:
>>> On 2026-05-20 12:42, Greg Kroah-Hartman wrote:
>>>> On Wed, May 20, 2026 at 12:27:39PM +0000, Umang Jain wrote:
>>>>> Hi Greg,
>>>>>
>>>>> On 2026-05-20 11:22, Greg Kroah-Hartman wrote:
>>>>>> On Wed, May 20, 2026 at 03:18:04PM +0530, Umang Jain wrote:
>>>>>>> early_ioremap() checks and fail, if the memory size exceeds the fixed
>>>>>>> boot-time mappings (dictated by NR_FIX_BTMAPS macro). We should ensure
>>>>>>> the correct maximum memory size is passed to early_ioremap() in the
>>>>>>> driver.
>>>>>>>
>>>>>>> Without this check and page size being 4K(4096), enabling xhci-dbc
>>>>>>> on steamdeck seems to issue the warning:
>>>>>>>
>>>>>>> steamdeck kernel: xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 0
>>>>>>> steamdeck kernel: ------------[ cut here ]------------
>>>>>>> ay 19 13:42:57 steamdeck kernel: WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xae/0x180
>>>>>>> steamdeck kernel: Modules linked in:
>>>>>>> steamdeck kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.18.25-valve1-gcab630e7af50 #13 PREEMPT(undef)  4b70872d9de6788b7f2d10dce46ada89e6cd177b
>>>>>>> steamdeck kernel: RIP: 0010:__early_ioremap+0xae/0x180
>>>>>>> steamdeck kernel: Code: 60 ba 3f a0 4c 89 ca 48 81 e3 00 f0 ff ff 48 81 e2 00 f0 ff ff 48 29 d3 48 89 14 24 48 89 da 48 c1 ea 0c 89 d5 83 fa 40 76 04 <0f> 0b eb a2 6b c0 c0 4d 89 ce 41 81 e6 ff 0f 00 00 44 8d b8 ff 05
>>>>>>> steamdeck kernel: RSP: 0000:ffffffff9fa03cb8 EFLAGS: 00010006 ORIG_RAX: 0000000000000000
>>>>>>> steamdeck kernel: RAX: 0000000000000000 RBX: 0000000000100000 RCX: 0000000000100000
>>>>>>> steamdeck kernel: RDX: 0000000000000100 RSI: 0000000000100000 RDI: 0000000080200000
>>>>>>> steamdeck kernel: RBP: 0000000000000100 R08: 0000000000000000 R09: 0000000080200000
>>>>>>> steamdeck kernel: R10: 0000000000000004 R11: ffffffff9fa03ad0 R12: 8000000000000163
>>>>>>> steamdeck kernel: R13: 0000000000000000 R14: 0000000080200000 R15: 0000000000000000
>>>>>>> steamdeck kernel: FS:  0000000000000000(0000) GS:0000000000000000(0000) knlGS:0000000000000000
>>>>>>> steamdeck kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>>>> steamdeck kernel: CR2: ffff888000000413 CR3: 000000020ed02000 CR4: 00000000000000b0
>>>>>>> steamdeck kernel: Call Trace:
>>>>>>> steamdeck kernel:  <TASK>
>>>>>>> steamdeck kernel:  ? early_xdbc_parse_parameter+0x32c/0x360
>>>>>>> steamdeck kernel:  ? setup_early_printk+0x4f5/0x520
>>>>>>> steamdeck kernel:  ? do_early_param+0x44/0x70
>>>>>>> steamdeck kernel:  ? parse_args+0x233/0x420
>>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>>> steamdeck kernel:  ? parse_early_options+0x29/0x30
>>>>>>> steamdeck kernel:  ? __pfx_do_early_param+0x10/0x10
>>>>>>> steamdeck kernel:  ? parse_early_param+0x64/0xc0
>>>>>>> steamdeck kernel:  ? setup_arch+0x542/0xbc0
>>>>>>> steamdeck kernel:  ? _printk+0x6b/0x90
>>>>>>> steamdeck kernel:  ? start_kernel+0x66/0x9a0
>>>>>>> steamdeck kernel:  ? x86_64_start_reservations+0x24/0x30
>>>>>>> steamdeck kernel:  ? x86_64_start_kernel+0xcc/0xd0
>>>>>>> steamdeck kernel:  ? common_startup_64+0x13e/0x141
>>>>>>> steamdeck kernel:  </TASK>
>>>>>>> steamdeck kernel: ---[ end trace 0000000000000000 ]---
>>>>>>>
>>>>>>> Signed-off-by: Umang Jain <uajain@igalia.com>
>>>>>>> ---
>>>>>>>    drivers/usb/early/xhci-dbc.c | 8 ++++++++
>>>>>>>    1 file changed, 8 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>>>>>>> index 41118bba9197..699a9ac6d6c3 100644
>>>>>>> --- a/drivers/usb/early/xhci-dbc.c
>>>>>>> +++ b/drivers/usb/early/xhci-dbc.c
>>>>>>> @@ -76,6 +76,14 @@ static void __iomem * __init xdbc_map_pci_mmio(u32 bus, u32 dev, u32 func)
>>>>>>>      	sz64 = 1ULL << __ffs64(sz64);
>>>>>>>    +	/*
>>>>>>> +	 * Check that size does not exceed fixed boot-time mappings
>>>>>>> +	 * dictated by NR_FIX_BTMAPS. early_ioremap() will WARN_ON()
>>>>>>> +	 * and not map memory in those cases.
>>>>>>> +	 */
>>>>>>> +	if (sz64 > (NR_FIX_BTMAPS << PAGE_SHIFT))
>>>>>>> +		sz64 = NR_FIX_BTMAPS << PAGE_SHIFT;
>>>>>>
>>>>>> You are bounding the size here, but does this mean that the hardware
>>>>>> itself is just broken and should be fixed up to properly report the
>>>>>> correct size?  Does this hardware actually have a debug controller?
>>>>>
>>>>> Hmm, to answer your first question as far as I have read, the size is
>>>>> inferred from PCI config with base address. My understanding here is
>>>>> that
>>>>> for early xhci debugging - the page mappings are fixed, so we need to
>>>>> bound the size for early_ioremap().
>>>>
>>>> So the device is providing the wrong size here?  Why is this an issue
>>>> only for this hardware and not other hardware?
>>>>
>>>>> The second answer is, yes the hardware has debug controller. We can
>>>>> configure it after boot
>>>>> and it works with USB3.1 Superspeed cable with host:
>>>>>
>>>>> (on target)
>>>>> (A+)(root@steamdeck ~)# echo enable  >
>>>>> /sys/devices/pci0000:00/0000:00:08.1/0000:04:00.3/dbc
>>>>> (A+)(root@steamdeck ~)# dmesg | grep DbC
>>>>> [  366.276124] xhci_hcd 0000:04:00.3: DbC connected
>>>>> [  366.637223] xhci_hcd 0000:04:00.3: DbC configured
>>>>>
>>>>> (on host)
>>>>> [114288.650481] usb 4-2: new SuperSpeed USB device number 55 using
>>>>> xhci_hcd
>>>>> [114288.662907] usb 4-2: New USB device found, idVendor=1d6b,
>>>>> idProduct=0010, bcdDevice= 0.10
>>>>> [114288.662935] usb 4-2: New USB device strings: Mfr=1, Product=2,
>>>>> SerialNumber=3
>>>>> [114288.662945] usb 4-2: Product: Linux USB Debug Target
>>>>> [114288.662953] usb 4-2: Manufacturer: Linux Foundation
>>>>> [114288.662960] usb 4-2: SerialNumber: 0001
>>>>> [114288.666320] usb_debug 4-2:1.0: xhci_dbc converter detected
>>>>> [114288.666474] usb 4-2: xhci_dbc converter now attached to ttyUSB0
>>>>>    
>>>>>>
>>>>>> And what changed to cause this to start complaining?  Does it fix a
>>>>>> specific commit?  This hardware has been around for a long time, did we
>>>>>> mess something up in the kernel for it recently?
>>>>>
>>>>> This fix/patch is only for early xdbc. As mentioned above, it can be
>>>>> used/configured after boot.
>>>>> So yes, the hardware has been around but I don't think that early xdbc
>>>>> capability was investigated at any point in time. I don't see recents
>>>>> commits early xhci as well so maybe it was hidden all this time.
>>>>
>>>> Ok, but it is good to figure out what is "wrong" here that this hardware
>>>> is causing this warning to happen, yet other hardware does not.  Either
>>>> the kernel has always been wrong (totally a possibility), or this
>>>> hardware is reporting invalid ranges.  Figuring out which is true would
>>>> be good to figure out here.
>>>
>>> Oh yes definitely.
>>>
>>> I, although don't have any order hardware so I will look around. I
>>> haven't investigated the ranges yet, so I will investigate that too. My
>>> logic initially was that it's the "early boot" that is forcing a
>>> pages/size capping so we need to fit there.
>>>   From __early_ioremap() in mm/early_ioremap.c
>>>
>>> ...
>>> 	/*
>>> 	 * Mappings have to fit in the FIX_BTMAP area.
>>> 	 */
>>> 	nrpages = size >> PAGE_SHIFT;
>>> 	if (WARN_ON(nrpages > NR_FIX_BTMAPS))
>>> 		return NULL;
>>>
>>> ...
>>>
>>
>> Sometimes a xHC controller report a larger size than early ioremap supports.
>> This is because xHC from different vendors supports different extended
>> capabilities, both standard ones like DbC and vendor specific ones, all at vendor chosen offsets.
>>
> 
> That's a very useful information and I didn't really realise that there
> are vendor specific DbC information that could be read out for
> early-xhci dbg capability.
> 
> The size reported for 2 controllers are : 1MB (See output of in the end)
> 
>> To find offset of a extended capability we need to walk the extended capability list. If we limit the size here in software then we need to very carefully walk the capability list, making sure we don't go over that limit.
> 
> True. However, I am wondering how would be go about mapping all the
> extended capability list for early dbc? Or should we do it even (stick
> to the standard dbc and skip the vendor specific ones) because
> early_ioremap() is already fixed to 512 boot-time mappings. Do you have
> any opinion on this problem?
> 

An extended capability list entry first byte will be the ID of the capability.
DbC is standardized and has an ID "10".

Vendor capabilities start at ID 192.
The vendor specific capabilities are not related to DbC.

Following 16 bytes of extended capability entry contains offset to the next
extended capability. This offset value is offset from this current extended
capability to the next.

If xHCI reports larger size than ioremap supports I would:
map the max ioremap size,

1.  Read offset of first extended capability from a xHCI register
2.  Make sure offset < max ioremap size
3.  Read capability ID,
4.  If (capability id == "10") (DbC),
         ensure offset + 56 < max ioremap size, then use DbC
    else
         read offset value of next capability.
         Add new offset to existing offset.
         Check summed offset is < max ioremap size
         goto step 3.

Check out xhci_find_next_ext_cap() in xhci-ext-caps.h
It can be used for most steps above.

Thanks
Mathias