* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-03 17:51 UTC (permalink / raw)
To: linux-usb-devel; +Cc: Daniel Drake, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <44817083.508@gentoo.org>
Am Samstag, 3. Juni 2006 13:20 schrieb Daniel Drake:
> I tried to submit this patch yesterday, but it doesn't appear to have
> been delivered. The patch is probably a bit on the large side, so I'll
> try again over http:
>
> http://dev.gentoo.org/~dsd/kernel/zd1211rw.patch
>
> Any comments appreciated.
+static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
+{
+ static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
+ return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
+}
Why on the stack?
+static int zd1211_hw_reset_phy(struct zd_chip *chip)
+{
+ static const struct zd_ioreq16 ioreqs[] = {
+ { CR0, 0x0a }, { CR1, 0x06 }, { CR2, 0x26 },
+ { CR3, 0x38 }, { CR4, 0x80 }, { CR9, 0xa0 },
+ { CR10, 0x81 }, { CR11, 0x00 }, { CR12, 0x7f },
+ { CR13, 0x8c }, { CR14, 0x80 }, { CR15, 0x3d },
+ { CR16, 0x20 }, { CR17, 0x1e }, { CR18, 0x0a },
+ { CR19, 0x48 }, { CR20, 0x0c }, { CR21, 0x0c },
+ { CR22, 0x23 }, { CR23, 0x90 }, { CR24, 0x14 },
+ { CR25, 0x40 }, { CR26, 0x10 }, { CR27, 0x19 },
+ { CR28, 0x7f }, { CR29, 0x80 }, { CR30, 0x4b },
+ { CR31, 0x60 }, { CR32, 0x43 }, { CR33, 0x08 },
+ { CR34, 0x06 }, { CR35, 0x0a }, { CR36, 0x00 },
+ { CR37, 0x00 }, { CR38, 0x38 }, { CR39, 0x0c },
+ { CR40, 0x84 }, { CR41, 0x2a }, { CR42, 0x80 },
+ { CR43, 0x10 }, { CR44, 0x12 }, { CR46, 0xff },
+ { CR47, 0x1E }, { CR48, 0x26 }, { CR49, 0x5b },
+ { CR64, 0xd0 }, { CR65, 0x04 }, { CR66, 0x58 },
+ { CR67, 0xc9 }, { CR68, 0x88 }, { CR69, 0x41 },
+ { CR70, 0x23 }, { CR71, 0x10 }, { CR72, 0xff },
+ { CR73, 0x32 }, { CR74, 0x30 }, { CR75, 0x65 },
+ { CR76, 0x41 }, { CR77, 0x1b }, { CR78, 0x30 },
+ { CR79, 0x68 }, { CR80, 0x64 }, { CR81, 0x64 },
+ { CR82, 0x00 }, { CR83, 0x00 }, { CR84, 0x00 },
+ { CR85, 0x02 }, { CR86, 0x00 }, { CR87, 0x00 },
+ { CR88, 0xff }, { CR89, 0xfc }, { CR90, 0x00 },
+ { CR91, 0x00 }, { CR92, 0x00 }, { CR93, 0x08 },
+ { CR94, 0x00 }, { CR95, 0x00 }, { CR96, 0xff },
+ { CR97, 0xe7 }, { CR98, 0x00 }, { CR99, 0x00 },
+ { CR100, 0x00 }, { CR101, 0xae }, { CR102, 0x02 },
+ { CR103, 0x00 }, { CR104, 0x03 }, { CR105, 0x65 },
+ { CR106, 0x04 }, { CR107, 0x00 }, { CR108, 0x0a },
+ { CR109, 0xaa }, { CR110, 0xaa }, { CR111, 0x25 },
+ { CR112, 0x25 }, { CR113, 0x00 }, { CR119, 0x1e },
+ { CR125, 0x90 }, { CR126, 0x00 }, { CR127, 0x00 },
+ { },
+ { CR5, 0x00 }, { CR6, 0x00 }, { CR7, 0x00 },
+ { CR8, 0x00 }, { CR9, 0x20 }, { CR12, 0xf0 },
+ { CR20, 0x0e }, { CR21, 0x0e }, { CR27, 0x10 },
+ { CR44, 0x33 }, { CR47, 0x1E }, { CR83, 0x24 },
+ { CR84, 0x04 }, { CR85, 0x00 }, { CR86, 0x0C },
+ { CR87, 0x12 }, { CR88, 0x0C }, { CR89, 0x00 },
+ { CR90, 0x10 }, { CR91, 0x08 }, { CR93, 0x00 },
+ { CR94, 0x01 }, { CR95, 0x00 }, { CR96, 0x50 },
+ { CR97, 0x37 }, { CR98, 0x35 }, { CR101, 0x13 },
+ { CR102, 0x27 }, { CR103, 0x27 }, { CR104, 0x18 },
+ { CR105, 0x12 }, { CR109, 0x27 }, { CR110, 0x27 },
+ { CR111, 0x27 }, { CR112, 0x27 }, { CR113, 0x27 },
+ { CR114, 0x27 }, { CR115, 0x26 }, { CR116, 0x24 },
+ { CR117, 0xfc }, { CR118, 0xfa }, { CR120, 0x4f },
+ { CR123, 0x27 }, { CR125, 0xaa }, { CR127, 0x03 },
+ { CR128, 0x14 }, { CR129, 0x12 }, { CR130, 0x10 },
+ { CR131, 0x0C }, { CR136, 0xdf }, { CR137, 0x40 },
+ { CR138, 0xa0 }, { CR139, 0xb0 }, { CR140, 0x99 },
+ { CR141, 0x82 }, { CR142, 0x54 }, { CR143, 0x1c },
+ { CR144, 0x6c }, { CR147, 0x07 }, { CR148, 0x4c },
+ { CR149, 0x50 }, { CR150, 0x0e }, { CR151, 0x18 },
+ { CR160, 0xfe }, { CR161, 0xee }, { CR162, 0xaa },
+ { CR163, 0xfa }, { CR164, 0xfa }, { CR165, 0xea },
+ { CR166, 0xbe }, { CR167, 0xbe }, { CR168, 0x6a },
+ { CR169, 0xba }, { CR170, 0xba }, { CR171, 0xba },
+ /* Note: CR204 must lead the CR203 */
+ { CR204, 0x7d },
+ { },
+ { CR203, 0x30 },
+ };
This is too much to allocate on the stack.
+static void disconnect(struct usb_interface *intf)
+{
+ struct net_device *netdev = zd_intf_to_netdev(intf);
+ struct zd_mac *mac = zd_netdev_mac(netdev);
+ struct zd_usb *usb = &mac->chip.usb;
+
+ dev_dbg_f(zd_usb_dev(usb), "\n");
+
+ zd_netdev_disconnect(netdev);
+
+ /* Just in case something has gone wrong! */
+ zd_usb_disable_rx(usb);
+ zd_usb_disable_int(usb);
+
+ /* If the disconnect has been caused by a removal of the
+ * driver module, the reset allows reloading of the driver. If the
+ * reset will not be executed here, the upload of the firmware in the
+ * probe function caused by the reloading of the driver will fail.
+ */
+ usb_reset_device(interface_to_usbdev(intf));
+
+ /* If somebody still waits on this lock now, this is an error. */
+ zd_netdev_free(netdev);
+ dev_dbg(&intf->dev, "disconnected\n");
+}
This is racy. It allows io to disconnected devices. You must take the
lock and set a flag that you test after you've taken the lock elsewhere.
Regards
Oliver
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Daniel Drake @ 2006-06-03 19:35 UTC (permalink / raw)
To: Oliver Neukum; +Cc: linux-usb-devel, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <200606031951.09135.oliver@neukum.org>
Oliver Neukum wrote:
> +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> +{
> + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> +}
>
> Why on the stack?
Technically it's not on the stack because it is static const (it goes in
rodata), but I don't think that this invalidates your point. What's the
alternative? kmalloc and kfree every time?
(Just seems a little over the top for such a small array)
> +static int zd1211_hw_reset_phy(struct zd_chip *chip)
> +{
> + static const struct zd_ioreq16 ioreqs[] = {
>
> This is too much to allocate on the stack.
Again static const, it's definately in rodata, checked with objdump. Do
we need to change this?
> +static void disconnect(struct usb_interface *intf)
> This is racy. It allows io to disconnected devices. You must take the
> lock and set a flag that you test after you've taken the lock elsewhere.
Will fix, thanks.
Daniel
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-03 22:25 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-usb-devel, John W. Linville, netdev, Ulrich Kunitz
In-Reply-To: <4481E497.2000505@gentoo.org>
Am Samstag, 3. Juni 2006 21:35 schrieb Daniel Drake:
> Oliver Neukum wrote:
> > +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> > +{
> > + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> > + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> > +}
> >
> > Why on the stack?
>
> Technically it's not on the stack because it is static const (it goes in
> rodata), but I don't think that this invalidates your point. What's the
> alternative? kmalloc and kfree every time?
In this case rodata will work. However, if you ever switch to direct DMA
it will fail. I really did overlook the const keyword.
[..]
> > +static void disconnect(struct usb_interface *intf)
> > This is racy. It allows io to disconnected devices. You must take the
> > lock and set a flag that you test after you've taken the lock elsewhere.
>
> Will fix, thanks.
You're welcome
Regards
Oliver
^ permalink raw reply
* [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
As announced earlier in this list, I am working on providing kernel support for providing regulatory
information to be used to set usable channels, max power, and other information needed by IEEE802.11
drivers. The database will be maintained as a text file processed by a user-space daemon. I now have
the complete system running on my machine. The full database and the user space daemon are available
through a subversion repository at svn://lwfinger.dynalias.org/ide1/ieee80211_geo.
The details of the implementation are as follows:
1. A new routine, ieee80211_init_geo has been written that is called by a driver wishing to use this
functionality. The arguments are an ieee80211_device, a two-character ISO3661 country code, and a
flag that is true if the device is to be used outdoors. This new routine does the following:
a) It establishes a default set of wireless parameters that will be supplied to the driver if the
user space daemon is not running, if the daemon does not respond in a timely fashion, or if the
daemon supplies data that do not pass rudimentary validity checks. The default data includes b/g
channels 1 - 11 for indoor usage at a maximum power of 20 dBm (100 mW). At present, no 5 GHz
channels are defined in the default set. This set of parameters should be legal everywhere.
b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for
communication with the daemon. The first, which is read by the daemon, contains the country and
outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data
corresponding to the country and indoor/outdoor information passed from the kernel.
c) It next spin loops for up to 1 second waiting for the user space daemon to respond. As noted
earlier, if this loop times out, the default set is supplied.
d) It then calls ieee80211_set_geo to load the channel data into the appropriate place in the
ieee80211_device block, and returns the status to the driver.
2. The user-space daemon, which need not be run as root, does the following:
a) It verifies that the text file containing the regulatory information is intact by assuming
that the last line of the file contains the md5 sum for all of the file except for this last line.
The scheme is certainly not tamper proof, but it ensures that whomever has modified the file has
some technical skills. If the checksum is not correct, the program generates an appropriate error
message and exits.
b) It then process the country information consisting of a number pointing to an entry describing
the 2.4 GHz band information, a second number pointing to the description of the 5 GHz bands, and a
two-character country code.
c) It then reads the groups that describe the allowed channels for the 2.4 GHz band and similar
information for the 5 GHz bands and builds the tables in the form needed by the ieee80211_geo
structure. Each input line consists of (a)the band identification characters "b", "bg", "a", or "h",
(b) a channel range consisting of the starting and ending channels, (c) the number of channels
between each stop (normally 1 for b/g and 4 for a), (d) the maximum eirp power for this channel in
dBm, and (e) a set of flags for these channels. Flags currently implemented are for 802.11b only,
for passive scanning, or for 802.11h rules. These data are checked to confirm that every group
mentioned in the country section is indeed present, that the channels listed are appropriate for
that band, and that there are no duplicate channels in any group. If there are any difficulties with
the data the daemon aborts.
d) It then daemonizes, unless the -F command-line switch was supplied.
e) It then spins waiting for the existence of file '/proc/net/ieee80211_geo/country', which is
the indication that the kernel is requesting data.
f) It then reads the country and outdoor flag, finds the appropriate entries in its internal
tables and writes the data back through the pseudo-file.in /proc. If the country code is unknown, a
default dataset is supplied. The program then loops back to step e) and waits for the next driver load.
A segment of the country section of the data file is as follows (data are 2.4 GHz group, 5 GHz group
ISO country name and English country name):
0 0 AO Angola, Republic of
0 0 AI Anguilla
0 0 AG Antigua and Barbuda
9 12 AR Argentina, Argentine Republic
0 0 AM Armenia
0 0 AW Aruba
2 2 AU Australia, Commonwealth of
1 1 AT Austria, Republic of
0 0 AZ Azerbaijan, Republic of
A couple of representative groups from the 2.4 GHz band are:
# Band Ch_Range Ch_Spacing Power Flags
#
bgGroup: 0 - Unspecified Country
# - Saudi Arabia (http://www.citc.sa)
#
bg 1 - 11 1 20 I
#
bgGroup: 1 - General European Union (EU)
# - India (Cetecom June 2 2005)
#
bg 1 - 13 1 20 B
#
Similarly, a couple of 5 GHz groups are:
aGroup: 0 - Unspecified (or unknown details for) Country
# - Bulgaria, Liechtenstein, Portugal, Romania, Slovakia, Spain
#
#
aGroup: 1 - General European Union (EU)
# - French Guiana and Reunion
#
h 36 - 48 4 23 I
h 52 - 64 4 23 IP
h 104 - 140 4 30 BP
I welcome your comments. Part 2 will show a debug dump of the converted database, Part 3 will
present the patch needed to add the new routine to the ieee80211 routines, and Part 4 will show the
patches needed to modify the bcm43xx driver to use the new routine..
Larry
^ permalink raw reply
* [RFC ] [2 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - database
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
This message shows each of the 2.4 GHz and 5 GHz bands split into indoor and outdoor usage. For each
group, the ISO name for that country is shown before the channel listing. There are a lot of
countries that do not belong in the default group. I welcome any input you can provide for these
missing countries, and any other incorrect information. Note: The country code EU is a pseudonym for
the entire European Union.
Thanks, Larry
=============================================================================================
IEEE80211 Regulatory/Geographical Daemon (V0.1)
Using Database Version of 26 May 2006
=================================================
Countries in 2.4 GHz group 0
AF, AL, DZ, AS, AD, AO, AI, AG, AM, AW, AZ, BS, BH, BD, BB, BY, BZ, BJ, BM, BT
BO, BA, BW, BV, IO, VG, BN, BF, BI, KH, CM, CV, KY, CF, TD, CX, CC, KM, CD, CG
CK, CI, DJ, DM, DO, TL, EG, SV, GQ, ER, ET, FO, FK, FJ, PF, TF, GA, GM, GE, GH
GI, GL, GD, GP, GU, GT, GN, GW, GY, HT, HM, HN, IS, ID, IR, IQ, IL, JO, KZ, KE
KI, KP, KW, KG, LA, LB, LS, LR, LY, MO, MG, MW, MY, MV, ML, MH, MQ, MR, MU, YT
FM, MD, MC, MN, MS, MA, MZ, MM, NA, NR, NP, AN, NC, NZ, NI, NE, NG, NU, NF, MP
NO, OM, PK, PW, PS, PA, PG, PH, PN, PR, QA, RW, SH, KN, LC, PM, VC, WS, SM, ST
SA, SN, CS, SC, SL, SG, SB, SO, ZA, GS, LK, SD, SR, SJ, SZ, CH, SY, TW, TJ, TZ
TH, TG, TK, TO, TT, TN, TM, TC, TV, VI, UG, UA, AE, UM, UY, UZ, VU, VE, VN, WF
EH, YE, ZM, ZW
Indoor Group 0 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
Outdoor Group 0 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 1
AT, BE, BG, HR, CY, CZ, DK, EE, EU, FI, DE, GR, VA, HU, IN, IE, IT, LV, LI, LT
LU, MK, MT, NL, PL, PT, RO, SK, SI, ES, SE, TR, GB
Indoor Group 1 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 1 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
=================================================
Countries in 2.4 GHz group 2
AU
Indoor Group 2 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
Outdoor Group 2 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
=================================================
Countries in 2.4 GHz group 3
FR
Indoor Group 3 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 3 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 10
10 2457 10
11 2462 10
12 2467 10
13 2472 10
=================================================
Countries in 2.4 GHz group 4
CN
Indoor Group 4 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 27
2 2417 27
3 2422 27
4 2427 27
5 2432 27
6 2437 27
7 2442 27
8 2447 27
9 2452 27
10 2457 27
11 2462 27
12 2467 27
13 2472 27
Outdoor Group 4 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 27
2 2417 27
3 2422 27
4 2427 27
5 2432 27
6 2437 27
7 2442 27
8 2447 27
9 2452 27
10 2457 27
11 2462 27
12 2467 27
13 2472 27
=================================================
Countries in 2.4 GHz group 5
HK, US
Indoor Group 5 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
Outdoor Group 5 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
=================================================
Countries in 2.4 GHz group 6
CL, CO, CR, CU, EC, JM, MX, PY, PE, RU
Indoor Group 6 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 6 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 7
BR, CA
Indoor Group 7 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 30
2 2417 30
3 2422 30
4 2427 30
5 2432 30
6 2437 30
7 2442 30
8 2447 30
9 2452 30
10 2457 30
11 2462 30
Outdoor Group 7 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 30
2 2417 30
3 2422 30
4 2427 30
5 2432 30
6 2437 30
7 2442 30
8 2447 30
9 2452 30
10 2457 30
11 2462 30
=================================================
Countries in 2.4 GHz group 8
GF, RE
Indoor Group 8 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 20
2 2417 20
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 20
10 2457 20
11 2462 20
12 2467 20
13 2472 20
Outdoor Group 8 with 11 channels in 2.4 GHz band
Chn Freq Power Flags
3 2422 20
4 2427 20
5 2432 20
6 2437 20
7 2442 20
8 2447 20
9 2452 10
10 2457 10
11 2462 10
12 2467 10
13 2472 10
=================================================
Countries in 2.4 GHz group 9
AR
Indoor Group 9 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 36
2 2417 36
3 2422 36
4 2427 36
5 2432 36
6 2437 36
7 2442 36
8 2447 36
9 2452 36
10 2457 36
11 2462 36
12 2467 36
13 2472 36
Outdoor Group 9 has no channels in 2.4 GHz band
=================================================
Countries in 2.4 GHz group 10
JP
Indoor Group 10 with 14 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
12 2467 23
13 2472 23
14 2484 23 B_ONLY
Outdoor Group 10 with 14 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 23
2 2417 23
3 2422 23
4 2427 23
5 2432 23
6 2437 23
7 2442 23
8 2447 23
9 2452 23
10 2457 23
11 2462 23
12 2467 23
13 2472 23
14 2484 23 B_ONLY
=================================================
Countries in 2.4 GHz group 11
KR
Indoor Group 11 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 28
2 2417 28
3 2422 28
4 2427 28
5 2432 28
6 2437 28
7 2442 28
8 2447 28
9 2452 28
10 2457 28
11 2462 28
12 2467 28
13 2472 28
Outdoor Group 11 with 13 channels in 2.4 GHz band
Chn Freq Power Flags
1 2412 28
2 2417 28
3 2422 28
4 2427 28
5 2432 28
6 2437 28
7 2442 28
8 2447 28
9 2452 28
10 2457 28
11 2462 28
12 2467 28
13 2472 28
=================================================
Countries in 5 GHz group 0
AF, AL, DZ, AS, AD, AO, AI, AG, AM, AW, AZ, BS, BH, BD, BB, BY, BZ, BJ, BM, BT
BO, BA, BW, BV, IO, VG, BN, BG, BF, BI, KH, CM, CV, KY, CF, TD, CX, CC, KM, CD
CG, CK, CR, CI, DJ, DM, DO, TL, EC, EG, SV, GQ, ER, ET, FO, FK, FJ, PF, TF, GA
GM, GE, GH, GI, GL, GD, GP, GU, GT, GN, GW, GY, HT, HM, HN, IS, ID, IR, IQ, IL
JO, KZ, KE, KI, KP, KW, KG, LA, LB, LS, LR, LY, LI, MO, MG, MW, MY, MV, ML, MH
MQ, MR, MU, YT, FM, MD, MC, MN, MS, MA, MZ, MM, NA, NR, NP, AN, NC, NZ, NI, NE
NG, NU, NF, MP, NO, OM, PK, PW, PS, PA, PG, PY, PH, PN, PT, PR, QA, RO, RU, RW
SH, KN, LC, PM, VC, WS, SM, ST, SN, CS, SC, SL, SG, SK, SB, SO, ZA, GS, ES, LK
SD, SR, SJ, SZ, CH, SY, TW, TJ, TZ, TH, TG, TK, TO, TT, TN, TM, TC, TV, VI, UG
UA, AE, UM, UY, UZ, VU, VE, VN, WF, EH, YE, ZM, ZW
Indoor Group 0 has no channels in 5 GHz band
Outdoor Group 0 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 1
AT, HR, CY, CZ, DK, EE, EU, FI, FR, GF, DE, VA, HU, IE, IT, LV, LT, LU, MK, MT
NL, PL, RE, SI, SE, GB
Indoor Group 1 with 18 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23 PASSIVE H_RULES
40 5200 23 PASSIVE H_RULES
44 5220 23 PASSIVE H_RULES
48 5240 23 PASSIVE H_RULES
52 5260 23 PASSIVE H_RULES
56 5280 23 PASSIVE H_RULES
60 5300 23 PASSIVE H_RULES
64 5320 23 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
Outdoor Group 1 with 10 channels in 5 GHz bands
Chn Freq Power Flags
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
=================================================
Countries in 5 GHz group 2
AU
Indoor Group 2 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 2 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 30
153 5765 30
157 5785 30
161 5805 30
=================================================
Countries in 5 GHz group 3
SA
Indoor Group 3 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
149 5745 23
153 5765 23
157 5785 23
161 5805 23
Outdoor Group 3 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 4
CN
Indoor Group 4 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 27
153 5765 27
157 5785 27
161 5805 27
Outdoor Group 4 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 27
153 5765 27
157 5785 27
161 5805 27
=================================================
Countries in 5 GHz group 5
HK
Indoor Group 5 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
Outdoor Group 5 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 23
56 5280 23
60 5300 23
64 5320 23
=================================================
Countries in 5 GHz group 6
GR, TR
Indoor Group 6 with 8 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23 PASSIVE H_RULES
40 5200 23 PASSIVE H_RULES
44 5220 23 PASSIVE H_RULES
48 5240 23 PASSIVE H_RULES
52 5260 23 PASSIVE H_RULES
56 5280 23 PASSIVE H_RULES
60 5300 23 PASSIVE H_RULES
64 5320 23 PASSIVE H_RULES
Outdoor Group 6 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 7
BR, CA
Indoor Group 7 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 30
56 5280 30
60 5300 30
64 5320 30
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 7 with 8 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 30
56 5280 30
60 5300 30
64 5320 30
149 5745 30
153 5765 30
157 5785 30
161 5805 30
=================================================
Countries in 5 GHz group 8
JM, PE
Indoor Group 8 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 8 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 9
BE
Indoor Group 9 with 11 channels in 5 GHz bands
Chn Freq Power Flags
100 5500 30 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
Outdoor Group 9 with 11 channels in 5 GHz bands
Chn Freq Power Flags
100 5500 30 PASSIVE H_RULES
104 5520 30 PASSIVE H_RULES
108 5540 30 PASSIVE H_RULES
112 5560 30 PASSIVE H_RULES
116 5580 30 PASSIVE H_RULES
120 5600 30 PASSIVE H_RULES
124 5620 30 PASSIVE H_RULES
128 5640 30 PASSIVE H_RULES
132 5660 30 PASSIVE H_RULES
136 5680 30 PASSIVE H_RULES
140 5700 30 PASSIVE H_RULES
=================================================
Countries in 5 GHz group 10
IN
Indoor Group 10 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 20
40 5200 20
44 5220 20
48 5240 20
52 5260 20
56 5280 20
60 5300 20
64 5320 20
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 10 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 11
US
Indoor Group 11 with 12 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 23
40 5200 23
44 5220 23
48 5240 23
52 5260 30 PASSIVE H_RULES
56 5280 30 PASSIVE H_RULES
60 5300 30 PASSIVE H_RULES
64 5320 30 PASSIVE H_RULES
149 5745 36
153 5765 36
157 5785 36
161 5805 36
Outdoor Group 11 with 8 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 30 PASSIVE H_RULES
56 5280 30 PASSIVE H_RULES
60 5300 30 PASSIVE H_RULES
64 5320 30 PASSIVE H_RULES
149 5745 36
153 5765 36
157 5785 36
161 5805 36
=================================================
Countries in 5 GHz group 12
AR
Indoor Group 12 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 36
153 5765 36
157 5785 36
161 5805 36
Outdoor Group 12 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 13
CL, CO, CU
Indoor Group 13 with 4 channels in 5 GHz bands
Chn Freq Power Flags
149 5745 30
153 5765 30
157 5785 30
161 5805 30
Outdoor Group 13 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 14
MX
Indoor Group 14 with 22 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 20
40 5200 20
44 5220 20
48 5240 20
52 5260 20
56 5280 20
60 5300 20
64 5320 20
104 5520 20
108 5540 20
112 5560 20
116 5580 20
120 5600 20
124 5620 20
128 5640 20
132 5660 20
136 5680 20
140 5700 20
149 5745 20
153 5765 20
157 5785 20
161 5805 20
Outdoor Group 14 has no channels in 5 GHz band
=================================================
Countries in 5 GHz group 15
JP
Indoor Group 15 with 4 channels in 5 GHz bands
Chn Freq Power Flags
34 5170 23
38 5190 23
42 5210 23
46 5230 23
Outdoor Group 15 with 4 channels in 5 GHz bands
Chn Freq Power Flags
34 5170 23
38 5190 23
42 5210 23
46 5230 23
=================================================
Countries in 5 GHz group 16
KR
Indoor Group 16 with 19 channels in 5 GHz bands
Chn Freq Power Flags
36 5180 28
40 5200 28
44 5220 28
48 5240 28
52 5260 28
56 5280 28
60 5300 28
64 5320 28
100 5500 28
104 5520 28
108 5540 28
112 5560 28
116 5580 28
120 5600 28
124 5620 28
149 5745 28
153 5765 28
157 5785 28
161 5805 28
Outdoor Group 16 with 15 channels in 5 GHz bands
Chn Freq Power Flags
52 5260 28
56 5280 28
60 5300 28
64 5320 28
100 5500 28
104 5520 28
108 5540 28
112 5560 28
116 5580 28
120 5600 28
124 5620 28
149 5745 28
153 5765 28
157 5785 28
161 5805 28
Database contains 239 countries, 12 groups in the 2.4 GHz band,
and 17 groups in the 5 GHz bands.
^ permalink raw reply
* [RFC ] [3 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - Patches for ieee80211
From: Larry Finger @ 2006-06-03 22:45 UTC (permalink / raw)
To: netdev, John Linville
This message contains the patch to add routine ieee80211_init_geo to the kernel, and a new flag
definition for the IEEE80211 codes. Note: I know that my mailer has messed up the white space by
converting all the tabs to spaces. The original files are OK. Larry
=====================================================================================
diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
index d5926bf..8a5dc0f 100644
--- a/include/net/ieee80211.h
+++ b/include/net/ieee80211.h
@@ -965,6 +965,7 @@ #define IEEE80211_52GHZ_CHANNELS (IEEE80
enum {
IEEE80211_CH_PASSIVE_ONLY = (1 << 0),
+ IEEE80211_CH_80211H_RULES = (1 << 1),
IEEE80211_CH_B_ONLY = (1 << 2),
IEEE80211_CH_NO_IBSS = (1 << 3),
IEEE80211_CH_UNIFORM_SPREADING = (1 << 4),
@@ -973,10 +974,10 @@ enum {
};
struct ieee80211_channel {
- u32 freq;
+ u32 freq; /* in MHz */
u8 channel;
u8 flags;
- u8 max_power;
+ u8 max_power; /* in dBm */
};
struct ieee80211_geo {
@@ -1260,6 +1261,9 @@ extern const struct ieee80211_geo *ieee8
extern int ieee80211_set_geo(struct ieee80211_device *ieee,
const struct ieee80211_geo *geo);
+extern int ieee80211_init_geo(struct ieee80211_device *ieee,
+ char * country, u8 outdoor);
+
extern int ieee80211_is_valid_channel(struct ieee80211_device *ieee,
u8 channel);
extern int ieee80211_channel_to_index(struct ieee80211_device *ieee,
diff --git a/net/ieee80211/ieee80211_geo.c b/net/ieee80211/ieee80211_geo.c
index 192243a..2e4806b 100644
--- a/net/ieee80211/ieee80211_geo.c
+++ b/net/ieee80211/ieee80211_geo.c
@@ -41,6 +41,7 @@ #include <linux/types.h>
#include <linux/wireless.h>
#include <linux/etherdevice.h>
#include <asm/uaccess.h>
+#include <linux/delay.h>
#include <net/ieee80211.h>
@@ -133,6 +134,136 @@ int ieee80211_set_geo(struct ieee80211_d
return 0;
}
+static char ieee80211_country[10];
+static uint ieee80211_outdoor;
+static struct proc_dir_entry *ieee80211_geo_proc;
+static uint ieee80211_data_back;
+struct ieee80211_geo *geo;
+static uint bytes_xfer;
+
+static int show_geo_country(char *page, char **start, off_t offset,
+ int count, int *eof, void *data)
+{
+ return snprintf(page, count, "%s %d\n", ieee80211_country, ieee80211_outdoor);
+}
+
+static int store_geo_data(struct file *file, const char __user * buffer,
+ unsigned long count, void *data)
+{
+ unsigned long len = min((unsigned long)sizeof(struct ieee80211_geo) , count);
+ int i;
+
+ if (copy_from_user((geo + bytes_xfer), buffer, len)) {
+ IEEE80211_ERROR( "Error return from copy_from_user.\n");
+ return -EFAULT;
+ }
+ bytes_xfer += len;
+ if (bytes_xfer == sizeof(struct ieee80211_geo)) {
+ IEEE80211_DEBUG_INFO( "All data has been received.\n");
+ if (!geo->bg_channels && !geo->a_channels) { /* if no channels specified - error */
+ IEEE80211_DEBUG_INFO( "No bg or a/h channels specified.\n");
+ return count;
+ }
+ if (geo->bg_channels > IEEE80211_24GHZ_CHANNELS) { /* too many bg channels */
+ IEEE80211_DEBUG_INFO( "Too many bg channels specified.\n");
+ return count;
+ }
+ if (geo->a_channels > IEEE80211_52GHZ_CHANNELS) { /* too many a channels */
+ IEEE80211_DEBUG_INFO( "Too many a/h channels specified.\n");
+ return count;
+ }
+ for (i=0; i<geo->a_channels; i++) {
+ if (geo->a[i].channel < IEEE80211_52GHZ_MIN_CHANNEL ||
+ geo->a[i].channel > IEEE80211_52GHZ_MAX_CHANNEL)
+ return count; /* here if channel out of range */
+ }
+ for (i=0; i<geo->bg_channels; i++) {
+ if (geo->bg[i].channel < IEEE80211_24GHZ_MIN_CHANNEL ||
+ geo->bg[i].channel > IEEE80211_24GHZ_MAX_CHANNEL)
+ return count; /* here if channel out of range */
+ }
+ IEEE80211_DEBUG_INFO( "Data passed sanity checks.\n"); /* data seems to be correct */
+ ieee80211_data_back = 0;
+ }
+ return count;
+}
+
+int ieee80211_init_geo(struct ieee80211_device *ieee,
+ char *country, u8 outdoor)
+{
+ int ret;
+ struct proc_dir_entry *e1, *e2;
+
+ static const struct ieee80211_geo ieee80211_geos[] = {
+ { /* Default parameters to be returned if daemon not running or other error */
+ "---",
+ .a_channels = 0,
+ .bg_channels = 11,
+ .bg = {{.freq = 2412, .channel = 1, .max_power = 20},
+ {.freq = 2417, .channel = 2, .max_power = 20},
+ {.freq = 2422, .channel = 3, .max_power = 20},
+ {.freq = 2427, .channel = 4, .max_power = 20},
+ {.freq = 2432, .channel = 5, .max_power = 20},
+ {.freq = 2437, .channel = 6, .max_power = 20},
+ {.freq = 2442, .channel = 7, .max_power = 20},
+ {.freq = 2447, .channel = 8, .max_power = 20},
+ {.freq = 2452, .channel = 9, .max_power = 20},
+ {.freq = 2457, .channel = 10, .max_power = 20},
+ {.freq = 2462, .channel = 11, .max_power = 20}
+ },
+ },
+ };
+
+ IEEE80211_DEBUG_INFO( "Country Code: %s, Outdoor: %d\n", country, outdoor);
+ memcpy(ieee80211_country, country, strlen(country));
+ ieee80211_outdoor = outdoor;
+ ieee80211_geo_proc = proc_mkdir("ieee80211_geo", proc_net);
+ (void)ieee80211_set_geo( ieee, ieee80211_geos); /* load default data in case of error */
+ if (ieee80211_geo_proc == NULL) {
+ IEEE80211_ERROR( "Unable to create ieee80211_geo"
+ " proc directory - default geo data loaded\n");
+ return -EIO;
+ }
+ geo = kzalloc(sizeof(struct ieee80211_geo), GFP_KERNEL);
+ if (!geo) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+ e1 = create_proc_entry("geo_country", S_IFREG | S_IRUSR | S_IWUSR,
+ ieee80211_geo_proc);
+ e1->read_proc = show_geo_country;
+ e2 = create_proc_entry("geo_data", S_IWUSR | S_IWGRP | S_IWOTH,
+ ieee80211_geo_proc);
+ ieee80211_data_back = 1;
+ bytes_xfer = 0;
+ e2->write_proc = store_geo_data;
+
+ if (!e1 || !e2 ) {
+ IEEE80211_ERROR( "Unable to create files in ieee80211_geo"
+ " - default data loaded.\n");
+ ret = -EIO;
+ goto free_geo;
+ }
+ for (ret=0; ret<1000; ret++) {
+ if (!ieee80211_data_back)
+ break;
+ udelay(1000);
+ }
+ if (ret == 1000) {
+ ret = -EIO;
+ IEEE80211_DEBUG_INFO( "ieee80211_geo daemon not running - default data loaded.\n");
+ goto free_geo; /* daemon not running */
+ }
+ ret = ieee80211_set_geo( ieee, geo);
+free_geo:
+ kfree(geo);
+cleanup:
+ remove_proc_entry("geo_country", ieee80211_geo_proc);
+ remove_proc_entry("geo_data", ieee80211_geo_proc);
+ remove_proc_entry("ieee80211_geo", proc_net);
+ return ret;
+}
+
const struct ieee80211_geo *ieee80211_get_geo(struct ieee80211_device *ieee)
{
return &ieee->geo;
@@ -177,4 +308,5 @@ EXPORT_SYMBOL(ieee80211_is_valid_channel
EXPORT_SYMBOL(ieee80211_freq_to_channel);
EXPORT_SYMBOL(ieee80211_channel_to_index);
EXPORT_SYMBOL(ieee80211_set_geo);
+EXPORT_SYMBOL(ieee80211_init_geo);
EXPORT_SYMBOL(ieee80211_get_geo);
^ permalink raw reply related
* [RFC ] [4 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - Patches for bcm43xx to use new ieee80211 routine
From: Larry Finger @ 2006-06-03 22:46 UTC (permalink / raw)
To: netdev, John Linville
This message shows the patch needed to convert the bcm43xx driver to use the new ieee80211_init_geo
routine. Note: I know my mailer has butchered the white space by changing all the tabs into spaces.
The original source is OK. Larry
===================================================================================================
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c \
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index 7ed18ca..eb88a4e 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -87,9 +87,15 @@ static int modparam_long_retry = BCM43xx
module_param_named(long_retry, modparam_long_retry, int, 0444);
MODULE_PARM_DESC(long_retry, "Long-Retry-Limit (0 - 15)");
-static int modparam_locale = -1;
-module_param_named(locale, modparam_locale, int, 0444);
-MODULE_PARM_DESC(country, "Select LocaleCode 0-11 (For travelers)");
+static char modparam_locale[] = " ";
+static char country[3];
+
+module_param_string(country, modparam_locale, 3, 0444);
+MODULE_PARM_DESC(country, "Two character ISO Country Name (For Travelers)");
+
+static int modparam_outdoor;
+module_param_named(outdoor, modparam_outdoor, int, 0444);
+MODULE_PARM_DESC(outdoor, "Set to 1 if interface to be used outdoors");
static int modparam_noleds;
module_param_named(noleds, modparam_noleds, int, 0444);
@@ -621,38 +627,6 @@ static const char * bcm43xx_locale_iso(u
return " ";
}
-static const char * bcm43xx_locale_string(u8 locale)
-{
- switch (locale) {
- case BCM43xx_LOCALE_WORLD:
- return "World";
- case BCM43xx_LOCALE_THAILAND:
- return "Thailand";
- case BCM43xx_LOCALE_ISRAEL:
- return "Israel";
- case BCM43xx_LOCALE_JORDAN:
- return "Jordan";
- case BCM43xx_LOCALE_CHINA:
- return "China";
- case BCM43xx_LOCALE_JAPAN:
- return "Japan";
- case BCM43xx_LOCALE_USA_CANADA_ANZ:
- return "USA/Canada/ANZ";
- case BCM43xx_LOCALE_EUROPE:
- return "Europe";
- case BCM43xx_LOCALE_USA_LOW:
- return "USAlow";
- case BCM43xx_LOCALE_JAPAN_HIGH:
- return "JapanHigh";
- case BCM43xx_LOCALE_ALL:
- return "All";
- case BCM43xx_LOCALE_NONE:
- return "None";
- }
- assert(0);
- return "";
-}
-
static inline u8 bcm43xx_crc8(u8 crc, u8 data)
{
static const u8 t[] = {
@@ -860,17 +834,12 @@ #endif
bcm->sprom.locale = (value & 0x0F00) >> 8;
bcm->sprom.antennas_aphy = (value & 0x3000) >> 12;
bcm->sprom.antennas_bgphy = (value & 0xC000) >> 14;
- if (modparam_locale != -1) {
- if (modparam_locale >= 0 && modparam_locale <= 11) {
- bcm->sprom.locale = modparam_locale;
- printk(KERN_WARNING PFX "Operating with modified "
- "LocaleCode %u (%s)\n",
- bcm->sprom.locale,
- bcm43xx_locale_string(bcm->sprom.locale));
- } else {
- printk(KERN_WARNING PFX "Module parameter \"locale\" "
- "invalid value. (0 - 11)\n");
- }
+ if (strcmp(modparam_locale, " ")) {
+ printk(KERN_WARNING PFX "Operating with modified Country "
+ "Code %s\n", modparam_locale);
+ strcpy(country, modparam_locale);
+ } else {
+ strcpy(country, bcm43xx_locale_iso(bcm->sprom.locale));
}
/* pa0b* */
@@ -939,69 +908,6 @@ #endif
return 0;
}
-static int bcm43xx_geo_init(struct bcm43xx_private *bcm)
-{
- struct ieee80211_geo *geo;
- struct ieee80211_channel *chan;
- int have_a = 0, have_bg = 0;
- int i;
- u8 channel;
- struct bcm43xx_phyinfo *phy;
- const char *iso_country;
-
- geo = kzalloc(sizeof(*geo), GFP_KERNEL);
- if (!geo)
- return -ENOMEM;
-
- for (i = 0; i < bcm->nr_80211_available; i++) {
- phy = &(bcm->core_80211_ext[i].phy);
- switch (phy->type) {
- case BCM43xx_PHYTYPE_B:
- case BCM43xx_PHYTYPE_G:
- have_bg = 1;
- break;
- case BCM43xx_PHYTYPE_A:
- have_a = 1;
- break;
- default:
- assert(0);
- }
- }
- iso_country = bcm43xx_locale_iso(bcm->sprom.locale);
-
- if (have_a) {
- for (i = 0, channel = IEEE80211_52GHZ_MIN_CHANNEL;
- channel <= IEEE80211_52GHZ_MAX_CHANNEL; channel++) {
- chan = &geo->a[i++];
- chan->freq = bcm43xx_channel_to_freq_a(channel);
- chan->channel = channel;
- }
- geo->a_channels = i;
- }
- if (have_bg) {
- for (i = 0, channel = IEEE80211_24GHZ_MIN_CHANNEL;
- channel <= IEEE80211_24GHZ_MAX_CHANNEL; channel++) {
- chan = &geo->bg[i++];
- chan->freq = bcm43xx_channel_to_freq_bg(channel);
- chan->channel = channel;
- }
- geo->bg_channels = i;
- }
- memcpy(geo->name, iso_country, 2);
- if (0 /*TODO: Outdoor use only */)
- geo->name[2] = 'O';
- else if (0 /*TODO: Indoor use only */)
- geo->name[2] = 'I';
- else
- geo->name[2] = ' ';
- geo->name[3] = '\0';
-
- ieee80211_set_geo(bcm->ieee, geo);
- kfree(geo);
-
- return 0;
-}
-
/* DummyTransmission function, as documented on
* http://bcm-specs.sipsolutions.net/DummyTransmission
*/
@@ -3486,13 +3392,15 @@ static int bcm43xx_attach_board(struct b
bcm43xx_radio_turn_off(bcm);
err = bcm43xx_phy_init_tssi2dbm_table(bcm);
+ bcm43xx_wireless_core_disable(bcm);
if (err)
goto err_80211_unwind;
- bcm43xx_wireless_core_disable(bcm);
}
- err = bcm43xx_geo_init(bcm);
+ printk(KERN_INFO PFX "Country Code = %s, Outdoor code = %d\n", country, modparam_outdoor);
+ err = ieee80211_init_geo(bcm->ieee, country, modparam_outdoor);
if (err)
goto err_80211_unwind;
+
bcm43xx_pctl_set_crystal(bcm, 0);
/* Set the MAC address in the networking subsystem */
^ permalink raw reply related
* Re: [RFC ] [1 of 4] IEEE802.11 Regulatory/Geographical Support for drivers - statement of project
From: Michael Buesch @ 2006-06-03 23:12 UTC (permalink / raw)
To: Larry Finger; +Cc: John Linville, netdev
In-Reply-To: <448210EF.10103@lwfinger.net>
On Sunday 04 June 2006 00:45, Larry Finger wrote:
> b) It then creates a new directory, '/proc/net/ieee80211_geo', and populates it with 2 files for
> communication with the daemon. The first, which is read by the daemon, contains the country and
> outdoor codes, and the second is for the the daemon to write the 'struct ieee80211_geo' data
> corresponding to the country and indoor/outdoor information passed from the kernel.
Use sysfs, please.
--
Greetings Michael.
^ permalink raw reply
* [PATCH] ipx: endian bug in ipxrtr_route_packet()
From: Alexey Dobriyan @ 2006-06-03 23:36 UTC (permalink / raw)
To: netdev; +Cc: Arnaldo Carvalho de Melo
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
Also, there is the following snippet in net/ipx/af_ipx.c, line 1174
f.ipx_special = sipx->sipx_special;
The former is unsigned char and is compared with 1 and 2. The latter is
__be16 if I'm not mistaken. Is there a bug hiding?
--- a/net/ipx/ipx_route.c
+++ b/net/ipx/ipx_route.c
@@ -238,7 +237,7 @@ int ipxrtr_route_packet(struct sock *sk,
}
/* Apply checksum. Not allowed on 802.3 links. */
- if (sk->sk_no_check || intrfc->if_dlink_type == IPX_FRAME_8023)
+ if (sk->sk_no_check || intrfc->if_dlink_type == htons(IPX_FRAME_8023))
ipx->ipx_checksum = 0xFFFF;
else
ipx->ipx_checksum = ipx_cksum(ipx, len + sizeof(struct ipxhdr));
^ permalink raw reply
* [PATCH] bcm43xx: add DMA rx poll workaround to DMA4
From: Michael Buesch @ 2006-06-04 0:20 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev
This is a bugfix and 2.6.17 stuff, if still possible to push upstream.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
index bbecba0..d0318e5 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.c
@@ -624,25 +624,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -660,16 +663,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -839,8 +842,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
--
Greetings Michael.
^ permalink raw reply related
* RE: kernel panic (on DHCP discover?) in sky2 driver of 2.6.17-rc1
From: Guenther Thomsen @ 2006-06-04 4:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: John W. Linville, netdev
I received the hardware back and took the opportunity to test with 2.6.17-rc5-git11. So far I did only little tests (ttcp on both interfaces in, out or mixed with some 10e6 packets), but it looks good. No errors (well, 16 overruns in 76574513 packets) and line rate (about 111MB/s) on both channels simultaneously. Hurray!
Thanks a lot for you continued efforts.
Guenther
-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]
Sent: Tuesday, May 16, 2006 12:12 PM
To: Guenther Thomsen
Cc: John W. Linville; netdev@vger.kernel.org
Subject: Re: kernel panic (on DHCP discover?) in sky2 driver of
2.6.17-rc1
Could you try the 2.6.17-rc4 version with this patch. It turns out the board
seems to give out of order status responses.
Ignore the vendor sk98lin driver, when I try the stock version it spends it's
life resetting itself because it sets up PCI bus wrong. If I fix that, it spends
it's time getting confused because it can't handle intermixed status reports
properly (checksum et all is per port not per board).
drivers/net/sky2.c | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
792547bc5e8e4f7d5a1070a168056f429635c254
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index ffd267f..11e7914 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1020,8 +1020,27 @@ static int sky2_up(struct net_device *de
struct sky2_hw *hw = sky2->hw;
unsigned port = sky2->port;
u32 ramsize, rxspace, imask;
- int err = -ENOMEM;
+ int cap, err;
+ struct net_device *otherdev = hw->dev[sky2->port^1];
+ /*
+ * Reduce split transactions (and turn off) rx checksums to
+ * prevent problems with dual ports.
+ */
+ if (otherdev && netif_running(otherdev) &&
+ (cap = pci_find_capability(hw->pdev, PCI_CAP_ID_PCIX))) {
+ struct sky2_port *osky2 = netdev_priv(otherdev);
+ u16 cmd;
+
+ cmd = sky2_pci_read16(hw, cap + PCI_X_CMD);
+ cmd &= ~PCI_X_CMD_MAX_SPLIT;
+ sky2_pci_write16(hw, cap + PCI_X_CMD, cmd);
+
+ sky2->rx_csum = 0;
+ osky2->rx_csum = 0;
+ }
+
+ err = -ENOMEM;
if (netif_msg_ifup(sky2))
printk(KERN_INFO PFX "%s: enabling interface\n", dev->name);
@@ -3067,12 +3086,7 @@ static __devinit struct net_device *sky2
sky2->duplex = -1;
sky2->speed = -1;
sky2->advertising = sky2_supported_modes(hw);
-
- /* Receive checksum disabled for Yukon XL
- * because of observed problems with incorrect
- * values when multiple packets are received in one interrupt
- */
- sky2->rx_csum = (hw->chip_id != CHIP_ID_YUKON_XL);
+ sky2->rx_csum = 1;
spin_lock_init(&sky2->phy_lock);
sky2->tx_pending = TX_DEF_PENDING;
--
1.2.4
^ permalink raw reply related
* icmp or table->lock deadlock bug? (lockdep) (fwd)
From: James Morris @ 2006-06-04 4:09 UTC (permalink / raw)
To: netdev
---------- Forwarded message ----------
Date: Fri, 2 Jun 2006 16:31:44 -0700 (PDT)
From: Matthew L Foster <mfoster167@yahoo.com>
To: linux-kernel@vger.kernel.org
Cc: mfoster167@yahoo.com
Subject: icmp or table->lock deadlock bug? (lockdep)
Perhaps someone has hit this one already but in case not:
====================================
[ BUG: possible deadlock detected! ]
------------------------------------
kicker/2665 is trying to acquire lock:
(&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
but task is already holding lock:
(&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
which could potentially lead to deadlocks!
other info that might help us debug this:
2 locks held by kicker/2665:
#0: (&table->lock){-.-+}, at: [<c02b1384>] ipt_do_table+0x68/0x294
#1: (&sk->sk_lock.slock#3){-+..}, at: [<c029dab8>] icmp_send+0x100/0x332
stack backtrace:
<c01030b8> show_trace+0x16/0x19 <c0103586> dump_stack+0x1a/0x1f
<c012a880> __lockdep_acquire+0x6c6/0x907 <c012addb> lockdep_acquire+0x4b/0x63
<c02cdab1> _read_lock_bh+0x27/0x2f <c02b1384> ipt_do_table+0x68/0x294
<c02b1e37> ipt_hook+0x1b/0x20 <c0279606> nf_iterate+0x26/0x5a
<c02798ab> nf_hook_slow+0x41/0xba <c0282888> ip_push_pending_frames+0x2e2/0x3a9
<c029d39d> icmp_push_reply+0xc2/0xcd <c029dc8b> icmp_send+0x2d3/0x332
<c02b371c> reject+0x49/0x551 <c02b155d> ipt_do_table+0x241/0x294
<c02b162b> ipt_hook+0x1b/0x20 <c0279606> nf_iterate+0x26/0x5a
<c02798ab> nf_hook_slow+0x41/0xba <c0280482> ip_local_deliver+0x58/0x1e6
<c02803fd> ip_rcv+0x3d5/0x402 <c026bc9b> netif_receive_skb+0x13d/0x1a4
<c026d552> process_backlog+0x7c/0x112 <c026d35c> net_rx_action+0x5b/0xed
<c01188ca> __do_softirq+0x45/0x9f <c0104428> do_softirq+0x45/0xa4
=======================
<c0118954> irq_exit+0x30/0x3c <c01044f7> do_IRQ+0x70/0x7d
<c0102b45> common_interrupt+0x25/0x2c
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-04 8:02 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606031045.08763.stefan@loplof.de>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
On Saturday 3 June 2006 10:45, Stefan Rompf wrote:
> Am Freitag 02 Juni 2006 16:30 schrieb Ivo van Doorn:
>
> > > Or actually, I don't think the radiobtn/ won't be actually needed as
> > > prefix. The name passed to the radiobtn driver by the driver should be
> > > sufficient.
> >
> > Updated version,
> >
> > Signed-off-by Ivo van Doorn <IvDoorn@gmail.com>
>
> I don't like the patch in it's current form. Many notebooks have a number of
> additional keys that need to be queried/polled using the same interface, but
> just one button is to control the radio, the rest are multimedia keys that
> just need to be forwarded to userspace. Or maybe a bluetooth key.
Except for the bluetooth radio key (which should be supported by the radiobtn interface as well)
the other buttons have support through already excisting input devices if I am correct.
This radiobtn driver is there to poll the device frequently about the radio state only
since that is one of the few buttons that is not sending anything to userspace at the moment.
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] bcm43xx-d80211: add DMA rx poll workaround to DMA4
From: Michael Buesch @ 2006-06-04 9:41 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, bcm43xx-dev
This is the same patch as before, but for the dscape port.
Please apply to wireless-dev.
--
Also add the Poll RX DMA Memory workaround to the DMA4
(xmitstatus) path.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..ebe0984 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -604,25 +604,28 @@ err_destroy_tx0:
static u16 generate_cookie(struct bcm43xx_dmaring *ring,
int slot)
{
- u16 cookie = 0x0000;
+ u16 cookie = 0xF000;
/* Use the upper 4 bits of the cookie as
* DMA controller ID and store the slot number
- * in the lower 12 bits
+ * in the lower 12 bits.
+ * Note that the cookie must never be 0, as this
+ * is a special value used in RX path.
*/
switch (ring->mmio_base) {
default:
assert(0);
case BCM43xx_MMIO_DMA1_BASE:
+ cookie = 0xA000;
break;
case BCM43xx_MMIO_DMA2_BASE:
- cookie = 0x1000;
+ cookie = 0xB000;
break;
case BCM43xx_MMIO_DMA3_BASE:
- cookie = 0x2000;
+ cookie = 0xC000;
break;
case BCM43xx_MMIO_DMA4_BASE:
- cookie = 0x3000;
+ cookie = 0xD000;
break;
}
assert(((u16)slot & 0xF000) == 0x0000);
@@ -640,16 +643,16 @@ struct bcm43xx_dmaring * parse_cookie(st
struct bcm43xx_dmaring *ring = NULL;
switch (cookie & 0xF000) {
- case 0x0000:
+ case 0xA000:
ring = dma->tx_ring0;
break;
- case 0x1000:
+ case 0xB000:
ring = dma->tx_ring1;
break;
- case 0x2000:
+ case 0xC000:
ring = dma->tx_ring2;
break;
- case 0x3000:
+ case 0xD000:
ring = dma->tx_ring3;
break;
default:
@@ -867,8 +870,18 @@ static void dma_rx(struct bcm43xx_dmarin
/* We received an xmit status. */
struct bcm43xx_hwxmitstatus *hw = (struct bcm43xx_hwxmitstatus *)skb->data;
struct bcm43xx_xmitstatus stat;
+ int i = 0;
stat.cookie = le16_to_cpu(hw->cookie);
+ while (stat.cookie == 0) {
+ if (unlikely(++i >= 10000)) {
+ assert(0);
+ break;
+ }
+ udelay(2);
+ barrier();
+ stat.cookie = le16_to_cpu(hw->cookie);
+ }
stat.flags = hw->flags;
stat.cnt1 = hw->cnt1;
stat.cnt2 = hw->cnt2;
--
Greetings Michael.
^ permalink raw reply related
* [PATCH] bcm43xx-d80211: Fix 64bit compiler warnings
From: Michael Buesch @ 2006-06-04 10:03 UTC (permalink / raw)
To: linville; +Cc: netdev, bcm43xx-dev
Fix all 64bit compiler warnings.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
index e882bc1..0f7303e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_debugfs.c
@@ -227,7 +227,7 @@ static ssize_t tsf_write_file(struct fil
res = -EFAULT;
goto out_unlock;
}
- if (sscanf(buf, "%lli", &tsf) != 1) {
+ if (sscanf(buf, "%llu", (unsigned long long *)(&tsf)) != 1) {
printk(KERN_INFO PFX "debugfs: invalid values for \"tsf\"\n");
res = -EINVAL;
goto out_unlock;
@@ -449,11 +449,11 @@ void bcm43xx_printk_dump(const char *dat
size_t size,
const char *description)
{
- size_t i;
+ unsigned int i;
char c;
- printk(KERN_INFO PFX "Data dump (%s, %u bytes):",
- description, size);
+ printk(KERN_INFO PFX "Data dump (%s, %lu bytes):",
+ description, (unsigned long)size);
for (i = 0; i < size; i++) {
c = data[i];
if (i % 8 == 0)
@@ -468,12 +468,13 @@ void bcm43xx_printk_bitdump(const unsign
size_t bytes, int msb_to_lsb,
const char *description)
{
- size_t i;
+ unsigned int i;
int j;
const unsigned char *d;
- printk(KERN_INFO PFX "*** Bitdump (%s, %u bytes, %s) ***",
- description, bytes, msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
+ printk(KERN_INFO PFX "*** Bitdump (%s, %lu bytes, %s) ***",
+ description, (unsigned long)bytes,
+ msb_to_lsb ? "MSB to LSB" : "LSB to MSB");
for (i = 0; i < bytes; i++) {
d = data + i;
if (i % 8 == 0)
diff --git a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
index dc11260..1dfd74e 100644
--- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
+++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c
@@ -180,7 +180,7 @@ static int alloc_ringmemory(struct bcm43
if (ring->dmabase + BCM43xx_DMA_RINGMEMSIZE > BCM43xx_DMA_BUSADDRMAX) {
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RINGMEMORY >1G "
"(0x%08x, len: %lu)\n",
- ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
+ (unsigned int)ring->dmabase, BCM43xx_DMA_RINGMEMSIZE);
dma_free_coherent(dev, BCM43xx_DMA_RINGMEMSIZE,
ring->vbase, ring->dmabase);
return -ENOMEM;
@@ -292,7 +292,7 @@ static int setup_rx_descbuffer(struct bc
dev_kfree_skb_any(skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA RX SKB >1G "
"(0x%08x, len: %u)\n",
- dmaaddr, ring->rx_buffersize);
+ (unsigned int)dmaaddr, ring->rx_buffersize);
return -ENOMEM;
}
meta->skb = skb;
@@ -711,7 +711,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, hdr_skb->len);
+ (unsigned int)meta->dmaaddr, hdr_skb->len);
return -ENOMEM;
}
@@ -742,7 +742,7 @@ static int dma_tx_fragment(struct bcm43x
dev_kfree_skb_irq(hdr_skb);
printk(KERN_ERR PFX ">>>FATAL ERROR<<< DMA TX SKB >1G "
"(0x%08x, len: %u)\n",
- meta->dmaaddr, skb->len);
+ (unsigned int)meta->dmaaddr, skb->len);
return -ENOMEM;
}
--
Greetings Michael.
^ permalink raw reply related
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Stefan Rompf @ 2006-06-04 10:14 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606041002.33696.IvDoorn@gmail.com>
Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
> Except for the bluetooth radio key (which should be supported by the
> radiobtn interface as well) the other buttons have support through already
> excisting input devices if I am correct.
You are wrong for quite a bunch of laptop models. That's why I pointed you to
the wistron_btns driver. Alternatively, look at the acerhk driver
(http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
number of additional buttons that need to be handled by a special driver, all
sent to userspace, and just one of them to trigger the wireless card. Other
models just handle the button in ACPI and generate an additional ACPI event.
Looking at the RT2400-driver, I see what you want to accomplish: Take the view
of the WLAN card on the hardware controlled button enable/disable and
generate events on it. However, in many cases it is another driver (see
above) that sets or clears this state, and this should be the instance to
send the input event.
Note that I do not have objections against the driver being included in the
kernel - it just does not qualify as generic radiobutton support, but I know
it's hard to find a good name ;-)
Looking at the code only: There should be an additional non-polling interface
for drivers that can generate events on the own.
Stefan
^ permalink raw reply
* Re: [RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
From: Ivo van Doorn @ 2006-06-04 11:44 UTC (permalink / raw)
To: Stefan Rompf; +Cc: Francois Romieu, netdev, rt2400-devel
In-Reply-To: <200606041214.45999.stefan@loplof.de>
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
On Sunday 4 June 2006 12:14, Stefan Rompf wrote:
> Am Sonntag 04 Juni 2006 10:02 schrieb Ivo van Doorn:
>
> > Except for the bluetooth radio key (which should be supported by the
> > radiobtn interface as well) the other buttons have support through already
> > excisting input devices if I am correct.
>
> You are wrong for quite a bunch of laptop models. That's why I pointed you to
> the wistron_btns driver. Alternatively, look at the acerhk driver
> (http://www2.informatik.hu-berlin.de/~tauber/acerhk/). Many systems have a
> number of additional buttons that need to be handled by a special driver, all
> sent to userspace, and just one of them to trigger the wireless card. Other
> models just handle the button in ACPI and generate an additional ACPI event.
Ok, indeed a valid point.
Would it be better when the radio_button structure contains a list
of button structures each with its own poll function and current state.
And the radiobtn will loop through the list after each poll_delay time calling
all poll functions. That way drivers can specify themselves which buttons need to be polled.
By renaming enable_radio and disable_radio in the radiobtn structure it could
be made more generic for sending a certain event to the device and not only
an instruction for the radio.
> Looking at the RT2400-driver, I see what you want to accomplish: Take the view
> of the WLAN card on the hardware controlled button enable/disable and
> generate events on it. However, in many cases it is another driver (see
> above) that sets or clears this state, and this should be the instance to
> send the input event.
>
> Note that I do not have objections against the driver being included in the
> kernel - it just does not qualify as generic radiobutton support, but I know
> it's hard to find a good name ;-)
Thats true. :)
Now lets see how this thing can be made a but more generic. ;)
> Looking at the code only: There should be an additional non-polling interface
> for drivers that can generate events on the own.
Welll if the enable_radio and disable_radio are being renamed to a more
generic send_event for sending an event to the driver or something,
something similar can be done for the other way around I think, another handler
to send an event from driver to radiobtn. But should such an event also trigger
a call back to the driver, or should only the input event be triggered?
Ivo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
From: Meelis Roos @ 2006-06-04 12:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <44804379.60808@trash.net>
> Please enable DEBUG_IP_FIREWALL_USER in net/netfilter/x_tables.c as well
> and retry. Results of the raw or mangle table would also be interesting
> because they contain a different number of built-in chains.
Sorry it took so long, I was away. Adding this define does not seem to
do much (table->private->number prints only):
On boot (1 nat rule):
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack
translate_table: size 632
Finished chain 0
Finished chain 3
Finished chain 4
table->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cba528d4
modprobe iptable_nat succeeded in manual modprobe.
modprobe iptable_filter:
translate_table: size 632
Bad offset cbbd910c
modprobe iptable_mangle:
translate_table: size 936
Bad offset cbbd80dc
modprobe iptable_raw:
translate_table: size 480
Bad offset cb8abd44
Retrying ifup and ifdown that tried to do iptables -D and iptables -I:
t->private->number = 4
t->private->number = 4
t->private->number = 4
translate_table: size 800
Bad offset cbbd80dc
t->private->number = 4
And retrying it more (succeeded this time):
t->private->number = 4
t->private->number = 4
translate_table: size 800
Finished chain 0
Finished chain 3
Finished chain 4
ip_tables: Translated table
do_replace: oldnum=4, initnum=4, newnum=5
t->private->number = 5
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: OLPC (One Laptop Per Child) Developer's program.
From: Anand Kumria @ 2006-06-04 13:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <1149335345.5053.177.camel@pmac.infradead.org>
On Sat, 03 Jun 2006 12:49:05 +0100, David Woodhouse wrote:
> On Tue, 2006-05-30 at 17:42 -0400, Jim Gettys wrote:
>> As you know, we've said we were going to have a developer's program. You
>> can find more information, including how to apply for boards at:
>>
>> http://wiki.laptop.org/index.php/Developers_Program
>>
>> Note that these are bare PC prototype boards, not packaged machines.
>> Jim Gettys
>
> ObNetdev:
>
> One thing we really need is NAT-PT or an equivalent for allowing access
> to the Legacy Internet from IPv6-only hosts. As soon as I finish playing
> with JFFS2 improvements, I plan to start looking at that.
Wouldn't miredo mostly fit the bill? It won't get through Symmetric NATs
(by design) but those are supposed to be uncommon.
Cheers,
Anand
^ permalink raw reply
* PATCH SB1250 NAPI support
From: Tom Rix @ 2006-06-04 16:45 UTC (permalink / raw)
To: tbm, jgarzik, netdev, linux-mips, mark.e.mason, trix@specifix.com
In-Reply-To: <20060525133505.GH8746@deprecation.cyrius.com>
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
A while ago I submitted this patch for NAPI support for SB1250 / SB1480.
I have tested it again on the recent (6/3/06) linux-mips kernel.
Tom
Below is the original posting.
This patch adds NAPI support for the Broadcom Sibyte SB1xxx family. The
changes are limited to adding a new config key SBMAC_NAPI to the drivers/
net/Kconfig and by adding the poll op and interrupt support to drivers/
net/sb1250-mac.c.
This patch also has a fix to drivers/net/sb1250-mac.c, the dma descriptor
table ptr is allocated, aligned and the aligned ptr is freed. If the ptr
was not already aligned (usually is) then the free would not work of what
was returned by the kmalloc. A variable was added to store the unaligned
pointer so that it could be properly freed.
I have tested this patch on a BCM91250A-SWARM Pass 2 / An.
Mark Mason from Broadcom was very helpful and tested this patch on at
least a 1480.
Tom
On Thu, 25 May 2006 08:35:05 -0500, Martin Michlmayr <tbm@cyrius.com>
wrote:
> * Tom Rix <trix@specifix.com> [2006-05-25 08:06]:
>> I am busy now but will get to it sometime.
>> It will require retesting with the latest kernel source.
>> Is there a particular maintainer(s) that I should cc on this patch?
>
> jgarzik@pobox.com
>
> He just reminded people that the merge window for 2.6.18 will open
> soon (and that he's collecting patches for that already) so now would
> be an excellent time.
>
> Thanks.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
[-- Attachment #2: mips-sb1250-mac-NAPI-3.patch --]
[-- Type: application/octet-stream, Size: 10804 bytes --]
diff -rup a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig 2006-03-09 04:25:38.000000000 -0600
+++ b/drivers/net/Kconfig 2006-03-09 05:30:48.000000000 -0600
@@ -2008,10 +2008,6 @@ config R8169_NAPI
If in doubt, say N.
-config NET_SB1250_MAC
- tristate "SB1250 Ethernet support"
- depends on SIBYTE_SB1xxx_SOC
-
config R8169_VLAN
bool "VLAN support"
depends on R8169 && VLAN_8021Q
@@ -2021,6 +2017,27 @@ config R8169_VLAN
If in doubt, say Y.
+config NET_SB1250_MAC
+ tristate "SB1250 Ethernet support"
+ depends on SIBYTE_SB1xxx_SOC
+
+config SBMAC_NAPI
+ bool "Use Rx Polling (NAPI) (EXPERIMENTAL)"
+ depends on NET_SB1250_MAC && EXPERIMENTAL
+ help
+ NAPI is a new driver API designed to reduce CPU and interrupt load
+ when the driver is receiving lots of packets from the card. It is
+ still somewhat experimental and thus not yet enabled by default.
+
+ If your estimated Rx load is 10kpps or more, or if the card will be
+ deployed on potentially unfriendly networks (e.g. in a firewall),
+ then say Y here.
+
+ See <file:Documentation/networking/NAPI_HOWTO.txt> for more
+ information.
+
+ If in doubt, say y.
+
config SIS190
tristate "SiS190/SiS191 gigabit ethernet support"
depends on PCI
diff -rup a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c
--- a/drivers/net/sb1250-mac.c 2006-03-09 04:25:41.000000000 -0600
+++ b/drivers/net/sb1250-mac.c 2006-03-09 05:30:52.000000000 -0600
@@ -209,6 +209,7 @@ typedef struct sbmacdma_s {
* This stuff is for maintenance of the ring
*/
+ sbdmadscr_t *sbdma_dscrtable_unaligned;
sbdmadscr_t *sbdma_dscrtable; /* base of descriptor table */
sbdmadscr_t *sbdma_dscrtable_end; /* end of descriptor table */
@@ -291,8 +292,8 @@ static int sbdma_add_rcvbuffer(sbmacdma_
static int sbdma_add_txbuffer(sbmacdma_t *d,struct sk_buff *m);
static void sbdma_emptyring(sbmacdma_t *d);
static void sbdma_fillring(sbmacdma_t *d);
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d);
-static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d);
+static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll);
+static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll);
static int sbmac_initctx(struct sbmac_softc *s);
static void sbmac_channel_start(struct sbmac_softc *s);
static void sbmac_channel_stop(struct sbmac_softc *s);
@@ -313,6 +314,10 @@ static struct net_device_stats *sbmac_ge
static void sbmac_set_rx_mode(struct net_device *dev);
static int sbmac_mii_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static int sbmac_close(struct net_device *dev);
+#if defined (CONFIG_SBMAC_NAPI)
+static int sbmac_poll(struct net_device *poll_dev, int *budget);
+#endif
+
static int sbmac_mii_poll(struct sbmac_softc *s,int noisy);
static int sbmac_mii_probe(struct net_device *dev);
@@ -740,7 +745,7 @@ static void sbdma_initctx(sbmacdma_t *d,
d->sbdma_maxdescr = maxdescr;
- d->sbdma_dscrtable = (sbdmadscr_t *)
+ d->sbdma_dscrtable_unaligned = d->sbdma_dscrtable = (sbdmadscr_t *)
kmalloc((d->sbdma_maxdescr+1)*sizeof(sbdmadscr_t), GFP_KERNEL);
/*
@@ -782,7 +787,6 @@ static void sbdma_initctx(sbmacdma_t *d,
d->sbdma_int_timeout = 0;
}
#endif
-
}
/**********************************************************************
@@ -1150,13 +1154,14 @@ static void sbdma_fillring(sbmacdma_t *d
* nothing
********************************************************************* */
-static void sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d)
+static int sbdma_rx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll)
{
int curidx;
int hwidx;
sbdmadscr_t *dsc;
struct sk_buff *sb;
int len;
+ int work_done = 0;
for (;;) {
/*
@@ -1234,8 +1239,15 @@ static void sbdma_rx_process(struct sbma
sb->ip_summed = CHECKSUM_NONE;
}
}
-
+
+#if defined(CONFIG_SBMAC_NAPI)
+ if (0 == poll)
+ netif_rx(sb);
+ else
+ netif_receive_skb(sb);
+#else
netif_rx(sb);
+#endif
}
} else {
/*
@@ -1252,8 +1264,9 @@ static void sbdma_rx_process(struct sbma
*/
d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
-
+ work_done++;
}
+ return work_done;
}
@@ -1275,15 +1288,22 @@ static void sbdma_rx_process(struct sbma
* nothing
********************************************************************* */
-static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d)
+static void sbdma_tx_process(struct sbmac_softc *sc,sbmacdma_t *d, int poll)
{
int curidx;
int hwidx;
sbdmadscr_t *dsc;
struct sk_buff *sb;
unsigned long flags;
+ int packets_handled = 0;
spin_lock_irqsave(&(sc->sbm_lock), flags);
+
+ if (d->sbdma_remptr == d->sbdma_addptr)
+ goto end_unlock;
+
+ hwidx = (int) (((__raw_readq(d->sbdma_curdscr) & M_DMA_CURDSCR_ADDR) -
+ d->sbdma_dscrtable_phys) / sizeof(sbdmadscr_t));
for (;;) {
/*
@@ -1298,15 +1318,12 @@ static void sbdma_tx_process(struct sbma
*/
curidx = d->sbdma_remptr - d->sbdma_dscrtable;
- hwidx = (int) (((__raw_readq(d->sbdma_curdscr) & M_DMA_CURDSCR_ADDR) -
- d->sbdma_dscrtable_phys) / sizeof(sbdmadscr_t));
/*
* If they're the same, that means we've processed all
* of the descriptors up to (but not including) the one that
* the hardware is working on right now.
*/
-
if (curidx == hwidx)
break;
@@ -1337,6 +1354,7 @@ static void sbdma_tx_process(struct sbma
d->sbdma_remptr = SBDMA_NEXTBUF(d,sbdma_remptr);
+ packets_handled++;
}
/*
@@ -1344,15 +1362,15 @@ static void sbdma_tx_process(struct sbma
* Other drivers seem to do this when we reach a low
* watermark on the transmit queue.
*/
+
+ if (packets_handled)
+ netif_wake_queue(d->sbdma_eth->sbm_dev);
- netif_wake_queue(d->sbdma_eth->sbm_dev);
-
+ end_unlock:
spin_unlock_irqrestore(&(sc->sbm_lock), flags);
}
-
-
/**********************************************************************
* SBMAC_INITCTX(s)
*
@@ -1396,7 +1414,6 @@ static int sbmac_initctx(struct sbmac_so
* Initialize the DMA channels. Right now, only one per MAC is used
* Note: Only do this _once_, as it allocates memory from the kernel!
*/
-
sbdma_initctx(&(s->sbm_txdma),s,0,DMA_TX,SBMAC_MAX_TXDESCR);
sbdma_initctx(&(s->sbm_rxdma),s,0,DMA_RX,SBMAC_MAX_RXDESCR);
@@ -1420,9 +1437,9 @@ static int sbmac_initctx(struct sbmac_so
static void sbdma_uninitctx(struct sbmacdma_s *d)
{
- if (d->sbdma_dscrtable) {
- kfree(d->sbdma_dscrtable);
- d->sbdma_dscrtable = NULL;
+ if (d->sbdma_dscrtable_unaligned) {
+ kfree(d->sbdma_dscrtable_unaligned);
+ d->sbdma_dscrtable_unaligned = d->sbdma_dscrtable = NULL;
}
if (d->sbdma_ctxtable) {
@@ -1609,12 +1626,12 @@ static void sbmac_channel_start(struct s
#if defined(CONFIG_SIBYTE_BCM1x55) || defined(CONFIG_SIBYTE_BCM1x80)
__raw_writeq(M_MAC_RXDMA_EN0 |
- M_MAC_TXDMA_EN0, s->sbm_macenable);
+ M_MAC_TXDMA_EN0, s->sbm_macenable);
#elif defined(CONFIG_SIBYTE_SB1250) || defined(CONFIG_SIBYTE_BCM112X)
__raw_writeq(M_MAC_RXDMA_EN0 |
- M_MAC_TXDMA_EN0 |
- M_MAC_RX_ENABLE |
- M_MAC_TX_ENABLE, s->sbm_macenable);
+ M_MAC_TXDMA_EN0 |
+ M_MAC_RX_ENABLE |
+ M_MAC_TX_ENABLE, s->sbm_macenable);
#else
#error invalid SiByte MAC configuation
#endif
@@ -1624,15 +1641,15 @@ static void sbmac_channel_start(struct s
* Accept any TX interrupt and EOP count/timer RX interrupts on ch 0
*/
__raw_writeq(((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
- ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0), s->sbm_imr);
+ ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0),
+ s->sbm_imr);
#else
/*
* Accept any kind of interrupt on TX and RX DMA channel 0
*/
__raw_writeq((M_MAC_INT_CHANNEL << S_MAC_TX_CH0) |
- (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), s->sbm_imr);
+ (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), s->sbm_imr);
#endif
-
/*
* Enable receiving unicasts and broadcasts
*/
@@ -2067,7 +2084,6 @@ static irqreturn_t sbmac_intr(int irq,vo
* Read the ISR (this clears the bits in the real
* register, except for counter addr)
*/
-
isr = __raw_readq(sc->sbm_isr) & ~M_MAC_COUNTER_ADDR;
if (isr == 0)
@@ -2079,13 +2095,31 @@ static irqreturn_t sbmac_intr(int irq,vo
* Transmits on channel 0
*/
+#if defined(CONFIG_SBMAC_NAPI)
if (isr & (M_MAC_INT_CHANNEL << S_MAC_TX_CH0)) {
- sbdma_tx_process(sc,&(sc->sbm_txdma));
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 0);
}
/*
* Receives on channel 0
*/
+ if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
+ if (netif_rx_schedule_prep(dev))
+ {
+ __raw_writeq(0, sc->sbm_imr);
+ __netif_rx_schedule(dev);
+ }
+ else
+ {
+ sbdma_rx_process(sc,&(sc->sbm_rxdma), 0);
+ }
+ }
+#else
+ /* Non NAPI */
+
+ if (isr & (M_MAC_INT_CHANNEL << S_MAC_TX_CH0)) {
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 0);
+ }
/*
* It's important to test all the bits (or at least the
@@ -2105,8 +2139,9 @@ static irqreturn_t sbmac_intr(int irq,vo
if (isr & (M_MAC_INT_CHANNEL << S_MAC_RX_CH0)) {
- sbdma_rx_process(sc,&(sc->sbm_rxdma));
+ sbdma_rx_process(sc,&(sc->sbm_rxdma), 0);
}
+#endif
}
return IRQ_RETVAL(handled);
}
@@ -2405,7 +2440,10 @@ static int sbmac_init(struct net_device
dev->do_ioctl = sbmac_mii_ioctl;
dev->tx_timeout = sbmac_tx_timeout;
dev->watchdog_timeo = TX_TIMEOUT;
-
+#if defined(CONFIG_SBMAC_NAPI)
+ dev->poll = sbmac_poll;
+ dev->weight = 16;
+#endif
dev->change_mtu = sb1250_change_mtu;
/* This is needed for PASS2 for Rx H/W checksum feature */
@@ -2818,7 +2856,37 @@ static int sbmac_close(struct net_device
return 0;
}
+#if defined(CONFIG_SBMAC_NAPI)
+static int sbmac_poll(struct net_device *dev, int *budget)
+{
+ int work_to_do;
+ int work_done;
+ struct sbmac_softc *sc = netdev_priv(dev);
+
+ work_to_do = min(*budget, dev->quota);
+ work_done = sbdma_rx_process(sc,&(sc->sbm_rxdma), 1);
+ sbdma_tx_process(sc,&(sc->sbm_txdma), 1);
+
+ *budget -= work_done;
+ dev->quota -= work_done;
+
+ if (work_done < work_to_do) {
+ netif_rx_complete(dev);
+
+#ifdef CONFIG_SBMAC_COALESCE
+ __raw_writeq(((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_TX_CH0) |
+ ((M_MAC_INT_EOP_COUNT | M_MAC_INT_EOP_TIMER) << S_MAC_RX_CH0),
+ sc->sbm_imr);
+#else
+ __raw_writeq((M_MAC_INT_CHANNEL << S_MAC_TX_CH0) |
+ (M_MAC_INT_CHANNEL << S_MAC_RX_CH0), sc->sbm_imr);
+#endif
+ }
+
+ return (work_done >= work_to_do);
+}
+#endif
#if defined(SBMAC_ETH0_HWADDR) || defined(SBMAC_ETH1_HWADDR) || defined(SBMAC_ETH2_HWADDR) || defined(SBMAC_ETH3_HWADDR)
static void
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: John Que @ 2006-06-04 16:29 UTC (permalink / raw)
To: Oliver Neukum
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606040025.32275.oliver@neukum.org>
Hello,
I must confess I don't know much about the ZyDas driver and the rewrite
dirver, but folliowing this post I looked a bit at the code (of both
zd1211 and the rewrite version) and I have a little question; this may
be
seen as a (little) off topic but I will be happy if somebody will
raise this coin.
I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
file zd1205.c; grepping for request_irq() in the rewrite driver yields
no results.
(I looked at the rewrite version from a week ago but in this point it
is probably the
same).
Why is this so ? I assume that the softmac layer does not call request_irq() on
behalf of the driver because this is not supposed to be like it, as I understand
its functionality. Can anybody briefly calrify this point ?
Regards,
John
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Samstag, 3. Juni 2006 21:35 schrieb Daniel Drake:
> > Oliver Neukum wrote:
> > > +static int read_mac_addr(struct zd_chip *chip, u8 *mac_addr)
> > > +{
> > > + static const zd_addr_t addr[2] = { CR_MAC_ADDR_P1, CR_MAC_ADDR_P2 };
> > > + return _read_mac_addr(chip, mac_addr, (const zd_addr_t *)addr);
> > > +}
> > >
> > > Why on the stack?
> >
> > Technically it's not on the stack because it is static const (it goes in
> > rodata), but I don't think that this invalidates your point. What's the
> > alternative? kmalloc and kfree every time?
>
> In this case rodata will work. However, if you ever switch to direct DMA
> it will fail. I really did overlook the const keyword.
>
> [..]
> > > +static void disconnect(struct usb_interface *intf)
> > > This is racy. It allows io to disconnected devices. You must take the
> > > lock and set a flag that you test after you've taken the lock elsewhere.
> >
> > Will fix, thanks.
>
> You're welcome
>
> Regards
> Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-04 17:17 UTC (permalink / raw)
To: John Que
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606040929p7a6ea69aw9488a75d611b23e5@mail.gmail.com>
Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> file zd1205.c; grepping for request_irq() in the rewrite driver yields
> no results.
> (I looked at the rewrite version from a week ago but in this point it
> is probably the
> same).
> Why is this so ? I assume that the softmac layer does not call request_irq() on
> behalf of the driver because this is not supposed to be like it, as I understand
> its functionality. Can anybody briefly calrify this point ?
A USB driver never will request an irq. Interrupt handling is done in
the core usb layer. Individual drivers have no business there.
Regards
Oliver
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Rami Rosen @ 2006-06-04 18:03 UTC (permalink / raw)
To: Oliver Neukum
Cc: John Que, Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606041917.55496.oliver@neukum.org>
Hi,
While I did not yet review fully the code , I saw some definitions
which are not in use. (more than 150 such definitions, in one file) I
think it may be better to remove this #define statements to make the
code more readable. In case there will be a need in the future, the needed
#define statements can be returned.
The definitions which are not in use are from zd_chip.h.
It is mentioned there that these definitions are taken from the ZYDAS
driver and not all of them are relevant for the rewrite driver;
however, it seems to me that
removing them may be thought of.
Anyhow you did a great job and I hope I will find time to really delve
into the code.
The definitions I am talking about are: (see zd_chip.h)
CR_RF_IF_CLK
CR_RF_IF_DATA
CR_PE1_PE2
CR_PE2_DLY
CR_LE1
CR_LE2
CR_RADIO_PD
CR_RF2948_PD
CR_ENABLE_PS_MANUAL_AGC
CR_SA2400_SER_AP
CR_I2C_WRITE
CR_SA2400_SER_RP
CR_RADIO_PE
CR_RST_BUS_MASTER
CR_HSTSCHG
CR_PHY_ON
CR_RX_DELAY
CR_GPIO_1
CR_GPIO_2
CR_EncryBufMux
CR_MAC_PS_STATE
INT_TX_COMPLETE
INT_RX_COMPLETE
INT_RETRY_FAIL
INT_WAKEUP
INT_DTIM_NOTIFY
INT_CFG_NEXT_BCN
INT_BUS_ABORT
INT_TX_FIFO_READY
INT_UART
INT_TX_COMPLETE_EN
INT_RX_COMPLETE_EN
INT_RETRY_FAIL_EN
INT_WAKEUP_EN
INT_DTIM_NOTIFY_EN
INT_CFG_NEXT_BCN_EN
INT_BUS_ABORT_EN
INT_TX_FIFO_READY_EN
INT_UART_EN
CR_TSF_LOW_PART
CR_TSF_HIGH_PART
CR_UART_RBR_THR_DLL
CR_UART_DLM_IER
CR_UART_IIR_FCR
CR_UART_LCR
CR_UART_MCR
CR_UART_LSR
CR_UART_MSR
CR_UART_ECR
CR_UART_STATUS
CR_PCI_TX_ADDR_P1
CR_PCI_TX_AddR_P2
CR_PCI_RX_AddR_P1
CR_PCI_RX_AddR_P2
CR_BSSID_P1
CR_BSSID_P2
CR_RX_TIMEOUT
CR_RATE_9M
CR_RATE_18M
CR_RATE_36M
CR_RATE_48M
CR_RATE_54M
CR_RX_OFFSET
CR_PHY_DELAY
CR_BCN_FIFO
CR_DEVICE_STATE
CR_UNDERRUN_CNT
CR_BCN_FIFO_SEMAPHORE
CR_IFS_VALUE
CR_RX_TIME_OUT
CR_TOTAL_RX_FRM
CR_CRC32_CNT
CR_CRC16_CNT
CR_DECRYPTION_ERR_UNI
CR_RX_FIFO_OVERRUN
CR_DECRYPTION_ERR_MUL
CR_NAV_CNT
CR_NAV_CCA
CR_RETRY_CNT
CR_READ_TCB_ADDR
CR_READ_RFD_ADDR
CR_TOTAL_TX_FRM
CR_CAM_MODE
CR_CAM_ROLL_TB_LOW
CR_CAM_ROLL_TB_HIGH
CR_CAM_ADDRESS
CR_CAM_DATA
CR_ROMDIR
CR_DECRY_ERR_FLG_LOW
CR_DECRY_ERR_FLG_HIGH
CR_WEPKEY0
CR_WEPKEY1
CR_WEPKEY2
CR_WEPKEY3
CR_WEPKEY4
CR_WEPKEY5
CR_WEPKEY6
CR_WEPKEY7
CR_WEPKEY8
CR_WEPKEY9
CR_WEPKEY10
CR_WEPKEY11
CR_WEPKEY12
CR_WEPKEY13
CR_WEPKEY14
CR_WEPKEY15
CR_TKIP_MODE
CR_EEPROM_PROTECT0
CR_EEPROM_PROTECT1
CR_DBG_FIFO_RD
CR_DBG_SELECT
CR_FIFO_Length
CR_RSSI_MGC
CR_PON
CR_RX_ON
CR_TX_ON
CR_CHIP_EN
CR_LO_SW
CR_TXRX_SW
CR_S_MD
CR_USB_DEBUG_PORT
STA_RX_FILTER
E2P_PWR_CAL_VALUE2
E2P_PWR_CAL_VALUE3
E2P_PWR_CAL_VALUE4
E2P_PWR_INT_VALUE2
E2P_PWR_INT_VALUE3
E2P_PWR_INT_VALUE4
E2P_ALLOWED_CHANNEL
E2P_DEVICE_VER
E2P_36M_CAL_VALUE2
E2P_36M_CAL_VALUE3
E2P_36M_CAL_VALUE4
E2P_11A_INT_VALUE1
E2P_11A_INT_VALUE2
E2P_11A_INT_VALUE3
E2P_11A_INT_VALUE4
E2P_48M_CAL_VALUE2
E2P_48M_CAL_VALUE3
E2P_48M_CAL_VALUE4
E2P_48M_INT_VALUE1
E2P_48M_INT_VALUE2
E2P_48M_INT_VALUE3
E2P_48M_INT_VALUE4
E2P_54M_CAL_VALUE2
E2P_54M_CAL_VALUE3
E2P_54M_CAL_VALUE4
E2P_54M_INT_VALUE1
E2P_54M_INT_VALUE2
E2P_54M_INT_VALUE3
E2P_54M_INT_VALUE4
FW_SOFT_RESET
FW_FLASH_CHK
Regards,
Rami Rosen
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> > file zd1205.c; grepping for request_irq() in the rewrite driver yields
> > no results.
> > (I looked at the rewrite version from a week ago but in this point it
> > is probably the
> > same).
> > Why is this so ? I assume that the softmac layer does not call request_irq() on
> > behalf of the driver because this is not supposed to be like it, as I understand
> > its functionality. Can anybody briefly calrify this point ?
>
> A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
>
> Regards
> Oliver
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: John Que @ 2006-06-04 18:22 UTC (permalink / raw)
To: Oliver Neukum
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <200606041917.55496.oliver@neukum.org>
Hello Oliver,
I am sorry, but I think I don't understand ,
You said:
>A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
but in the zd1211 driver (not the rewrite version) I found this
call to request an irq:
request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev)
Also when looking in the linux tree, I see some request_irq() calls in USB
drivers, for exmaple in some drivers under usb/gadgaets, and more.
Can you please elaborate a bit ? What do you mean by saying
"A USB driver never will request an irq"?
-- John
On 6/4/06, Oliver Neukum <oliver@neukum.org> wrote:
> Am Sonntag, 4. Juni 2006 18:29 schrieb John Que:
> > I had noticed that the zd1211 driver does call request_irq() in zd1205_open(),
> > file zd1205.c; grepping for request_irq() in the rewrite driver yields
> > no results.
> > (I looked at the rewrite version from a week ago but in this point it
> > is probably the
> > same).
> > Why is this so ? I assume that the softmac layer does not call request_irq() on
> > behalf of the driver because this is not supposed to be like it, as I understand
> > its functionality. Can anybody briefly calrify this point ?
>
> A USB driver never will request an irq. Interrupt handling is done in
> the core usb layer. Individual drivers have no business there.
>
> Regards
> Oliver
>
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
From: Oliver Neukum @ 2006-06-04 19:06 UTC (permalink / raw)
To: John Que
Cc: Daniel Drake, linux-usb-devel, John W. Linville, netdev,
Ulrich Kunitz
In-Reply-To: <ada605fb0606041122w36ad8320wa0a5d8241c98644c@mail.gmail.com>
Am Sonntag, 4. Juni 2006 20:22 schrieb John Que:
> Hello Oliver,
>
> I am sorry, but I think I don't understand ,
> You said:
> >A USB driver never will request an irq. Interrupt handling is done in
> > the core usb layer. Individual drivers have no business there.
>
> but in the zd1211 driver (not the rewrite version) I found this
> call to request an irq:
> request_irq(dev->irq, &zd1205_intr, SA_SHIRQ, dev->name, dev)
>
> Also when looking in the linux tree, I see some request_irq() calls in USB
> drivers, for exmaple in some drivers under usb/gadgaets, and more.
>
> Can you please elaborate a bit ? What do you mean by saying
> "A USB driver never will request an irq"?
The architecture is as follows:
device driver <---> USB core <---> host driver <=== USB ===> gadget driver <---> function driver
Only those drivers that deal with the hardware directly request interrupts.
A device driver submits URBs and deals with callbacks.
Regards
Oliver
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox