netdev
[Top] [All Lists]

Re: ipw2100: firmware problem

To: James Ketrenos <jketreno@xxxxxxxxxxxxxxx>
Subject: Re: ipw2100: firmware problem
From: Pavel Machek <pavel@xxxxxx>
Date: Thu, 9 Jun 2005 23:11:13 +0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, vda@xxxxxxxxxxxxx, abonilla@xxxxxxxxxxxxxxxxx, jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx, ipw2100-admin@xxxxxxxxxxxxxxx
In-reply-to: <42A8AE2A.4080104@linux.intel.com>
References: <200506090909.55889.vda@ilport.com.ua> <20050608.231657.59660080.davem@davemloft.net> <20050609104205.GD3169@elf.ucw.cz> <20050609.125324.88476545.davem@davemloft.net> <42A8AE2A.4080104@linux.intel.com>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.9i
Hi!

> >I agree.
> >
> >There is a similar problem in the Acenic driver, it brings the
> >link up and receives broadcast packets as soon as the driver
> >is loaded.  Mostly this is because the driver inits the chip
> >and registers the IRQ handler at probe time, whereas nearly
> >every other driver does this at ->open() time.
> >  
> >
> The ipw2100 originally postponed doing any initialization until open was
> called.  The problem at that time was that distributions were crafted to
> rely on link detection (I believe via ethtoolop's get_link) before they
> would bring the interface up.
> 
> With a wireless device, you don't have link until you are associated... 
> chicken and egg.  The solution was to move initialization and
> association to the probe.
> 
> I don't know if all the distributions have moved away from this model. 
> If they have and the devices are brought up regardless of link, then
> going back to delaying radio initialization until the open() is called
> is workable. 

Ook, great, I see.
                                                                Pavel

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