Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2464766pxb; Tue, 9 Mar 2021 03:16:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJxnQQ/JqpGqjhBRdDeEuIGrxVViA28iJKZDzYisGXgqEGCGUilCHmECXsIuPdSvpj6ktAUB X-Received: by 2002:a05:6402:2215:: with SMTP id cq21mr3499746edb.281.1615288587686; Tue, 09 Mar 2021 03:16:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615288587; cv=none; d=google.com; s=arc-20160816; b=Stjy8uGwmFOKKqmviyJkY0FIbJf66f/mYZPZQxswq+dR48olIy0aoI5/eipE3csWYM fsy6rLoKYyRYTfvI5va8VbRNXaU02yjwysSfPa5c/YkNoeyV0FI0PallSMovkhXfml0g 4jaUIMITfXTwVe9DHghjPLr0yTce3dlQwNACt05lS/qgEhahtUlGIVFQDUnX0HHzk4fk 2dUVonECRrTvBzbRnPBYgky5Nx9sGY6orHfG0qZ9A6dTvdV6rEO51knsiynr4R1se7PS bT3Q7feAimU9SBcz9MP5qZ7QdK4NLmLQT4gNNOwkMNmdqI2WzSJWHufiofB9z5fUNfNA X3qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=cKjwO43AjsBJoUH6JaO2Y5XWi3uHramUf/9ys8jvzbs=; b=G3K35H6QyFt3CcBzeY5wjlXwkiKwoFMJSNBi1/DeSGLDbq3HSVgryyxewP7li0Hl9q 9QQvflSuyK4uTe2aRflcdZdxZwl7Z9Ao6PMXMM5AYAIO+Q7k8OG4rvlq8NIvj08kXFs0 Lwgj7CjeM5PIfQZHIlNt0Kp+w6MfDk50AkAb54xfbKf/pbchkopUoWMyJ8E8671jC3Pt c8BkOEm/9SDHBOuMsx/eHw5Xy5HskzoajUOSXt77msr7M9hLatGwseGReR/F6QnsBt4q 1XgynDwb05kRoSilKq0DyH/7YFtMeYFrOFXk3qty3r/wcjRnto7OU3jfiV4aIDdQ8Tqv glig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=IUkDYmdX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a23si1340907eje.83.2021.03.09.03.16.05; Tue, 09 Mar 2021 03:16:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=IUkDYmdX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229948AbhCILPB (ORCPT + 99 others); Tue, 9 Mar 2021 06:15:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44432 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229875AbhCILOk (ORCPT ); Tue, 9 Mar 2021 06:14:40 -0500 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 781AFC061762 for ; Tue, 9 Mar 2021 03:14:36 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id h4so20127585ljl.0 for ; Tue, 09 Mar 2021 03:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cKjwO43AjsBJoUH6JaO2Y5XWi3uHramUf/9ys8jvzbs=; b=IUkDYmdXyRJ+5eqh5KaFAAav9I7fgeq5aJkWK2UclTqJ3DaNd+VsjtR5q06fui9WXK vf1b4BTQklr/p9t2OGjzoduMVlfBvwaj3ZUXvEqaVil5eQ58ERriPFCI1276Lsm6E6Qs znM0/daP+ANcymrxL2HJMHsf3oYJryKxg26zlCQD+Kc2UQQmxQgGPEgsVc9cbkWUrJM5 OY1THL0sfTB7KwJoDZEP4MEuBBMsFX/hYfnG4jbPcM1l0OR8uWhn+3csn+h8lstYLR97 aVaZd1sB5lMIEo3EID8BZM1zBgsfWLRilssJzwaU/hlIgt7TkVBHy9cXXDdV2y5bNAzU 5P0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cKjwO43AjsBJoUH6JaO2Y5XWi3uHramUf/9ys8jvzbs=; b=BHP15HrwPtWdXq8eHnmtiblGnsL8EA77yH3WblYcylpxEE8pqIdgV0d01yjVmb3+W9 67lfGcS6TR1Kh2OifKsDFZ4aa9u/Cw+ia3JuOoO/fu6Yo8txfxa54fsgL7jYt6S7Iawr yG7mRL2AoRAQhO3iLyFe3W0gU00ftNLXp6Ns5+MNKYsBi6y9xKK9pZv6LscJ5JYFo7xw 1PrTQPi8FcqC5rhzGU/h8z5iPoqWd8gT1xXqzDLnQxf7nT1Hv7HP22qBspw0wnDapte/ YnOUGaPTIkGAKCXdd3qEcTeLzKgsyLqsPYmkp9k4DOG4XjvlvAfoNc7rnyW5MYyTHxcJ /JtQ== X-Gm-Message-State: AOAM531iRSqGaZQzZP+RDViNDTyq/6V8nrgSbXukdtw0zz8ydBizeDvS 8XKAYbpcgnJ0YG5YoynOzMG+YVUDR2elf3W0QAAr4w== X-Received: by 2002:a2e:7001:: with SMTP id l1mr16537048ljc.200.1615288474745; Tue, 09 Mar 2021 03:14:34 -0800 (PST) MIME-Version: 1.0 References: <20210304213902.83903-1-marcan@marcan.st> <20210304213902.83903-13-marcan@marcan.st> <6e4880b3-1fb6-0cbf-c1a5-7a46fd9ccf62@marcan.st> <20210308211306.GA2920998@robh.at.kernel.org> In-Reply-To: <20210308211306.GA2920998@robh.at.kernel.org> From: Linus Walleij Date: Tue, 9 Mar 2021 12:14:23 +0100 Message-ID: Subject: Re: [RFT PATCH v3 12/27] of/address: Add infrastructure to declare MMIO as non-posted To: Rob Herring Cc: Arnd Bergmann , Hector Martin , linux-arm-kernel , Marc Zyngier , Olof Johansson , Krzysztof Kozlowski , Mark Kettenis , Tony Lindgren , Mohamed Mediouni , Stan Skowronek , Alexander Graf , Will Deacon , Mark Rutland , Andy Shevchenko , Greg Kroah-Hartman , Jonathan Corbet , Catalin Marinas , Christoph Hellwig , "David S. Miller" , DTML , "open list:SERIAL DRIVERS" , Linux Doc Mailing List , linux-samsung-soc , "open list:GENERIC INCLUDE/ASM HEADER FILES" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 8, 2021 at 10:13 PM Rob Herring 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 =E2=82=AC0.01 Linus Walleij