On 2020-02-12 11:56 am, David Laight wrote:
From: Robin Murphy
Sent: 12 February 2020 11:43
...
If the device *is* inherently 64-bit capable, then setting 64-bit masks
in the driver is correct - if a 64-bit IP block happens to have been
integrated with only 32 address bits wired up, but the system has memory
above the 32-bit boundary, then that should be described via
"dma-ranges", which should then end up being used to further constrain
the device masks internally to the DMA API.
Given how often this happens (please can I shoot some more
hardware engineers - he says while compiling some VHDL)
is it possible to allocate some memory pages that are
aliases if the address bits over 31 are ignored?
Then (at least some) drivers could to a run-time probe
reading to the high address and checking the data didn't
appear in the low address.
Only one such set of pages is needed - access can be locked.
But they'd need to be reserved early on.
(Oh, for that much control over page allocation!)
It's a fun idea, but there's no guarantee that the platform memory map
is actually suitable (AMD Seattle is the go-to counterexample), and
having an opt-in test that every driver has to implement individually
sounds like a maintenance nightmare. I think it's far better all round
to just expect the firmware-provided machine description - be it
devicetree, ACPI, or whatever - to correctly describe the integration.
Robin.
