Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Malte Gell @ 2009-09-29 11:07 UTC (permalink / raw)
  To: Hin-Tak Leung; +Cc: linux-wireless
In-Reply-To: <3ace41890909290328l14620ed6o4939488e268d76a3@mail.gmail.com>


"Hin-Tak Leung" <hintak.leung@gmail.com> wrote

> CONFIG_COMPAT_WIRELESS_28
> 

Jep, changed to 27, but, did not compile......:

/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.c: In function 
‘ar9170_usb_cancel_urbs’:
/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.c:380: error: implicit 
declaration of function ‘usb_poison_anchored_urbs’
make[5]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170/usb.o] Fehler 1
make[4]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath/ar9170] Fehler 2
make[3]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless/ath] Fehler 2
make[2]: *** [/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29/drivers/net/wireless] Fehler 2
make[1]: *** [_module_/home/malte_gell/download/src/wifi/compat-
wireless-2009-09-29] Fehler 2
make[1]: Leaving directory `/usr/src/linux-2.6.27.29-0.1'
make: *** [modules] Fehler 2


^ permalink raw reply

* Re: Firmware versioning best practices
From: Holger Schurig @ 2009-09-29 11:01 UTC (permalink / raw)
  To: Tomas Winkler; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1ba2fa240909290345k776826a6jc692d9d8dfe7577@mail.gmail.com>

> > Don't put the version into the filename. This is not a common
> > practice for Linux / BSD / whatever systems. Usually you have
> > a "kmail" file, not a kmail3.5, kmail4.0 and kmail4.2 file.
> 
> I think in this context libyyy.so.x.y.z is better analogy.
> firmware is not an executable What is the reasoning behind this
> common practice? 

There's no version of the library in the file-name, but the 
version of the API. So if the API changes, and might break users 
of the API, you increase the filename.

But you won't have a libc-2.3.6.so file. Instead you have a 
package "libc6_2.3.6.ds1-13etch9_i386.deb" which contains the 
file libc.so.6.

-- 
http://www.holgerschurig.de

^ permalink raw reply

* Re: Firmware versioning best practices
From: Tomas Winkler @ 2009-09-29 10:45 UTC (permalink / raw)
  To: Holger Schurig
  Cc: Luis R. Rodriguez, linux-wireless, reinette chatre, Kalle Valo,
	Johannes Berg, Christian Lamparter, Bob Copeland
In-Reply-To: <200909290859.25075.hs4233@mail.mn-solutions.de>

On Tue, Sep 29, 2009 at 8:59 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
>> Or shall we have the same firmware filename and simply query
>> the firmware for a map of capabilities? Any other ideas?
>
> Don't put the version into the filename. This is not a common
> practice for Linux / BSD / whatever systems. Usually you have
> a "kmail" file, not a kmail3.5, kmail4.0 and kmail4.2 file.

I think in this context libyyy.so.x.y.z is better analogy. firmware is
not an executable
What is the reasoning behind this common practice?

> Versions or capability maps can be stored inside the firmware and
> queried at load time. E.g. the libertas driver does it that way.

It's only check if it fits but cannot fall back to an older version.
.
>
> If you make your firmware redistributable (which I recommend),
> the version will also be stored in the package metadata, e.g.
> the rpm or deb file and the infrastructure for rpm/yum deb/apt.
>
> --
> http://www.holgerschurig.de
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Thanks
Tomas

^ permalink raw reply

* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Hin-Tak Leung @ 2009-09-29 10:28 UTC (permalink / raw)
  To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909291145.35972.malte.gell@gmx.de>

On Tue, Sep 29, 2009 at 10:45 AM, Malte Gell <malte.gell@gmx.de> wrote:
>
> "Hin-Tak Leung" <hintak.leung@gmail.com> wrote
>
>> > So, no need to modify compat-2.6.28.c? Does it automatically happen?
>>
>> You may or may not  see any errors at the linker stage (the LD part in
>> stage 2). If you get to that point without further error, then, well,
>> count yourself lucky and just give "make install ; make unload;
>> modprobe -v ar9170" a go.
>
> Ho ho ;-) I got a lot of warnings like this:
>
>  include/linux/tracepoint.h:86:1: warning: this is the location of the
> previous definition
>
> But, it DID compile! Thanx a lot.
>
> To be sure I did a find . -name "*.ko" and got these modules:
>
> ./drivers/net/wireless/ath/ath.ko
> ./net/rfkill/rfkill_backport.ko
> ./net/wireless/cfg80211.ko
> ./net/mac80211/mac80211.ko
>
> I just wonder, where is ar9170usb !? I did ./scripts/driver-select ar9170
>
> Malte
>

Argh... try changing this line  in config.mk

ifndef CONFIG_COMPAT_WIRELESS_28

to ...27.

apparently it is disabled below 2.6.28.  but then, yours is somewhere between.
------------
commit 13e9384e59b2cadaef7468f1417b9a1327419c89
Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date:   Tue Jul 21 14:43:15 2009 -0700

    ar9170 works needs more compat work for 2.6.27

    We leave it only enabled for >= 2.6.28,
    usb_hcd_unlink_urb() is used within usb_poison_urb()
    and although it is available on 2.6.27 its not exported
    and cannot be re-implemented. If we figure out a way
    to drop the urb from the hardware queue as usb_hcd_unlink_urb()
    does then we can backport this.

    Also I think we need to backport usb_kill_urb_queue().

    Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
------------

^ permalink raw reply

* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Malte Gell @ 2009-09-29  9:45 UTC (permalink / raw)
  To: Hin-Tak Leung, ndiswrapper-general; +Cc: linux-wireless
In-Reply-To: <3ace41890909290206g3019a9cbv29048837804f830@mail.gmail.com>


"Hin-Tak Leung" <hintak.leung@gmail.com> wrote

> > So, no need to modify compat-2.6.28.c? Does it automatically happen?
> 
> You may or may not  see any errors at the linker stage (the LD part in
> stage 2). If you get to that point without further error, then, well,
> count yourself lucky and just give "make install ; make unload;
> modprobe -v ar9170" a go.

Ho ho ;-) I got a lot of warnings like this:

 include/linux/tracepoint.h:86:1: warning: this is the location of the 
previous definition

But, it DID compile! Thanx a lot.

To be sure I did a find . -name "*.ko" and got these modules:

./drivers/net/wireless/ath/ath.ko
./net/rfkill/rfkill_backport.ko
./net/wireless/cfg80211.ko
./net/mac80211/mac80211.ko

I just wonder, where is ar9170usb !? I did ./scripts/driver-select ar9170

Malte

^ permalink raw reply

* Re: [PATCH 2/3] iwmc3200wifi: select IWMC3200TOP in Kconfig
From: Zhu Yi @ 2009-09-29  9:22 UTC (permalink / raw)
  To: Winkler, Tomas
  Cc: davem@davemloft.net, linville@tuxdriver.com,
	netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-mmc@vger.kernel.org, Perez-Gonzalez, Inaky, Kao, Cindy H,
	Cohen, Guy, Rindjunsky, Ron
In-Reply-To: <1253662724-16497-3-git-send-email-tomas.winkler@intel.com>

On Wed, 2009-09-23 at 07:38 +0800, Winkler, Tomas wrote:
> iwmc3200wifi requires iwmc3200top  for its operation
> 
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>

Acked-by: Zhu Yi <yi.zhu@intel.com>

Thanks,
-yi

> ---
>  drivers/net/wireless/iwmc3200wifi/Kconfig |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/wireless/iwmc3200wifi/Kconfig b/drivers/net/wireless/iwmc3200wifi/Kconfig
> index c62da43..69faaf1 100644
> --- a/drivers/net/wireless/iwmc3200wifi/Kconfig
> +++ b/drivers/net/wireless/iwmc3200wifi/Kconfig
> @@ -3,6 +3,7 @@ config IWM
>  	depends on MMC && WLAN_80211 && EXPERIMENTAL
>  	depends on CFG80211
>  	select FW_LOADER
> +	select IWMC3200TOP
>  	help
>  	  The Intel Wireless Multicomm 3200 hardware is a combo
>  	  card with GPS, Bluetooth, WiMax and 802.11 radios. It


^ permalink raw reply

* Re: bleeding edge ar9170usb: Fritz N USB support?
From: Hin-Tak Leung @ 2009-09-29  9:14 UTC (permalink / raw)
  To: Malte Gell; +Cc: linux-wireless
In-Reply-To: <200909291014.57777.malte.gell@gmx.de>

On Tue, Sep 29, 2009 at 9:14 AM, Malte Gell <malte.gell@gmx.de> wrote:
> Hello!
>
> At
>
> http://linuxwireless.org/en/users/Drivers/ar9170
>
> I read support for the 802.11n Fritz N USB will be until kernel 2.6.32.
>
> So, I wonder is this USB stick already supported in the bleeding edge compat-
> wireless-2.6?

sigh. bleeding edge compat-wireless is ahead of Linus' tree (I already
told you, and probably more than once).

^ permalink raw reply

* Re: Disassociating atheros wlan with 2.6.31
From: Kristoffer Ericson @ 2009-09-29  9:16 UTC (permalink / raw)
  To: Justin P. Mattock
  Cc: Stefan Lippers-Hollmann, linux-wireless,
	linux-kernel@vger.kernel.org
In-Reply-To: <4ABBD170.6060702@gmail.com>

On Thu, 24 Sep 2009 13:07:12 -0700
"Justin P. Mattock" <justinmattock@gmail.com> wrote:

> Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > CCing linux-wireless@vger.kernel.org, as it's not very likely to get
> > noticed here by wireless developers.
> >
> > On Thursday 24 September 2009, Justin P. Mattock wrote:
> >    
> >> Kristoffer Ericson wrote:
> >>      
> >>> Greetings,
> >>>
> >>> When moving from vanilla 2.6.30->2.6.31 I noticed that I get dissasociated from
> >>> my wlan hub with regular intervalls. This did not happen on 2.6.30.
> >>> I cant see any pattern aside from that it happens at regular intervalls
> >>> (around 10-15mins). It works again when I re-identifies myself.
> >>>
> >>> Got an Asus 1000HE with Atheros chipset.
> >>> Havent had time to bisect it, just wanted to check
> >>> if this is an known issue. Ive ruled out faulty wlan hub
> >>> since everything works fine when going back to 2.6.30.
> >>>
> >>> nothing much on dmesg:
> >>> uhci_hcd 0000:00:1d.1: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
> >>> uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000d480
> >>> usb usb3: configuration #1 chosen from 1 choice
> >>> hub 3-0:1.0: USB hub found
> >>> hub 3-0:1.0: 2 ports detected
> >>> uhci_hcd 0000:00:1d.2: PCI INT C ->   GSI 18 (level, low) ->   IRQ 18
> >>> uhci_hcd 0000:00:1d.2: setting latency timer to 64
> >>> uhci_hcd 0000:00:1d.2: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
> >>> uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d800
> >>> usb usb4: configuration #1 chosen from 1 choice
> >>> hub 4-0:1.0: USB hub found
> >>> hub 4-0:1.0: 2 ports detected
> >>> uhci_hcd 0000:00:1d.3: PCI INT D ->   GSI 16 (level, low) ->   IRQ 16
> >>> uhci_hcd 0000:00:1d.3: setting latency timer to 64
> >>> uhci_hcd 0000:00:1d.3: UHCI Host Controller
> >>> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
> >>> uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d880
> >>> usb usb5: configuration #1 chosen from 1 choice
> >>> hub 5-0:1.0: USB hub found
> >>> hub 5-0:1.0: 2 ports detected
> >>> input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
> >>> usb 1-4: new high speed USB device using ehci_hcd and address 3
> >>> usb 1-4: configuration #1 chosen from 1 choice
> >>> hub 1-4:1.0: USB hub found
> >>> hub 1-4:1.0: 4 ports detected
> >>> usb 1-5: new high speed USB device using ehci_hcd and address 4
> >>> usb 1-5: configuration #1 chosen from 1 choice
> >>> usb 1-8: new high speed USB device using ehci_hcd and address 6
> >>> usb 1-8: configuration #1 chosen from 1 choice
> >>> Initializing USB Mass Storage driver...
> >>> scsi4 : SCSI emulation for USB Mass Storage devices
> >>> usbcore: registered new interface driver usb-storage
> >>> USB Mass Storage support registered.
> >>> usb-storage: device found at 4
> >>> usb-storage: waiting for device to settle before scanning
> >>> HDA Intel 0000:00:1b.0: PCI INT A ->   GSI 16 (level, low) ->   IRQ 16
> >>> HDA Intel 0000:00:1b.0: setting latency timer to 64
> >>> usb 2-2: new full speed USB device using uhci_hcd and address 2
> >>> ath9k 0000:01:00.0: PCI INT A ->   GSI 19 (level, low) ->   IRQ 19
> >>> ath9k 0000:01:00.0: setting latency timer to 64
> >>> usb 2-2: configuration #1 chosen from 1 choice
> >>> input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8
> >>> usbcore: registered new interface driver usbserial
> >>> USB Serial support registered for generic
> >>> usb 5-1: new full speed USB device using uhci_hcd and address 2
> >>> usb 5-1: configuration #1 chosen from 1 choice
> >>> usb 1-4.1: new full speed USB device using ehci_hcd and address 7
> >>> ath: EEPROM regdomain: 0x60
> >>> ath: EEPROM indicates we should expect a direct regpair map
> >>> ath: Country alpha2 being used: 00
> >>> ath: Regpair used: 0x60
> >>> Bluetooth: Core ver 2.15
> >>> NET: Registered protocol family 31
> >>> Bluetooth: HCI device and connection manager initialized
> >>> Bluetooth: HCI socket layer initialized
> >>> Bluetooth: Generic Bluetooth USB driver ver 0.5
> >>> usb 1-4.1: configuration #1 chosen from 1 choice
> >>> usb 1-4.2: new low speed USB device using ehci_hcd and address 8
> >>> usb 1-4.2: configuration #1 chosen from 1 choice
> >>> usb 1-4.4: new low speed USB device using ehci_hcd and address 9
> >>> usbcore: registered new interface driver hiddev
> >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input9
> >>> generic-usb 0003:04D9:1203.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input0
> >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input10
> >>> generic-usb 0003:04D9:1203.0002: input,hidraw1: USB HID v1.11 Device [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input1
> >>> usbcore: registered new interface driver usbhid
> >>> usbhid: v2.6:USB HID core driver
> >>> usb 1-4.4: configuration #1 chosen from 1 choice
> >>> input: B16_b_02 USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input11
> >>> generic-usb 0003:046D:C025.0003: input,hidraw2: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-4.4/input0
> >>> usbcore: registered new interface driver btusb
> >>> usbcore: registered new interface driver usbserial_generic
> >>> usbserial: USB Serial Driver core
> >>> USB Serial support registered for GSM modem (1-port)
> >>> option 2-2:1.0: GSM modem (1-port) converter detected
> >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
> >>> option 2-2:1.1: GSM modem (1-port) converter detected
> >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
> >>> usbcore: registered new interface driver option
> >>> option: v0.7.2:USB Driver for GSM modems
> >>> USB Serial support registered for pl2303
> >>> pl2303 1-4.1:1.0: pl2303 converter detected
> >>> usb 1-4.1: pl2303 converter now attached to ttyUSB2
> >>> usbcore: registered new interface driver pl2303
> >>> pl2303: Prolific PL2303 USB to serial adaptor driver
> >>> phy0: Selected rate control algorithm 'ath9k_rate_control'
> >>> Registered led device: ath9k-phy0::radio
> >>> Registered led device: ath9k-phy0::assoc
> >>> Registered led device: ath9k-phy0::tx
> >>> Registered led device: ath9k-phy0::rx
> >>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8880000, irq=19
> >>> scsi 4:0:0:0: Direct-Access     Single   Flash Reader     1.00 PQ: 0 ANSI: 0
> >>> sd 4:0:0:0: Attached scsi generic sg1 type 0
> >>> sd 4:0:0:0: [sdb] 15954944 512-byte logical blocks: (8.16 GB/7.60 GiB)
> >>> usb-storage: device scan complete
> >>> sd 4:0:0:0: [sdb] Write Protect is off
> >>> sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>>    sdb: sdb1
> >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
> >>> sd 4:0:0:0: [sdb] Attached SCSI removable disk
> >>> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> >>> EXT3 FS on sda1, internal journal
> >>> Bluetooth: L2CAP ver 2.13
> >>> Bluetooth: L2CAP socket layer initialized
> >>> Bluetooth: SCO (Voice Link) ver 0.6
> >>> Bluetooth: SCO socket layer initialized
> >>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> >>> Bridge firewalling registered
> >>> Bluetooth: RFCOMM TTY layer initialized
> >>> Bluetooth: RFCOMM socket layer initialized
> >>> Bluetooth: RFCOMM ver 1.11
> >>> ATL1E 0000:03:00.0: irq 27 for MSI/MSI-X
> >>> fuse init (API version 7.12)
> >>> ip_tables: (C) 2000-2006 Netfilter Core Team
> >>> nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> >>> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> >>> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
> >>> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> PPP generic driver version 2.4.2
> >>> NET: Registered protocol family 10
> >>> lo: Disabled Privacy Extensions
> >>> ADDRCONF(NETDEV_UP): eth0: link is not ready
> >>> PPP BSD Compression module registered
> >>> PPP Deflate Compression module registered
> >>> wlan0: no IPv6 routers present
> >>> CE: hpet increasing min_delta_ns to 15000 nsec
> >>> wlan0: no probe response from AP 00:14:7c:ae:d1:90 - disassociating
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
> >>> wlan0: authenticated
> >>> wlan0: associate with AP 00:14:7c:ae:d1:90
> >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
> >>> wlan0: associated
> >>> [kristoffer@boggieman wine.git]$
> >>>
> >>>
> >>>
> >>>        
> >> yeah I'm seeing this with my macbook pro(ath9k)
> >> while streaming music, all of a sudden things just crap out.
> >> (not sure if this is why, or something else).
> >>
> >> Justin P. Mattock
> >>      
> >
> > I'm getting similar reports for iwl3945 and 2.6.31.[01], but can't confirm
> > this on my own (non-iwl{3945,agn}, non-ath9k) hardware yet.
> >
> > Regards
> > 	Stefan Lippers-Hollmann
> >
> >    
> I don't mind doing a bisect from 30 - present, but first I need to
> do some other stuff.

Got any updates on this? Im stuck in doing other kernel stuff and has
left 2.6.31 currently since I need it for internet sharing (through wlan0).
Its a real pain having it drop every 15mins. 

> 
> Justin P. Mattock


-- 
Kristoffer Ericson <kristoffer.ericson@gmail.com>

^ permalink raw reply

* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Hin-Tak Leung @ 2009-09-29  9:06 UTC (permalink / raw)
  To: Malte Gell; +Cc: Hin-Tak Leung, ndiswrapper-general, linux-wireless
In-Reply-To: <200909291058.43765.malte.gell@gmx.de>

On Tue, Sep 29, 2009 at 9:58 AM, Malte Gell <malte.gell@gmx.de> wrote:
>
> "Hin-Tak Leung" <hintak_leung@yahoo.co.uk> wrote
>
>> Hmm, I see you have already posted to linux-wireless and already got your
>>  answers. Hauke has already given you the answer - your kernel tree is
>>  *not* 2.6.27(.0), and as it is obvious that you have 2.6.27.29-0.1, which
>>  is 2.6.27.29 + suse-patches. Even 2.6.27.29 is not 2.6.27(.0), but
>>  somewhat closer to 2.6.28. And you really have already had your answer -
>>  your tree is somewhat between 2.6.27 and 2.6.28, and *neither*.
>>
>> My suggestion would be simply to delete all the 'error: redefinition' parts
>>  from net/compat-2.6.28.h , because you already have them in the suse tree.
>
> Thanx for your efforts. By the way, do I need to set  CONFIG_TRACEPOINTS in the
> kernel? I just see it is _not_ set in openSUSE 11.1.

No, do *not* modify any kernel config files. You should not do that,
as the compat modules should be compiled against a correct config, as
in a config that corresponds to how your kernel was built.

>>  You may also need to delete something from net/compat-2.6.28.c, but that
>>  will happen during the linking stage (much later).
>
> So, no need to modify compat-2.6.28.c? Does it automatically happen?

You may or may not  see any errors at the linker stage (the LD part in
stage 2). If you get to that point without further error, then, well,
count yourself lucky and just give "make install ; make unload;
modprobe -v ar9170" a go.

^ permalink raw reply

* Re: cannot compile compate-wirless snapshots
From: Hin-Tak Leung @ 2009-09-29  9:00 UTC (permalink / raw)
  To: Malte Gell; +Cc: Hauke Mehrtens, linux-wireless
In-Reply-To: <200909291050.54388.malte.gell@gmx.de>

On Tue, Sep 29, 2009 at 9:50 AM, Malte Gell <malte.gell@gmx.de> wrote:
>
> Hauke Mehrtens <hauke@hauke-m.de> wrote
>
>
>> Does this file exists in your installation?
>> /lib/modules/`uname -r`/build/include/linux/tracepoint.h ?
>
> Yes, but, look:
>
> cd /usr/src/linux
>
> grep -i tracepoint .config
>
> # CONFIG_TRACEPOINTS is not set
>
> Do I need to set it to yes?
>
> Malte
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

No. You should not manually edit any kernel config file (the
compat-wireless module should be built against a config matching your
running kernel, not a massaged version of it) and what is in
/usr/src/linux is irrelevant , because that is not your running
kernel.

The relevant config is probably /boot/config-`uname -r`, but, please
do *not* modify it.

I already wrote - your best bet is simply deleting all the 'error
redefintion' parts from net/compat-2.6.28.h, since your kernel tree is
somewhere between 2.6.27 and 2.6.28 . (and also delete some part of
net/compat-2.6.28.c when possible later linker error arises).

^ permalink raw reply

* Re: compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Malte Gell @ 2009-09-29  8:58 UTC (permalink / raw)
  To: Hin-Tak Leung; +Cc: ndiswrapper-general, linux-wireless
In-Reply-To: <999306.93095.qm@web23102.mail.ird.yahoo.com>


"Hin-Tak Leung" <hintak_leung@yahoo.co.uk> wrote
 
> Hmm, I see you have already posted to linux-wireless and already got your
>  answers. Hauke has already given you the answer - your kernel tree is
>  *not* 2.6.27(.0), and as it is obvious that you have 2.6.27.29-0.1, which
>  is 2.6.27.29 + suse-patches. Even 2.6.27.29 is not 2.6.27(.0), but
>  somewhat closer to 2.6.28. And you really have already had your answer -
>  your tree is somewhat between 2.6.27 and 2.6.28, and *neither*.
> 
> My suggestion would be simply to delete all the 'error: redefinition' parts
>  from net/compat-2.6.28.h , because you already have them in the suse tree.

Thanx for your efforts. By the way, do I need to set  CONFIG_TRACEPOINTS in the 
kernel? I just see it is _not_ set in openSUSE 11.1.

>  You may also need to delete something from net/compat-2.6.28.c, but that
>  will happen during the linking stage (much later).

So, no need to modify compat-2.6.28.c? Does it automatically happen?

Regards
Malte

^ permalink raw reply

* compat-wireless tracepoint error Re: [Ndiswrapper-general] Need help to create driver for Netgear WN111v2
From: Hin-Tak Leung @ 2009-09-29  8:51 UTC (permalink / raw)
  To: Malte Gell; +Cc: ndiswrapper-general, linux-wireless
In-Reply-To: <200909290956.49681.malte.gell@gmx.de>


--- On Tue, 29/9/09, Malte Gell <malte.gell@gmx.de> wrote:

> "Hin-Tak Leung" <hintak_leung@yahoo.co.uk>
> wrote
> 
> > --- On Tue, 29/9/09, Malte Gell <malte.gell@gmx.de>
> wrote:
> > > I prefer to wait ;-) This way I can stick with
> kernel
> > > 2.6.27 and just install
> > > this package, otherwise I would have to upgrade
> my kernel,
> > > because ar9170
> > > needs kernel >= 2.6.29 as far as I know. And i
> always
> > > fear, a kernel update
> > > could break other things,
>  
> > Where did you learn this from? It says bleeding-edge
> compat-wireless
> > (http://linuxwireless.org/en/users/Download#Compat-wireless_release_types)
> > requires Kernel >= 2.6.27 . and it is not a *full*
> kernel update -
> 
> Yes, compat-wirless-2.6 needs kernel 2.6.27, but, the
> ar9170 driver requires 
> kernel 2.6.29, below you can see the "make" output when
> building compat-
> wireless-2.6 from today on kernel 2.6.27. It is this
> tracepoint issue that 
> requires kernel 2.6.29
> 
> Regards
> Malte

Hmm, I see you have already posted to linux-wireless and already got your answers. Hauke has already given you the answer - your kernel tree is *not* 2.6.27(.0), and as it is obvious that you have 2.6.27.29-0.1, which is 2.6.27.29 + suse-patches. Even 2.6.27.29 is not 2.6.27(.0), but somewhat closer to 2.6.28. And you really have already had your answer - your tree is somewhat between 2.6.27 and 2.6.28, and *neither*. 

My suggestion would be simply to delete all the 'error: redefinition' parts from net/compat-2.6.28.h , because you already have them in the suse tree.
You may also need to delete something from net/compat-2.6.28.c, but that will happen during the linking stage (much later).

> 
> 
> ./scripts/driver-select ar9170
> 
> make
> 
> ./scripts/gen-compat-autoconf.sh config.mk >
> include/linux/compat_autoconf.h
> make -C /lib/modules/2.6.27.29-0.1-k7/build 
> M=/home/malte_gell/download/src/wifi/compat-wireless-2009-09-29
> modules
> make[1]: Entering directory `/usr/src/linux-2.6.27.29-0.1'
>   LD     
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/drivers/net/wireless/ath/built-in.o
>   CC [M] 
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/drivers/net/wireless/ath/main.o
> In file included from
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat.h:19,
>              
>    from <command-line>:0:
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat-2.6.28.h:152: error:
> redefinition of 
> ‘struct tracepoint’
> In file included from
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat.h:19,
>              
>    from <command-line>:0:
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat-2.6.28.h:182:1:
> warning: "DEFINE_TRACE" 
> redefined
> In file included from include/linux/module.h:19,
>              
>    from include/linux/textsearch.h:7,
>              
>    from include/linux/skbuff.h:26,
>              
>    from
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat-2.6.28.h:10,
>              
>    from
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat.h:19,
>              
>    from <command-line>:0:
> include/linux/tracepoint.h:86:1: warning: this is the
> location of the previous 
> definition
> /home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/include/net/compat-2.6.28.h:186: error:
> redefinition of 
> ‘tracepoint_update_probe_range’
> include/linux/tracepoint.h:100: error: previous definition
> of 
> ‘tracepoint_update_probe_range’ was here
> make[4]: *** [/home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/drivers/net/wireless/ath/main.o] Fehler
> 1
> make[3]: *** [/home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/drivers/net/wireless/ath] Fehler 2
> make[2]: *** [/home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29/drivers/net/wireless] Fehler 2
> make[1]: ***
> [_module_/home/malte_gell/download/src/wifi/compat-
> wireless-2009-09-29] Fehler 2
> make[1]: Leaving directory `/usr/src/linux-2.6.27.29-0.1'
> make: *** [modules] Fehler 2
> 
> 


      

^ permalink raw reply

* Re: cannot compile compate-wirless snapshots
From: Malte Gell @ 2009-09-29  8:50 UTC (permalink / raw)
  To: Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <4ABDE7AC.1090409@hauke-m.de>


Hauke Mehrtens <hauke@hauke-m.de> wrote


> Does this file exists in your installation?
> /lib/modules/`uname -r`/build/include/linux/tracepoint.h ?

Yes, but, look:

cd /usr/src/linux

grep -i tracepoint .config

# CONFIG_TRACEPOINTS is not set

Do I need to set it to yes?

Malte

^ permalink raw reply

* Re: cannot compile compate-wirless snapshots
From: Malte Gell @ 2009-09-29  8:47 UTC (permalink / raw)
  To: Hauke Mehrtens; +Cc: linux-wireless
In-Reply-To: <4ABDE7AC.1090409@hauke-m.de>

Hello, sorry for my late reply....

Hauke Mehrtens <hauke@hauke-m.de> wrote

> Malte Gell wrote:
> > Hello,
> >
> > actually I can build the stable compat-wirless-2.6.30.ta.bz2 just fine.
> >
> > But I get make errors, when I try to build the daily snapshot, see below.
> > I use openSUSE on a 2.6.27 kernel.

> what kernel are you using? 

2.6.27.29-0.1 from openSUSE 11.1

> Does this file exists in your installation?
> /lib/modules/`uname -r`/build/include/linux/tracepoint.h ?

Yes ! The kernel tracepoint API is there in openSuSE11.1, but I still cannot 
compile compat-wireless-2.6

 Besides tracepoint thing, does ar9170us require 2.6.29? As said, tracepoint 
does exist in my kernel....

thanx
Malte

^ permalink raw reply

* bleeding edge ar9170usb: Fritz N USB support?
From: Malte Gell @ 2009-09-29  8:14 UTC (permalink / raw)
  To: linux-wireless

Hello!

At

http://linuxwireless.org/en/users/Drivers/ar9170

I read support for the 802.11n Fritz N USB will be until kernel 2.6.32. 

So, I wonder is this USB stick already supported in the bleeding edge compat-
wireless-2.6?

Thanx
Malte

^ permalink raw reply

* Re: Question on general wireless testing tree compilation.
From: Balaji Ravindran @ 2009-09-29  7:29 UTC (permalink / raw)
  To: Hin-Tak Leung; +Cc: Linux Wireless
In-Reply-To: <3ace41890909281452x3170c8c6g5dc56cff85663099@mail.gmail.com>

Hi,

Thanks for this info, i shall try to keep the old *working* config  
option. Though, with the README help file, I was successfully able to  
make and *select* my new target kernel, i had a kernel panic, and was  
not able to boot to it, also i noticed that my USB keybd and mouse  
connected to my monitor's usb port did not come up, so i guess  
something bad happened while doing make modules_install install, or  
while setting up the configurations before making.

I shall try to re-compile with my known good configuration.

Thanks again for the info.

Thanks

Balaji R


On Sep 28, 2009, at 2:52 PM, Hin-Tak Leung wrote:

>
> Also, compat-wireless (which just replaces the wireless-related kernel
> modules) is sometimes a quicker/easier alternative to the whole
> wireless-testing.


^ permalink raw reply

* Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Holger Schurig @ 2009-09-29  7:24 UTC (permalink / raw)
  To: Bing Zhao
  Cc: Dan Williams, libertas-dev@lists.infradead.org,
	linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F704306DDA6C1B6@SC-VEXCH1.marvell.com>

> iwconfig wlan0 power period 0   -> enable deep sleep (enter
> deep sleep immediately) 

> iwconfig wlan0 power period 5   -> enable auto deep sleep
> (enter deep sleep automatically after 5s idle time) 

> iwconfig wlan0 power period -1  -> disable deep sleep / auto
> deep sleep 

ACK from my side (not that I'm the maintainer ...)

-- 
http://www.holgerschurig.de

^ permalink raw reply

* Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Holger Schurig @ 2009-09-29  7:04 UTC (permalink / raw)
  To: Bing Zhao
  Cc: Dan Williams, libertas-dev@lists.infradead.org,
	linux-wireless@vger.kernel.org, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F704306DDA6C1B6@SC-VEXCH1.marvell.com>

Hi Bing !

Please note that I just sent an experimental patch to enable 
cfg80211 for libertas.

Once this is polished, you can immediately start using 
nl80211/cfg80211 to configure such things, there's no need to 
have the full thingy (e.g. wpa_supplicant via -Dnl80211 working 
with WEP/WPA/WPA2) working, those things are not interrelated.


-- 
http://www.holgerschurig.de

^ permalink raw reply

* Re: Firmware versioning best practices
From: Holger Schurig @ 2009-09-29  6:59 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: linux-wireless, reinette chatre, Kalle Valo, Johannes Berg,
	Christian Lamparter, Bob Copeland
In-Reply-To: <43e72e890909281517k23abaf8dvd3e84837ce307429@mail.gmail.com>

> Or shall we have the same firmware filename and simply query
> the firmware for a map of capabilities? Any other ideas?

Don't put the version into the filename. This is not a common 
practice for Linux / BSD / whatever systems. Usually you have 
a "kmail" file, not a kmail3.5, kmail4.0 and kmail4.2 file.

Versions or capability maps can be stored inside the firmware and 
queried at load time. E.g. the libertas driver does it that way.

If you make your firmware redistributable (which I recommend), 
the version will also be stored in the package metadata, e.g. 
the rpm or deb file and the infrastructure for rpm/yum deb/apt.

-- 
http://www.holgerschurig.de

^ permalink raw reply

* Re: compat-wireless master-2009-09-28 breakage and suggested fixes
From: Hin-Tak Leung @ 2009-09-29  3:33 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <20090929025509.GB6529@mosca>

On Tue, Sep 29, 2009 at 3:55 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Mon, Sep 28, 2009 at 07:35:22PM -0700, Hin-Tak Leung wrote:
>> commit d0cf9c0dadcdc89a755bcb301cfc9c796eb28ccf
>> Author: Stephen Hemminger <shemminger@vyatta.com>
>> Date:   Mon Aug 31 19:50:57 2009 +0000
>>
>>     wireless: convert drivers to netdev_tx_t
>>
>> and the 2nd change due to this:
>>
>> commit 384912ed194e43c03ad1cdaa09b0b1e488c34d46
>> Author: Marcel Holtmann <marcel@holtmann.org>
>> Date:   Mon Aug 31 21:08:19 2009 +0000
>>
>>     net: Add DEVTYPE support for Ethernet based devices
>>
>> Both of these changes are traced back to changes in
>> <linux/netdevice.h> , which compat-wireless does not ship. What's your
>> policy on these kind of changes to compat-wireless?
>> (the 2nd SET_NETDEV_DEVTYPE change probably can be spanned by an
>> ifndef SET_NETDEV_DEVTYPE, and roll into
>> "compat/patches/01-netdev.patch"? Should the first kind of change also
>> go into compat/patches/01-netdev.patch?)
>
> I don't see this yet on wireless-testing but it is on 2.6.32.
> I backported this as follows. I'll push this out shortly.
>
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Subject: [PATCH] Fix compilation against for 2.6.32 changes
>
> 2.6.32 added SET_NETDEV_DEVTYPE() and netdev_tx

Argh, I see what you are getting at: codes that emulates "API changes
between 2.6.(x-1) and 2.6.(x)" go into file
compat/compat-2.6.(x).{h,c} .
The 'compatibility code for new kernel' wording wasn't too obvious :-).

>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

Acked.

> ---
>  compat/compat-2.6.32.h |   12 ++++++++++++
>  1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/compat/compat-2.6.32.h b/compat/compat-2.6.32.h
> index f7081f2..418b521 100644
> --- a/compat/compat-2.6.32.h
> +++ b/compat/compat-2.6.32.h
> @@ -31,6 +31,18 @@
>
>  #define dev_change_net_namespace(a, b, c) (-EOPNOTSUPP)
>
> +#define SET_NETDEV_DEVTYPE(netdev, type)
> +
> +#ifdef __KERNEL__
> +/* Driver transmit return codes */
> +enum netdev_tx {
> +       BACKPORT_NETDEV_TX_OK = NETDEV_TX_OK,       /* driver took care of packet */
> +       BACKPORT_NETDEV_TX_BUSY = NETDEV_TX_BUSY,         /* driver tx path was busy*/
> +       BACKPORT_NETDEV_TX_LOCKED = NETDEV_TX_LOCKED,  /* driver tx lock was already taken */
> +};
> +typedef enum netdev_tx netdev_tx_t;
> +#endif /* __KERNEL__ */
> +
>  #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32)) */
>
>  #endif /* LINUX_26_32_COMPAT_H */
> --
> 1.6.3.3
>
>

^ permalink raw reply

* Re: compat-wireless master-2009-09-28 breakage and suggested fixes
From: Luis R. Rodriguez @ 2009-09-29  2:55 UTC (permalink / raw)
  To: Hin-Tak Leung; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <3ace41890909281935k284402f3q90b54ae20a636eeb@mail.gmail.com>

On Mon, Sep 28, 2009 at 07:35:22PM -0700, Hin-Tak Leung wrote:
> commit d0cf9c0dadcdc89a755bcb301cfc9c796eb28ccf
> Author: Stephen Hemminger <shemminger@vyatta.com>
> Date:   Mon Aug 31 19:50:57 2009 +0000
> 
>     wireless: convert drivers to netdev_tx_t
> 
> and the 2nd change due to this:
> 
> commit 384912ed194e43c03ad1cdaa09b0b1e488c34d46
> Author: Marcel Holtmann <marcel@holtmann.org>
> Date:   Mon Aug 31 21:08:19 2009 +0000
> 
>     net: Add DEVTYPE support for Ethernet based devices
> 
> Both of these changes are traced back to changes in
> <linux/netdevice.h> , which compat-wireless does not ship. What's your
> policy on these kind of changes to compat-wireless?
> (the 2nd SET_NETDEV_DEVTYPE change probably can be spanned by an
> ifndef SET_NETDEV_DEVTYPE, and roll into
> "compat/patches/01-netdev.patch"? Should the first kind of change also
> go into compat/patches/01-netdev.patch?)

I don't see this yet on wireless-testing but it is on 2.6.32.
I backported this as follows. I'll push this out shortly.

From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] Fix compilation against for 2.6.32 changes

2.6.32 added SET_NETDEV_DEVTYPE() and netdev_tx

Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 compat/compat-2.6.32.h |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/compat/compat-2.6.32.h b/compat/compat-2.6.32.h
index f7081f2..418b521 100644
--- a/compat/compat-2.6.32.h
+++ b/compat/compat-2.6.32.h
@@ -31,6 +31,18 @@
 
 #define dev_change_net_namespace(a, b, c) (-EOPNOTSUPP)
 
+#define SET_NETDEV_DEVTYPE(netdev, type)
+
+#ifdef __KERNEL__
+/* Driver transmit return codes */
+enum netdev_tx {
+	BACKPORT_NETDEV_TX_OK = NETDEV_TX_OK,       /* driver took care of packet */
+	BACKPORT_NETDEV_TX_BUSY = NETDEV_TX_BUSY,         /* driver tx path was busy*/
+	BACKPORT_NETDEV_TX_LOCKED = NETDEV_TX_LOCKED,  /* driver tx lock was already taken */
+};
+typedef enum netdev_tx netdev_tx_t;
+#endif /* __KERNEL__ */
+
 #endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,32)) */
 
 #endif /* LINUX_26_32_COMPAT_H */
-- 
1.6.3.3


^ permalink raw reply related

* compat-wireless master-2009-09-28 breakage and suggested fixes
From: Hin-Tak Leung @ 2009-09-29  2:35 UTC (permalink / raw)
  To: Luis R. Rodriguez, linux-wireless

Hi Luis,

A couple of breakages against current wireless testing head:

compat-release  - master-2009-09-23-1-gd1e5747
git-describe  v2.6.32-rc1-39226-g63dbea4
master-tag master-2009-09-28

-----------
make[1]: Entering directory `/usr/src/kernels/2.6.30.8-67.fc11.x86_64'
  CC [M]  /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.o
