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]

Message-ID: <AANLkTimyrGkqtjo99+aV+N4KcrC2_3PprpRD2tRo_NtC@mail.gmail.com>
Date:	Thu, 27 Jan 2011 19:54:41 +0000
From:	Daniel Drake <dsd@...top.org>
To:	Andres Salomon <dilinger@...ued.net>
Cc:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	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

Hi,



On 14 January 2011 21:43, Andres Salomon <dilinger@...ued.net> wrote:
>> In case "[v2,13/15] x86/rtc: don't register rtc if we the DT blob" [0]
>> goes into the category "lost track" and not "had no time to reply"
>> could please take a look? The important part is where it could change
>> behavior for OLPC and it migh end up without a RTC. I Cc Andres
>> Salomon as might know where the RTC on OLPC is comming from.
>
> The RTC that OLPC uses for XO-1 was interspersed w/ the power management
> stuff, so it hasn't gone upstream yet (dsd is still working on the pm
> stuff). Thus, for Linus kernels the XO-1 uses rtc_cmos; so yes, this
> could break things.
>
> On OLPC kernels on the XO-1, we read RTC information from the
> CS5536's MSRs (note that there's nothing there that's OLPC-specific, so
> this should probably become a generic geode RTC driver).  I'm unfamiliar
> with the XO-1.5, but it appears we use the VX855 RTC (at least for
> wakeups). I don't see a specific RTC driver for it, so I suspect it
> relies on rtc_cmos.

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.

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.

Does that make sense?

Thanks,
Daniel
--
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/