Kevin Hilman had written, on 10/05/2009 01:15 PM, the following:
+ gpmc_cs_read_reg(i, GPMC_CS_CONFIG7);
+ }
here is a theoretical bug:
1: GPMC, 1, 2, 3 4 5 configured 6 7 not configured.
2. Save and restore 1: save and restore variables which are static will
contain 1-5 and not 6&7
3. next I disable 2,3
3. save will save 1,4,5 BUT my variable will contain 1,2,3,4,5 ->
restore will rename 2,3 (which I did not intend)..
Not sure I follow the problem here. What do you mean by "rename".
The saved context will have values for 2 and 3, but the is_valid
flag will not be set, so they shouldn't be used.
My bad.. s/rename/enable/ for 2,3 ->definitely not something I would
like to see.
I must be missing something here.
I don't see how the restore will do anything if 2,3 have been disabled
(by gpmc_cs_free()). AFAICT, the save hook will have cleared the
is_valid flag, so the restore will do nothing.
For clarity, I'm also going to modify this patch to set the is_valid
flag using gpmc_cs_mem_enabled() which make it more clear that
it's using the same check as gpmc_cs_[enable|disable]_mem()
Got it. Thanks.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
