Re: Generic-xhci driver issue and changes for 64-but physical memory space

From: Gary Jennejohn <>
Date: Thu, 29 Jul 2021 16:13:32 +0200
On Thu, 29 Jul 2021 11:20:13 +0000
Sha Faisal via freebsd-hackers <> wrote:

> Mailing to freebsd-hackers, after adding my email id to subscriber list.
> Please assist with the below query.
> Regards
> Faisal
> From: Sha Faisal <>
> Date: Thursday, 29 July 2021 at 12:19 AM
> To: "" <>
> Cc: Justin Hibbits <>, Kumara N Babu <>, Vikram M Gadagkar <>
> Subject: Generic-xhci driver issue and changes for 64-but physical memory space
> Hello FreeBSD-hackers
> Inn one of our new platforms we have physical RAM placed above the 4GB mark.
> And the eUSB device is capable of doing 64-bit DMA.
> The USBPHY uses the generic-xhci driver and when we were bringing-up we hit the issue below and the code panics
> xhci0: <Marvell Integrated USB 3.0 controller> mem 0x10243000-0x10243fff irq 15 on simplebus1
> xhci0: 64 bytes context size, 32-bit DMA
> panic: vm_wait in early boot
> I modified the below function call , and the usb driver is up and it works fine. Please suggest if this change is fine and can be incorporated.
> #define IS_DMA_32B      1
> #define IS_DMA_64B      0
> err = xhci_init(sc, dev, IS_DMA_64B);

As a locally maintained patch this would be acceptable.  But I greatly
doubt that this change would make it into the source tree as written.

Since the generic-xhci driver knows basically nothing about the hardware
it takes the conservative approach of always using 32-bit DMA.

Strangely enough, the code in xhci.c, which tries to determine the DMA
size by reading a register in the controller, thinks that this
controller only supports 32-bit DMA.

If I were the maintainer of this code the only way I would allow this
change would be if it used the pci register values unique to this
controller to set the dma32 flag in xhci_init() to 0 and otherwise
keep the default value of 1.

Gary Jennejohn
Received on Thu Jul 29 2021 - 14:13:32 UTC

Original text of this message