Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1905303pxb; Fri, 5 Mar 2021 02:37:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJyCRsec1xbtCcKkldEQ6x5yMIfTq/5rq0ENCDmFOBQv8j8q1hSATxgB1GmDo7t8679HlT1V X-Received: by 2002:a17:906:68c1:: with SMTP id y1mr1634805ejr.289.1614940626912; Fri, 05 Mar 2021 02:37:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614940626; cv=none; d=google.com; s=arc-20160816; b=Vz2d58Rue0u7Hj5wEYI6GhQg2YsDfJ3x7m3+4m3YCUTtKJpO82DltHEMeNKxo2hir8 Ok5jmusfi96UZnm4rAsxdwTvrAOKGlLwMcO1Fv9rJ8znlCo7lAzhN0ILAGbAjiXdfaSf Eu2UxPwIZnNJJyzuAjLiX96pjn57xO7BAJrMJBDJHlG5wfnZnHE9z+9/J/B/ElaBXX64 +RZYcsvIS6z+IK+l0+HLNTOIZffKRc3bUcimRyLJgSBlH71XWKTLB5rDzqDGRco9YzJE kv1OqMIMXCetN/ybHx/ax89IOePLRQp9mbA2qOlOGnF7YtL02Ni3oastowdI+010iW8u jSYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=aU5n3V+5MklHsxkxwTHpN5JN12LAcfIzcOHfilMxsnc=; b=r9Qc4k2Ao/+dQwAMslNvvjQKKYHZtT4/HsOJB5hp3W05r1Yi5Y9vwVZAWd2vkSGeml 1J9KIO6eOcmm+Z9ET1rM1pCdMwsfZdv1pxx5fCfLuQh52lCpbCGSGRdkvqfQQa1Rl/+J qS9HNz1c9BdJDZ9YW8C++c3Q6xH4IS+IRMRufxH9xObd4rKeJxEGr4igVkic6c4kAKI1 HBGXAZmEZXfjSWIzvy1pNXcxhOpbEJNGznq+BFRaPRVY6EvQ53kJwHVYHEBy90dxrgP+ LQ717OiKhvspl/DdFIRWzBqJba8W1lJxKBlpvAFgPF05TlXuK+aYDJ209u4bh8N3A7Vq VqzQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y8si1326021edw.240.2021.03.05.02.36.44; Fri, 05 Mar 2021 02:37:06 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229582AbhCEKdg (ORCPT + 99 others); Fri, 5 Mar 2021 05:33:36 -0500 Received: from 6.mo173.mail-out.ovh.net ([46.105.43.93]:39737 "EHLO 6.mo173.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229558AbhCEKdW (ORCPT ); Fri, 5 Mar 2021 05:33:22 -0500 Received: from player750.ha.ovh.net (unknown [10.109.156.41]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id 263991633EF for ; Fri, 5 Mar 2021 11:24:47 +0100 (CET) Received: from milecki.pl (ip-194-187-74-233.konfederacka.maverick.com.pl [194.187.74.233]) (Authenticated sender: rafal@milecki.pl) by player750.ha.ovh.net (Postfix) with ESMTPSA id E44FC1BA40728; Fri, 5 Mar 2021 10:24:36 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G001e4f3bde1-afa5-4127-9562-5a7b4f35abba, 4F7D11A3904BD8E553EC742B87CBB6774FEDAA0F) smtp.auth=rafal@milecki.pl X-OVh-ClientIp: 194.187.74.233 Subject: Re: [PATCH 2/2] nvmem: iomap: new driver exposing NVMEM accessible using I/O mapping To: Srinivas Kandagatla , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Rob Herring Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, Florian Fainelli , Vivek Unune , bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org References: <20210304144132.24098-1-zajec5@gmail.com> <20210304144132.24098-2-zajec5@gmail.com> <047bced8-6c20-4a0a-c7ea-e0ad83318461@linaro.org> From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Message-ID: <93708a21-3444-f68e-c834-a4f769a0acba@milecki.pl> Date: Fri, 5 Mar 2021 11:24:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <047bced8-6c20-4a0a-c7ea-e0ad83318461@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 499336608932138519 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledruddtiedgudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheptfgrfhgrlhcuofhilhgvtghkihcuoehrrghfrghlsehmihhlvggtkhhirdhplheqnecuggftrfgrthhtvghrnhepkeduheejheffudefhffghfegjeejleetkeevueelveegkefhhfffieehleelgfevnecukfhppedtrddtrddtrddtpdduleegrddukeejrdejgedrvdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejhedtrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomheprhgrfhgrlhesmhhilhgvtghkihdrphhlpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.03.2021 11:02, Srinivas Kandagatla wrote: > On 04/03/2021 14:41, Rafał Miłecki wrote: >> From: Rafał Miłecki >> >> This is a generic NVMEM access method used e.g. by Broadcom for their >> NVRAM on MIPS and Northstar devices. >> >> Signed-off-by: Rafał Miłecki >> --- >>   drivers/nvmem/Kconfig  |  7 +++ >>   drivers/nvmem/Makefile |  2 + >>   drivers/nvmem/iomap.c  | 99 ++++++++++++++++++++++++++++++++++++++++++ >>   3 files changed, 108 insertions(+) >>   create mode 100644 drivers/nvmem/iomap.c >> >> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig >> index 75d2594c16e1..3d5c5684685d 100644 >> --- a/drivers/nvmem/Kconfig >> +++ b/drivers/nvmem/Kconfig >> @@ -278,4 +278,11 @@ config NVMEM_RMEM >>         This driver can also be built as a module. If so, the module >>         will be called nvmem-rmem. >> + >> +config NVMEM_IOMAP >> +    tristate "I/O mapped NVMEM support" >> +    depends on HAS_IOMEM >> +    help >> +      This driver supports NVMEM that can be accessed using I/O mapping. >> + >>   endif >> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile >> index 5376b8e0dae5..88a3b6979c53 100644 >> --- a/drivers/nvmem/Makefile >> +++ b/drivers/nvmem/Makefile >> @@ -57,3 +57,5 @@ obj-$(CONFIG_SPRD_EFUSE)    += nvmem_sprd_efuse.o >>   nvmem_sprd_efuse-y        := sprd-efuse.o >>   obj-$(CONFIG_NVMEM_RMEM)     += nvmem-rmem.o >>   nvmem-rmem-y            := rmem.o >> +obj-$(CONFIG_NVMEM_IOMAP)    += nvmem_iomap.o >> +nvmem_iomap-y            := iomap.o >> diff --git a/drivers/nvmem/iomap.c b/drivers/nvmem/iomap.c >> new file mode 100644 >> index 000000000000..ab6b40858a64 >> --- /dev/null >> +++ b/drivers/nvmem/iomap.c >> @@ -0,0 +1,99 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (C) 2021 Rafał Miłecki >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +struct iomap { >> +    struct device *dev; >> +    void __iomem *base; >> +}; >> + >> +static int iomap_read(void *context, unsigned int offset, void *val, >> +              size_t bytes) >> +{ >> +    struct iomap *priv = context; >> +    u8 *src = priv->base + offset; >> +    u8 *dst = val; >> +    size_t tmp; >> + >> +    tmp = offset % 4; >> +    memcpy_fromio(dst, src, tmp); >> +    dst += tmp; >> +    src += tmp; >> +    bytes -= tmp; >> + >> +    tmp = rounddown(bytes, 4); >> +    __ioread32_copy(dst, src, tmp / 4); >> +    dst += tmp; >> +    src += tmp; >> +    bytes -= tmp; >> + >> +    memcpy_fromio(dst, src, bytes); >> + > > > You could just do this! > >     while (bytes--) >         *val++ = readb(priv->base + offset + i++); Do you mean that as replacement for "memcpy_fromio" or the whole function code? The reason for using __ioread32_copy() was to improve reading performance (using aligned 32 bit access where possible). I'm not sure if that really matters? P.S. Please don't yell at me in every sentence :( Makes me a bit sad :(