[patch] do not allow IPW_2100=Y or IPW_2200=Y

[patch] do not allow IPW_2100=Y or IPW_2200=Y

[Pavel Machek]

Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
(not as a module). Unfortunately, such configuration does not work,
because these drivers need a firmware, and it can't be loaded by
userspace loader when userspace is not running.

Is there better way of creating N/m config option?

Signed-off-by: Pavel Machek <pavel@suse.cz>

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index fa9d2c4..050febb 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -144,9 +144,14 @@ config PCMCIA_RAYCS
 comment "Wireless 802.11b ISA/PCI cards support"
 	depends on NET_RADIO && (ISA || PCI || PPC_PMAC || PCMCIA)
 
+
+config MODULE_ONLY
+	tristate
+	default m
+
 config IPW2100
 	tristate "Intel PRO/Wireless 2100 Network Connection"
-	depends on NET_RADIO && PCI
+	depends on NET_RADIO && PCI && MODULE_ONLY
 	select FW_LOADER
 	select IEEE80211
 	---help---
@@ -200,7 +205,7 @@ config IPW2100_DEBUG
 
 config IPW2200
 	tristate "Intel PRO/Wireless 2200BG and 2915ABG Network Connection"
-	depends on NET_RADIO && PCI
+	depends on NET_RADIO && PCI && MODULE_ONLY
 	select FW_LOADER
 	select IEEE80211
 	---help---

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Jeff Garzik]

Pavel Machek wrote:
> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> (not as a module). Unfortunately, such configuration does not work,
> because these drivers need a firmware, and it can't be loaded by
> userspace loader when userspace is not running.

False, initramfs...

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Auke Kok]

Jeff Garzik wrote:
> Pavel Machek wrote:
>> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
>> (not as a module). Unfortunately, such configuration does not work,
>> because these drivers need a firmware, and it can't be loaded by
>> userspace loader when userspace is not running.
> 
> False, initramfs...

which would warrant some extra documentation in Kconfig explaining that this 
driver needs initramfs with firmware for it to work when compiled in the 
kernel. A link to the ipw2x00 documentation might also help.

Cheers,

Auke

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[David Miller]

From: Auke Kok <auke-jan.h.kok@intel.com>
Date: Mon, 10 Jul 2006 11:29:30 -0700

> Jeff Garzik wrote:
> > Pavel Machek wrote:
> >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> >> (not as a module). Unfortunately, such configuration does not work,
> >> because these drivers need a firmware, and it can't be loaded by
> >> userspace loader when userspace is not running.
> > 
> > False, initramfs...
> 
> which would warrant some extra documentation in Kconfig explaining that this 
> driver needs initramfs with firmware for it to work when compiled in the 
> kernel. A link to the ipw2x00 documentation might also help.

Besides, the initramfs runs long after the driver init routine
runs which is when the firmware needs to be available.

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Arjan van de Ven]

On Mon, 2006-07-10 at 11:47 -0700, David Miller wrote:
> From: Auke Kok <auke-jan.h.kok@intel.com>
> Date: Mon, 10 Jul 2006 11:29:30 -0700
> 
> > Jeff Garzik wrote:
> > > Pavel Machek wrote:
> > >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > >> (not as a module). Unfortunately, such configuration does not work,
> > >> because these drivers need a firmware, and it can't be loaded by
> > >> userspace loader when userspace is not running.
> > > 
> > > False, initramfs...
> > 
> > which would warrant some extra documentation in Kconfig explaining that this 
> > driver needs initramfs with firmware for it to work when compiled in the 
> > kernel. A link to the ipw2x00 documentation might also help.
> 
> Besides, the initramfs runs long after the driver init routine
> runs which is when the firmware needs to be available.

.. unless you use sysfs to do a fake hotunplug + replug the device, at
which point the driver init routine runs again.

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Joel Becker]

On Mon, Jul 10, 2006 at 08:51:58PM +0200, Arjan van de Ven wrote:
> > Besides, the initramfs runs long after the driver init routine
> > runs which is when the firmware needs to be available.
> 
> .. unless you use sysfs to do a fake hotunplug + replug the device, at
> which point the driver init routine runs again.

	Can we document how to do that?  I've wanted to synthesize such
things before, and I couldn't quite reason how.
	In my case, I had RHEL4 module-init-tools that don't wait for
modprobe, so I had to compile in scsi and qla2x00, but the qla2x00 needs
firmware, and it's too early...etc.

Joel

-- 

"Baby, even the losers
 Get luck sometimes.
 Even the losers
 Keep a little bit of pride."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Arjan van de Ven]

On Mon, 2006-07-10 at 13:56 -0700, Joel Becker wrote:
> On Mon, Jul 10, 2006 at 08:51:58PM +0200, Arjan van de Ven wrote:
> > > Besides, the initramfs runs long after the driver init routine
> > > runs which is when the firmware needs to be available.
> > 
> > .. unless you use sysfs to do a fake hotunplug + replug the device, at
> > which point the driver init routine runs again.
> 
> 	Can we document how to do that?  I've wanted to synthesize such
> things before, and I couldn't quite reason how.

just load fakephp

then do 
echo -n 0 > /sys/bus/pci/slots/0000:04:02.1/power
this hotunplugs it (fake)

then just do

echo -n 1 > /sys/bus/pci/slots/0000:04:02.0/power
(or any other device on the 04 bus) and the kernel finds the 04:02.1
device again...

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Joel Becker]

On Tue, Jul 11, 2006 at 04:42:13PM +0200, Arjan van de Ven wrote:
> just load fakephp

	Thanks!  I'd never heard of it :-)

Joel
 

-- 

"The only way to get rid of a temptation is to yield to it."
         - Oscar Wilde 

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Pavel Machek]

Hi!

> > > >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > >> (not as a module). Unfortunately, such configuration does not work,
> > > >> because these drivers need a firmware, and it can't be loaded by
> > > >> userspace loader when userspace is not running.
> > > > 
> > > > False, initramfs...
> > > 
> > > which would warrant some extra documentation in Kconfig explaining that this 
> > > driver needs initramfs with firmware for it to work when compiled in the 
> > > kernel. A link to the ipw2x00 documentation might also help.
> > 
> > Besides, the initramfs runs long after the driver init routine
> > runs which is when the firmware needs to be available.
> 
> .. unless you use sysfs to do a fake hotunplug + replug the device, at
> which point the driver init routine runs again.

Ouch, nice trick. But how do I actually pull it up? There's nothing
that looks like allowing that in /sys:

root@amd:/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0# ls
broken_parity_status  config  irq         power/     subsystem@
uevent
bus@                  device  local_cpus  resource   subsystem_device
vendor
class                 enable  modalias    resource0  subsystem_vendor
root@amd:/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0#

I tried going to bus/drivers/ and unbind/rebind ipw2200 driver; that
does not work. I tried echo 0 > enable; echo 1 > enable, but no trick,
either.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Arjan van de Ven]

On Tue, 2006-07-11 at 13:27 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > >> Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > > >> (not as a module). Unfortunately, such configuration does not work,
> > > > >> because these drivers need a firmware, and it can't be loaded by
> > > > >> userspace loader when userspace is not running.
> > > > > 
> > > > > False, initramfs...
> > > > 
> > > > which would warrant some extra documentation in Kconfig explaining that this 
> > > > driver needs initramfs with firmware for it to work when compiled in the 
> > > > kernel. A link to the ipw2x00 documentation might also help.
> > > 
> > > Besides, the initramfs runs long after the driver init routine
> > > runs which is when the firmware needs to be available.
> > 
> > .. unless you use sysfs to do a fake hotunplug + replug the device, at
> > which point the driver init routine runs again.
> 
> Ouch, nice trick. But how do I actually pull it up? There's nothing
> that looks like allowing that in /sys:
> 
> root@amd:/sys/devices/pci0000:00/0000:00:1e.0/0000:02:02.0# ls

/sys/bus/pci/slots/0000:04:02.1

need to go there via bus/pci/slots

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Michael Buesch]

On Monday 10 July 2006 19:53, you wrote:
> Pavel Machek wrote:
> > Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > (not as a module). Unfortunately, such configuration does not work,
> > because these drivers need a firmware, and it can't be loaded by
> > userspace loader when userspace is not running.
> 
> False, initramfs...

Does the ipw driver _really_ need the firmware on insmod time?
bcm43xx, for example, loads the firmware on "ifconfig up" time.
If ipw really needs the firmware on insmod, is it possible to
defer it to later at "ifconfig up" time?

-- 
Greetings Michael.

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Daniel Drake]

Michael Buesch wrote:
> Does the ipw driver _really_ need the firmware on insmod time?
> bcm43xx, for example, loads the firmware on "ifconfig up" time.
> If ipw really needs the firmware on insmod, is it possible to
> defer it to later at "ifconfig up" time?

Is bcm43xx able to get the MAC address before the firmware is loaded?
Last time I checked, if the MAC address is only discovered after the 
interface is created (as would be the case with ipw loading firmware on 
ifconfig up, I think), interface renaming does not work.

Daniel

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Michael Buesch]

On Tuesday 11 July 2006 13:53, you wrote:
> Michael Buesch wrote:
> > Does the ipw driver _really_ need the firmware on insmod time?
> > bcm43xx, for example, loads the firmware on "ifconfig up" time.
> > If ipw really needs the firmware on insmod, is it possible to
> > defer it to later at "ifconfig up" time?
> 
> Is bcm43xx able to get the MAC address before the firmware is loaded?

Yes. We have a PROM that is readable without firmware.
(And we actually do this and did it forever. So I don't know
where your assumption comes from ;) )

> Last time I checked, if the MAC address is only discovered after the 
> interface is created (as would be the case with ipw loading firmware on 
> ifconfig up, I think), interface renaming does not work.

-- 
Greetings Michael.

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Daniel Drake]

Michael Buesch wrote:
> Yes. We have a PROM that is readable without firmware.
> (And we actually do this and did it forever. So I don't know
> where your assumption comes from ;) )

It wasn't an assumption: I was stating something about the Intel cards. 
It is not possible to determine the MAC address for ipw2100/ipw2200 
until the firmware is loaded.

Daniel

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Pavel Machek]

On Mon 2006-07-10 23:05:06, Michael Buesch wrote:
> On Monday 10 July 2006 19:53, you wrote:
> > Pavel Machek wrote:
> > > Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel
> > > (not as a module). Unfortunately, such configuration does not work,
> > > because these drivers need a firmware, and it can't be loaded by
> > > userspace loader when userspace is not running.
> > 
> > False, initramfs...
> 
> Does the ipw driver _really_ need the firmware on insmod time?
> bcm43xx, for example, loads the firmware on "ifconfig up" time.
> If ipw really needs the firmware on insmod, is it possible to
> defer it to later at "ifconfig up" time?

Probably not. This (very dirty) hack implements that (with some level
of success -- ifconfig down/ifconfig up is enough to get wireless
working).

Signed-off-by: Pavel Machek <pavel@suse.cz>

									Pavel

--- clean-mm/drivers/net/wireless/ipw2200.c	2006-07-11 15:22:50.000000000 +0200
+++ linux-mm/drivers/net/wireless/ipw2200.c	2006-07-11 14:38:01.000000000 +0200
@@ -97,6 +97,7 @@
 static int bt_coexist = 0;
 static int hwcrypto = 0;
 static int roaming = 1;
+static int needs_reinit = 1;
 static const char ipw_modes[] = {
 	'a', 'b', 'g', '?'
 };
@@ -10013,10 +10014,20 @@
 	sys_config->silence_threshold = 0x1e;
 }
 
+static int ipw_pci_suspend(struct pci_dev *pdev, pm_message_t state);
+static int ipw_pci_resume(struct pci_dev *pdev);
+
 static int ipw_net_open(struct net_device *dev)
 {
 	struct ipw_priv *priv = ieee80211_priv(dev);
 	IPW_DEBUG_INFO("dev->open\n");
+
+	if (needs_reinit) {
+		printk("ipw: Delayed loading the firmware\n");
+		ipw_pci_suspend(priv->pci_dev, PMSG_FREEZE);
+		ipw_pci_resume(priv->pci_dev);
+	}
+
 	/* we should be verifying the device is ready to be opened */
 	mutex_lock(&priv->mutex);
 	if (!(priv->status & STATUS_RF_KILL_MASK) &&
@@ -11295,7 +11306,8 @@
 
 	if (ipw_up(priv)) {
 		mutex_unlock(&priv->mutex);
-		return -EIO;
+		needs_reinit = 1;
+		return 0;
 	}
 
 	mutex_unlock(&priv->mutex);


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Zhu Yi]

On Tue, 2006-07-11 at 15:32 +0200, Pavel Machek wrote:
> Probably not. This (very dirty) hack implements that (with some level
> of success -- ifconfig down/ifconfig up is enough to get wireless
> working).

You just need to

$ iwpriv ethX reset

Thanks,
-yi

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[John W. Linville]

On Wed, Jul 12, 2006 at 12:39:58PM +0800, Zhu Yi wrote:
> On Tue, 2006-07-11 at 15:32 +0200, Pavel Machek wrote:
> > Probably not. This (very dirty) hack implements that (with some level
> > of success -- ifconfig down/ifconfig up is enough to get wireless
> > working).
> 
> You just need to
> 
> $ iwpriv ethX reset

I presume that this is sufficient, and I can drop this thread (except
the comment cleanup patch)?

John
-- 
John W. Linville
linville@tuxdriver.com

[patch] cleanup // comments from ipw2200

[Pavel Machek]

ipw2200 uses // comments, and uses them for removing unneeded
code. Clean it up a bit.

Signed-off-by: Pavel Machek <pavel@suse.cz>

diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index b3300ff..758459e 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -2667,7 +2667,7 @@ static void ipw_fw_dma_abort(struct ipw_
 
 	IPW_DEBUG_FW(">> :\n");
 
-	//set the Stop and Abort bit
+	/* set the Stop and Abort bit */
 	control = DMA_CONTROL_SMALL_CB_CONST_VALUE | DMA_CB_STOP_AND_ABORT;
 	ipw_write_reg32(priv, IPW_DMA_I_DMA_CONTROL, control);
 	priv->sram_desc.last_cb_index = 0;
@@ -3002,8 +3002,6 @@ static int ipw_load_ucode(struct ipw_pri
 	if (rc < 0)
 		return rc;
 
-//      spin_lock_irqsave(&priv->lock, flags);
-
 	for (addr = IPW_SHARED_LOWER_BOUND;
 	     addr < IPW_REGISTER_DOMAIN1_END; addr += 4) {
 		ipw_write32(priv, addr, 0);
@@ -3097,8 +3095,6 @@ static int ipw_load_ucode(struct ipw_pri
 	   firmware have problem getting alive resp. */
 	ipw_write_reg8(priv, IPW_BASEBAND_CONTROL_STATUS, 0);
 
-//      spin_unlock_irqrestore(&priv->lock, flags);
-
 	return rc;
 }
 
@@ -6387,13 +6383,6 @@ static int ipw_wx_set_genie(struct net_d
 	    (wrqu->data.length && extra == NULL))
 		return -EINVAL;
 
-	//mutex_lock(&priv->mutex);
-
-	//if (!ieee->wpa_enabled) {
-	//      err = -EOPNOTSUPP;
-	//      goto out;
-	//}
-
 	if (wrqu->data.length) {
 		buf = kmalloc(wrqu->data.length, GFP_KERNEL);
 		if (buf == NULL) {
@@ -6413,7 +6402,6 @@ static int ipw_wx_set_genie(struct net_d
 
 	ipw_wpa_assoc_frame(priv, ieee->wpa_ie, ieee->wpa_ie_len);
       out:
-	//mutex_unlock(&priv->mutex);
 	return err;
 }
 
@@ -6426,13 +6414,6 @@ static int ipw_wx_get_genie(struct net_d
 	struct ieee80211_device *ieee = priv->ieee;
 	int err = 0;
 
-	//mutex_lock(&priv->mutex);
-
-	//if (!ieee->wpa_enabled) {
-	//      err = -EOPNOTSUPP;
-	//      goto out;
-	//}
-
 	if (ieee->wpa_ie_len == 0 || ieee->wpa_ie == NULL) {
 		wrqu->data.length = 0;
 		goto out;
@@ -6447,7 +6428,6 @@ static int ipw_wx_get_genie(struct net_d
 	memcpy(extra, ieee->wpa_ie, ieee->wpa_ie_len);
 
       out:
-	//mutex_unlock(&priv->mutex);
 	return err;
 }
 
@@ -6558,7 +6538,6 @@ static int ipw_wx_set_auth(struct net_de
 		ieee->ieee802_1x = param->value;
 		break;
 
-		//case IW_AUTH_ROAMING_CONTROL:
 	case IW_AUTH_PRIVACY_INVOKED:
 		ieee->privacy_invoked = param->value;
 		break;
@@ -6680,7 +6659,7 @@ static int ipw_wx_set_mlme(struct net_de
 
 	switch (mlme->cmd) {
 	case IW_MLME_DEAUTH:
-		// silently ignore
+		/* silently ignore */
 		break;
 
 	case IW_MLME_DISASSOC:
@@ -9766,7 +9745,7 @@ static int ipw_wx_set_monitor(struct net
 	return 0;
 }
 
-#endif				// CONFIG_IPW2200_MONITOR
+#endif				/* CONFIG_IPW2200_MONITOR */
 
 static int ipw_wx_reset(struct net_device *dev,
 			struct iw_request_info *info,
@@ -10009,7 +9988,7 @@ static  void init_sys_config(struct ipw_
 	sys_config->dot11g_auto_detection = 0;
 	sys_config->enable_cts_to_self = 0;
 	sys_config->bt_coexist_collision_thr = 0;
-	sys_config->pass_noise_stats_to_host = 1;	//1 -- fix for 256
+	sys_config->pass_noise_stats_to_host = 1;	/* 1 -- fix for 256 */
 	sys_config->silence_threshold = 0x1e;
 }
 



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Jan Engelhardt]

>Is there better way of creating N/m config option?

> config IPW2100
> 	tristate "Intel PRO/Wireless 2100 Network Connection"
>-	depends on NET_RADIO && PCI
>+	depends on NET_RADIO && PCI && MODULE_ONLY

"depends on NET_RADIO && PCI && m"


Jan Engelhardt
-- 

Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y

[Bodo Eggert]

Pavel Machek <pavel@ucw.cz> wrote:

> +++ linux-mm/drivers/net/wireless/ipw2200.c 

These are all uses of needs_reinit:

> +static int needs_reinit = 1;

> +             needs_reinit = 1;

I asume there is something missing.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html