Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver

[Eric Biederman <ebiederm@aristanetworks.com>]

On Sat, May 21, 2011 at 6:52 AM, Chris Metcalf <cmetcalf@tilera.com> wrote:
> Interesting!  I did in fact assume that most tools that read or write
> eeproms would tend to be "batch" tools, i.e. they would read or write
> whatever it was they wanted, then exit; the tool we have that modifies this
> EEPROM is written like that, for example.  It sounds like you're saying
> there are (or may be) tools that open the file descriptor and do writes to
> it, then don't exit or close the file descriptor, but expect the last write
> to have hit the device immediately.  It's fair to say that since my
> suggested API does defer the last sector's worth of writes until the app
> exits, it potentially violates that assumption, so it's a bad idea.

Plus the other gigantic difference that I have seen very few eeproms
that can hold a sectors worth of data.

My reading of this conversation is that you are confusing a configuration
eeprom with a nor flash boot device.  That is a bit like confusing a yellow
sticky not with the Encyclopedia Britannica.   They aren't at all the
same thing.

> On 5/21/2011 3:46 AM, Eric Biederman wrote:
>> What is wrong with an mtd driver?
>
> More backstory: we actually have an MTD driver for this device (in our
> local tree as drivers/mtd/devices/tile_srom.c) but we haven't yet tried to
> push it back to the community.  But it doesn't work for the most important
> purpose of this device, namely to serve as one of the possible boot streams
> at power-on.  For this, we have to control exactly what data is on what
> sector, which means a character (or sysfs) device.

How can an MTD driver not work to control exactly what data is on what
sector????  That is what MTD drivers do.

It sounds like you have a bug in either your userspace tools or your
implementation of your mtd driver.  That is definitely not a reason to
dump your device into a char device (mtdchar already exists).

> Sounds like the consensus is that a character driver is in fact the best
> option here.

I think the consensus is that your design is buggy.

Eric