[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201105241628.08819.stevie.trujillo@gmail.com>
Date: Tue, 24 May 2011 16:28:08 +0200
From: Stevie Trujillo <stevie.trujillo@...il.com>
To: Kyungmin Park <kmpark@...radead.org>
Cc: Américo Wang <xiyou.wangcong@...il.com>,
marco.stornelli@...il.com, linux-kernel@...r.kernel.org
Subject: Re: ramoops: is using platform_drivers correct?
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@...il.com>
wrote:
> > On Tue, May 24, 2011 at 2:14 PM, Kyungmin Park <kmpark@...radead.org>
wrote:
> >> On Tue, May 24, 2011 at 2:49 PM, Américo Wang <xiyou.wangcong@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists