[PATCH] e1000e: Unmap NV RAM when not in use.

Tim Gardner tim.gardner at canonical.com
Fri Sep 26 15:03:35 UTC 2008


Amit Kucheria wrote:
> On Fri, Sep 26, 2008 at 7:28 AM, Tim Gardner <tim.gardner at canonical.com> wrote:
>> This is what I'm thinking for the e1000e driver. Comments?
>>
>> rtg
>> --
>> Tim Gardner tim.gardner at canonical.com
> 
> So you map/unmap nvram on init/read/update/validate and still leave
> out write_nvm() ?
> 
> Why not just do the map/unmap around acquire_swflag and release_swflag?
> 
> Regards,
> Amit
> 

OK - I've come down from my late night crackhead high and simplified the
map/unmap algorithm. It still tracks mapping depth, but only maps in the
functions that actually use the flash access macros.

In response your your comment about write_nvm(), that function only
updates shadow RAM (which could also be a source of corruption if its
flushed out to NV RAM).

Actually, I'm wondering if leaving flash I/O space mapped is really the
root cause. I just can't see how undisciplined writes to flash space
could corrupt it. In order to change flash at all you have to follow a
pretty strict command sequence of reading the contents of a block,
erasing it, then writing it back out. Both the erase and write
operations require a sequence of commands to the flash part.

Furthermore, the only time shadow RAM is committed to flash is when
ethtool writes an EEPROM image. Not something that happens unless an
operator explicitly runs the program.

rtg
-- 
Tim Gardner tim.gardner at canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-UBUNTU-SAUCE-e1000e-Map-NV-RAM-dynamically-only-w.patch
Type: text/x-diff
Size: 6962 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20080926/be11a8c7/attachment.patch>


More information about the kernel-team mailing list