Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755301AbZCHWvk (ORCPT ); Sun, 8 Mar 2009 18:51:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754667AbZCHWvb (ORCPT ); Sun, 8 Mar 2009 18:51:31 -0400 Received: from terminus.zytor.com ([198.137.202.10]:53061 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754728AbZCHWvb (ORCPT ); Sun, 8 Mar 2009 18:51:31 -0400 Message-ID: <49B44BE8.1080700@zytor.com> Date: Sun, 08 Mar 2009 15:51:20 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Cliff Wickman CC: linux-kernel@vger.kernel.org, mingo@elte.hu Subject: Re: [PATCH] x86: access to efi reserved memory type References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1935 Lines: 51 Cliff Wickman wrote: > From: Cliff Wickman > > (this patch dates back to 2008-11-06 > http://marc.info/?l=linux-kernel&m=122600658522471&w=2 > but has never been applied.) > > Give drivers addresses of memory type EFI_RESERVED_TYPE. > This supports drivers that use vendor-specific memory, available > only to special devices. > > The walk() function scans the EFI memory map and does a callback to a > specified function for each memory area of a specified type. > efi_memmap_walk_reserved() provides a scan for type EFI_RESERVED_TYPE. > (an earlier version of this patch had proposed a new EFI type, but > EFI_RESERVED_TYPE should be sufficient, given that the firmware follows > the standard and does not use such memory for its own purposes) > > A UV driver will be posted to the community in the future that will use > these routines. > > Tested on 2.6.29-rc7 (and many previous versions) running on a > UV hardware simulator. > I have multiple issues with this patch. FIRST, this is identical to a platform driver. I really don't understand why it should need a special interface. SECOND, the EFI-specific callback interface is just plain weird. THIRD, saying "A UV driver will be posted to the community in the future that will use these routines" is not exactly motivation. At no point are you technically justifying this code. In particular, I really want to know why a plain platform device is insufficient, and look for a better solution than this, using the generic memory map interfaces rather than something EFI-specific. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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/