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.