Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3906232imm; Wed, 5 Sep 2018 07:50:01 -0700 (PDT) X-Google-Smtp-Source: ANB0VdboW8eXZeeS6US3a0g3egzL698Tmv7sUQdJy8rbO4gLThC+LhcOn4Ry47zOtUFZYhGHN4VP X-Received: by 2002:a17:902:bb85:: with SMTP id m5-v6mr39162715pls.46.1536159001212; Wed, 05 Sep 2018 07:50:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536159001; cv=none; d=google.com; s=arc-20160816; b=W9WUcnhev1gTn3hOWI808OBEmYlbAyMhrIH8/YAQJ/+bTmTjC3j7kfWbr9m+rz8EcD YkyERYeApNhPs2VaWlvfVuDBSNrv+Fyv1xmbtNW5lC+iAg9dhSx0TqJ0v6Pk+tDpilEA FaONQ+/kKQhOWiWdKSZh8nO82P/RVap6iQmlSdityi+XvW2hN+zLQ1wa64vZg2XY/+bM H6JzSk+EbB/dDNvWurSGW8nWWFvGJIc8TIZwKYlsSqldgPpZnSZtSK+TZfVIa020L0Pc mfo5A6ecxlLTWiYMW8SU9Q3mXfZj1zSwvs9z4tRTutJqCqcva5yDj+Z3yPRRyz0dytIi IfXA== 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 :references:in-reply-to:mime-version:dkim-signature; bh=l9pDxMXzKswdZPFz08WyTfA+3C3O2/jU1c8Et0lpuxo=; b=c5aSigjw7L9fC9ZydB9YLxZkgSpGSihq9aP42+s3a6IOG3bQ/n3fNXi3H6f5Wnw0/u vgpqKG3sop0PQiJP7qWh0/vQn+qb9Zh/a1DLAP6AbHqu1jVmdrb96BYPJ+rGNjkDGflj vpz8RfQ8Mnaig4bcpQ5kVYZys+ve6nRRf4v+XzBwJkYbLb0USB+/Wneozf6246N9SjYV VsbA+BA/efDd8E0Z3h9KfQdcdCkD9zZAL1MmFomN4BgpkgNs2PZL6Iu9/qKw7mBUvEcO RrQory5euzWh41VdrTuQs220CtCSkSr/2JIDmDk0Us1hxUR8wf42u7zSJvRuZS7IcORN +Y/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b="ee4Lth/I"; 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 k10-v6si2196345pfe.41.2018.09.05.07.49.44; Wed, 05 Sep 2018 07:50:01 -0700 (PDT) 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; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b="ee4Lth/I"; 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 S1727802AbeIETSa (ORCPT + 99 others); Wed, 5 Sep 2018 15:18:30 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:56066 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727364AbeIETSa (ORCPT ); Wed, 5 Sep 2018 15:18:30 -0400 Received: by mail-it0-f66.google.com with SMTP id d10-v6so10230005itj.5 for ; Wed, 05 Sep 2018 07:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l9pDxMXzKswdZPFz08WyTfA+3C3O2/jU1c8Et0lpuxo=; b=ee4Lth/IEAm8qgztzBcw32ktio8HF0H9eToPDQDwxv83JmMJ6Od3fjCihTgjKqJAWz lHZq3ssWoJqYPuyvKfhBJrJ00bCrkzQVCKAgOUpyOCcNrMz9kZe/TpQkbDcVkpdIqIAo Hg2oNcZk6gKqhAYTZsK7ctxBOxC153lM1P8Tuq2+wRtev8FcicKPoy2gHFn1zXZFcXjm 8LCTMceHQfs8wsaiAsHpabUguh2VieGOFaurDcKi7mqQCk9YQAwYozli7rEjU/iy32he 53QoqCy+AMgVDU77XE2T6d4vmAgh640oM9XBL3j822R+4XF8d0NTs35/ChIQBdbxuKl2 AFWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l9pDxMXzKswdZPFz08WyTfA+3C3O2/jU1c8Et0lpuxo=; b=KywBlBq4gzv1hDsk0QhwpLagzpOe+q8adB/TqmxZCHDSlIf7JMrVIpr0OEHAP2OWH2 6QeO7z6FU3MhXdm3ASYvBBm8rLfSlD6FodlOudkVawE0UJpqUz+7f4U8jvcdpJbcNk8o c20cRK7VRK4l89FN/FC3qJ+OD+dkrUUFdQiym/iSJody2Tb9kYs+Ty+pR/ARB4djNDpP sgYkxcepiNRLRbi21sfPiX7aCsMVSpp2EWmLyPbAmHwgbO6ZnFjO5aWfvE/tcNIE90kh aA5RhhIYKCfwoZlnjsXO2cSaa2Whevg2VBXdj/oFokGi0nqtfhjBHgRwEnZzITf6qJOI bSkg== X-Gm-Message-State: APzg51DIzmMd0AENinAaHuwne4Tal79VObizyjbLj7SvrlceRu71eVcM 8ztjEGSjs+3Zeiz6V8ITGRa9qaeDR23fTZEjqZL+yA== X-Received: by 2002:a24:41cd:: with SMTP id b74-v6mr631100itd.85.1536158878403; Wed, 05 Sep 2018 07:47:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:238d:0:0:0:0:0 with HTTP; Wed, 5 Sep 2018 07:47:57 -0700 (PDT) In-Reply-To: <20180905162135.700d2145@bbrezillon> References: <20180905095738.26406-1-brgl@bgdev.pl> <20180905095738.26406-12-brgl@bgdev.pl> <20180905155741.22b7d0ef@bbrezillon> <20180905162135.700d2145@bbrezillon> From: Bartosz Golaszewski Date: Wed, 5 Sep 2018 16:47:57 +0200 Message-ID: Subject: Re: [PATCH 11/13] nvmem: add support for cell lookups from machine code To: Boris Brezillon Cc: Srinivas Kandagatla , Joachim Eastwood , "David S . Miller" , Mauro Carvalho Chehab , Greg Kroah-Hartman , Andrew Morton , Arnd Bergmann , Jonathan Corbet , Sekhar Nori , Kevin Hilman , David Lechner , Andrew Lunn , Alban Bedel , Maxime Ripard , linux-doc , Linux Kernel Mailing List , Linux ARM , Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-09-05 16:21 GMT+02:00 Boris Brezillon : > On Wed, 5 Sep 2018 16:00:36 +0200 > Bartosz Golaszewski wrote: > >> 2018-09-05 15:57 GMT+02:00 Boris Brezillon : >> > On Wed, 5 Sep 2018 11:57:36 +0200 >> > Bartosz Golaszewski wrote: >> > >> >> >> >> +struct nvmem_cell_lookup { >> >> + const char *nvmem_name; >> >> + const char *dev_id; >> > >> > Shouldn't we have a con_id here? >> > >> >> + const char *cell_id; >> >> + struct list_head node; >> >> +}; >> >> I wanted to stay in line with the current API - nvmem_cell_get() takes >> as argument a string called cell_id. I wanted to reflect that here. > > Actually, you need both. con_id is the name you would have in your DT > in the nvmem-cell-names property, cell_id is the name of the cell > you'd find under the nvmem device node. > > Let's take an example: > > mydev { > #nvmem-cell-names = "mac-address", "revision"; > #nvmem-cells = <&cell1>, <&cell2>; > }; > > mynvmemdev { > #size-cells = <1>; > #address-cells = <1>; > > cell1: foo@0 { > reg = <0x0 0x6>; > }; > > cell2: bar@6 { > reg = <0x6 0x10>; > }; > }; > > this can be described the same way using a consumer lookup table: > > struct nvmem_cell_lookup_entry { > const char *con_id; > const char *nvmem_name; > const char *cell_name; > }; > > struct nvmem_cell_lookup_table { > struct list_head node; > const char *dev_id; > unsigned int nentries; > const struct nvmem_cell_lookup_entry *entries; > } > > static const struct nvmem_cell_lookup_entry mydev_nvmem_cells[] = { > { > .con_id = "mac-address", > .nvmem_name = "mynvmemdev", > .cell_name = "foo", > }, > { > .con_id = "revision", > .nvmem_name = "mynvmemdev", > .cell_name = "bar", > }, > } > > static const struct nvmem_cell_lookup_table mydev_nvmem_lookup = { > .dev_id = "mydev.0", > .nentries = ARRAY_SIZE(mydev_nvmem_cells), > .entries = mydev_nvmem_cells, > }; > > > ... > > nvmem_add_cell_lookups(&mydev_nvmem_lookup); Ok I get it. Shouldn't we change the argument name of nvmem_cell_get() and friends from 'name' to 'con_id' or simply 'id' similarly to what other frameworks do to avoid such confusion? I also don't see a need for splitting the lookup into two structures here. Something like: struct nvmem_cell_lookup { const char *nvmem_name; const char *cell_name; const char *dev_id; const char *con_id; }; Would be perfectly fine and would allow to register all lookups for given machine with a single call. How often does it happen that a single device needs multiple nvmem cells anyway? Bart