lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