On Wed, 2025-09-03 at 14:44 +0200, Jan Palus wrote: > > Thanks for the patch Klaus! While it does improve situation we're not > quite there yet. It appears that what used to be stored in `cpuaddr` var > is also very different from `range.cpu_addr` value so the results > in both `*tgt` and `*attr` are both wrong. > > Previously `cpuaddr` had a value like ie 0x8e8000000000000 or > 0x4d0000000000000. Now `range.cpu_addr` is always 0xffffffffffffffff. > Luckily what used to be stored in `cpuaddr`: > > u64 cpuaddr = of_read_number(range + na, pna) > > appears to be stored in range.pci_bus_addr now. I can't make any > informed comment about this discrepancy however I can confirm following > change (in addition to your patch) makes mvebu driver work again (or at > least like it used to work in 6.15, it still needs Pali's patches to > have some devices working): > > - *tgt = DT_CPUADDR_TO_TARGET(range.cpu_addr); > - *attr = DT_CPUADDR_TO_ATTR(range.cpu_addr); > + *tgt = DT_CPUADDR_TO_TARGET(range.parent_bus_addr); > + *attr = DT_CPUADDR_TO_ATTR(range.parent_bus_addr); Oh well, a CPU address that is not a CPU address.... Looking again at of_range_parser_one() - which I assume to be "correct" here: range->flags = parser->bus->get_flags(parser->range); range->bus_addr = of_read_number(parser->range + busflag_na, na - busflag_na); if (parser->dma) range->cpu_addr = of_translate_dma_address(parser->node, parser->range + na); else range->cpu_addr = of_translate_address(parser->node, parser->range + na); range->parent_bus_addr = of_read_number(parser->range + na, parser->pna); Indeed, range.cpu_addr is a translated version of range.parent_bus_addr, and does not seem to be relevant to pci-mvebu. The driver previously interpreted the raw part of the "/soc/pcie/ranges" resource (storing it in a local variable called cpuaddr). To restore the behavior completely, we thus can use range.parent_bus_addr --- confirming your test. I'll prepare a patch version 2, including this second fix.
