Re: [PATCH v2 01/15] x86/e820: remove conditional early mapping in parse_e820_ext

[Daniel Drake]

Hi,



On 14 January 2011 21:43, Andres Salomon <dilinger@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/