mmio_nvram.c users ?

mmio_nvram.c users ?

[Benjamin Herrenschmidt]

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...

Cheers,
Ben.

Re: mmio_nvram.c users ?

[Adrian Reber]

On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
> 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...

The PowerStation is also using it.

		Adrian

Re: mmio_nvram.c users ?

[Martyn Welch]

One day I'll manage to hit "Reply" or "Reply All" correctly...

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...
>
>   

We do on our boards, that would currently be the sbc310, sbc610 and
ppc9a (all FSL 86xx based boards). I also have 2 other boards I'm
currently working on that will also use that driver.

Martyn

> Cheers,
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>   


-- 
Martyn Welch (Principal Software Engineer)   |   Registered in England and
GE Intelligent Platforms                     |   Wales (3828642) at 100
T +44(0)127322748                            |   Barbirolli Square, Manchester,
E martyn.welch@ge.com                        |   M2 3AB  VAT:GB 927559189

Re: mmio_nvram.c users ?

[Josh Boyer]

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?

josh

Re: mmio_nvram.c users ?

[Benjamin Herrenschmidt]

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 ?

Cheers,
Ben.

Re: mmio_nvram.c users ?

[Josh Boyer]

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.

josh

Re: mmio_nvram.c users ?

[Benjamin Herrenschmidt]

On Sat, 2010-05-29 at 09:41 -0400, Josh Boyer wrote:
> 
> Probably.  Maybe we shouldn't have duplicated a driver in our platform
> code to begin with. 

I believe our nvram infrastructure predates it by a long shot :-)

powerpc /dev/nvram stuff is very very very ancient.

Cheers,
Ben.

Re: mmio_nvram.c users ?

[Arnd Bergmann]

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

Re: mmio_nvram.c users ?

[Benjamin Herrenschmidt]

On Sun, 2010-05-30 at 02:54 +0200, Arnd Bergmann wrote:
> 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. 

Right. Which is why I want to change it to be a platform device, so that
platforms explicitely instanciate it, which is probably the best thing
for now. That way, platforms that don't want the ppc specific nvram
stuff don't have to instanciate it, or platforms who want to use the mtd
bits, etc...

Cheers,
Ben.