public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Cliff Wickman <cpw@sgi.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [PATCH] x86: access to efi reserved memory type
Date: Sun, 08 Mar 2009 15:51:20 -0700	[thread overview]
Message-ID: <49B44BE8.1080700@zytor.com> (raw)
In-Reply-To: <E1Lfe8A-00056c-SH@eag09.americas.sgi.com>

Cliff Wickman wrote:
> From: Cliff Wickman <cpw@sgi.com>
> 
>  (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.


  reply	other threads:[~2009-03-08 22:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06 17:46 [PATCH] x86: access to efi reserved memory type Cliff Wickman
2009-03-08 22:51 ` H. Peter Anvin [this message]
2009-03-09 13:16   ` Robin Holt
  -- strict thread matches above, loose matches on Subject: below --
2009-03-24 19:48 Cliff Wickman
2008-11-06 21:22 Cliff Wickman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B44BE8.1080700@zytor.com \
    --to=hpa@zytor.com \
    --cc=cpw@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox