ipw2100: firmware problem

ipw2100: firmware problem

[Pavel Machek]

Hi!

I'm fighting with firmware problem: if ipw2100 is compiled into
kernel, it is loaded while kernel boots and firmware loader is not yet
available. That leads to uninitialized (=> useless) adapter.

What's the prefered way to solve this one? Only load firmware when
user does ifconfig eth1 up? [It is wifi, it looks like it would be
better to start firmware sooner so that it can associate to the
AP...].

Last initcall available in kernel is late_initcall; that's not late
enough for me. Is adding one more initcall that is started when
userland is available a solution?
								Pavel

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> Hi!
> 
> I'm fighting with firmware problem: if ipw2100 is compiled into
> kernel, it is loaded while kernel boots and firmware loader is not yet
> available. That leads to uninitialized (=> useless) adapter.
> 
> What's the prefered way to solve this one? Only load firmware when
> user does ifconfig eth1 up? [It is wifi, it looks like it would be
> better to start firmware sooner so that it can associate to the
> AP...].

Do you want to associate to an AP when your kernel boots,
_before_ any iwconfig had a chance to configure anything?
That's strange.

My position is that wifi drivers must start up in an "OFF" mode.
Do not send anything. Do not join APs or start IBSS.
Thus, no need to load fw in early boot.

Driver may load firmware and start actively doing something
only when iwconfig gets executed and thus driver is
instructed what to do.

Some drivers currently do not act this way, and thus
less advanced users may unknowingly run a wireless STA
(or worse, an AP!) on their notebook for years, interfering
with neighbors and/or violating local regulations (there are
countrles where 802.11 use needs licensing).
--
vda

Re: ipw2100: firmware problem

[Jirka Bohac]

On Wed, Jun 08, 2005 at 05:44:20PM +0300, Denis Vlasenko wrote:
> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
> 
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.
> 
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.

Agreed.

> Thus, no need to load fw in early boot.

I don't think this is true. Loading the firmware on the first
"ifconfig up" is problematic. Often, people want to rename the
device from ethX/wlanX/... to something stable. This is usually
based on the adapter's MAC address, which is not visible until
the firmware is loaded.

Prism54 does it this way and it really sucks. You need to bring
the adapter up to load the firmware, then bring it back down,
rename it, and bring it up again.

Denis: any plans for this to be fixed?

I agree that drivers should initialize the adapter in the OFF
state, but the firmware needs to be loaded earlier than the
first ifconfig up.

How about loading the firmware when the first ioctl touches the
device? This way, it would get loaded just before the MAC address
is retrieved.

regards,

-- 
Jirka Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CR

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > Do you want to associate to an AP when your kernel boots,
> > _before_ any iwconfig had a chance to configure anything?
> > That's strange.
> > 
> > My position is that wifi drivers must start up in an "OFF" mode.
> > Do not send anything. Do not join APs or start IBSS.
> 
> Agreed.

Me too ;-).

> > Thus, no need to load fw in early boot.
> 
> I don't think this is true. Loading the firmware on the first
> "ifconfig up" is problematic. Often, people want to rename the
> device from ethX/wlanX/... to something stable. This is usually
> based on the adapter's MAC address, which is not visible until
> the firmware is loaded.
> 
> Prism54 does it this way and it really sucks. You need to bring
> the adapter up to load the firmware, then bring it back down,
> rename it, and bring it up again.
> 
> Denis: any plans for this to be fixed?
> 
> I agree that drivers should initialize the adapter in the OFF
> state, but the firmware needs to be loaded earlier than the
> first ifconfig up.
> 
> How about loading the firmware when the first ioctl touches the
> device? This way, it would get loaded just before the MAC address
> is retrieved.

Thats really ugly :-(.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: ipw2100: firmware problem

[Simon Kelley]

Jirka Bohac wrote:
> On Wed, Jun 08, 2005 at 05:44:20PM +0300, Denis Vlasenko wrote:
> 
>>On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
>>
>>>What's the prefered way to solve this one? Only load firmware when
>>>user does ifconfig eth1 up? [It is wifi, it looks like it would be
>>>better to start firmware sooner so that it can associate to the
>>>AP...].
>>
>>Do you want to associate to an AP when your kernel boots,
>>_before_ any iwconfig had a chance to configure anything?
>>That's strange.
>>
>>My position is that wifi drivers must start up in an "OFF" mode.
>>Do not send anything. Do not join APs or start IBSS.
> 
> 
> Agreed.
> 
> 
>>Thus, no need to load fw in early boot.
> 
> 
> I don't think this is true. Loading the firmware on the first
> "ifconfig up" is problematic. Often, people want to rename the
> device from ethX/wlanX/... to something stable. This is usually
> based on the adapter's MAC address, which is not visible until
> the firmware is loaded.
> 
> Prism54 does it this way and it really sucks. You need to bring
> the adapter up to load the firmware, then bring it back down,
> rename it, and bring it up again.
> 

The atmel driver includes a small firmware stub which does nothing but 
determine the MAC address, to solve this problem. This is compiled into 
the driver and so doesn't depend on request_firmware(). The stub was 
created by reverse engineering the card and is GPL, so there's no 
problem including it in the kernel.

This is not a general solution, since it depends on the ability to 
create such MAC reader firmware, but it might be a possibility in this case.


Cheers,

Simon.

Re: ipw2100: firmware problem

[Feyd]

On Tue, 21 Jun 2005 08:42:08 +0100
Simon Kelley <simon@thekelleys.org.uk> wrote:

> The atmel driver includes a small firmware stub which does nothing but 
> determine the MAC address, to solve this problem. This is compiled into 

Does it power-down the card after reading the MAC?

Feyd

Re: ipw2100: firmware problem

[Simon Kelley]

Feyd wrote:
> On Tue, 21 Jun 2005 08:42:08 +0100
> Simon Kelley <simon@thekelleys.org.uk> wrote:
> 
> 
>>The atmel driver includes a small firmware stub which does nothing but 
>>determine the MAC address, to solve this problem. This is compiled into 
> 
> 
> Does it power-down the card after reading the MAC?
> 

Yes, it loads the special firmware, runs it to get the MAC, and then 
returns the card to quiesent state, ready for the real firmware load 
which happens at device open time.

Cheers,

Simon.

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > Hi!
> >
> > I'm fighting with firmware problem: if ipw2100 is compiled into
> > kernel, it is loaded while kernel boots and firmware loader
> is not yet
> > available. That leads to uninitialized (=> useless) adapter.

Pavel,

	I might be lost here but... How is the firmware loaded when using the
ipw2100-1.0.0/patches Kernel patch?

That patch normally works fine. It might not be the way you kernel
developers would like it, but maybe that could work the same way?


> >
> > What's the prefered way to solve this one? Only load firmware when
> > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > better to start firmware sooner so that it can associate to the
> > AP...].
>
> Do you want to associate to an AP when your kernel boots,
> _before_ any iwconfig had a chance to configure anything?
> That's strange.

Currently, when we install the driver, it associates to any open network on
boot. This is good, cause we don't want to be typing the commands all the
time just to associate. It works this way now and is pretty nice.

>
> My position is that wifi drivers must start up in an "OFF" mode.
> Do not send anything. Do not join APs or start IBSS.
> Thus, no need to load fw in early boot.
>
So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
scan?
When moving from modes with the firmwares, would I have to do ifconfig eth1
up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
iwconfig? Does it have that function?

I'm not sure, but I guess that you guys should use the same method that the
source/patches uses?

.Alejandro

Re: ipw2100: firmware problem

[Jiri Benc]

On Wed, 8 Jun 2005 09:05:27 -0600, Alejandro Bonilla wrote:
> 	I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?

It is loaded by request_firmware() during initialization of the adapter.
That doesn't work, as at that time no hotplug binary can be executed (we
are talking about ipw2100 built in the kernel, not built as a module).

> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.

It sounds very dangerous to me.

> So, to scan a network, I would have to do ifconfig eth1 up ; iwlist eth1
> scan?

No. Driver should request the firmware when it is told to perform a scan.

> When moving from modes with the firmwares, would I have to do ifconfig eth1
> up ; iwconfig eth1 mode monitor? or would the firmware be loaded with
> iwconfig? Does it have that function?

Firmware can be loaded automatically by the driver when there is some
request from userspace and the firmware has not been loaded yet.


-- 
Jiri Benc
SUSE Labs

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> 
> > On Wednesday 08 June 2005 17:23, Pavel Machek wrote:
> > > Hi!
> > >
> > > I'm fighting with firmware problem: if ipw2100 is compiled into
> > > kernel, it is loaded while kernel boots and firmware loader
> > is not yet
> > > available. That leads to uninitialized (=> useless) adapter.
> 
> Pavel,
> 
> 	I might be lost here but... How is the firmware loaded when using the
> ipw2100-1.0.0/patches Kernel patch?
> 
> That patch normally works fine. It might not be the way you kernel
> developers would like it, but maybe that could work the same way?
> 
> 
> > >
> > > What's the prefered way to solve this one? Only load firmware when
> > > user does ifconfig eth1 up? [It is wifi, it looks like it would be
> > > better to start firmware sooner so that it can associate to the
> > > AP...].
> >
> > Do you want to associate to an AP when your kernel boots,
> > _before_ any iwconfig had a chance to configure anything?
> > That's strange.
> 
> Currently, when we install the driver, it associates to any open network on
> boot. This is good, cause we don't want to be typing the commands all the
> time just to associate. It works this way now and is pretty nice.

What is so nice about this? That Linux novice user with his new lappie
will join a neighbor's network every time he powers up the lappie,
even without knowing that?

That will be analogous to me plugging ethernet cable into the switch and
wanting it to work, without any IP addr config, even without DHCP client.
Just power up the box (or modprobe an eth module) and it works! Cool, eh?

For some reason, we do not do this for wired nets. Why should wireless
be different?
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:09:55 +0300

> On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > Currently, when we install the driver, it associates to any open network on
> > boot. This is good, cause we don't want to be typing the commands all the
> > time just to associate. It works this way now and is pretty nice.
> 
> What is so nice about this? That Linux novice user with his new lappie
> will join a neighbor's network every time he powers up the lappie,
> even without knowing that?

I love this behavior, because it means that I don't have to do
anything special to get my setup at home working.

Me caveman
Me plug in wireless router
Me watch pretty lights
Me turn on computer
Me up interface
Computer work
Me no care other cavemen use wireless link

Configuration knobs are _madness_.  Things should work with minimal
intervention and configuration.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:16, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:09:55 +0300
> 
> > On Wednesday 08 June 2005 18:05, Alejandro Bonilla wrote:
> > > Currently, when we install the driver, it associates to any open network on
> > > boot. This is good, cause we don't want to be typing the commands all the
> > > time just to associate. It works this way now and is pretty nice.
> > 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> 
> I love this behavior, because it means that I don't have to do
> anything special to get my setup at home working.
> 
> Me caveman
> Me plug in wireless router
> Me watch pretty lights
> Me turn on computer
> Me up interface

You need to up interface? And surely you need ip addr? That's a knob also! :)

> Computer work
> Me no care other cavemen use wireless link
> 
> Configuration knobs are _madness_.  Things should work with minimal
> intervention and configuration.

Sure. I consider "iwconfig essid MyCave mode managed" a minimal intervention,
just like I consider "ip a a dev eth0 123.123.123.2/24 brd +; ip l set dev eth0 up"
a miniman interventian if I need IP configured.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:25:07 +0300

> You need to up interface? And surely you need ip addr? That's a knob also! :)

There's this thing called DHCP which takes care of this for me.
With IPV6, even less configuration can be necessary.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:28, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:25:07 +0300
> 
> > You need to up interface? And surely you need ip addr? That's a knob also! :)
> 
> There's this thing called DHCP which takes care of this for me.
> With IPV6, even less configuration can be necessary.

But DHCP does not start by itself, and it shuldn't.
You start dhcp client. That is a "minimal config" in this case.

Anyway, I think I start trolling... I should stop now.
--
vda

Re: ipw2100: firmware problem

[Wichert Akkerman]

Previously Denis Vlasenko wrote:
> But DHCP does not start by itself, and it shuldn't.

It does in most modern distros as far as I know. They use ifplugd or a
similar tool to monitor link status and configure the interface if a link is
detected.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > > Currently, when we install the driver, it associates to any open network on
> > > boot. This is good, cause we don't want to be typing the commands all the
> > > time just to associate. It works this way now and is pretty nice.
> > 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> 
> I love this behavior, because it means that I don't have to do
> anything special to get my setup at home working.
> 
> Me caveman
> Me plug in wireless router
> Me watch pretty lights
> Me turn on computer
> Me up interface
> Computer work
> Me no care other cavemen use wireless link
> 
> Configuration knobs are _madness_.  Things should work with minimal
> intervention and configuration.

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.

That way 

* above still works, only radio chat begins one step later

* if you are in environment where you absolutely do not want it to
talk on the radio (airplane, BlackHatCon with APs trying to hack you
all around), you can make it quiet without needing kernel/module
parameters.

								Pavel 

Re: ipw2100: firmware problem

[David S. Miller]

From: Pavel Machek <pavel@ucw.cz>
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.

Re: ipw2100: firmware problem

[James Ketrenos]

David S. Miller wrote:

>From: Pavel Machek <pavel@ucw.cz>
>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. 

James

Re: ipw2100: firmware problem

[Pavel Machek]

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

Re: ipw2100: firmware problem

[Arjan van de Ven]

On Thu, 2005-06-09 at 16:01 -0500, James Ketrenos wrote:
> 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. 

wouldn't you want that anyway for power saving reasons?

Re: ipw2100: firmware problem

[David S. Miller]

From: James Ketrenos <jketreno@linux.intel.com>
Date: Thu, 09 Jun 2005 16:01:30 -0500

> 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.

Yes, I see, and that does work for most ethernet devices.
I noticed that Debian's 3.1 installer used this to determine
which ethernet device it should use as the default in it's
network device dialogue.

One idea, returning true for get_link when the device is down, may not
be a bad idea for the wireless case.

Re: ipw2100: firmware problem

[Jeff Garzik]

James Ketrenos wrote:
> 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. 


When the interface is not up, we ideally want the device to be as 
passive as possible.

Most net drivers shut down as much as possible at dev->close() time, and 
it would really be good if wireless drivers followed suit.

	Jeff

Re: ipw2100: firmware problem

[Alejandro Bonilla]

Jeff Garzik wrote:

> James Ketrenos wrote:
>
>> 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. 
>
>
>
> When the interface is not up, we ideally want the device to be as 
> passive as possible.
>
> Most net drivers shut down as much as possible at dev->close() time, 
> and it would really be good if wireless drivers followed suit.
>
>     Jeff
>
>
>
OK. I understand the point and I totally agree with this. We really want 
the adapter to just do what the user or profiles ask the adapter to do. 
Yes, in an ideal world.

Let's talk about easyness. These adapters are in laptops. You don't want 
to type a lot of stop everytime you move from access points, reboots and 
so on. In a server enviroment with the ethernet adapters, we really just 
want them to do what they do and we have scripts for it. So, again, with 
mobile is different. An association on boot is fair and really OK. You 
are not really doing dhcp requests on boot and trying to get the 
internet from people for free. You just want you adapter running faster, 
get connected and get over whatever you have to do to start working or 
whatsoever.

Let's really think what would be the nicest way that the card should 
behave, after all if the adapter just associates, you are not really 
stealing any Internet. :)

Association on boot is how it has worked all the time, and in the 18 
months of the project, nobody has complained about it... So... I wonder, 
users are happy with it? (I know it might not be the correct way)

Just a thought.

.Alejandro

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> OK. I understand the point and I totally agree with this. We really want 
> the adapter to just do what the user or profiles ask the adapter to do. 
> Yes, in an ideal world.
> 
> Let's talk about easyness. These adapters are in laptops. You don't want 
> to type a lot of stop everytime you move from access points, reboots
> and 

We are not trying to make it hard to the users. Lets do the right
thing in kernel, and let userspace make it easy.
								Pavel

Re: ipw2100: firmware problem

[John Stoffel]

I'd like to chime in here and say that from my point of view, not
enabling the wireless network adaptor until asked by userspace is the
way to go. 

It reduces power requirements, and it pushes the configuration details
out to userspace, where they can be handled according to the policy
setup by the distro/user.

Having my latop bootup and turn on the wireless card and join an AP
without my explicity asking is a bad thing to have happen.  

John

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> Hi!
> 
> > OK. I understand the point and I totally agree with this. 
> We really want 
> > the adapter to just do what the user or profiles ask the 
> adapter to do. 
> > Yes, in an ideal world.
> > 
> > Let's talk about easyness. These adapters are in laptops. 
> You don't want 
> > to type a lot of stop everytime you move from access points, reboots
> > and 
> 
> We are not trying to make it hard to the users. Lets do the right
> thing in kernel, and let userspace make it easy.
> 								Pavel

Pavel,

	Agreed then. 

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> What is so nice about this? That Linux novice user with his new lappie
> will join a neighbor's network every time he powers up the lappie,
> even without knowing that?
>
> That will be analogous to me plugging ethernet cable into the
> switch and
> wanting it to work, without any IP addr config, even without
> DHCP client.
> Just power up the box (or modprobe an eth module) and it
> works! Cool, eh?
>

You want things one way, I like them in another way. Whoever makes this
decision should just know that we would like to have an option to make it
load with or without the ASSOC on.

James already said to use the options ipw2100 disable=1 if you don't want it
to associate everytime on boot.

At the end, who decides this?

.Alejandro


> For some reason, we do not do this for wired nets. Why should wireless
> be different?
> --
> vda
>

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 17:31, Alejandro Bonilla wrote:
> 
> > What is so nice about this? That Linux novice user with his new lappie
> > will join a neighbor's network every time he powers up the lappie,
> > even without knowing that?
> >
> > That will be analogous to me plugging ethernet cable into the
> > switch and
> > wanting it to work, without any IP addr config, even without
> > DHCP client.
> > Just power up the box (or modprobe an eth module) and it
> > works! Cool, eh?
> >
> 
> You want things one way, I like them in another way. Whoever makes this
> decision should just know that we would like to have an option to make it
> load with or without the ASSOC on.

But you already _have_ the option to associate. Just issue
appropriate iwconfig command (or embed one in startup script).

> James already said to use the options ipw2100 disable=1 if you don't want it
> to associate everytime on boot.

Do we have to add such option to each and every wireless driver now?
That would be wrong since iwconfig already exists.

> At the end, who decides this?

User. As I said, with no automatic assoc at module load user still
may easily attain that with iwconfig.

Adding kernel level wireless autoconfiguration duplicates the effort.
Since I am not going to give up a requirement to be able to stay radio
silent at boot (me too wants freedom, not only you), you need to add
disable=1 module parameter to each driver, which adds to the mess.

ALSA does the Right Thing. Sound is completely muted out at module load.
It's a user freedom to set desired volume level after that.
--
vda

RE: ipw2100: firmware problem

[Alejandro Bonilla]

>
> Adding kernel level wireless autoconfiguration duplicates the effort.
> Since I am not going to give up a requirement to be able to stay radio
> silent at boot (me too wants freedom, not only you), you need to add
> disable=1 module parameter to each driver, which adds to the mess.
>
> ALSA does the Right Thing. Sound is completely muted out at
> module load.
> It's a user freedom to set desired volume level after that.

Yeah right. I remember I had to google for 10 minutes to find the answer for
this one. Why would you install something, for it to not work?

It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
and enable it. Why would it make you google for more things to do? ALSA mute
on install is WAY way, not OK.

You *will* have to use a How-To with ALSA, nobody knows that your sound
would be off because some people decided it.

But this is out of the Topic. I agree with you all, but as I mentioned in a
more current email, this is a laptop, not a server. Things behave
differently and you want things faster. (Yes, I could have a script)

What I'm saying, is that just as ALSA, you will have to google even more
just to be able to look for the boot param for the driver for it to ASSOC on
boot like the Original drive does. Instead, if you simply don't want to
associate then turn off the Radio.

It's a simple FN+F2 or depends on your laptop.

Let's not make this a bigger thread, just decide and then do it that way.
I'm looking at this on the side of a supporter, seeing the emails from
users... "how do I make it behave as it was before" "it won't assoc on boot
anymore"

.Alejandro

> --
> vda
>

RE: ipw2100: firmware problem

[Lee Revell]

On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
> >
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
> 
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
> 
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.

It took you 10 minutes of googling before you thought to try the mixer?
Sorry dude, this is PEBKAC.

Lee

RE: ipw2100: firmware problem

[Alejandro Bonilla]

> > It thing of Mute in ALSA is stupid. If you want Sound, you
> install the Sound
> > and enable it. Why would it make you google for more things
> to do? ALSA mute
> > on install is WAY way, not OK.
>
> It took you 10 minutes of googling before you thought to try
> the mixer?
> Sorry dude, this is PEBKAC.
>
> Lee

Riiiight. It could be. Or it could be that no where in the world I have seen
something where the device would be disabled by default without notifying
the user. Why would you Mute the driver? Is the driver that bad, that the
developers would rather Mute the sound card, just in case if the sound cards
starts making noises and shit when the driver is loaded?

You are moving to another topic. Let's drop it.

.Alejandro

RE: ipw2100: firmware problem

[Lee Revell]

On Fri, 2005-06-10 at 15:00 -0600, Alejandro Bonilla wrote:
> > > It thing of Mute in ALSA is stupid. If you want Sound, you
> > install the Sound
> > > and enable it. Why would it make you google for more things
> > to do? ALSA mute
> > > on install is WAY way, not OK.
> >
> > It took you 10 minutes of googling before you thought to try
> > the mixer?
> > Sorry dude, this is PEBKAC.
> >
> > Lee
> 
> Riiiight. It could be. Or it could be that no where in the world I have seen
> something where the device would be disabled by default without notifying
> the user. Why would you Mute the driver? Is the driver that bad, that the
> developers would rather Mute the sound card, just in case if the sound cards
> starts making noises and shit when the driver is loaded?
> 

Userspace should handle it, doing this in the kernel is bloat.

My Debian system initializes the mixer settings to a sane state just
fine when the alsasound init script is run.  Maybe you need a better
distro.

Users who compile ALSA from source are expected to know what they are
doing.  And, if you watch the "make install" output, it prints a big fat
warning that all mixer controls are muted by default.

> You are moving to another topic. Let's drop it.

Agreed, but it was your OT rant that changed the topic...

Lee

Re: ipw2100: firmware problem

[Jan Rychter]

>>>>> "Lee" == Lee Revell <rlrevell@joe-job.com> writes:
 Lee> On Fri, 2005-06-10 at 07:23 -0600, Alejandro Bonilla wrote:
 >> >
 >> > Adding kernel level wireless autoconfiguration duplicates the
 >> > effort.  Since I am not going to give up a requirement to be able
 >> > to stay radio silent at boot (me too wants freedom, not only you),
 >> > you need to add disable=1 module parameter to each driver, which
 >> > adds to the mess.
 >> >
 >> > ALSA does the Right Thing. Sound is completely muted out at module
 >> > load.  It's a user freedom to set desired volume level after that.
 >>
 >> Yeah right. I remember I had to google for 10 minutes to find the
 >> answer for this one. Why would you install something, for it to not
 >> work?
 >>
 >> It thing of Mute in ALSA is stupid. If you want Sound, you install
 >> the Sound and enable it. Why would it make you google for more
 >> things to do? ALSA mute on install is WAY way, not OK.

 Lee> It took you 10 minutes of googling before you thought to try the
 Lee> mixer?  Sorry dude, this is PEBKAC.

Oh, really, you think this works so well? Ever tried to use more than
one soundcard? A USB audio device? Ever wondered why oh why one has to
always check and twiddle with the mixers? Why (it seems) setting the
volume of USB audio devices via alsamixer doesn't work for apps which
use OSS emulation? Ever wondered why alsactl restore doesn't get called
by udev by default?

The current Linux approach (most distributions) is to let the user be
the master. Which means lots of typing, configuring, tweaking. Try that
on a tablet pc without a keyboard.

Things should Just Work. I wish most Linux developers tried using a Mac
at least once in their lifetimes.

--J.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Friday 10 June 2005 16:23, Alejandro Bonilla wrote:
> > Adding kernel level wireless autoconfiguration duplicates the effort.
> > Since I am not going to give up a requirement to be able to stay radio
> > silent at boot (me too wants freedom, not only you), you need to add
> > disable=1 module parameter to each driver, which adds to the mess.
> >
> > ALSA does the Right Thing. Sound is completely muted out at
> > module load.
> > It's a user freedom to set desired volume level after that.
> 
> Yeah right. I remember I had to google for 10 minutes to find the answer for
> this one. Why would you install something, for it to not work?
> 
> It thing of Mute in ALSA is stupid. If you want Sound, you install the Sound
> and enable it. Why would it make you google for more things to do? ALSA mute
> on install is WAY way, not OK.
> 
> You *will* have to use a How-To with ALSA, nobody knows that your sound
> would be off because some people decided it.

Well, which sound level shall be set instead? 100%? Maybe too loud for
my 500 watt loudpeakers, eh? 50%? Still too many. 5%? Nah.
My machine at work has a headphone which is anything but loud.
5% is nearly silence for it.

See? It's not a kernel matter at which volume sound must be set.
It is impossible to decide on the 'right' default.
 
> But this is out of the Topic. I agree with you all, but as I mentioned in a
> more current email, this is a laptop, not a server. Things behave
> differently and you want things faster. (Yes, I could have a script)

Or laptop oriented distro can have a script for you,
just like they already do have for DHCPizing all ifaces.

Not kernel business.

> What I'm saying, is that just as ALSA, you will have to google even more
> just to be able to look for the boot param for the driver for it to ASSOC on
> boot like the Original drive does. Instead, if you simply don't want to
> associate then turn off the Radio.
> 
> It's a simple FN+F2 or depends on your laptop.
> 
> Let's not make this a bigger thread, just decide and then do it that way.
> I'm looking at this on the side of a supporter, seeing the emails from
> users... "how do I make it behave as it was before" "it won't assoc on boot
> anymore"

Users which can not figure it by themself have not much power in dictating
how kernel drivers are written. Sure we listen to users, but we won't
blidly follow any and all suggestions.

If users want it different nodoby prohibits them from writing their own
drivers, right? Or patching existing ones, for that matter. Send patches to lkml
for discussion.
--
vda

Re: ipw2100: firmware problem

[James Ketrenos]

Denis Vlasenko wrote:

>My position is that wifi drivers must start up in an "OFF" mode.
>Do not send anything. Do not join APs or start IBSS.
>Thus, no need to load fw in early boot.
>  
>
This should be an option for the user if that is the desired behavior. 
We support that with the ipw2100 and ipw2200 projects via module
parameters to disable the radio during module load.  Having a standard
module parameter for wireless drivers would be nice.

My approach is to make the driver so it supports as many usage models as
possible, leaving policy to other components of the system.  If the user
wants it to scan and associate immediately, that should be supported. 
Likewise if they want the module to be loaded w/ the radio off, they can
do that as well.

Since most (if not all) laptops support an RF kill switch, I tend to
defer to the physical switch as the user's point of control and set the
driver defaults to try and use the radio if it is enabled.

James

Re: ipw2100: firmware problem

[David S. Miller]

From: James Ketrenos <jketreno@linux.intel.com>
Date: Wed, 08 Jun 2005 12:10:37 -0500

> My approach is to make the driver so it supports as many usage models as
> possible, leaving policy to other components of the system.

I don't see how this kind of firmware load setup handles something
like an NFS root over such a device that requires firmware.

And let's not mention that I have to setup an initrd to make that
work, that's rediculious.

This is the kind of crap that happens when drivers in the kernel
are not self contained, and need "external stuff" to work properly.
It means that simple things like NFS root over the device do not
work in a straightforward, simple, and elegant manner.

I am likely to always take the position that device firmware
belongs in the kernel proper, not via these userland and filesystem
loading mechanism, none of which may be even _available_ when
we first need to get the device going.

Re: ipw2100: firmware problem

[Dave Jones]

On Wed, Jun 08, 2005 at 12:43:32PM -0700, David S. Miller wrote:
 
 > I am likely to always take the position that device firmware
 > belongs in the kernel proper, not via these userland and filesystem
 > loading mechanism, none of which may be even _available_ when
 > we first need to get the device going.

FWIW, I agree, though the licensing of the Intel firmware
prevents that iirc.  The biggest problem I face with this driver
in Fedora kernels is users mismatching firmware rev with the
driver version. Another problem that disappears if the two
are shipped together.

Of course this would then bring out the armchair lawyers on
the list and cause another 500 emails debating whether it
violates the gpl.

		Dave

Re: ipw2100: firmware problem

[David S. Miller]

From: Dave Jones <davej@redhat.com>
Date: Wed, 8 Jun 2005 15:49:02 -0400

> FWIW, I agree, though the licensing of the Intel firmware
> prevents that iirc.  The biggest problem I face with this driver
> in Fedora kernels is users mismatching firmware rev with the
> driver version. Another problem that disappears if the two
> are shipped together.

Yep, this license definitely hurts users, in many many ways.

If this kind of external firmware requirement existed for a popular
SCSI controller, more people would be up in arms about this and
understand the issue more clearly.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Wednesday 08 June 2005 22:43, David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
> 
> > My approach is to make the driver so it supports as many usage models as
> > possible, leaving policy to other components of the system.
> 
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.

You practically cannot avoid having initrd because you are very likely
to need to do some wifi config (at least ESSID and mode).
Well, you can, but it gets more arcane with each turn
(essid=,mode= module parameters - in each and every wifi driver!
and what if you need to set basic rates? Yet another parameter?).

It's analogous to DHCP+NFS_root boot - we do have ugly hack
of kernelspace dhcp client, but IIRC it is agreed that the Right Thing
is to do such things in userspace (if needed, via initrd/initramfs).

It simply allows for way more options what you can do in early boot
if you have early userspace.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:03:49 +0300

> You practically cannot avoid having initrd because you are very likely
> to need to do some wifi config (at least ESSID and mode).

I need neither at home.  It comes up by default just fine with
ifconfig.

Your points are valid, but they do not detract from the fact that
pieced up drivers, half in the kernel half somewhere else, is total
madness.  It is a lose for the user.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:10, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:03:49 +0300
> 
> > You practically cannot avoid having initrd because you are very likely
> > to need to do some wifi config (at least ESSID and mode).
> 
> I need neither at home.  It comes up by default just fine with
> ifconfig.
> 
> Your points are valid, but they do not detract from the fact that
> pieced up drivers, half in the kernel half somewhere else, is total
> madness.  It is a lose for the user.

Here I am totally agree. I would like to not have to mess with
separate firmware files. I even don't want binary firmware, gimme
the source!

Sadly, realities are such that we have to live somehow
with closed-source firmware. Worse, sometimes it even isn't freely
redistributable (vendor did not explicitly allowed that),
and thus we have to ship driver, but users must obtain
firmware elsewhere themself.

Thus so far we cannot avoid having split drivers.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:17:23 +0300

> Sadly, realities are such that we have to live somehow
> with closed-source firmware.

You have a choice, buy products from friendly vendors.
I use prism54 cards in my laptops for this reason.

If you like a vendor's products who aren't friendly, try
to voice intelligently your opinion to them as to why users
will benefit from them fixing the firmware situation.

Re: ipw2100: firmware problem

[Denis Vlasenko]

On Thursday 09 June 2005 09:20, David S. Miller wrote:
> From: Denis Vlasenko <vda@ilport.com.ua>
> Date: Thu, 9 Jun 2005 09:17:23 +0300
> 
> > Sadly, realities are such that we have to live somehow
> > with closed-source firmware.
> 
> You have a choice, buy products from friendly vendors.

I am trying! So far, I have Prism2.5, Prism54
and acx111 cards, and all of them require closed binary fw.

> I use prism54 cards in my laptops for this reason.

?! As far as I remember, it needs a fw and fw is not open...
did that change recently?
 
> If you like a vendor's products who aren't friendly, try
> to voice intelligently your opinion to them as to why users
> will benefit from them fixing the firmware situation.
--
vda

Re: ipw2100: firmware problem

[David S. Miller]

From: Denis Vlasenko <vda@ilport.com.ua>
Date: Thu, 9 Jun 2005 09:30:22 +0300

> On Thursday 09 June 2005 09:20, David S. Miller wrote:
> > I use prism54 cards in my laptops for this reason.
> 
> ?! As far as I remember, it needs a fw and fw is not open...
> did that change recently?

My bad, they are not.  You're right :-/

Re: ipw2100: firmware problem

[Jim Crilly]

On 06/09/05 09:30:22AM +0300, Denis Vlasenko wrote:
> On Thursday 09 June 2005 09:20, David S. Miller wrote:
> > From: Denis Vlasenko <vda@ilport.com.ua>
> > Date: Thu, 9 Jun 2005 09:17:23 +0300
> > 
> > > Sadly, realities are such that we have to live somehow
> > > with closed-source firmware.
> > 
> > You have a choice, buy products from friendly vendors.
> 
> I am trying! So far, I have Prism2.5, Prism54
> and acx111 cards, and all of them require closed binary fw.

Ralink cards don't require any binary firmware. I got one of the Hawking
Tech pcmcia cards off the shelf at a local CompUSA store and the card 
was a good $20 cheaper than a Linksys card. So far I haven't had any
problems with the card or the driver.

A list of Ralink hardware and drivers can be found at
http://ralink.rapla.net/ 

> vda
> 

Jim.

Re: ipw2100: firmware problem

[Jeff Garzik]

David S. Miller wrote:
> From: James Ketrenos <jketreno@linux.intel.com>
> Date: Wed, 08 Jun 2005 12:10:37 -0500
> 
> 
>>My approach is to make the driver so it supports as many usage models as
>>possible, leaving policy to other components of the system.
> 
> 
> I don't see how this kind of firmware load setup handles something
> like an NFS root over such a device that requires firmware.
> 
> And let's not mention that I have to setup an initrd to make that
> work, that's rediculious.
> 
> This is the kind of crap that happens when drivers in the kernel
> are not self contained, and need "external stuff" to work properly.
> It means that simple things like NFS root over the device do not
> work in a straightforward, simple, and elegant manner.


Actually these questions has already been answered (though I know you 
will probably grumble a bit :))

"early userspace" is the long term answer.  usr/* in the current kernel 
tree is a placeholder for an image that is shipped with the kernel, 
which provides things (kernel modules, userspace programs, firmware) 
that are necessary to boot.

The key is that it is shipped with the kernel source tree, and built 
into the kernel image, and _dropped from memory_ after init.  The entire 
process should all be automatic.

Linus ack'd the current stuff (by merging it, after some discussion) and 
would have merged klibc too, had it any users.

  ...

As to $current_thread, initramfs exists but "early userspace" does not. 
    There isn't AFAIK any infrastructure to automatically add firmware 
to initrd in any standard distribution (corrections welcome!).  So 
today, initrd+firmware is just a big pain.

Therefore, the easiest way to make things work today is to poke Intel to 
fix their firmware license so that we can distribute it with the kernel :)

	Jeff

Re: ipw2100: firmware problem

[David S. Miller]

From: Jeff Garzik <jgarzik@pobox.com>
Date: Thu, 09 Jun 2005 02:06:05 -0400

> Therefore, the easiest way to make things work today is to poke Intel to 
> fix their firmware license so that we can distribute it with the kernel :)

Seperate firmware from the in-kernel driver is a big headache for
users.  As DaveJ has stated, people make mistakes and try to match up
the wrong firmware version with the driver and stuff like that.  And
he should know as he has to deal sift through bogus bug reports from
people running into this problem.

If it's integrated, there are no problems like this.

Re: ipw2100: firmware problem

[Jeff Garzik]

David S. Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Thu, 09 Jun 2005 02:06:05 -0400
> 
> 
>>Therefore, the easiest way to make things work today is to poke Intel to 
>>fix their firmware license so that we can distribute it with the kernel :)
> 
> 
> Seperate firmware from the in-kernel driver is a big headache for
> users.  As DaveJ has stated, people make mistakes and try to match up
> the wrong firmware version with the driver and stuff like that.  And
> he should know as he has to deal sift through bogus bug reports from
> people running into this problem.
> 
> If it's integrated, there are no problems like this.

Early userspace is (a) shipped with the kernel source tree and (b) 
linked into vmlinux.  That's integrated.

The firmware images will be separate from the .c files (as they should 
be), but the kernel hacker still controls what gets loaded, and when.

But like I said, that's where we're going, not where we are now.

	Jeff

Re: ipw2100: firmware problem

[James Ketrenos]

Pavel Machek wrote:

>Hi!
>
>I'm fighting with firmware problem: if ipw2100 is compiled into
>kernel, it is loaded while kernel boots and firmware loader is not yet
>available. That leads to uninitialized (=> useless) adapter.
>  
>
We've been looking into whether the initrd can have the firmware affixed
to the end w/ some magic bytes to identify it.  If it works, enhancing
the request_firmware to support both hotplug and an initrd approach may
be reasonable.

>What's the prefered way to solve this one? Only load firmware when
>user does ifconfig eth1 up? [It is wifi, it looks like it would be
>better to start firmware sooner so that it can associate to the
>AP...].
>  
>
The debate goes back and forth on whether devices should come up only
after they are told, or initialize and start looking for a network as
soon as the module is loaded.

I lean more toward having the driver just do what it is told, defaulting
to trying to scan and associate so link is ready as soon as possible. 
We've added module parameters to change that behavior (disable and
associate for the ipw2100).

James

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> >I'm fighting with firmware problem: if ipw2100 is compiled into
> >kernel, it is loaded while kernel boots and firmware loader is not yet
> >available. That leads to uninitialized (=> useless) adapter.
> >  
> >
> We've been looking into whether the initrd can have the firmware affixed
> to the end w/ some magic bytes to identify it.  If it works, enhancing
> the request_firmware to support both hotplug and an initrd approach may
> be reasonable.

That seems pretty ugly to me... imagine more than one driver does this
:-(.

> >What's the prefered way to solve this one? Only load firmware when
> >user does ifconfig eth1 up? [It is wifi, it looks like it would be
> >better to start firmware sooner so that it can associate to the
> >AP...].
> >  
> >
> The debate goes back and forth on whether devices should come up only
> after they are told, or initialize and start looking for a network as
> soon as the module is loaded.
> 
> I lean more toward having the driver just do what it is told, defaulting
> to trying to scan and associate so link is ready as soon as possible. 
> We've added module parameters to change that behavior (disable and
> associate for the ipw2100).

Having a parameter to control this seems a bit too complex to me.

How is 

insmod ipw2100 enable=1

different from

insmod ipw2100
iwconfig eth1 start_scanning_or_whatever

?

								Pavel

Re: ipw2100: firmware problem

[James Ketrenos]

Pavel Machek wrote:

>>We've been looking into whether the initrd can have the firmware affixed
>>to the end w/ some magic bytes to identify it.  If it works, enhancing
>>the request_firmware to support both hotplug and an initrd approach may
>>be reasonable.
>>    
>>
>
>That seems pretty ugly to me... imagine more than one driver does this
>:-(.
>  
>
Not ideal, but not *that bad* if there is a standard way to stick the
data on the initrd image.  Its annoying to have to do it, but it does
enable the most usage models and allows the network to be brought up as
early as possible--which other components in the system may be relying on.

>Having a parameter to control this seems a bit too complex to me.
>
>How is 
>
>insmod ipw2100 enable=1
>
>different from
>
>insmod ipw2100
>iwconfig eth1 start_scanning_or_whatever
>
>?
>  
>
It defaults to enabled, so you just need to do:

    insmod ipw2100

and it will auto associate with an open network.  For the use case where
users want the device to load but not initialize, they can use

    insmod ipw2100 disable=1

If hotplug and firmware loading worked early in the init sequence, no
one would have issue with the current model; it works as users expect it
to work.  It magically finds and associates to networks, and your
network scripts can then kick off DHCP, all with little to no special
crafting or utility interfacing. 

James

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> >Having a parameter to control this seems a bit too complex to me.
> >
> >How is 
> >
> >insmod ipw2100 enable=1
> >
> >different from
> >
> >insmod ipw2100
> >iwconfig eth1 start_scanning_or_whatever
> >
> >?
> It defaults to enabled, so you just need to do:
> 
>     insmod ipw2100
> 
> and it will auto associate with an open network.  For the use case where
> users want the device to load but not initialize, they can use
> 
>     insmod ipw2100 disable=1
> 
> If hotplug and firmware loading worked early in the init sequence, no
> one would have issue with the current model; it works as users expect it
> to work.  It magically finds and associates to networks, and your
> network scripts can then kick off DHCP, all with little to no special
> crafting or utility interfacing. 

Actually it would still transmit when user did not want it to. I
believe that staying "quiet" is right thing, long-term. And it could
solve firmware-loading problems, short-term...

How long does association with AP take? Anyway it should be easy to
tell driver to associate ASAP, just after the insmod...
								Pavel

Re: ipw2100: firmware problem

[Zhu Yi]

Hi Pavel,

On Thu, 2005-06-09 at 00:34 +0200, Pavel Machek wrote:
> Actually it would still transmit when user did not want it to. I
> believe that staying "quiet" is right thing, long-term. And it could
> solve firmware-loading problems, short-term...

If ipw2100 is built into kernel, you can disable it by kernel parameter
ipw2100.disable=1. Then you can enable it with:

$ echo 0 > /sys/bus/pci/drivers/ipw2100/*/rf_kill

> How long does association with AP take? Anyway it should be easy to
> tell driver to associate ASAP, just after the insmod...

Are you suggesting by default it is disabled for built into kernel but
enabled as a module?

Thanks,
-yi

Re: ipw2100: firmware problem

[Pavel Machek]

Hi!

> > Actually it would still transmit when user did not want it to. I
> > believe that staying "quiet" is right thing, long-term. And it could
> > solve firmware-loading problems, short-term...
> 
> If ipw2100 is built into kernel, you can disable it by kernel parameter
> ipw2100.disable=1. Then you can enable it with:
> 
> $ echo 0 > /sys/bus/pci/drivers/ipw2100/*/rf_kill
> 
> > How long does association with AP take? Anyway it should be easy to
> > tell driver to associate ASAP, just after the insmod...
> 
> Are you suggesting by default it is disabled for built into kernel but
> enabled as a module?

I'm suggesting that by default it is disabled (in kernel or as a
module) and its automatically enabled during ifconfig up.

That way we can drop the kernel parameter and always do the right
thing.

								Pavel

Re: ipw2100: firmware problem

[Andi Kleen]

James Ketrenos <jketreno@linux.intel.com> writes:
>>
> We've been looking into whether the initrd can have the firmware affixed
> to the end w/ some magic bytes to identify it.  If it works, enhancing
> the request_firmware to support both hotplug and an initrd approach may
> be reasonable.

That space is already used in common distributions for replacement DSDTs

I guess at some point we will need a file system in there, but - oops -
we already have one, dont we? :)

-Andi

Re: ipw2100: firmware problem

[Olivier Galibert]

On Thu, Jun 09, 2005 at 03:56:15PM +0200, Andi Kleen wrote:
> I guess at some point we will need a file system in there, but - oops -
> we already have one, dont we? :)

Well, you could put .config in it too.

Frankly, a filesystem that:
- can be somehow linked with vmlinux and not separate like an initrd

- editable post vmlinux-linking

- gives files that can be accessed from request_firmware, acpi and
  friends even rather early in the boot process (i.e. well before any
  userland is allowed to exist)

- accessible post-boot through mounting of a special fs and/or /proc or something

would be quite useful.

  OG.

Re: ipw2100: firmware problem

[Jeff Garzik]

Olivier Galibert wrote:
> On Thu, Jun 09, 2005 at 03:56:15PM +0200, Andi Kleen wrote:
> 
>>I guess at some point we will need a file system in there, but - oops -
>>we already have one, dont we? :)
> 
> 
> Well, you could put .config in it too.
> 
> Frankly, a filesystem that:
> - can be somehow linked with vmlinux and not separate like an initrd
> 
> - editable post vmlinux-linking
> 
> - gives files that can be accessed from request_firmware, acpi and
>   friends even rather early in the boot process (i.e. well before any
>   userland is allowed to exist)
> 
> - accessible post-boot through mounting of a special fs and/or /proc or something
> 
> would be quite useful.

This exists.  It's called initramfs.  Read the kernel code :)

	Jeff