linux-kernel - Re: [PATCH v2 01/15] x86/e820: remove conditional early mapping in parse_e820

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]

Date:	Thu, 3 Feb 2011 10:40:51 -0800
From:	Andres Salomon <dilinger@...ued.net>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Daniel Drake <dsd@...top.org>, linux-kernel@...r.kernel.org,
	sodaville@...utronix.de, x86@...nel.org, dirk.brandewie@...il.com
Subject: Re: [PATCH v2 01/15] x86/e820: remove conditional early mapping in
 parse_e820_ext

On Tue, 1 Feb 2011 20:10:13 -0700
Grant Likely <grant.likely@...retlab.ca> wrote:

> On Tue, Feb 1, 2011 at 11:36 AM, Andres Salomon <dilinger@...ued.net>
> wrote:
> > On Tue, 01 Feb 2011 14:21:22 +0100
> > Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> >
> >> Daniel Drake wrote:
> >> > Hi,
> >> Hi,
> >>
> >> > Context: https://patchwork.kernel.org/patch/450681/
> >> >
> >> > This patch will indeed cause problems for OLPC. Thanks for
> >> > bringing it to our attention.
> >> >
> >> > On OLPC, the device tree is not used as a source of devices like
> >> > on other platforms, it is simply used to present information to
> >> > the kernel and userspace (in read-only fashion).
> >> >
> >> > If I understand it correctly, the above patch is saying: if we
> >> > have a device tree, don't add the standard x86 RTC device.
> >> Yes.
> >>
> >> > However, what we need it to say is: if we have a device tree
> >> > *and* the device tree is being used as a source of devices,
> >> > don't add the standard x86 RTC device.
> >> >
> >> > Therefore in the OLPC case, this particular bail-out condition
> >> > will never be met, because the device tree is not being used as
> >> > a source of devices.
> >> So it is not case now. Will it ever be?
> >>
> >
> > That is unclear.  For now, it's not, and there aren't plans to make
> > it so.
> >
> >> >
> >> > Does that make sense?
> >>
> >> I don't quite get how or what for do you use the device tree. Could
> >> you please answer me the following questions:
> >> - is the variable allnodes NULL in your case?
> >
> > No.
> >
> >> - variable initial_boot_params should be NULL in your case, right?
> >
> > Yes.
> >
> >> - how should I checked for "device tree is being used as a source
> >> of devices"? The nodes on in the device tree are not probed unless
> >> one calls of_platform_bus_probe() with a few ids. However I do
> >> this now unconditionally which is not a problem unless you have a
> >> device tree ...
> >
> > Perhaps it should be specifically checking for a fdt (by way of
> > initial_boot_params)?   Sparc also does not have
> > initial_boot_params, so one might even be able to drop an #ifdef in
> > the process.
> 
> OLPC is very much the oddball in this case.  Everyone else uses
> devicetree for registering devices.  It could be solved by making OLPC
> explicitly register the RTC.
> 
> g.
> 

That's actually what the plan is; the code just depends on PM features,
which is still being worked on.

--
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/