* mmio_nvram.c users ?
@ 2010-05-25 7:43 Benjamin Herrenschmidt
2010-05-25 8:41 ` Adrian Reber
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2010-05-25 7:43 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: mmio_nvram.c users ?
2010-05-25 7:43 mmio_nvram.c users ? Benjamin Herrenschmidt
@ 2010-05-25 8:41 ` Adrian Reber
2010-05-25 8:43 ` Martyn Welch
2010-05-25 11:00 ` Josh Boyer
2 siblings, 0 replies; 9+ messages in thread
From: Adrian Reber @ 2010-05-25 8:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mmio_nvram.c users ?
2010-05-25 7:43 mmio_nvram.c users ? Benjamin Herrenschmidt
2010-05-25 8:41 ` Adrian Reber
@ 2010-05-25 8:43 ` Martyn Welch
2010-05-25 11:00 ` Josh Boyer
2 siblings, 0 replies; 9+ messages in thread
From: Martyn Welch @ 2010-05-25 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mmio_nvram.c users ?
2010-05-25 7:43 mmio_nvram.c users ? Benjamin Herrenschmidt
2010-05-25 8:41 ` Adrian Reber
2010-05-25 8:43 ` Martyn Welch
@ 2010-05-25 11:00 ` Josh Boyer
2010-05-29 3:45 ` Benjamin Herrenschmidt
2 siblings, 1 reply; 9+ messages in thread
From: Josh Boyer @ 2010-05-25 11:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: mmio_nvram.c users ?
2010-05-25 11:00 ` Josh Boyer
@ 2010-05-29 3:45 ` Benjamin Herrenschmidt
2010-05-29 13:41 ` Josh Boyer
0 siblings, 1 reply; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2010-05-29 3:45 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
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.
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: mmio_nvram.c users ?
2010-05-29 3:45 ` Benjamin Herrenschmidt
@ 2010-05-29 13:41 ` Josh Boyer
2010-05-29 23:15 ` Benjamin Herrenschmidt
2010-05-30 0:54 ` Arnd Bergmann
0 siblings, 2 replies; 9+ messages in thread
From: Josh Boyer @ 2010-05-29 13:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: mmio_nvram.c users ?
2010-05-29 13:41 ` Josh Boyer
@ 2010-05-29 23:15 ` Benjamin Herrenschmidt
2010-05-30 0:54 ` Arnd Bergmann
1 sibling, 0 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2010-05-29 23:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd Bergmann
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mmio_nvram.c users ?
2010-05-29 13:41 ` Josh Boyer
2010-05-29 23:15 ` Benjamin Herrenschmidt
@ 2010-05-30 0:54 ` Arnd Bergmann
2010-05-30 5:13 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2010-05-30 0:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: mmio_nvram.c users ?
2010-05-30 0:54 ` Arnd Bergmann
@ 2010-05-30 5:13 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 9+ messages in thread
From: Benjamin Herrenschmidt @ 2010-05-30 5:13 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-05-30 5:13 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-25 7:43 mmio_nvram.c users ? Benjamin Herrenschmidt
2010-05-25 8:41 ` Adrian Reber
2010-05-25 8:43 ` Martyn Welch
2010-05-25 11:00 ` Josh Boyer
2010-05-29 3:45 ` Benjamin Herrenschmidt
2010-05-29 13:41 ` Josh Boyer
2010-05-29 23:15 ` Benjamin Herrenschmidt
2010-05-30 0:54 ` Arnd Bergmann
2010-05-30 5:13 ` Benjamin Herrenschmidt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).