Re: kernel oops with 2.6.32-rc2
2009/10/9 Celejar cele...@gmail.com: Oct 8 18:46:17 localhost kernel: [24031.297304] BUG: unable to handle kernel paging request at 2f40666a Oct 8 18:46:17 localhost kernel: [24031.297312] IP: [f8b1e5a3] b43_leds_unregister+0x13/0xa0 [b43] Already noticed and fixed: https://lists.berlios.de/pipermail/bcm43xx-dev/2009-October/006129.html Michael didn't specify in mail for which kernel is that patch, but I believe it'll hit 2.6.32-rc4 -- Rafał ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Broadcom cards for free
Hi, I've currently got two Broadcom cards to offer for free. http://bu3sch.de/misc/bcmcards.JPG The cardbus one is a WPC300N V1 802.11n card. It can be used for development of the b43 N-PHY code. The USB one is BCM4320 which works over RNDIS-WLAN. This device is disassembled and the EEPROM, which contains the on-board operating system, is unsoldered and connected through a pinheader. That means it can be read and/or reprogrammed outside of the device. The RF-shield on the RF-side of the board was removed. The device should work properly. It properly registers to the kernel, but I did not try if it works with the rndis-wlan driver. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom cards for free
Sounds interesting... especially now that N-PHY is actually being reverse-engineered (or is it?). The modded 4320 is an attempt to replace the built-in OS and use it with b43 as a softmac device... am I right? On 10/9/09, Michael Buesch m...@bu3sch.de wrote: Hi, I've currently got two Broadcom cards to offer for free. http://bu3sch.de/misc/bcmcards.JPG The cardbus one is a WPC300N V1 802.11n card. It can be used for development of the b43 N-PHY code. The USB one is BCM4320 which works over RNDIS-WLAN. This device is disassembled and the EEPROM, which contains the on-board operating system, is unsoldered and connected through a pinheader. That means it can be read and/or reprogrammed outside of the device. The RF-shield on the RF-side of the board was removed. The device should work properly. It properly registers to the kernel, but I did not try if it works with the rndis-wlan driver. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom cards for free
On Friday 09 October 2009 12:14:24 Gábor Stefanik wrote: Sounds interesting... especially now that N-PHY is actually being reverse-engineered (or is it?). I don't know if somebody is working on it, but the card could be useful for somebody working on it. The modded 4320 is an attempt to replace the built-in OS and use it with b43 as a softmac device... am I right? No, it was used to read the EEPROM. There were no attempts to reverse-engineer and rewrite the EEPROM, however one can do that with this device. It contains about 300kb data, so it's probably hard to reverse engineer. However, I think there's no need to start over from zero, because most parts of the device should be known. They're most likely just running their portable driver kit on it. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add 'struct b43_wl' missing declaration
On Friday 09 October 2009 16:13:53 Miguel Boton wrote: 'struct b43_wl' declaration is missing at 'leds.h'. It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'. Signed-off-by: Miguel Botón mbo...@gmail.com ack (That was fast enough, eh? :D) --- drivers/net/wireless/b43/leds.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/b43/leds.h b/drivers/net/wireless/b43/leds.h index 4c56187..32b66d5 100644 --- a/drivers/net/wireless/b43/leds.h +++ b/drivers/net/wireless/b43/leds.h @@ -1,6 +1,7 @@ #ifndef B43_LEDS_H_ #define B43_LEDS_H_ +struct b43_wl; struct b43_wldev; #ifdef CONFIG_B43_LEDS -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: add 'struct b43_wl' missing declaration
On 10/09/2009 09:13 AM, Miguel Boton wrote: 'struct b43_wl' declaration is missing at 'leds.h'. It should be declared to avoid getting some GCC warnings at 'b43_leds_unregister'. Signed-off-by: Miguel Botón mbo...@gmail.com What architecture? There must be something strange with your configuration as I see no such warnings. Please post your .CONFIG. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Broken patch for b43
Hi, Unfortunately, my patch entitled 43: Fix PPC crash in rfkill polling on unload had more problems than a locking error. When you switch the RF off, you cannot turn the radio back on without unloading/reloading the module. I have an alternative fix for the PPC that is now being tested; however, it may just restrict the unload/load problem to older models. To know whether that is a possibility, I need to know if anyone has a G PHY device with PHY revision = 2 that also has an RFKILL switch. Note: LP PHYs (ID of 4315) will have such revisions, but they do not count. Thanks, Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broadcom cards for free
On 10/09/2009 05:14 AM, Gábor Stefanik wrote: Sounds interesting... especially now that N-PHY is actually being reverse-engineered (or is it?). I'm still working on it, although a lot of my time is taken in testing openSUSE 11.2 pre-release code. As the release date is Nov. 12, that will soon be over. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broken patch for b43
On 10/09/2009 10:41 AM, Gábor Stefanik wrote: G-PHY revision =2 is handled by b43legacy, not b43, so it shouldn't be a problem. I thought that was the case; however, the traceback on the PPC with the problem shows: NIP [c001bb6c] ioread16+0x8/0x18 LR [f1078610] ssb_pci_read16+0x30/0x68 [ssb] Call Trace: [ef87fec0] [f1076b58] ssb_device_enable+0xe0/0x118 [ssb] (unreliable) [ef87fed0] [f34c68e0] b43_is_hw_radio_enabled+0x60/0x74 [b43] [ef87fee0] [f34c693c] b43_rfkill_poll+0x48/0x134 [b43] It seems to me that the only way that b43_is_hw_radio_enabled gets to ssb_pci_read16 is with a call to b43_read16, and that implies phy.rev = 2. I have a request in to the OP on the bug to get the details of his device. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broken patch for b43
On Friday 09 October 2009 18:17:20 Larry Finger wrote: On 10/09/2009 10:41 AM, Gábor Stefanik wrote: G-PHY revision =2 is handled by b43legacy, not b43, so it shouldn't be a problem. That is not true. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: b43: do not stack-allocate pio rx/tx header and tail buffers (was: pull request: wireless-2.6 2009-10-08)
On Friday 09 October 2009 19:46:31 Albert Herranz wrote: I'm not arguing if the patch should have been immediately merged upstream or not without your ack (I'm probably more on your side here, as the patch was still being discussed on the ML). The patch [1] may not be up to your quality standards or may not take into account other requirements (that you have not expressed nor on the ML nor on IRC) but I'm sure it's far from being random, move crap or add stupid comments. That's the unfair part. The reason I posted the initial patch for review was because you kind of told me [2]. [20:06] mb_ Anyway, I'm not going to fix this. If you need it fixed, please send patches Yeah, but that doesn't mean that either hack is acceptable. It just means that my time is limited and I added this non-issue (which I still think it is) to the very bottom of my priority list. After ~22 hours if I'm not mistaken (yes, less than 24...) John, who had previously expressed his intentions to merge the patch [5], picked it for wireless-2.6. And a day later, more or less again, John did the GIT PULL request. My impression was, that if the maintainer rejects a patch and asks for a new version, the upstream maintainer must not take the patch until the maintainer acked the new version. It seems I was wrong, though. My point here is that there's no reason for such strong words concerning the quality of the patch code. It's really not that bad for such wording. I'm sure that if the patch was really crap it would have been immediately NAK'ed by you or by any sane maintainer. It _was_ immediately NAK'ed by me. I did not know that I need to NAK every single new version of a patch explicitely. I thought NAK-ing a patch would put it into some special state that only an explicit ACK could take it out of. -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43/legacy: Fix usage of host_pci pointer
We must check the bustype before using the host_pci pointer.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
This does not fix a bug, but is required for a future patch which puts
the pointer into a union.
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2009-10-09
18:47:03.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c2009-10-09
18:47:52.0 +0200
@@ -4671,7 +4671,7 @@ static int b43_wireless_core_attach(stru
{
struct b43_wl *wl = dev-wl;
struct ssb_bus *bus = dev-dev-bus;
- struct pci_dev *pdev = bus-host_pci;
+ struct pci_dev *pdev = (bus-bustype == SSB_BUSTYPE_PCI) ?
bus-host_pci : NULL;
int err;
bool have_2ghz_phy = 0, have_5ghz_phy = 0;
u32 tmp;
@@ -4804,7 +4804,7 @@ static int b43_one_core_attach(struct ss
if (!list_empty(wl-devlist)) {
/* We are not the first core on this chip. */
- pdev = dev-bus-host_pci;
+ pdev = (dev-bus-bustype == SSB_BUSTYPE_PCI) ?
dev-bus-host_pci : NULL;
/* Only special chips support more than one wireless
* core, although some of the other chips have more than
* one wireless core as well. Check for this and
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c 2009-10-09
18:47:03.0 +0200
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c 2009-10-09
18:47:52.0 +0200
@@ -3592,7 +3592,7 @@ static int b43legacy_wireless_core_attac
{
struct b43legacy_wl *wl = dev-wl;
struct ssb_bus *bus = dev-dev-bus;
- struct pci_dev *pdev = bus-host_pci;
+ struct pci_dev *pdev = (bus-bustype == SSB_BUSTYPE_PCI) ?
bus-host_pci : NULL;
int err;
int have_bphy = 0;
int have_gphy = 0;
@@ -3706,7 +3706,7 @@ static int b43legacy_one_core_attach(str
if (!list_empty(wl-devlist)) {
/* We are not the first core on this chip. */
- pdev = dev-bus-host_pci;
+ pdev = (dev-bus-bustype == SSB_BUSTYPE_PCI) ?
dev-bus-host_pci : NULL;
/* Only special chips support more than one wireless
* core, although some of the other chips have more than
* one wireless core as well. Check for this and
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] ssb: Put host pointers into a union
This slightly shrinks the structure.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/ssb/driver_pcicore.c
===
--- wireless-testing.orig/drivers/ssb/driver_pcicore.c 2008-07-20
12:09:34.0 +0200
+++ wireless-testing/drivers/ssb/driver_pcicore.c 2009-10-09
19:01:59.0 +0200
@@ -551,13 +551,13 @@ int ssb_pcicore_dev_irqvecs_enable(struc
might_sleep_if(pdev-id.coreid != SSB_DEV_PCI);
/* Enable interrupts for this device. */
- if (bus-host_pci
- ((pdev-id.revision = 6) || (pdev-id.coreid == SSB_DEV_PCIE))) {
+ if ((pdev-id.revision = 6) || (pdev-id.coreid == SSB_DEV_PCIE)) {
u32 coremask;
/* Calculate the coremask for the device. */
coremask = (1 dev-core_index);
+ SSB_WARN_ON(bus-bustype != SSB_BUSTYPE_PCI);
err = pci_read_config_dword(bus-host_pci, SSB_PCI_IRQMASK,
tmp);
if (err)
goto out;
Index: wireless-testing/include/linux/ssb/ssb.h
===
--- wireless-testing.orig/include/linux/ssb/ssb.h 2009-09-11
21:27:27.0 +0200
+++ wireless-testing/include/linux/ssb/ssb.h2009-10-09 19:10:42.0
+0200
@@ -269,7 +269,8 @@ struct ssb_bus {
const struct ssb_bus_ops *ops;
- /* The core in the basic address register window. (PCI bus only) */
+ /* The core currently mapped into the MMIO window.
+* Not valid on all host-buses. So don't use outside of SSB. */
struct ssb_device *mapped_device;
union {
/* Currently mapped PCMCIA segment. (bustype ==
SSB_BUSTYPE_PCMCIA only) */
@@ -281,14 +282,17 @@ struct ssb_bus {
* On PCMCIA-host busses this is used to protect the whole MMIO access.
*/
spinlock_t bar_lock;
- /* The bus this backplane is running on. */
+ /* The host-bus this backplane is running on. */
enum ssb_bustype bustype;
- /* Pointer to the PCI bus (only valid if bustype == SSB_BUSTYPE_PCI). */
- struct pci_dev *host_pci;
- /* Pointer to the PCMCIA device (only if bustype ==
SSB_BUSTYPE_PCMCIA). */
- struct pcmcia_device *host_pcmcia;
- /* Pointer to the SDIO device (only if bustype == SSB_BUSTYPE_SDIO). */
- struct sdio_func *host_sdio;
+ /* Pointers to the host-bus. Check bustype before using any of these
pointers. */
+ union {
+ /* Pointer to the PCI bus (only valid if bustype ==
SSB_BUSTYPE_PCI). */
+ struct pci_dev *host_pci;
+ /* Pointer to the PCMCIA device (only if bustype ==
SSB_BUSTYPE_PCMCIA). */
+ struct pcmcia_device *host_pcmcia;
+ /* Pointer to the SDIO device (only if bustype ==
SSB_BUSTYPE_SDIO). */
+ struct sdio_func *host_sdio;
+ };
/* See enum ssb_quirks */
unsigned int quirks;
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Optimize PIO scratchbuffer usage
This optimizes the PIO scratchbuffer usage.
Signed-off-by: Michael Buesch m...@bu3sch.de
---
Index: wireless-testing/drivers/net/wireless/b43/b43.h
===
--- wireless-testing.orig/drivers/net/wireless/b43/b43.h2009-10-09
19:50:15.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/b43.h 2009-10-09
20:15:41.0 +0200
@@ -749,12 +749,6 @@ struct b43_wldev {
#endif
};
-/*
- * Include goes here to avoid a dependency problem.
- * A better fix would be to integrate xmit.h into b43.h.
- */
-#include xmit.h
-
/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
struct b43_wl {
/* Pointer to the active wireless device on this chip */
@@ -830,13 +824,9 @@ struct b43_wl {
struct b43_leds leds;
#ifdef CONFIG_B43_PIO
- /*
-* RX/TX header/tail buffers used by the frame transmit functions.
-*/
- struct b43_rxhdr_fw4 rxhdr;
- struct b43_txhdr txhdr;
- u8 rx_tail[4];
- u8 tx_tail[4];
+ /* Kmalloc'ed scratch space for PIO TX/RX. Protected by wl-mutex. */
+ u8 pio_scratchspace[110] __attribute__((__aligned__(8)));
+ u8 pio_tailspace[4] __attribute__((__aligned__(8)));
#endif /* CONFIG_B43_PIO */
};
Index: wireless-testing/drivers/net/wireless/b43/pio.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/pio.c2009-10-09
19:50:15.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/pio.c 2009-10-09
20:15:41.0 +0200
@@ -341,12 +341,15 @@ static u16 tx_write_2byte_queue(struct b
q-mmio_base + B43_PIO_TXDATA,
sizeof(u16));
if (data_len 1) {
+ u8 *tail = wl-pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl-pio_tailspace) 2);
+
/* Write the last byte. */
ctl = ~B43_PIO_TXCTL_WRITEHI;
b43_piotx_write16(q, B43_PIO_TXCTL, ctl);
- wl-tx_tail[0] = data[data_len - 1];
- wl-tx_tail[1] = 0;
- ssb_block_write(dev-dev, wl-tx_tail, 2,
+ tail[0] = data[data_len - 1];
+ tail[1] = 0;
+ ssb_block_write(dev-dev, tail, 2,
q-mmio_base + B43_PIO_TXDATA,
sizeof(u16));
}
@@ -392,27 +395,27 @@ static u32 tx_write_4byte_queue(struct b
q-mmio_base + B43_PIO8_TXDATA,
sizeof(u32));
if (data_len 3) {
- wl-tx_tail[3] = 0;
+ u8 *tail = wl-pio_tailspace;
+ BUILD_BUG_ON(sizeof(wl-pio_tailspace) 4);
+
+ memset(tail, 0, 4);
/* Write the last few bytes. */
ctl = ~(B43_PIO8_TXCTL_8_15 | B43_PIO8_TXCTL_16_23 |
B43_PIO8_TXCTL_24_31);
switch (data_len 3) {
case 3:
ctl |= B43_PIO8_TXCTL_16_23 | B43_PIO8_TXCTL_8_15;
- wl-tx_tail[0] = data[data_len - 3];
- wl-tx_tail[1] = data[data_len - 2];
- wl-tx_tail[2] = data[data_len - 1];
+ tail[0] = data[data_len - 3];
+ tail[1] = data[data_len - 2];
+ tail[2] = data[data_len - 1];
break;
case 2:
ctl |= B43_PIO8_TXCTL_8_15;
- wl-tx_tail[0] = data[data_len - 2];
- wl-tx_tail[1] = data[data_len - 1];
- wl-tx_tail[2] = 0;
+ tail[0] = data[data_len - 2];
+ tail[1] = data[data_len - 1];
break;
case 1:
- wl-tx_tail[0] = data[data_len - 1];
- wl-tx_tail[1] = 0;
- wl-tx_tail[2] = 0;
+ tail[0] = data[data_len - 1];
break;
}
b43_piotx_write32(q, B43_PIO8_TXCTL, ctl);
@@ -455,6 +458,7 @@ static int pio_tx_frame(struct b43_pio_t
int err;
unsigned int hdrlen;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct b43_txhdr *txhdr = (struct b43_txhdr *)wl-pio_scratchspace;
B43_WARN_ON(list_empty(q-packets_list));
pack = list_entry(q-packets_list.next,
@@ -462,7 +466,9 @@ static int pio_tx_frame(struct b43_pio_t
cookie = generate_cookie(q, pack);
hdrlen = b43_txhdr_size(dev);
- err = b43_generate_txhdr(dev, (u8 *)wl-txhdr, skb,
+ BUILD_BUG_ON(sizeof(wl-pio_scratchspace) sizeof(struct b43_txhdr));
+ B43_WARN_ON(sizeof(wl-pio_scratchspace) hdrlen);
+ err = b43_generate_txhdr(dev, (u8 *)txhdr, skb,
info, cookie);
if (err)
[PATCH] b43: Remove me as maintainer
Remove me Signed-off-by: Michael Buesch m...@bu3sch.de --- A properly signed-off patch version... MAINTAINERS |1 - 1 file changed, 1 deletion(-) --- wireless-testing.orig/MAINTAINERS +++ wireless-testing/MAINTAINERS @@ -1066,7 +1066,6 @@ F:include/net/ax25.h F: net/ax25/ B43 WIRELESS DRIVER -M: Michael Buesch m...@bu3sch.de M: Stefano Brivio stefano.bri...@polimi.it L: linux-wirel...@vger.kernel.org W: http://linuxwireless.org/en/users/Drivers/b43 -- Greetings, Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Broken patch for b43
On Fri, Oct 9, 2009 at 6:22 PM, Michael Buesch m...@bu3sch.de wrote: On Friday 09 October 2009 18:17:20 Larry Finger wrote: On 10/09/2009 10:41 AM, Gábor Stefanik wrote: G-PHY revision =2 is handled by b43legacy, not b43, so it shouldn't be a problem. That is not true. -- Greetings, Michael. Oops... yes, I confused the PHY vs. MAC revisions. -- Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