In file included from
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.c:29:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/ieee80211_i.h:1053:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘ieee80211_monitor_start_xmit’
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/ieee80211_i.h:1055:
error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘ieee80211_subif_start_xmit’
make[3]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/main.o]
Error 1
make[2]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211] Error 2
make[1]: *** [_module_/home/Hin-Tak/tmp-git/compat-wireless-2.6] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.30.8-67.fc11.x86_64'
make: *** [modules] Error 2
----------

----------
  CC [M]  /home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.o
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.c: In
function ‘ieee80211_if_add’:
/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.c:815:
error: implicit declaration of function ‘SET_NETDEV_DEVTYPE’
make[3]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211/iface.o]
Error 1
make[2]: *** [/home/Hin-Tak/tmp-git/compat-wireless-2.6/net/mac80211] Error 2
make[1]: *** [_module_/home/Hin-Tak/tmp-git/compat-wireless-2.6] Error 2
----------

The first error can be fixed by inserting the netdev_tx_t enum:

----------------
$ diff -u ../wireless-testing/net/mac80211/ieee80211_i.h
net/mac80211/ieee80211_i.h
--- ../wireless-testing/net/mac80211/ieee80211_i.h	2009-09-29
01:21:11.000000000 +0100
+++ net/mac80211/ieee80211_i.h	2009-09-29 02:43:26.000000000 +0100
@@ -28,6 +28,24 @@
 #include "key.h"
 #include "sta_info.h"

+#ifdef NETDEV_TX_OK
+#undef NETDEV_TX_OK
+#endif
+#ifdef NETDEV_TX_BUSY
+#undef NETDEV_TX_BUSY
+#endif
+#ifdef NETDEV_TX_LOCKED
+#undef NETDEV_TX_LOCKED
+#endif
+
+/* Driver transmit return codes */
+enum netdev_tx {
+       NETDEV_TX_OK = 0,       /* driver took care of packet */
+       NETDEV_TX_BUSY,         /* driver tx path was busy*/
+       NETDEV_TX_LOCKED = -1,  /* driver tx lock was already taken */
+};
+typedef enum netdev_tx netdev_tx_t;
+
 struct ieee80211_local;

 /* Maximum number of broadcast/multicast frames to buffer when some of the
------------------

The 2nd by adding SET_NETDEV_DEVTYPE():
----------
--- ../wireless-testing/net/mac80211/iface.c	2009-09-29 01:21:11.000000000 +0100
+++ net/mac80211/iface.c	2009-09-29 02:50:54.000000000 +0100
@@ -22,6 +22,8 @@
 #include "led.h"
 #include "driver-ops.h"

+#define SET_NETDEV_DEVTYPE(net, devtype)       ((net)->dev.type = (devtype))
+
 /**
  * DOC: Interface list locking
  *
-------------

The first change is due to this:

commit d0cf9c0dadcdc89a755bcb301cfc9c796eb28ccf
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Mon Aug 31 19:50:57 2009 +0000

    wireless: convert drivers to netdev_tx_t

and the 2nd change due to this:

commit 384912ed194e43c03ad1cdaa09b0b1e488c34d46
Author: Marcel Holtmann <marcel@holtmann.org>
Date:   Mon Aug 31 21:08:19 2009 +0000

    net: Add DEVTYPE support for Ethernet based devices

Both of these changes are traced back to changes in
<linux/netdevice.h> , which compat-wireless does not ship. What's your
policy on these kind of changes to compat-wireless?
(the 2nd SET_NETDEV_DEVTYPE change probably can be spanned by an
ifndef SET_NETDEV_DEVTYPE, and roll into
"compat/patches/01-netdev.patch"? Should the first kind of change also
go into compat/patches/01-netdev.patch?)

^ permalink raw reply

* [RFC v2] compat-2.6: mangle drivers and symbols for driver-select
From: Luis R. Rodriguez @ 2009-09-29  1:35 UTC (permalink / raw)
  To: linux-wireless
  Cc: Luis R. Rodriguez, John W. Linville, Tim Gardner, Greg KH,
	Andrey Yurovsky, Hauke Mehrtens, Johannes Berg

When building only one driver with driver-select you will have bust
other present wireless drivers since they still rely on the old
mac80211 and cfg80211 modules. This is a non-issue unless you are
a distribution maintainer and do not want to build all modules
provided by compat-wireless. If you are an OEM you may also want
to just provide a one-driver solution for your own device without
affecting other drivers present.

When driver-select is used add a CONFIG_COMPAT_WIRELESS_MANGLE
so that mangled symbols are enabled and all cfg80211 and mac80211
driver symbols get mangled with a backport_ prefix.

Each driver family which has their own set of modules will also
need to define their own set of mangle definitions. This can be
done on compat/compat.h

The last step required to make this work is to rename the built
modules your driver will depend on. So mac80211 will become
backport_mac80211 and cfg80211 backport_cfg80211. As with
symbols driver families may also need to deal with this.
For example ath9k will require ath to be renamed to backport_ath.

Usbnet is a different story -- for that I think the best thing
is to just backport these modules. You will run into issues
with usbnet only if compiling all modules and it will only
become an issue with users of non backported usbnet modules.
If we backport all usbnet modules this is a non-issue.

Cc: John W. Linville <linville@tuxdriver.com>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Greg KH <greg@kroah.com>
Cc: Andrey Yurovsky <andrey@cozybit.com>
Cc: Hauke Mehrtens <hauke@hauke-m.de>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---

This one compiles for me and build a backport_mac80211,
backport_cfg80211, and even backport_ath, however I end up wit this
warning:

WARNING: at /build/buildd/linux-2.6.31/fs/sysfs/dir.c:487 sysfs_add_one+0xc5/0x130()
Hardware name: 7660A14
sysfs: cannot create duplicate filename '/class/ieee80211'
Modules linked in: backport_cfg80211(+) <etc>
Pid: 5604, comm: modprobe Tainted: G        WC 2.6.31-10-generic #34-Ubuntu
Call Trace:
 [<ffffffff81059778>] warn_slowpath_common+0x78/0xb0
 [<ffffffff8105980c>] warn_slowpath_fmt+0x3c/0x40
 [<ffffffff81181845>] sysfs_add_one+0xc5/0x130
 [<ffffffff81181913>] create_dir+0x63/0xb0
 [<ffffffff81181994>] sysfs_create_dir+0x34/0x50
 [<ffffffff8126f46a>] ? kobject_get+0x1a/0x30
 [<ffffffff8126f5c7>] kobject_add_internal+0xb7/0x200
 [<ffffffff8126f73f>] kset_register+0x2f/0x60
 [<ffffffff8131c9a8>] __class_register+0xf8/0x220
 [<ffffffffa0024000>] ? cfg80211_init+0x0/0x92 [backport_cfg80211]
 [<ffffffffa0265837>] wiphy_sysfs_init+0x17/0x20 [backport_cfg80211]
 [<ffffffffa0024020>] cfg80211_init+0x20/0x92 [backport_cfg80211]
 [<ffffffff8100a047>] do_one_initcall+0x37/0x1a0
 [<ffffffff8108cbc7>] sys_init_module+0xd7/0x230
 [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
---[ end trace d8ca39e614c01267 ]---
kobject_add_internal failed for ieee80211 with -EEXIST, don't try to register things with the same name in the same directory.

Do we want to live with a new /class/backport_ieee80211/ ?
I'm not sure what the downside to this, someone more familiar with
this please let me know.

 compat/compat.h                |  161 ++++++++++++++++++++++++++++++++++++++++
 config.mk                      |    2 +
 scripts/admin-update.sh        |    2 +-
 scripts/driver-select          |   36 +++++++++-
 scripts/gen-compat-autoconf.sh |   10 ++-
 5 files changed, 206 insertions(+), 5 deletions(-)

diff --git a/compat/compat.h b/compat/compat.h
index 05612b2..24c3f31 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -22,4 +22,165 @@
 #include <net/compat-2.6.31.h>
 #include <net/compat-2.6.32.h>
 
+#ifdef CONFIG_COMPAT_WIRELESS_MANGLE
+
+/*
+ * When we use driver-select you are building one driver so all your
+ * other drivers present in your existing kernel can go bust since they
+ * rely on older versions of mac80211 and cfg80211. Because of this we
+ * mangle your symbols so that your new single compat-wireless driver
+ * only relies on the new mac80211 and cfg80211 backported modules.
+ */
+
+/* cfg80211 */
+#define wiphy_new					backport_wiphy_new
+#define wiphy_register					backport_wiphy_register
+#define wiphy_rfkill_start_polling			backport_wiphy_rfkill_start_polling
+#define wiphy_rfkill_stop_polling			backport_wiphy_rfkill_stop_polling
+#define wiphy_unregister				backport_wiphy_unregister
+#define wiphy_free					backport_wiphy_free
+#define wiphy_rfkill_set_hw_state			backport_wiphy_rfkill_set_hw_state
+#define cfg80211_ibss_joined				backport_cfg80211_ibss_joined
+#define print_ssid					backport_print_ssid
+#define lib80211_crypt_info_init			backport_lib80211_crypt_info_init
+#define lib80211_crypt_info_free			backport_lib80211_crypt_info_free
+#define lib80211_crypt_deinit_entries			backport_lib80211_crypt_deinit_entries
+#define lib80211_crypt_quiescing			backport_lib80211_crypt_quiescing
+#define lib80211_crypt_deinit_handler			backport_lib80211_crypt_deinit_handler
+#define lib80211_crypt_delayed_deinit			backport_lib80211_crypt_delayed_deinit
+#define lib80211_register_crypto_ops			backport_lib80211_register_crypto_ops
+#define lib80211_unregister_crypto_ops			backport_lib80211_unregister_crypto_ops
+#define lib80211_get_crypto_ops				backport_lib80211_get_crypto_ops
+#define cfg80211_send_rx_auth				backport_cfg80211_send_rx_auth
+#define cfg80211_send_rx_assoc				backport_cfg80211_send_rx_assoc
+#define cfg80211_send_deauth				backport_cfg80211_send_deauth
+#define cfg80211_send_disassoc				backport_cfg80211_send_disassoc
+#define cfg80211_send_auth_timeout			backport_cfg80211_send_auth_timeout
+#define cfg80211_send_assoc_timeout			backport_cfg80211_send_assoc_timeout
+#define cfg80211_michael_mic_failure			backport_cfg80211_michael_mic_failure
+#define cfg80211_testmode_alloc_reply_skb		backport_cfg80211_testmode_alloc_reply_skb
+#define cfg80211_testmode_reply				backport_cfg80211_testmode_reply
+#define cfg80211_testmode_alloc_event_skb		backport_cfg80211_testmode_alloc_event_skb
+#define cfg80211_testmode_event				backport_cfg80211_testmode_event
+#define ieee80211_radiotap_iterator_init		backport_ieee80211_radiotap_iterator_init
+#define ieee80211_radiotap_iterator_next		backport_ieee80211_radiotap_iterator_next
+#define freq_reg_info					backport_freq_reg_info
+#define wiphy_apply_custom_regulatory			backport_wiphy_apply_custom_regulatory
+#define regulatory_hint					backport_regulatory_hint
+#define cfg80211_scan_done				backport_cfg80211_scan_done
+#define cfg80211_get_bss				backport_cfg80211_get_bss
+#define cfg80211_get_mesh				backport_cfg80211_get_mesh
+#define cfg80211_inform_bss				backport_cfg80211_inform_bss
+#define cfg80211_inform_bss_frame			backport_cfg80211_inform_bss_frame
+#define cfg80211_put_bss				backport_cfg80211_put_bss
+#define cfg80211_unlink_bss				backport_cfg80211_unlink_bss
+#define cfg80211_wext_siwscan				backport_cfg80211_wext_siwscan
+#define cfg80211_wext_giwscan				backport_cfg80211_wext_giwscan
+#define cfg80211_connect_result				backport_cfg80211_connect_result
+#define cfg80211_roamed					backport_cfg80211_roamed
+#define cfg80211_disconnected				backport_cfg80211_disconnected
+#define ieee80211_get_response_rate			backport_ieee80211_get_response_rate
+#define ieee80211_channel_to_frequency			backport_ieee80211_channel_to_frequency
+#define ieee80211_frequency_to_channel			backport_ieee80211_frequency_to_channel
+#define __ieee80211_get_channel				backport___ieee80211_get_channel
+#define rfc1042_header					backport_rfc1042_header
+#define bridge_tunnel_header				backport_bridge_tunnel_header
+#define ieee80211_hdrlen				backport_ieee80211_hdrlen
+#define ieee80211_get_hdrlen_from_skb			backport_ieee80211_get_hdrlen_from_skb
+#define ieee80211_data_to_8023				backport_ieee80211_data_to_8023
+#define ieee80211_data_from_8023			backport_ieee80211_data_from_8023
+#define cfg80211_classify8021d				backport_cfg80211_classify8021d
+#define ieee80211_bss_get_ie				backport_ieee80211_bss_get_ie
+
+/*
+ * Your kernel's wext stuff is left intact as its built-in so we do not provide 
+ * defines for that here.
+ */
+
+#define cfg80211_wext_giwname				backport_cfg80211_wext_giwname
+#define cfg80211_wext_siwmode				backport_cfg80211_wext_siwmode
+#define cfg80211_wext_giwmode				backport_cfg80211_wext_giwmode
+#define cfg80211_wext_giwrange				backport_cfg80211_wext_giwrange
+#define cfg80211_wext_siwrts				backport_cfg80211_wext_siwrts
+#define cfg80211_wext_giwrts				backport_cfg80211_wext_giwrts
+#define cfg80211_wext_siwfrag				backport_cfg80211_wext_siwfrag
+#define cfg80211_wext_giwfrag				backport_cfg80211_wext_giwfrag
+#define cfg80211_wext_siwretry				backport_cfg80211_wext_siwretry
+#define cfg80211_wext_giwretry				backport_cfg80211_wext_giwretry
+#define cfg80211_wext_siwencode				backport_cfg80211_wext_siwencode
+#define cfg80211_wext_siwencodeext			backport_cfg80211_wext_siwencodeext
+#define cfg80211_wext_giwencode				backport_cfg80211_wext_giwencode
+#define cfg80211_wext_siwfreq				backport_cfg80211_wext_siwfreq
+#define cfg80211_wext_giwfreq				backport_cfg80211_wext_giwfreq
+#define cfg80211_wext_siwtxpower			backport_cfg80211_wext_siwtxpower
+#define cfg80211_wext_giwtxpower			backport_cfg80211_wext_giwtxpower
+#define cfg80211_wext_siwauth				backport_cfg80211_wext_siwauth
+#define cfg80211_wext_giwauth				backport_cfg80211_wext_giwauth
+#define cfg80211_wext_siwpower				backport_cfg80211_wext_siwpower
+#define cfg80211_wext_giwpower				backport_cfg80211_wext_giwpower
+#define cfg80211_wext_siwrate				backport_cfg80211_wext_siwrate
+#define cfg80211_wext_giwrate				backport_cfg80211_wext_giwrate
+#define cfg80211_wireless_stats				backport_cfg80211_wireless_stats
+#define cfg80211_wext_siwap				backport_cfg80211_wext_siwap
+#define cfg80211_wext_giwap				backport_cfg80211_wext_giwap
+#define cfg80211_wext_siwessid				backport_cfg80211_wext_siwessid
+#define cfg80211_wext_giwessid				backport_cfg80211_wext_giwessid
+#define cfg80211_wext_siwgenie				backport_cfg80211_wext_siwgenie
+#define cfg80211_wext_siwmlme				backport_cfg80211_wext_siwmlme
+
+/* mac80211 */
+#define ieee80211_start_tx_ba_session			backport_ieee80211_start_tx_ba_session
+#define ieee80211_start_tx_ba_cb			backport_ieee80211_start_tx_ba_cb
+#define ieee80211_start_tx_ba_cb_irqsafe		backport_ieee80211_start_tx_ba_cb_irqsafe
+#define ieee80211_stop_tx_ba_session			backport_ieee80211_stop_tx_ba_session
+#define ieee80211_stop_tx_ba_cb				backport_ieee80211_stop_tx_ba_cb
+#define ieee80211_stop_tx_ba_cb_irqsafe			backport_ieee80211_stop_tx_ba_cb_irqsafe
+#define __ieee80211_get_radio_led_name			backport___ieee80211_get_radio_led_name
+#define __ieee80211_get_assoc_led_name			backport___ieee80211_get_assoc_led_name
+#define __ieee80211_get_tx_led_name			backport___ieee80211_get_tx_led_name
+#define __ieee80211_get_rx_led_name			backport___ieee80211_get_rx_led_name
+#define ieee80211_tx_status_irqsafe			backport_ieee80211_tx_status_irqsafe
+#define ieee80211_tx_status				backport_ieee80211_tx_status
+#define ieee80211_restart_hw				backport_ieee80211_restart_hw
+#define ieee80211_alloc_hw				backport_ieee80211_alloc_hw
+#define ieee80211_register_hw				backport_ieee80211_register_hw
+#define ieee80211_unregister_hw				backport_ieee80211_unregister_hw
+#define ieee80211_free_hw				backport_ieee80211_free_hw
+#define ieee80211_beacon_loss				backport_ieee80211_beacon_loss
+#define ieee80211_rate_control_register			backport_ieee80211_rate_control_register
+#define ieee80211_rate_control_unregister		backport_ieee80211_rate_control_unregister
+#define rate_control_send_low				backport_rate_control_send_low
+#define ieee80211_rx					backport_ieee80211_rx
+#define ieee80211_rx_irqsafe				backport_ieee80211_rx_irqsafe
+#define ieee80211_scan_completed			backport_ieee80211_scan_completed
+#define ieee80211_find_sta				backport_ieee80211_find_sta
+#define ieee80211_get_tkip_key				backport_ieee80211_get_tkip_key
+#define ieee80211_beacon_get				backport_ieee80211_beacon_get
+#define ieee80211_rts_get				backport_ieee80211_rts_get
+#define ieee80211_ctstoself_get				backport_ieee80211_ctstoself_get
+#define ieee80211_get_buffered_bc			backport_ieee80211_get_buffered_bc
+#define wiphy_to_ieee80211_hw				backport_wiphy_to_ieee80211_hw
+#define ieee80211_generic_frame_duration		backport_ieee80211_generic_frame_duration
+#define ieee80211_rts_duration				backport_ieee80211_rts_duration
+#define ieee80211_ctstoself_duration			backport_ieee80211_ctstoself_duration
+#define ieee80211_wake_queue				backport_ieee80211_wake_queue
+#define ieee80211_stop_queue				backport_ieee80211_stop_queue
+#define ieee80211_stop_queues				backport_ieee80211_stop_queues
+#define ieee80211_queue_stopped				backport_ieee80211_queue_stopped
+#define ieee80211_wake_queues				backport_ieee80211_wake_queues
+#define ieee80211_iterate_active_interfaces		backport_ieee80211_iterate_active_interfaces
+#define ieee80211_iterate_active_interfaces_atomic	backport_ieee80211_iterate_active_interfaces_atomic
+#define ieee80211_queue_work				backport_ieee80211_queue_work
+#define ieee80211_queue_delayed_work			backport_ieee80211_queue_delayed_work
+
+/* Atheros */
+#define ath_regd_init					backport_ath_regd_init
+#define ath_is_world_regd				backport_ath_is_world_regd
+#define ath_reg_notifier_apply				backport_ath_reg_notifier_apply
+#define ath_regd_get_band_ctl				backport_ath_regd_get_band_ctl
+#define ath_hw_setbssidmask				backport_ath_hw_setbssidmask
+
+#endif /* CONFIG_COMPAT_WIRELESS_MANGLE */
+
+
 #endif /* LINUX_26_COMPAT_H */
