From patchwork Sun Nov 27 23:10:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 13056915 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 027CCC4332F for ; Sun, 27 Nov 2022 23:11:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=3M7Hz5QSfTfkaZG6KDMK5i/IIK2EgdsPXZtNWH2hYYU=; b=hK+BmobZcnaEGK u5Ck4B4zojpL2ZoOT8CJMy1uO1hFN2shxAynZVzMWneesgGicPmgDMv0jrKeweBwE6eJI7zuKfagF EQbDK56/ARvoQCem78QzHkOGBo9EHvQyQBrz8rmhuG0O2boSx+bZQyIiwcOdhb2JHZ61jxsTWsQwB D0bTh/iKrJrdsYGmj4cem+WppFLC719rgme1G2XSjIglI0GaKvrx0KiFLRF0ecZd405x3gMuQogd0 EXPm7LoFBamisORgSNUZKoQI1yswD3FwaW+VQvNZovxVNjizT7eIzxIgWKKkFWq5vbpJ4vKHnTDv8 IC4LkM4H++y7ZxvZYv+w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ozQnb-00E8QZ-T2; Sun, 27 Nov 2022 23:11:00 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ozQnW-00E8Mz-WD; Sun, 27 Nov 2022 23:10:56 +0000 Received: by mail-lf1-x130.google.com with SMTP id c1so14859737lfi.7; Sun, 27 Nov 2022 15:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=k8JXtlo4DWFyHURdtAccWfZAXE3cOsEDHes1809eE/U=; b=QW9F8xXcDk6+dTNytDZQt+FDxATthPJl4PyRcDASxAZnVPMrhSGrtAqYfMauiA2RC4 qX3sAEj2SgBWgdSJ9mgXapjj8gjYXO8e6aPIVmEf7zfftdfZFQloCpPS1MukHL7KCc5p nywgoMZfSNUk9LQoSg2VVwtmXEk9pM9n1F8LKMOl3SwSTRZ0YHm3iWi3j/nkHElM6L1q oX4ULjLTHXgzr1h4oXqyYo4497dTUu9irJ55DryuzE9fv2+Ov49HNWzK/rlgNv9kThPv jrhpPLMQo+K1ROIYZmtgwWUUeFq3IisZdawefHcj5JWHF/p6/1Og1Y7wYH0lqXM6KWvw zpLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=k8JXtlo4DWFyHURdtAccWfZAXE3cOsEDHes1809eE/U=; b=6BXwFuvYhs7mgW6qTq26/11wJ+pWwFY/l5SRvgwNuf7+E1VguB4eOQPMEuh7oMlEvq i+c7eJ+YOXtPMrvrqffUk/eAzgsX8LoZhX0Ma7yP0KUXdu6Iruns6yQeFViFhEortiM2 VQ7d98YAprmH2ZLdxe+sDfya8Dg2EHZNX1TyR3Kjsc2qnwnRiih3Jzq9axB9oFx6ejWd MLIGcDYeeb8XDWoLYZQJ7XdVULhJYMOy+pvORllHqTdrXqijcwMPO4D/VH7j/5fE3gMA wDZr2NyOA7qZntM0s1n4eqnDvnEvuf/iIkyrJhgRJZGqAHOIpxnL8xjg55zpp9WzBnuf fLkA== X-Gm-Message-State: ANoB5plja8lNrocDi/gyd9Ao0A5+KGtog+QAMUfSi8GU7Io6jUUhdmyw dJy4uo2N5rQ087LjT6LpQQk= X-Google-Smtp-Source: AA0mqf7sUKQqb/1PAv8GCFQE+7LTmVRJLj315wSetO38JXCWb7+qDuuRDemCeeABGvrEU3plpkHwYw== X-Received: by 2002:a05:6512:210d:b0:4a2:741f:1909 with SMTP id q13-20020a056512210d00b004a2741f1909mr17557432lfr.484.1669590646981; Sun, 27 Nov 2022 15:10:46 -0800 (PST) Received: from localhost.lan (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by smtp.gmail.com with ESMTPSA id d17-20020a0565123d1100b004b4ea0f4e7fsm1439984lfv.299.2022.11.27.15.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Nov 2022 15:10:46 -0800 (PST) From: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= To: Srinivas Kandagatla Cc: Michael Walle , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Shawn Guo , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, u-boot@lists.denx.de, =?utf-8?b?UmFmYcWCIE1p?= =?utf-8?b?xYJlY2tp?= Subject: [PATCH 1/2] nvmem: core: refactor .cell_post_process() CB arguments Date: Mon, 28 Nov 2022 00:10:34 +0100 Message-Id: <20221127231035.17547-1-zajec5@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221127_151055_066604_E7F36F04 X-CRM114-Status: GOOD ( 18.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Rafał Miłecki Pass whole NVMEM cell struct and length pointer as arguments to callback functions. This allows: 1. Cells content to be modified based on more info Some cells (identified by their names) contain specific data that needs further processing. This can be e.g. MAC address stored in an ASCII format. NVMEM consumers expect MAC to be read in a binary form. More complex cells may be additionally described in DT. This change allows also accessing relevant DT nodes and reading extra info. 2. Adjusting data length If cell processing results in reformatting it, it's required to adjust length. This again applies e.g. to the MAC format change from ASCII to the byte-based. Later on we may consider more cleanups & features like: 1. Dropping "const char *id" and just using NVMEM cell name 2. Adding extra argument for cells providing multiple values Signed-off-by: Rafał Miłecki --- This solution conflicts with 1 part of Michael's work: [PATCH v2 00/20] nvmem: core: introduce NVMEM layouts https://lore.kernel.org/linux-arm-kernel/20220901221857.2600340-1-michael@walle.cc/ Instead of: 1. Adding NVMEM cell-level post_process callback 2. Adding callback (.fixup_cell_info()) for setting callbacks 3. Dropping NVMEM device-level post_process callback I decided to refactor existing callback. Michael's work on adding #nvmem-cell-cells should be possible to easily rebase on top of those changes. This doen't add support for 1 cell providing multiple values. That needs to be added later once we sort out #nvmem-cell-cells bindings. This fixes the basic case with reformatting cells data. --- drivers/nvmem/core.c | 19 +++---------------- drivers/nvmem/imx-ocotp.c | 8 ++++---- include/linux/nvmem-provider.h | 17 ++++++++++++++--- 3 files changed, 21 insertions(+), 23 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 321d7d63e068..0bc3e26e4ca8 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -46,16 +46,6 @@ struct nvmem_device { #define to_nvmem_device(d) container_of(d, struct nvmem_device, dev) #define FLAG_COMPAT BIT(0) -struct nvmem_cell_entry { - const char *name; - int offset; - int bytes; - int bit_offset; - int nbits; - struct device_node *np; - struct nvmem_device *nvmem; - struct list_head node; -}; struct nvmem_cell { struct nvmem_cell_entry *entry; @@ -1416,24 +1406,21 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem, int rc; rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes); - if (rc) return rc; + if (len) + *len = cell->bytes; /* shift bits in-place */ if (cell->bit_offset || cell->nbits) nvmem_shift_read_buffer_in_place(cell, buf); if (nvmem->cell_post_process) { - rc = nvmem->cell_post_process(nvmem->priv, id, - cell->offset, buf, cell->bytes); + rc = nvmem->cell_post_process(nvmem->priv, cell, id, buf, len); if (rc) return rc; } - if (len) - *len = cell->bytes; - return 0; } diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c index 14284e866f26..d383989d48bf 100644 --- a/drivers/nvmem/imx-ocotp.c +++ b/drivers/nvmem/imx-ocotp.c @@ -222,8 +222,8 @@ static int imx_ocotp_read(void *context, unsigned int offset, return ret; } -static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, - void *data, size_t bytes) +static int imx_ocotp_cell_pp(void *context, struct nvmem_cell_entry *cell, + const char *id, void *data, size_t *len) { struct ocotp_priv *priv = context; @@ -233,8 +233,8 @@ static int imx_ocotp_cell_pp(void *context, const char *id, unsigned int offset, u8 *buf = data; int i; - for (i = 0; i < bytes/2; i++) - swap(buf[i], buf[bytes - i - 1]); + for (i = 0; i < cell->bytes / 2; i++) + swap(buf[i], buf[cell->bytes - i - 1]); } } diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h index 50caa117cb62..b0d2b6af9f37 100644 --- a/include/linux/nvmem-provider.h +++ b/include/linux/nvmem-provider.h @@ -14,14 +14,25 @@ #include struct nvmem_device; -struct nvmem_cell_info; + +struct nvmem_cell_entry { + const char *name; + int offset; + int bytes; + int bit_offset; + int nbits; + struct device_node *np; + struct nvmem_device *nvmem; + struct list_head node; +}; + typedef int (*nvmem_reg_read_t)(void *priv, unsigned int offset, void *val, size_t bytes); typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset, void *val, size_t bytes); /* used for vendor specific post processing of cell data */ -typedef int (*nvmem_cell_post_process_t)(void *priv, const char *id, unsigned int offset, - void *buf, size_t bytes); +typedef int (*nvmem_cell_post_process_t)(void *priv, struct nvmem_cell_entry *cell, const char *id, + void *buf, size_t *len); enum nvmem_type { NVMEM_TYPE_UNKNOWN = 0,