Date: Wed, 4 Mar 2009 18:54:18 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Brian Maly <bmaly@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>, linux-kernel@vger.kernel.org,
       ying.huang@intel.com
Subject: Re: [PATCH] fix DMI for EFI
Message-ID: <20090304175418.GB29823@elte.hu>
References: <49A9F597.4010601@redhat.com> <86802c440902281856h1dc950e7me8568cd5dca59da9@mail.gmail.com> <49ADEDA3.1030406@redhat.com> <20090304110022.GB18165@elte.hu> <49AE9850.9020103@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49AE9850.9020103@redhat.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1163
Lines: 32


* Brian Maly <bmaly@redhat.com> wrote:

>
>
>> Hm, could we ever find ourselves in the positition of having to access 
>> the DMI strings table in the EFI init code, to implement a quirk? I 
>> think that's quite plausible.
>
>> OTOH, with some DMI quirks in EFI tables it's a bit of a chicken and 
>> egg problem. Can DMI strings ever be outside of EFI tables on EFI 
>> systems?
>
>> 	Ingo
>
> Right now it is EFI that loads the dmi tables (and all other 
> tables such as ACPI), so it is a chicken and the egg. I think 
> that if dmi is ever needed by EFI, the dmi scan will have to 
> be moved inside efi_init. We could move the dmi scan into 
> efi_init and do the dmi scan the moment we have the dmi table. 
> Thats really the soonest point we could scan on EFI systems. 
> Im OK with moving dmi to efi_init if you prefer.

Your patch looks fine, but i'd like to hear the opinion of Ying 
Huang as well.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/