diff --git a/config.mk b/config.mk
index b482b68..5bbf1f1 100644
--- a/config.mk
+++ b/config.mk
@@ -4,6 +4,8 @@ export
 ## Make sure to have each variable declaration start
 ## in the first column, no whitespace allowed.
 
+-include $(PWD)/driver-select.mk
+
 ifeq ($(wildcard $(KLIB_BUILD)/.config),)
 # These will be ignored by compat autoconf
  CONFIG_PCI=y
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index c65952d..0b8722b 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -210,7 +210,7 @@ if [ -d ./.git ]; then
 		echo -e "This is a ${RED}bleeding edge${NORMAL} compat-wireless release based on: ${PURPLE}$MASTER_TAG${NORMAL}"
 		;;
 	"linux-2.6-allstable.git") # HPA's all stable tree
-		echo "This is a ${GREEN}stable${NORMAL} compat-wireless release based on: ${PURPLE}$(git describe --abbrev=0)${NORMAL}"
+		echo -e "This is a ${GREEN}stable${NORMAL} compat-wireless release based on: ${PURPLE}$(git describe --abbrev=0)${NORMAL}"
 		;;
 	"linux-2.6.git") # Linus' 2.6 tree
 		;;
diff --git a/scripts/driver-select b/scripts/driver-select
index dcb777c..76b3be6 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -11,6 +11,8 @@ EEPROM_MAKEFILE="drivers/misc/eeprom/Makefile"
 DRIVERS_NET_USB_MAKEFILE="drivers/net/usb/Makefile"
 SSB_MAKEFILE="drivers/ssb/Makefile"
 
