From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754955AbcIIUnW (ORCPT ); Fri, 9 Sep 2016 16:43:22 -0400 Received: from mail-ua0-f172.google.com ([209.85.217.172]:34801 "EHLO mail-ua0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754588AbcIIUnT (ORCPT ); Fri, 9 Sep 2016 16:43:19 -0400 MIME-Version: 1.0 In-Reply-To: <2852054.37zytD0HIa@wuerfel> References: <1469134557-26869-1-git-send-email-hotran@apm.com> <2529114.aAikiSWl11@wuerfel> <2852054.37zytD0HIa@wuerfel> From: Hoan Tran Date: Fri, 9 Sep 2016 13:43:17 -0700 Message-ID: Subject: Re: [PATCH] hwmon: xgene: access mailbox as RAM To: Arnd Bergmann Cc: Guenter Roeck , Jean Delvare , Jonathan Corbet , Rob Herring , Jassi Brar , Ashwin Chaugule , Duc Dang , Loc Ho , linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org, lkml , linux-arm-kernel@lists.infradead.org, Devicetree List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 9, 2016 at 12:58 PM, Arnd Bergmann wrote: > On Friday, September 9, 2016 12:24:32 PM CEST Hoan Tran wrote: >> On Fri, Sep 9, 2016 at 8:38 AM, Arnd Bergmann wrote: >> > The newly added hwmon driver fails to build in an allmodconfig >> > index bc78a5d10182..e834dfb3acca 100644 >> > --- a/drivers/hwmon/xgene-hwmon.c >> > +++ b/drivers/hwmon/xgene-hwmon.c >> > @@ -34,7 +34,8 @@ >> > #include >> > #include >> > #include >> > -#include >> > +#include >> >> Alphabetical order. >> >> > struct acpi_pcct_shared_memory *generic_comm_base = ctx->pcc_comm_addr; >> > - void *ptr = generic_comm_base + 1; >> > + u32 *ptr = (void*)(generic_comm_base + 1); >> >> Space before "*". > > Ok. > >> > @@ -652,9 +653,9 @@ static int xgene_hwmon_probe(struct platform_device *pdev) >> > */ >> > ctx->comm_base_addr = cppc_ss->base_address; >> > if (ctx->comm_base_addr) { >> > - ctx->pcc_comm_addr = >> > - acpi_os_ioremap(ctx->comm_base_addr, >> > - cppc_ss->length); >> > + ctx->pcc_comm_addr = memremap(ctx->comm_base_addr, >> > + cppc_ss->length, >> > + MEMREMAP_WT); >> >> It should be MEMREMAP_WB. As mailbox shared memory is on RAM and our >> co-processor is also in the coherency domain. > > Right, I was wondering about this, since I could not figure out what > the other side is (hardware, service processor or firmware). > So MEMREMAP_WB makes sense here. > > Two more questions: > > * Any comment on the byte ordering of the data in this line: > > /* Copy the message to the PCC comm space */ > for (i = 0; i < sizeof(struct slimpro_resp_msg) / 4; i++) > - writel_relaxed(msg[i], ptr + i * 4); > + WRITE_ONCE(ptr[i], cpu_to_le32(msg[i])); > > This assumes that the old code was correct even when running on > big-endian kernels and the message data consists of 32-bit data words. > If the message has some other format instead, we would need to treat > this as a byte stream and not do swapping here but instead do it > (if any) in the code that reads or writes the actual data here. This is 32-bit data words. > > * Are you sure you don't need any smp_rmb()/smp_wmb() barriers > between the accesses? No, we don't need a strict read/write during access PCC subspace. Just make sure all access is committed before PCC send message to the platform which done by PCC mailbox driver. Thanks Hoan > > Arnd