[Top] [All Lists]

Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping

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@xxxxxxxxxxxxxxxx>; from jgarzik@xxxxxxxxxxxxxxxx on Wed, May 31, 2000 at 05:57:59PM -0400
References: <20000531114830.J1417@xxxxxxxxxxxxx> <39358AE7.55E892A@xxxxxxxxxxxxxxxx>
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.


<Prev in Thread] Current Thread [Next in Thread>