linux-kernel - Re: MTD EEPROM support and driver integration

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]

Date:	Sun, 7 Jul 2013 09:15:01 +0200
From:	Maxime Ripard <maxime.ripard@...e-electrons.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Artem Bityutskiy <dedekind1@...il.com>,
	Shawn Guo <shawn.guo@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	oliver@...inagl.nl, linux-mtd@...ts.infradead.org,
	Wolfram Sang <wsa@...-dreams.de>,
	Jean Delvare <khali@...ux-fr.org>, linux-i2c@...r.kernel.org
Subject: Re: MTD EEPROM support and driver integration

On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
> On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
> > What other option would we have?
> > 
> > I also thought about writing an EEPROM framework of its own, but the
> > line is really thin between a large EEPROM and say a small SPI
> > dataflash, which would make it pretty hard to choose between such a
> > framework and MTD.
> 
> Isn't flash by definition block based, while EEPROM can be written
> in byte or word units? I think that is a significant difference, although
> it doesn't necessarily mean that we can't use MTD for both.

Ah, right.

> We also have a bunch of OTP drivers spread around the kernel, it probably
> makes sense to consolidate them at the same time, at least on the DT binding
> side if not the device drivers.

From a quick grep, the only one I've seen so far are:
  - imx6q, that has a hook at machine start to poke into its OCOTP to
    retrieve some frequency scaling parameters it seems. I'm not sure
    how the current solution could improve the situation for this
    use-case, but the DT bindings of the OCOTP is just a DT node, with
    no clients, so we have nothing to worry about here.
  - imx28, that has a hook at machine start to look up the MAC address
    values and patch the ethernet controller nodes to add the right
    local-mac-address property. This one could benefit from the new
    bindings, but we already mentionned it, and I intended to develop
    with an imx28 board anyway.
  - picoxcell-pc3x3 DTSI has a node for a OTP device, but they don't
    seem to be doing anything with it, nor do they seem to have a driver
    for it. So I guess we don't care about migrating for this one
    either.

Did you have other cases in mind?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)