From nobody Sun Feb 8 09:27:44 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBF31C7EE23 for ; Mon, 5 Jun 2023 13:34:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232426AbjFENed (ORCPT ); Mon, 5 Jun 2023 09:34:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44848 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231370AbjFENe1 (ORCPT ); Mon, 5 Jun 2023 09:34:27 -0400 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE1D8DB for ; Mon, 5 Jun 2023 06:34:25 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1685972064; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Kf6zgkDUnecNfzu3j5XSu5/huKGd/SdarF/Qmk9HXkg=; b=e3vzuYc+FQS4U26zWHOa1Nuw6wzI+Q4pu2QiWAwmFJXBtt41NvtzYC1g475fXEc3IgpvJw 8aUqcvLqwYSmAynnaUt/sHuvpppFiaCQzZj0lRYQTsVRz0jSFIYiCLVMsnZsquD3tbVbnd AKBla+3BywAN+pzMNKc+XyRR7WKQ85MGhQLX+aJKceuDSC0MlKHcfAQrG9LMLEI5HeHcWj bcB+XNWPssl6VnooV+EqkYBphWXFuj0Xz0nTp24ClEa6dN0bHzuTaQ/nBCwkbufGB6iWmX JRj0kBUsmLHWdPTDc6DzKYfhKMYyzNZXYhy1PsmJZgUNhgVLzE7pPjq95qi7Yw== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id A553DFF80D; Mon, 5 Jun 2023 13:34:23 +0000 (UTC) From: Miquel Raynal To: Greg Kroah-Hartman Cc: Luka Perkov , Robert Marko , Thomas Petazzoni , , Srinivas Kandagatla , Rafael J Wysocki , Miquel Raynal Subject: [PATCH v3 1/4] sysfs: Improve readability by following the kernel coding style Date: Mon, 5 Jun 2023 15:34:19 +0200 Message-Id: <20230605133422.45840-2-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230605133422.45840-1-miquel.raynal@bootlin.com> References: <20230605133422.45840-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The purpose of the if/else block is to select the right sysfs directory entry to be used for the files creation. At a first look when you have the file in front of you, it really seems like the "create_files()" lines right after the block are badly indented and the "else" does not guard. In practice the code is correct but lacks curly brackets to show where the big if/else block actually ends. Add these brackets to comply with the current kernel coding style and to ease the understanding of the whole logic. Signed-off-by: Miquel Raynal --- fs/sysfs/group.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c index eeb0e3099421..990309132c93 100644 --- a/fs/sysfs/group.c +++ b/fs/sysfs/group.c @@ -142,8 +142,10 @@ static int internal_create_group(struct kobject *kobj,= int update, return PTR_ERR(kn); } } - } else + } else { kn =3D kobj->sd; + } + kernfs_get(kn); error =3D create_files(kn, kobj, uid, gid, grp, update); if (error) { --=20 2.34.1 From nobody Sun Feb 8 09:27:44 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72815C7EE2D for ; Mon, 5 Jun 2023 13:34:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234112AbjFENek (ORCPT ); Mon, 5 Jun 2023 09:34:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233783AbjFENe2 (ORCPT ); Mon, 5 Jun 2023 09:34:28 -0400 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E385BE6 for ; Mon, 5 Jun 2023 06:34:26 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1685972065; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BnxJRDgHOO186L7ZZTLYXtl0YeXqHFhN/6nM2DacTKg=; b=TRpLEJJ5RPsMqlYRSwTrPxboO1YiZ9iFV9/0prjcNUVaAZxz218DVb2/7301Y5ZN8KPFD1 q9GMln5iiWA2M0x2gMo336cxE1jlh6OHdn7j6IZ4aW1lazo9OjiPpxqcMPSoL/bh9EAnKi pH1Ghaep30P5YJSCBzvD+rphACpH/BUrCj9ecM2rei9R6o9HwmXTDBtwNT09YCrm/75dvd 9XAVXeH8GNqKGQmIGcMweIDiB8aVl4M+7xY2lc8w57KPcIOV9+4fWTK0STLiq54DLGF/UX ZIsFDiceT+4m+HcKiwhMvGQkbbaIBKT4ha8upQQhxauX6rNYMbXjR2jGkdgTzA== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 70937FF80C; Mon, 5 Jun 2023 13:34:24 +0000 (UTC) From: Miquel Raynal To: Greg Kroah-Hartman Cc: Luka Perkov , Robert Marko , Thomas Petazzoni , , Srinivas Kandagatla , Rafael J Wysocki , Miquel Raynal Subject: [PATCH v3 2/4] sysfs: Skip empty folders creation Date: Mon, 5 Jun 2023 15:34:20 +0200 Message-Id: <20230605133422.45840-3-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230605133422.45840-1-miquel.raynal@bootlin.com> References: <20230605133422.45840-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Most sysfs attributes are statically defined, the goal with this design being to be able to move all the filesystem description into read-only memory. Anyway, it may be relevant in some cases to populate attributes at run time. This leads to situation where an attribute may or may not be present depending on conditions which are not known at compile time, up to the point where no attribute at all gets added in a folder which then becomes "sometimes" empty. Problem is, providing an attribute group with a name and without .[bin_]attrs members will be loudly refused by the core, leading in most cases to a device registration failure. The simple way to support such situation right now is to dynamically allocate an empty attribute array, which is: * a (small) waste of space * a waste of time * disturbing, to say the least, as an empty sysfs folder will be created anyway. Another (even worse) possibility would be to dynamically overwrite a member of the attribute_group list, hopefully the last, which is also supposed to remain in the read-only section. In order to avoid these hackish situations, while still giving a little bit of flexibility, we might just check the validity of the .[bin_]attrs list and, if empty, just skip the attribute group creation instead of failing. This way, developers will not be tempted to workaround the core with useless allocations or strange writes on supposedly read-only structures. The content of the WARN() message is kept but turned into a debug message in order to help developers understanding why their sysfs folders might now silently fail to be created. Signed-off-by: Miquel Raynal --- Hello Greg, This is the solution I opted for to avoid core splats when creating empty sysfs directories. The nice side effect is that the directories do not even get created which seem the right approach in this case and avoids to deal with any kind of cleanup either (or maybe I overlooked something?). Let me know what you think of it. This is a try of course, perhaps we need something way more robust, but at a first look it seemed perfectly consistent. Thanks, Miqu=C3=A8l fs/sysfs/group.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c index 990309132c93..138676463336 100644 --- a/fs/sysfs/group.c +++ b/fs/sysfs/group.c @@ -118,11 +118,13 @@ static int internal_create_group(struct kobject *kobj= , int update, /* Updates may happen before the object has been instantiated */ if (unlikely(update && !kobj->sd)) return -EINVAL; + if (!grp->attrs && !grp->bin_attrs) { - WARN(1, "sysfs: (bin_)attrs not set by subsystem for group: %s/%s\n", - kobj->name, grp->name ?: ""); - return -EINVAL; + pr_debug("sysfs: (bin_)attrs not set by subsystem for group: %s/%s, skip= ping\n", + kobj->name, grp->name ?: ""); + return 0; } + kobject_get_ownership(kobj, &uid, &gid); if (grp->name) { if (update) { --=20 2.34.1 From nobody Sun Feb 8 09:27:44 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EB77C7EE24 for ; Mon, 5 Jun 2023 13:34:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234154AbjFENep (ORCPT ); Mon, 5 Jun 2023 09:34:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234098AbjFENe2 (ORCPT ); Mon, 5 Jun 2023 09:34:28 -0400 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2ED0D2 for ; Mon, 5 Jun 2023 06:34:27 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1685972066; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QUIYbUJt+Cl/OQINsVO/8Ug45EH5iacT/hNl2EpfQ/k=; b=nX8jdpMVZCkY0JwiNgTs2/AkkYvqZZn70B8zIx8fV36lLjX1u/q+PtFaQk17mqeCzZ9Y9q 4k9wefyFwIaRU6M6pN0ARpgZ5HslssfZe5panS+n0HArfzJDVAcYFSA4m/Xiu1r9QdY6sj eKRekgpftSP1oCaJQ2tFBai8FmQCNHHTtFCONXfZ3p2pynsr8bEMwqHmWOW5sipa5EKFFy qccypx4kWWWdfQ1Oe1aZObMw4D80tybwefnIJz1q46x0MZWr+jpcO+u0kU+nizOyge8G+S nY89es1Mlw2WrJ+rl4yYaoPreZw0TqtDpTWMoD3Kqt2yoerdRXk0OsXbcVrnng== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id D2921FF80E; Mon, 5 Jun 2023 13:34:25 +0000 (UTC) From: Miquel Raynal To: Greg Kroah-Hartman Cc: Luka Perkov , Robert Marko , Thomas Petazzoni , , Srinivas Kandagatla , Rafael J Wysocki , Miquel Raynal Subject: [PATCH v3 3/4] ABI: sysfs-nvmem-cells: Expose cells through sysfs Date: Mon, 5 Jun 2023 15:34:21 +0200 Message-Id: <20230605133422.45840-4-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230605133422.45840-1-miquel.raynal@bootlin.com> References: <20230605133422.45840-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The binary content of nvmem devices is available to the user so in the easiest cases, finding the content of a cell is rather easy as it is just a matter of looking at a known and fixed offset. However, nvmem layouts have been recently introduced to cope with more advanced situations, where the offset and size of the cells is not known in advance or is dynamic. When using layouts, more advanced parsers are used by the kernel in order to give direct access to the content of each cell regardless of their position/size in the underlying device, but these information were not accessible to the user. By exposing the nvmem cells to the user through a dedicated cell/ folder containing one file per cell, we provide a straightforward access to useful user information without the need for re-writing a userland parser. Content of nvmem cells is usually: product names, manufacturing date, MAC addresses, etc, Signed-off-by: Miquel Raynal --- Documentation/ABI/testing/sysfs-nvmem-cells | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-nvmem-cells diff --git a/Documentation/ABI/testing/sysfs-nvmem-cells b/Documentation/AB= I/testing/sysfs-nvmem-cells new file mode 100644 index 000000000000..641a7d7dad76 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-nvmem-cells @@ -0,0 +1,19 @@ +What: /sys/bus/nvmem/devices/.../cells/ +Date: May 2023 +KernelVersion: 6.5 +Contact: Miquel Raynal +Description: + The cells/ folder contains one file per cell exposed by + the nvmem device. The name of the file is the cell name. + The length of the file is the size of the cell (when + known). The content of the file is the binary content of + the cell (may sometimes be ASCII, likely without + trailing character). + Note: This file is only present if CONFIG_NVMEM_SYSFS + is enabled + + ex:: + + hexdump -C /sys/bus/nvmem/devices/1-00563/cells/product-name + 00000000 54 4e 34 38 4d 2d 50 2d 44 4e |TN48M-P-DN| + 0000000a --=20 2.34.1 From nobody Sun Feb 8 09:27:44 2026 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6454AC7EE2D for ; Mon, 5 Jun 2023 13:35:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234128AbjFENeu (ORCPT ); Mon, 5 Jun 2023 09:34:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234101AbjFENea (ORCPT ); Mon, 5 Jun 2023 09:34:30 -0400 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A83EDA for ; Mon, 5 Jun 2023 06:34:28 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1685972067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ul0VaxBEo8g8rMrRqLfw/GSk/B+aKOEx/21Oio7OP10=; b=QalijX1ciJf2AhowToySXhKEEnq6CMrQWEe9uwjZZt+YlTt7oC/3IIPTXWE58twZuB9P4T 5unLopqKTsNYZDXXITVKcUOheClxnnPj6CC/uIv1SlVG7fcKscgYKRkynPj3Bmkj+L00WH vIU5Xtz154IpL4UAXmNKi3hTqbmkED0lwgrvkXA43jnclNx1R5aBs3VsxERD3pZAuJAwfJ CU92KVGReiPVRK9b+FfcwjCni6dO4GVH9puOX/URaR4YDdtxFXK0A1xvIOw78S5V03xe5F 0LOA5t6CWhKHuziokEZ8f7FR+eNK57/NNd13K1Y16UDuMyNvWop63G/Z5iiHlw== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 9DDA3FF810; Mon, 5 Jun 2023 13:34:26 +0000 (UTC) From: Miquel Raynal To: Greg Kroah-Hartman Cc: Luka Perkov , Robert Marko , Thomas Petazzoni , , Srinivas Kandagatla , Rafael J Wysocki , Miquel Raynal Subject: [PATCH v3 4/4] nvmem: core: Expose cells through sysfs Date: Mon, 5 Jun 2023 15:34:22 +0200 Message-Id: <20230605133422.45840-5-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230605133422.45840-1-miquel.raynal@bootlin.com> References: <20230605133422.45840-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The binary content of nvmem devices is available to the user so in the easiest cases, finding the content of a cell is rather easy as it is just a matter of looking at a known and fixed offset. However, nvmem layouts have been recently introduced to cope with more advanced situations, where the offset and size of the cells is not known in advance or is dynamic. When using layouts, more advanced parsers are used by the kernel in order to give direct access to the content of each cell, regardless of its position/size in the underlying device. Unfortunately, these information are not accessible by users, unless by fully re-implementing the parser logic in userland. Let's expose the cells and their content through sysfs to avoid these situations. Of course the relevant NVMEM sysfs Kconfig option must be enabled for this support to be available. Not all nvmem devices expose cells. Indeed, the .bin_attrs attribute group member will be filled at runtime only when relevant and will remain empty otherwise. In this case, as the cells attribute group will be empty, it will not lead to any additional folder/file creation. Exposed cells are read-only. There is, in practice, everything in the core to support a write path, but as I don't see any need for that, I prefer to keep the interface simple (and probably safer). The interface is documented as being in the "testing" state which means we can later add a write attribute if though relevant. There is one limitation though: if a layout is built as a module but is not properly installed in the system and loaded manually with insmod while the nvmem device driver was built-in, the cells won't appear in sysfs. But if done like that, the cells won't be usable by the built-in kernel drivers anyway. Signed-off-by: Miquel Raynal --- drivers/nvmem/core.c | 128 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 124 insertions(+), 4 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 342cd380b420..625e3de273b7 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -325,6 +325,61 @@ static umode_t nvmem_bin_attr_is_visible(struct kobjec= t *kobj, return nvmem_bin_attr_get_umode(nvmem); } =20 +static struct nvmem_cell *nvmem_create_cell(struct nvmem_cell_entry *entry, + const char *id, int index); + +static ssize_t nvmem_cell_attr_read(struct file *filp, struct kobject *kob= j, + struct bin_attribute *attr, char *buf, + loff_t pos, size_t count) +{ + struct nvmem_cell_entry *entry; + struct nvmem_cell *cell =3D NULL; + struct nvmem_device *nvmem; + size_t cell_sz, read_len; + struct device *dev; + void *content; + + if (attr->private) + dev =3D attr->private; + else + dev =3D kobj_to_dev(kobj); + nvmem =3D to_nvmem_device(dev); + + mutex_lock(&nvmem_mutex); + list_for_each_entry(entry, &nvmem->cells, node) { + if (strncmp(entry->name, attr->attr.name, XATTR_NAME_MAX)) + continue; + + cell =3D nvmem_create_cell(entry, entry->name, 0); + if (IS_ERR(cell)) { + mutex_unlock(&nvmem_mutex); + return PTR_ERR(cell); + } + + break; + } + mutex_unlock(&nvmem_mutex); + + if (!cell) + return -EINVAL; + + content =3D nvmem_cell_read(cell, &cell_sz); + if (IS_ERR(content)) { + read_len =3D PTR_ERR(content); + goto destroy_cell; + } + + read_len =3D min_t(unsigned int, cell_sz - pos, count); + memcpy(buf, content + pos, read_len); + kfree(content); + +destroy_cell: + kfree_const(cell->id); + kfree(cell); + + return read_len; +} + /* default read/write permissions */ static struct bin_attribute bin_attr_rw_nvmem =3D { .attr =3D { @@ -346,8 +401,14 @@ static const struct attribute_group nvmem_bin_group = =3D { .is_bin_visible =3D nvmem_bin_attr_is_visible, }; =20 +/* Cell attributes will be dynamically allocated */ +static struct attribute_group nvmem_cells_group =3D { + .name =3D "cells", +}; + static const struct attribute_group *nvmem_dev_groups[] =3D { &nvmem_bin_group, + &nvmem_cells_group, NULL, }; =20 @@ -406,6 +467,59 @@ static void nvmem_sysfs_remove_compat(struct nvmem_dev= ice *nvmem, device_remove_bin_file(nvmem->base_dev, &nvmem->eeprom); } =20 +static int nvmem_populate_sysfs_cells(struct nvmem_device *nvmem) +{ + struct bin_attribute **cells_attrs, *attrs; + struct nvmem_cell_entry *entry; + unsigned int ncells =3D 0, i =3D 0; + int ret =3D 0; + + mutex_lock(&nvmem_mutex); + + if (list_empty(&nvmem->cells)) + goto unlock_mutex; + + list_for_each_entry(entry, &nvmem->cells, node) + ncells++; + + /* Allocate an array of attributes with a sentinel */ + cells_attrs =3D devm_kcalloc(&nvmem->dev, ncells + 1, + sizeof(struct bin_attribute *), GFP_KERNEL); + if (!cells_attrs) { + ret =3D -ENOMEM; + goto unlock_mutex; + } + + attrs =3D devm_kcalloc(&nvmem->dev, ncells, sizeof(struct bin_attribute),= GFP_KERNEL); + if (!attrs) { + ret =3D -ENOMEM; + goto unlock_mutex; + } + + /* Initialize each attribute to take the name and size of the cell */ + list_for_each_entry(entry, &nvmem->cells, node) { + sysfs_bin_attr_init(&attrs[i]); + attrs[i].attr.name =3D devm_kstrdup(&nvmem->dev, entry->name, GFP_KERNEL= ); + attrs[i].attr.mode =3D 0444; + attrs[i].size =3D entry->bytes; + attrs[i].read =3D &nvmem_cell_attr_read; + if (!attrs[i].attr.name) { + ret =3D -ENOMEM; + goto unlock_mutex; + } + + cells_attrs[i] =3D &attrs[i]; + i++; + } + + nvmem_cells_group.bin_attrs =3D cells_attrs; + +unlock_mutex: + mutex_unlock(&nvmem_mutex); + + return ret; +} + #else /* CONFIG_NVMEM_SYSFS */ =20 static int nvmem_sysfs_setup_compat(struct nvmem_device *nvmem, @@ -976,16 +1090,22 @@ struct nvmem_device *nvmem_register(const struct nvm= em_config *config) if (rval) goto err_remove_cells; =20 + rval =3D nvmem_add_cells_from_layout(nvmem); + if (rval) + goto err_remove_cells; + +#ifdef CONFIG_NVMEM_SYSFS + rval =3D nvmem_populate_sysfs_cells(nvmem); + if (rval) + goto err_remove_cells; +#endif + dev_dbg(&nvmem->dev, "Registering nvmem device %s\n", config->name); =20 rval =3D device_add(&nvmem->dev); if (rval) goto err_remove_cells; =20 - rval =3D nvmem_add_cells_from_layout(nvmem); - if (rval) - goto err_remove_cells; - blocking_notifier_call_chain(&nvmem_notifier, NVMEM_ADD, nvmem); =20 return nvmem; --=20 2.34.1