On Mon, Mar 8, 2021 at 10:13 PM Rob Herring <robh@xxxxxxxxxx> wrote: > On Mon, Mar 08, 2021 at 09:29:54PM +0100, Arnd Bergmann wrote: > > This is obviously more work for the drivers, but at least it keeps > > the common code free of the hack while also allowing drivers to > > use ioremap_np() intentionally on other platforms. > > I don't agree. The problem is within the interconnect. The device and > its driver are unaware of this. If it is possible that a driver needs to use posted access on one SoC and nonposted on another SoC then clearly the nature of the access need to be part of the memory access abstraction, obviously ioremap() one way or another. Having the driver conditionally use different ioremap_* functions depending on SoC seems awkward. We had different execution paths for OF and ACPI drivers and have been working hard to create fwnode to abstract this away for drivers used with both abstractions for example. If we can hide it from drivers from day 1 I think we can save maintenance costs in the long run. Given that the Apple silicon through it's heritage from Samsung S3C (the genealogy is unclear to me) already share drivers with this platform, this seems to already be the case so it's not a theoretical use case. The core argument here seems to be "will this become common practice or is it an Apple-ism?" That is a question to someone who is deep down there synthesizing SoCs. It appears the market for custom silicon laptops has just begun. There are people that can answer this question but I doubt that we have access to them or that they would tell us. What is an educated guess? It seems Arnds position is that it's an Apple-ism and I kind of trust him on this. At the same time I know that in emerging markets, what copycats are likely to do is say "give me exactly what Apple has, exactly that thing". Just my €0.01 Linus Walleij
