Subject: Re: pci-sysfs resource mmap broken
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linux-pci@atrey.karlin.mff.cuni.cz
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>, Greg KH <greg@kroah.com>
In-Reply-To: <1114493609.7183.55.camel@gaston>
References: <1114493609.7183.55.camel@gaston>
Content-Type: text/plain
Date: Tue, 26 Apr 2005 16:09:41 +1000
Message-Id: <1114495782.7112.60.camel@gaston>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1357
Lines: 34

On Tue, 2005-04-26 at 15:33 +1000, Benjamin Herrenschmidt wrote:

> In a similar vein, the "resource" is exposing directly to userland the
> content of "struct resource". This doesn't mean anything. The kernel is
> internally playing all sort of offset tricks on these values, so they
> can't be used for anything useful, either via /dev/mem, or for io port
> accesses, or whatever.
> 
> Shouldn't we expose the BAR values & size rather here ? That is,
> reconsitutes non-offset'd resources, possibly with arch help, or just
> reading BAR to get base, and apply resource size & flags ?

  .../...

Ok, after a bit more thinking, I think I'll go that way for now, please
let me know if you think I'm wrong:

rename "resource" to "resources" and make it contain a start address
that matches the BAR value, that is something that has at least some
sort of meaning in userland and can be passed to pci_mmap_page_range().
To do that "translation", I'll read the BAR value, and use it as start,
then use the resource size & flags.

The name change will also allow userland to "detect" the fixed
implementation.

Ben.


-
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/