* Wang Long <long.wangl...@huawei.com> [150327 02:43]: > If we set ramoops.mem_type=1 in command line, the current > code can not change mem_type to 1, because it is assigned > to 0 in function ramoops_register_dummy. > > This patch make it possible to change mem_type parameter > in command line. > > Signed-off-by: Wang Long <long.wangl...@huawei.com> > > --- > fs/pstore/ram.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c > index 44a549b..65e0532 100644 > --- a/fs/pstore/ram.c > +++ b/fs/pstore/ram.c > @@ -65,7 +65,7 @@ module_param(mem_size, ulong, 0400); > MODULE_PARM_DESC(mem_size, > "size of reserved RAM used to store oops/panic logs"); > > -static unsigned int mem_type; > +static unsigned int mem_type = 0; > module_param(mem_type, uint, 0600); > MODULE_PARM_DESC(mem_type, > "set to 1 to try to use unbuffered memory (default 0)");
The BSS gets cleared during init so no need to initialize the mem_type separately here and you can drop the change above AFAIK. > @@ -608,7 +608,7 @@ static void ramoops_register_dummy(void) > > dummy_data->mem_size = mem_size; > dummy_data->mem_address = mem_address; > - dummy_data->mem_type = 0; > + dummy_data->mem_type = mem_type; > dummy_data->record_size = record_size; > dummy_data->console_size = ramoops_console_size; > dummy_data->ftrace_size = ramoops_ftrace_size; For this change sounds like a bug. Sorry I was not able to test that with the hardware I have here. Good thing you have been able to verify it with your hardware. If you drop the first part and repost, please also feel free to add: Acked-by: Tony Lindgren <t...@atomide.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