+SELECT_CONF="driver-select.mk"
+
 # used to backup files from foo to foo.${BACKUP_EXT}
 # If you change this also modify restore_compat() and
 # restore_file() below I couldn't find a way to use
@@ -51,6 +53,16 @@ function usage {
 	echo -e "\t${GREEN}restore${NORMAL}: you can use this option to restore compat-wireless to the original state"
 }
 
+function generate_driver_select_conf {
+	echo "CONFIG_COMPAT_WIRELESS_MANGLE=y" > $SELECT_CONF
+}
+
+function mangle_mac80211_modules {
+	sed -e 's/cfg80211/backport_cfg80211/' net/wireless/Makefile > .mangled
+	mv .mangled net/wireless/Makefile
+	sed -e 's/mac80211/backport_mac80211/' net/mac80211/Makefile > .mangled
+	mv .mangled net/mac80211/Makefile
+}
 function backup_file {
 	if [ -f $1.${BACKUP_EXT} ]; then
 		echo -e "Backup exists: ${CYAN}${1}.${BACKUP_EXT}${NORMAL}"
@@ -135,11 +147,17 @@ function disable_var_02 {
 	disable_usbnet
 }
 
+function mangle_ath_modules {
+	sed -e 's|ath\([^59]\)|ath_backport\1|' drivers/net/wireless/ath/Makefile > .mangled
+	mv .mangled  drivers/net/wireless/ath/Makefile
+}
+
 function select_ath_driver 
 {
 	backup_file $ATH_MAKEFILE
 	perl -i -ne 'print if /'$1'/ || /CONFIG_ATH_COMMON/ || /ath-objs/ ' $ATH_MAKEFILE
 	disable_var_01
+	mangle_ath_modules
 }
 
 # iwlwifi stuff needs more work
@@ -163,6 +181,7 @@ function restore_compat {
 	for i in $FILES; do
 		restore_file $i
 	done
+	rm -f $SELECT_CONF
 }
 
 if [ $# -ne 1 ]; then
@@ -181,9 +200,12 @@ if [[ ! -f built-in.o ]]; then
 	fi
 fi
 
-# Always backup the top level Makefile, unless restoring
+# Always backup the top level Makefile, unless restoring.
+# Also, always generate a driver-select.mk so that compat-wireless
+# mangles symbols for us.
 if [[ "$1" != "restore" ]]; then
 	backup_file Makefile
+	generate_driver_select_conf
 fi
 
 # If a user selects a new driver make sure we clean up for them
@@ -205,43 +227,55 @@ case $1 in
 		select_drivers		CONFIG_ATH_COMMON \
 					CONFIG_ZD1211RW
 		disable_var_01
+		mangle_ath_modules
+		mangle_mac80211_modules
 		;;
 	ath)
 		select_drivers		CONFIG_ATH_COMMON
 		disable_var_01
+		mangle_ath_modules
+		mangle_mac80211_modules
 		;;
 	intel)
 		select_drivers		CONFIG_IWLWIFI \
 					CONFIG_IPW
 		disable_var
