linux-kernel - Re: [PATCH] platform/chrome: Add pstore platform

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: <20131125200344.GF18046@saruman.home>
Date:	Mon, 25 Nov 2013 14:03:44 -0600
From:	Felipe Balbi <balbi@...com>
To:	Olof Johansson <olof@...om.net>
CC:	Felipe Balbi <balbi@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>,
	Benson Leung <bleung@...omium.org>
Subject: Re: [PATCH] platform/chrome: Add pstore platform_device

Hi,

On Mon, Nov 25, 2013 at 11:59:50AM -0800, Olof Johansson wrote:
> >> +static int __init chromeos_pstore_init(void)
> >> +{
> >> +     if (dmi_check_system(chromeos_pstore_dmi_table))
> >
> > is this check really necessary ? I would assume that your probe would
> > only be called if the device matches the dmi MODULE_DEVICE_TABLE().
> >
> > Except that you don't have a probe function which is quite odd. Also,
> > there's nothing using chromeos_ramoops_data, how does this work ?
> 
> This is just a module that registers the device. The driver side is
> handled by pstore. See Documentation/ramoops.txt.
> 
> That's also why the DMI table is needed: The module init is generic,
> and if built-in instead of loaded based on DMI table contents, it will
> always run. There's no specific device to bind against, since there's
> none in the tables passed in from firmware in this case.

I see now, thanks :-)

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)