| To: | Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping |
| From: | Anton Blanchard <anton@xxxxxxxxxxxxx> |
| Date: | Wed, 31 May 2000 15:26:08 -0700 |
| Cc: | linux-kernel@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <39358AE7.55E892A@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Wed, May 31, 2000 at 05:57:59PM -0400 |
| References: | <20000531114830.J1417@linuxcare.com> <39358AE7.55E892A@mandrakesoft.com> |
| Sender: | owner-netdev@xxxxxxxxxxx |
| User-agent: | Mutt/1.0.1i |
> Use pci_resource_end, avoid the unnecessary addition.
Good point.
> Why is the dev->base_addr assignment not conditional on USE_IO as well?
OK, to be consistent it should not be.
> Or be more specific,
> 1) What are the semantics of mem_{start,end} versus base_addr? And,
> 2) Why does ifconfig truncate a valid 32-bit address, when
> dev->base_addr equals something like 0xF1234567? I noticed this but
> never got around to looking into the reason.
I do not know the intended semantics, but someone decided that a short was
enough to store the base address:
struct ifmap
{
unsigned long mem_start;
unsigned long mem_end;
unsigned short base_addr;
unsigned char irq;
unsigned char dma;
unsigned char port;
/* 3 bytes spare */
};
So we have to use mem_start/end for this.
Anton
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: sendto problem, Statux |
|---|---|
| Next by Date: | 802.1q Was (Re: Plans for 2.5 / 2.6 ???, jamal |
| Previous by Thread: | Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping, Jeff Garzik |
| Next by Thread: | Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping, Jeff Garzik |
| Indexes: | [Date] [Thread] [Top] [All Lists] |