Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver | Date | Sat, 21 May 2011 10:32:51 +0200 |
| |
On Saturday 21 May 2011 09:46:55 Eric Biederman wrote: > On Fri, May 20, 2011 at 4:39 PM, Chris Metcalf <cmetcalf@tilera.com> wrote: > > On 5/20/2011 6:40 PM, Eric Biederman wrote: > > The direct motivation for this case is to "impedance match" to the > > hypervisor driver for this device, which handles sector management > > internally, so the Linux device doesn't have to. Having a 'flush' method > > avoids excessive re-writes of the same sector for certain access patterns. > > The only alternatives that I see are to rewrite the tile userspace tools, > > but they are the way they are because the current model gives good > > consistency guarantees for writing the boot rom in the presence of > > arbitrary failure modes; or, to add something like a delayed timer event > > that allows the Linux driver to notify the hypervisor driver that writes > > are likely complete and it can write out the last sector. Neither of these > > are particularly attractive. > > What is wrong with an mtd driver? > > Looking a bit back into the conversation it appears clear that you are > talking about something that resembles NOR flash with multiple sectors, > etc. > > eeproms have random byte access and are typically 256 bytes. You devices > doesn't sound anything like an eeprom.
MTD implies that you have low-level access to the NOR flash registers, which this one doesn't. It's certainly not the right Linux interface for a high-level flash device, and there is no precedent for this at all in Linux.
We do have precedent for multiple interfaces that have the same purpose as this one:
drivers/misc/eeprom/* drivers/char/ps3flash.c drivers/char/nwflash.c drivers/char/bfin-otp.c arch/powerpc/kernel/rtas_flash.c drivers/sbus/char/jsflash.c
And then some more that I missed, plus the ones that use MTD.
Arnd
| |