+		mangle_mac80211_modules
 		;;
 	iwlwifi)
 		select_driver		CONFIG_IWLWIFI
 		disable_var_01
+		mangle_mac80211_modules
 		;;
 	wl12xx)
 		select_drivers		CONFIG_WL12XX
 		disable_var_01
+		mangle_mac80211_modules
 		;;
 	ath5k)
 		select_driver		CONFIG_ATH_COMMON
 		select_ath_driver	CONFIG_ATH5K
+		mangle_mac80211_modules
 		;;
 	ath9k)
 		select_driver		CONFIG_ATH_COMMON
 		select_ath_driver	CONFIG_ATH9K
+		mangle_mac80211_modules
 		;;
 	ar9170)
 		select_driver		CONFIG_ATH_COMMON
 		select_ath_driver	CONFIG_AR9170_USB
+		mangle_mac80211_modules
 		;;
 	rtl818x)
 		select_drivers		CONFIG_RTL8180 CONFIG_RTL8187
 		disable_var_02
+		mangle_mac80211_modules
 		;;
 	zd1211rw)
 		select_driver		CONFIG_ZD1211RW
 		disable_var_01
+		mangle_mac80211_modules
 		;;
 	*)
 		echo "Unsupported driver"
diff --git a/scripts/gen-compat-autoconf.sh b/scripts/gen-compat-autoconf.sh
index 6c7cae7..e1ff8c5 100755
--- a/scripts/gen-compat-autoconf.sh
+++ b/scripts/gen-compat-autoconf.sh
@@ -21,9 +21,13 @@ if [ $# -ne 1 ]; then
 	exit
 fi
 
-COMPAT_CONFIG="$1"
+if [ -f driver-select.mk ]; then
+	COMPAT_CONFIGS="$1 driver-select.mk"
+else
+	COMPAT_CONFIGS="$1"
+fi
 
-if [ ! -f $COMPAT_CONFIG ]; then
+if [ ! -f $1 ]; then
 	echo "File $1 is not a file"
 	exit
 fi
@@ -148,7 +152,7 @@ kernel_version_req $OLDEST_KERNEL_SUPPORTED
 define_config_req CONFIG_WIRELESS_EXT
 
 # For each CONFIG_FOO=x option
-for i in $(grep '^CONFIG_' $COMPAT_CONFIG); do
+for i in $(grep '^CONFIG_' $COMPAT_CONFIGS | awk -F":" '{print $2}'); do
 	# Get the element on the left of the "="
 	VAR=$(echo $i | cut -d"=" -f 1)
 	# Get the element on the right of the "="
-- 
1.6.3.3


^ permalink raw reply related

* Re: Firmware versioning best practices
From: John W. Linville @ 2009-09-29  0:42 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Luis R. Rodriguez, linux-wireless, reinette chatre, Kalle Valo,
	Johannes Berg, Christian Lamparter, Bob Copeland
In-Reply-To: <1254181937.2659.34.camel@localhost.localdomain>

On Mon, Sep 28, 2009 at 04:52:17PM -0700, Marcel Holtmann wrote:
> Hi Luis,
> 
> > The ath_hif_usb driver will require the ar9271 firmware file but in
> > the future an open firmware might become available. The ar9170 driver
> > already is under the same situation already: a closed firmware is
> > available but an open firmware can be used, only thing is ar9170 uses
> > the same firmware name for both. We *could* change ar9170 to use the
> > Intel practice of tagging a version at the end of each firmware
> > release, like ar9170-1.fw but ar9170 originally was implemented with a
> > 2-stage firmware requirement and so ar9170-1.fw is already taken.
> > 
> > ar9170 still needs a solution for the different firmwares, once we
> > start supporting the open firmware through some sort of release but
> > I'd like to address ath_hif_usb now early so that we don't run into
> > these snags and use some decent convention that is easy to follow.
> > 
> > As I noted above, Intel seems to use the device-1.fw, device-2.fw
> > naming convention. Is this the best approach? Or shall we have the
> > same firmware filename and simply query the firmware for a map of
> > capabilities? Any other ideas?
> 
> the general rule of thumb is that if you break the firmware API/ABI or
> change it then the firmware name should be different. So for example if
> you have some new driver functionality that requires new firmware then
> you better use a new firmware name. Otherwise it is just fine to use the
> same name if the functionality is not changing. If you can actually
> detect the new firmware features from the firmware filename, then you
> might not even have to bother with a different name. However keep in
> mind that you still need to load at least the previous version of the
> firmware and keep that working.
> 
> For open source firmware vs binary blobs, we don't really have a good
> reference. In theory the driver should always try loading both and if
> one succeeds then go with it. At no point the driver should stop working
> only because a firmware is missing while either an open source or binary
> one for that matter would have been available.
> 
> If you have a binary and an open source available, then you might wanna
> have a Kconfig option which to try first. Like prefer the open source
> over the binary one, but at the end of the day most system will ship
> with only one anyway. And a module parameter would work here as well.

This seems like a good piece of advise (as does Pavel's).  Perhaps
someone should capture this on the wiki?

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

^ permalink raw reply

* Re: [RFC] compat-2.6: mangle symbols for driver-select
From: Luis R. Rodriguez @ 2009-09-29  0:33 UTC (permalink / raw)
  To: Andrey Yurovsky; +Cc: tim.gardner, linux-wireless, Greg KH, Johannes Berg
In-Reply-To: <45e8e6c40909281702i2e5497e7l3a6492151f506ce5@mail.gmail.com>

On Mon, Sep 28, 2009 at 5:02 PM, Andrey Yurovsky <andrey@cozybit.com> wrote:
> On a side note, the compat-wireless name mangling will help with
> another problem:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/249186
>
> ...this happens because compat-wireless builds a version of the usbnet
> module but then there are Ethernet dongles (ex: asix) that rely on the
> stock version of usbnet (they aren't updated by compat-wireless) and
> the user gets a symbols mismatch as a result.  This won't be an issue
> if compat-wireless' usbnet has mangled names for its symbols.

Good call.

My solution to this was to consider backporting the usb modules that
use usbnet, these modules are pretty dormant development wise so it
certainly is something we could do.

I'm giving this mangle thing another shot now since I don't see anyone
stepping up, I won't do usbnet, my first target will obviously be
Atheros drivers :)

  Luis

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox