Re: [patch 2.6.24-rc1] resource_len() utility function

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Alan Cox <alan@...>
Cc: Jeff Garzik <jeff@...>, Linux Kernel list <linux-kernel@...>, Andrew Morton <akpm@...>, Greg KH <greg@...>
Date: Thursday, October 25, 2007 - 12:31 pm

On Thursday 25 October 2007, Alan Cox wrote:

I'm assuming you mean they should continue to work like they
do today:  return the resource.  Your pseudocode below shows
an iomap utility taking a resource.



Sure, for PCI ... where the meaning of BARs is a fixed part of the
hardware spec, and it's not uncommon to skip a few.

But as I noted, that notion doesn't apply cleanly outside PCI;
indexes aren't necessarily portable between systems.  So any
such interface should discourage their use.


One issue with a dev_iomap() is that only memory resources
really need mapping ... but *all* of them need claiming.
(Modulo the detail that the iomap morphs i/o addresses too.)

The $SUBJECT function is a (minor) simplification for both
the mapping and claiming steps.

I think I'd rather see a dev_resource_claim() which combines
the request_{,mem_}region() semantics with mapping ... that
way drivers could save code, not just unify the two types
of register addressing.

- Dave


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[patch 2.6.24-rc1] resource_len() utility function, David Brownell, (Wed Oct 24, 9:20 pm)
Re: [patch 2.6.24-rc1] resource_len() utility function, David Brownell, (Wed Oct 24, 10:39 pm)
Re: [patch 2.6.24-rc1] resource_len() utility function, Jeff Garzik, (Wed Oct 24, 10:08 pm)
Re: [patch 2.6.24-rc1] resource_len() utility function, David Brownell, (Wed Oct 24, 10:47 pm)
Re: [patch 2.6.24-rc1] resource_len() utility function, Jeff Garzik, (Wed Oct 24, 11:46 pm)
Re: [patch 2.6.24-rc1] resource_len() utility function, David Brownell, (Thu Oct 25, 12:38 am)
Re: [patch 2.6.24-rc1] resource_len() utility function, David Brownell, (Thu Oct 25, 12:31 pm)