Linux USB
 help / color / mirror / Atom feed
From: Umang Jain <uajain@igalia.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lucas De Marchi <demarchi@kernel.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-dev@igalia.com
Subject: Re: [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap()
Date: Wed, 20 May 2026 12:54:43 +0000	[thread overview]
Message-ID: <329c3970d932c21ca0ead6a84e573bd2@igalia.com> (raw)
In-Reply-To: <2026052001-regally-dizziness-2271@gregkh>

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

  reply	other threads:[~2026-05-20 12:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20  9:48 [PATCH] usb: early: xhci-dbc: Ensure correct memory size for early_ioremap() Umang Jain
2026-05-20 11:22 ` Greg Kroah-Hartman
2026-05-20 12:27   ` Umang Jain
2026-05-20 12:42     ` Greg Kroah-Hartman
2026-05-20 12:54       ` Umang Jain [this message]
2026-05-25 21:01         ` Mathias Nyman
2026-05-27 13:22           ` Umang Jain
2026-06-01 13:35             ` Mathias Nyman
2026-05-29  9:03           ` Umang Jain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=329c3970d932c21ca0ead6a84e573bd2@igalia.com \
    --to=uajain@igalia.com \
    --cc=demarchi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-dev@igalia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox