linux-kernel - Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA9_cmetqnqTQPCd8ya5AJPKQw8ary8CwsE6TUv=f57O=_MH5w@mail.gmail.com>
Date:	Thu, 28 May 2015 18:20:50 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, devicetree@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sascha Hauer <s.hauer@...gutronix.de>, sboyd@...eaurora.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	pantelis.antoniou@...sulko.com, Rob Herring <robh+dt@...nel.org>,
	Mark Brown <broonie@...nel.org>,
	Kumar Gala <galak@...eaurora.org>, mporter@...sulko.com,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	linux-api@...r.kernel.org, linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap.

On Thu, May 21, 2015 at 9:42 AM, Srinivas Kandagatla
<srinivas.kandagatla@...aro.org> wrote:
> Thankyou all for providing inputs and comments on previous versions of this patchset.
> Here is the v5 of the patchset addressing all the issues raised as
> part of previous versions review.
>
> This patchset adds a new simple NVMEM framework to kernel.
>
> Up until now, NVMEM drivers were stored in drivers/misc, where they all had to
> duplicate pretty much the same code to register a sysfs file, allow in-kernel
> users to access the content of the devices they were driving, etc.
>
> This was also a problem as far as other in-kernel users were involved, since
> the solutions used were pretty much different from on driver to another, there
> was a rather big abstraction leak.
>
> Introduction of this framework aims at solving this. It also introduces DT
> representation for consumer devices to go get the data they require (MAC
> Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs.
>
> After learning few things about QCOM qfprom and other eeprom/efuses, which
> has packed fields at bit level. Which makes it important to add support to
> such memories. This version adds support to this type of non volatile
> memories by adding support to bit level nvmem-cells.
>
> Having regmap interface to this framework would give much better
> abstraction for nvmems on different buses.
>
> patch 1-2 Introduces two regmap helper functions.
> patch 3-6 Introduces the NVMEM framework.
> Patch 7 Adds helper functions for nvmems based on mmio.
> Patch 8 migrates an existing driver to nvmem framework.
> Patch 9-10 Adds Qualcomm specific qfprom driver.
> Patch 11 adds entry in MAINTAINERS.
>
> Its also possible to migrate other nvmem drivers to this framework.
>
> Providers APIs:
>         nvmem_register/unregister();
>
> Consumers APIs:
> Cell based apis for both DT/Non-DT:
>         nvmem_cell_get()/nvmem_cell_put();
>         nvmem_cell_read()/nvmem_cell_write();
>
> Raw byte access apis for both DT/non-DT.
>         nvmem_device_get()/nvmem_device_put()
>         nvmem_device_read()/nvmem_device_write();
>         nvmem_device_cell_read()/nvmem_device_cell_write();
>
> Device Tree:
>
>         /* Provider */
>         qfprom: qfprom@...00000 {
>                 ...
>
>                 /* Data cells */
>                 tsens_calibration: calib@404 {
>                         reg = <0x404 0x10>;
>                 };
>
>                 tsens_calibration_bckp: calib_bckp@504 {
>                         reg = <0x504 0x11>;
>                         bit-offset = 6;
>                         nbits = 128;
>                 };
>
>                 pvs_version: pvs-version@6 {
>                         reg = <0x6 0x2>
>                         bit-offset = 7;
>                         nbits = 2;
>                 };
>
>                 speed_bin: speed-bin@c{
>                         reg = <0xc 0x1>;
>                         bit-offset = 2;
>                         nbits   = 3;
>
>                 };
>                 ...
>         };
>
> userspace interface: binary file in /sys/class/nvmem/*/nvmem
>
> ex:
> hexdump /sys/class/nvmem/qfprom0/nvmem
>
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> ...
> *
> 0001000
>
> Changes since v4(https://lkml.org/lkml/2015/3/30/725)
>  * rename eeprom to nvmem suggested by Matt Porter

Apologies for the bikeshed fly-by review, but given we already have
NVME and are adding an NVDIMM driver sub-system is s/eeprom/nvmem/ a
good idea?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/