Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5088656ybl; Tue, 14 Jan 2020 03:20:02 -0800 (PST) X-Google-Smtp-Source: APXvYqzhynyw2AlSxBbMk5srqQhnu/S9YEjo89O/fFajXfQP/lZov2GVq6WLdy511EQ2x8ofF8Fd X-Received: by 2002:a9d:6005:: with SMTP id h5mr17364543otj.153.1579000802642; Tue, 14 Jan 2020 03:20:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579000802; cv=none; d=google.com; s=arc-20160816; b=bdsJe+m1Fs6XV2JBdeqPbyfOZbUw4xlxohjQUb//OnqNQN0ECqsGM4aqISnacuiWsd 5uo0V+YKLr9djFsOHKCZNzCMoItCdSNufB3s2F5s0pIW9KKRLmtxiqlhTl40DHiHGoxe uKK988A+hdnqJ2mpAO+pceOCEI68AKbVbbffVZls2FoT4N+KQCMYmciR2Hi6tfhmuxZ7 x/q6jrQMCp6MfSCiDAwGZDMg0hK4cGgVYZ9SWgDK9RpT0dL3LPSEbSOCvKCGh0q683ub mfI8sIp1VBSPxil66/d1iz1vfQtyqKwAaOU41jleUwjP7Re9yJlXZebCHaEH9s8QD3ix UVag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=C3a71HxwJDt9cLF+hJzTOd5RJNAuaAqJbrHrw3v0Rgo=; b=Y8XuJQZ1vNgpGgzQMR9I9DNvHudNDdcYqsWOuz9MxB0fSfEBpFERd//NDNvhmi/mc+ dp/lj1XlmqhvxyK6nchZ1g5lHtGxxsA8KfmP3Lg++WDKiZR1+fUZApi8z8s+EVxGoDgF nuklReCUHoHEkZXsxizfMr0DCR6uLvGPjwpwlEKPLsyI6bweQNOVr1NxanC3iE31gV2Q EL9DxDhquZz2Gsr6W2l/fOhDQ+wKzjzi9FQNHQ72HmN/GARKylwfBSZYr+gW0V932lwO 2R0d1CV7+QMrTIcPzlqzbnQVYsNHRrHqdzuSGpzSgHEIYuUah8wvAYE7lh8eGSrj7e8r O37w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d23si7464967oij.270.2020.01.14.03.19.50; Tue, 14 Jan 2020 03:20:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728914AbgANLRr (ORCPT + 99 others); Tue, 14 Jan 2020 06:17:47 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:49183 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725820AbgANLRr (ORCPT ); Tue, 14 Jan 2020 06:17:47 -0500 Received: from mail-qv1-f53.google.com ([209.85.219.53]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1McGtA-1jN6BR3ans-00cdtS for ; Tue, 14 Jan 2020 12:17:46 +0100 Received: by mail-qv1-f53.google.com with SMTP id z3so5460700qvn.0 for ; Tue, 14 Jan 2020 03:17:45 -0800 (PST) X-Gm-Message-State: APjAAAWXuovQ9UOgj7HTrrPjfne4KrFKCu33o3bunG8/Okej3L0FIIdI oxotZn2n14pRpapePg+U5XCuoNJcpBHiAedde6M= X-Received: by 2002:a0c:ead1:: with SMTP id y17mr15513188qvp.210.1579000664506; Tue, 14 Jan 2020 03:17:44 -0800 (PST) MIME-Version: 1.0 References: <3f5567ec928e20963d729350e6d674c4acb0c7a0.1578648530.git.viresh.kumar@linaro.org> <20200113064156.lt3xxpzygattz3he@vireshk-i7> <20200114092615.nvj6mkwkplub5ul7@vireshk-i7> <20200114111110.jhkj2y47ncp5233r@vireshk-i7> In-Reply-To: <20200114111110.jhkj2y47ncp5233r@vireshk-i7> From: Arnd Bergmann Date: Tue, 14 Jan 2020 12:17:28 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type To: Viresh Kumar Cc: Sudeep Holla , Jassi Brar , cristian.marussi@arm.com, peng.fan@nxp.com, "linux-kernel@vger.kernel.org" , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:++IQvtTspzRE29UBi6vKzQmPn++cVPobveGFppCp1HlcB9IDD9l nhWpmZ4fbdhWSuGqx0xQlhEcFGoP49+gzvUF9DxTQQiZ0IzgJFvJIynx1Ey2k7OilWXDfKR QI59JnnftB77TzszUjOFuN8OgeqU1vcIxzRN/LwQCQg6ZlqI834rr7dQzr7eDos+8U5TTlj Qw61eY0YRNesID+aTIlAg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lGCghHztiNE=:WvVOeayv+u0dt/9LImrsQ8 wjBV48dMe2D5wnKKFs5QV2J1aMny4XeMWKTPFMotxPVre4r5OpANfRlyNIuKqPGhBJXz+RwvF tRBGtin0sjINLmw+Id/N+9ffW7DJMYybPcjiKiiPLN1QqvYDGQn6ig80reftWJddNBur4jTy1 Pm6QyylniGbDGZsOL8S1Z9BeWWc4uHU03IN4dJULCb8jnyqTWb9JQ9DIBznCsR3vz8nK50rzt TO9gKXANn1X24g9BlTcDIFkGbsbmAGTj2lRf5xzncAZvADh+Bub1W4BhOD2QbFNeDWpCBNz4z 7LVygLoQcVWJsnbxxTrZIuk+Df/pztCfUe2SSoRkGrpLxgVRKzkikI+uEkO8p6b6nshvjN6nR iddcGucwY+j6c41h8S4htdyTrBaZrDQjTsIBkfosNuMvH/NCIPW0AcjDs2VI0NaYCa7lHoAY6 iEsM3dqNYYCAHTDZllDvdXykxsYDVUvUyKsYyxFBkCnIMORx5VBAqiVaRmBJB3B3jIjDP8GVW yfpL8fbjTl6PZxfzThL5fOW8lT37Pe9vTSADXetk6Qzuxc7w40R5T2c43Y/AeHXUciJc7iWxq DtDKQhBxgTIU+ELuMQe7ZnOznTbk6QCbf9q2EfXoA6c8m80QEF3JYDBlLPAnRjXtL1xxY6F5H o7ygE/If9/DJEN4uyfK0c4Tz8IFE5U/ACn1Mo4MoSl7Rlw9e01OMRVW4R9PWJbvPsmLw/Vxyi cIOsyu83/XZMDJZ+gCDxTr3G+KSwzbdymsyVBt5ptDMemOeglSr0jUn6EoxP8IlT5YtsQUWZh MB0MR4XFz8z0qa5tmbwx88msAJ65kreI1Za+RyEqXfHZYXUXpggSa9V2BVdPhPCxWXLV9RKiU Du3PAxE4ct22Ym2jt94Q== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 14, 2020 at 12:11 PM Viresh Kumar wrote: > > On 14-01-20, 10:56, Arnd Bergmann wrote: > > My point was that you cannot mix __iomem accesses with pointer > > accesses. As I understood it, the current version uses a pointer to a > > The current version is stupid as I misunderstood the whole __iomem > thing and just dropped it :) > > > hardware mailbox with structured data, so you have to use ioremap() > > to get a token you can pass into ioread(), but (some of) the new > > transport types would just be backed by regular RAM, on which this > > is not a well-defined operation and you have to use memremap() > > and memcpy() instead. > > Okay, I think I understand that a bit now. So here are the things > which I may need to do now: > > - Maybe move payload to struct scmi_mailbox structure, as that is the > transport dependent structure.. > > - Do ioremap, etc in mailbox.c only instead of driver.c > > - Provide more ops in struct scmi_transport_ops to provide read/write > helpers to the payload and implement the ones based on > ioread/iowrite in mailbox.c .. > > Am I thinking in the right direction now ? That sounds about right. What I'm still not sure about is whether the current kernel code is actually correct and should use iomeap() in the first place. Can you confirm that all current hardware implementations actually use MMIO type registers here rather than just rely on a buffer in RAM? Arnd