Re: ramoops: is using platform_drivers correct?

[Stevie Trujillo <stevie.trujillo@gmail.com>]

On Tuesday 24 May 2011 16:16:13 Kyungmin Park wrote:
> On Tue, May 24, 2011 at 11:12 PM, Américo Wang <xiyou.wangcong@gmail.com> 
wrote:
> > On Tue, May 24, 2011 at 2:14 PM, Kyungmin Park <kmpark@infradead.org> 
wrote:
> >> On Tue, May 24, 2011 at 2:49 PM, Américo Wang <xiyou.wangcong@gmail.com> 
wrote:
> >>> Huh? Is this for x86 too? Why so unfriendly for end-users?
> >> 
> >> I don't know which address is acceptable for x86, in case of ARM, each
> >> SoCs has different SRAM address. so it's not good to define for all
> >> SoCs and ARM.
> >> 
> >>> I think we need some kernel parameter like 'crashkernel=' (or memmap=)
> >>> to reserve memory for ramoops, right?
> >> 
> >> The first implementation is just module parameters.
> >> ramoops.address=0x??????? ramoops.size=0x????. So I patched it as
> >> using platform devices.
> >> and the reason use the platform is it's dependent on each SoCs and board
> >> usage.
> > 
> > But the result is that this makes end-users harder to use it.
> > 
> > Using platform API still relies on a hard-code address, at least in
> > your example,
> > so, why not leave it as a module parameter to let user to find the
> > correct address?
> 
> It's possible. I just make it possible to use the platform driver. you
> can specify the original method.

I don't think it's possible without also having a platform_device. 
ramoops_probe is never called here, I think platform_driver_probe returns -
ENODEV.

static int __init ramoops_init(void)
{
    return platform_driver_probe(&ramoops_driver, ramoops_probe);
}

Maybe one could run platform_driver_probe() only if (!mem_address && 
!mem_size)?

Unrelated question: should the printk()s end with "\n"? I see they do that 
other places in the kernel.