netdev
[Top] [All Lists]

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

To: Anton Blanchard <anton@xxxxxxxxxxxxx>
Subject: Re: [PATCH] eepro100 device name <-> pci bus/slot/func mapping
From: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Wed, 31 May 2000 21:33:20 -0400
Cc: linux-kernel@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Organization: MandrakeSoft
References: <20000531114830.J1417@xxxxxxxxxxxxx> <39358AE7.55E892A@xxxxxxxxxxxxxxxx> <20000531152608.A24217@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
Anton Blanchard wrote:
> 
> 
> > 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.

Well crap.  All of the drivers use base_addr regardless of PIO or MMIO,
and none use mem_start/end AFAICS.  It should be no trouble to simply
assign mem_start/end for reporting purposes and ignore them otherwise,
but having 'base_addr' be a short here is a real PITA, since it doesn't
reflect real-life usage.

IMHO we should ditch mem_start/end, OR ditch base_addr...

        Jeff


-- 
Jeff Garzik              | Liberty is always dangerous, but
Building 1024            | it is the safest thing we have.
MandrakeSoft, Inc.       |      -- Harry Emerson Fosdick

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