On Saturday 29 May 2010, Josh Boyer wrote:
> On Sat, May 29, 2010 at 01:45:04PM +1000, Benjamin Herrenschmidt wrote:
> >On Tue, 2010-05-25 at 07:00 -0400, Josh Boyer wrote:
> >> On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
> >> >Hi folks !
> >> >
> >> >Anybody aware of anything other than Cell using that driver ?
> >> >
> >> >I'd like to make it a platform driver instead of having something that
> >> >pokes at anything that has a "device_type" set to "nvram" (which is
> >> >gross and bogus). But I need to know what platforms to fixup...
> >>
> >> Why bother? You could just use either drivers/mtd/devices/{phram.c or
> >> slram.c}
> >> and get the same functionality at that point, couldn't you?
> >
> >Won't that break existing userspace ?
>
> Probably. Maybe we shouldn't have duplicated a driver in our platform code to
> begin with.
The reason we have the driver is so that we're able to use the kernel
internal functions for arch/powerpc/kernel/nvram_64.c on it, which
operated on the well-defined interface for partitions inside of the
nvram memory.
mtd/phram provides a completely different abstraction, which is normally
used for block- or file system based access. They also both have
the character device, but that's not really the main point.
The part that is unfortunate is the device_type matching in the driver,
which was a result of clueluess firmware and Linux developers (i.e. me)
at the time.
Arnd
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
