All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Michal Pecio <michal.pecio@gmail.com>
Cc: Xincheng Zhang <zhangxincheng@ultrarisc.com>,
	cyrozap@gmail.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	mathias.nyman@intel.com
Subject: Re: [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805
Date: Fri, 26 Jun 2026 09:06:15 +0100	[thread overview]
Message-ID: <20260626090615.616666b4@pumpkin> (raw)
In-Reply-To: <20260625191852.0a8d511c.michal.pecio@gmail.com>

On Thu, 25 Jun 2026 19:18:52 +0200
Michal Pecio <michal.pecio@gmail.com> wrote:

...
> Right, your addresses barely exceed the 36 bit limit. And I found why
> my chip behaved differently - 40 bit DMA was a firmware upgrade.
> 
> After downgrading my controller from 00013704 to 00013600 it truncates
> addresses to 36 bits and fails like yours. And it's a pretty nasty bug,
> because some of those accesses are writes to scratchpad buffers, so
> without IOMMU the chip corrupts unrelated memory below 64GB.
> 
> You can check your FW version with this one-liner:
> lspci -d 1106:3483 -xxx | awk '/^50:/ { print "VL805 FW version: " $5 $4 $3 $2 }'
> 
> More about VL805 firmwares:
> https://github.com/jpmorrison/VL805
> 
> One could ask whether 36 bits is low enough for all VL805, but I think
> it is because the bug is hard not to notice and nobody ever reported it
> on systems with less than 64 GB of RAM, even though 16 or 32 GB without
> IOMMU was a common option in DDR3 generation PCs, which is also about
> the era when this controller was introduced.

36 bits is just enough to support 32bit x86 with PAE.
Seems very short sighted.
IIRC xhci has a quite restrictive limit on address boundaries so supporting
larger addresses is just latches - there is no need for a 64bit counter.

Can you do a read-back of one of the control registers that contains
an address - if you are lucky the high bits will return zero.
That might let the generic code enforce a limit.

-- David

> 
> Regards,
> Michal
> 


  parent reply	other threads:[~2026-06-26  8:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  7:32 [PATCH] usb: xhci-pci: Disable 64-bit DMA for VIA VL805 Xincheng Zhang
2026-06-23 10:18 ` Michal Pecio
2026-06-24  5:26   ` Xincheng Zhang
2026-06-24  7:06   ` Xincheng Zhang
2026-06-25  0:04     ` Michal Pecio
2026-06-25  2:16       ` Xincheng Zhang
2026-06-25 17:18         ` Michal Pecio
2026-06-26  2:08           ` Xincheng Zhang
2026-06-26  8:06           ` David Laight [this message]
2026-06-26  8:57             ` Michal Pecio
2026-06-26 10:55               ` David Laight

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=20260626090615.616666b4@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=cyrozap@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=michal.pecio@gmail.com \
    --cc=zhangxincheng@ultrarisc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.