[Top] [All Lists]

Re: ipw2100: firmware problem

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: ipw2100: firmware problem
From: James Ketrenos <jketreno@xxxxxxxxxxxxxxx>
Date: Thu, 09 Jun 2005 16:01:30 -0500
Cc: pavel@xxxxxx, vda@xxxxxxxxxxxxx, abonilla@xxxxxxxxxxxxxxxxx, jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, ipw2100-admin@xxxxxxxxxxxxxxx
In-reply-to: <>
References: <> <> <> <>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050519
David S. Miller wrote:

>From: Pavel Machek <pavel@xxxxxx>
>Date: Thu, 9 Jun 2005 12:42:05 +0200
>>I'm not saying it should not work automagically. But it is wrong to
>>start transmitting on wireless as soon as kernel boots. It should stay
>>quiet in the radio until it is either told to talk or until interface
>>is upped.
>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. 


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