On Wednesday 24 March 2010 15:16:03 Larry Finger wrote:
I have modified ssb to supply a MAC address of 80:80:80:80:80:80, rather than
What about also setting the local-assignment bit for this temporary address?
The one remaining problem is that the interface has already been renamed
before
On Tuesday 23 March 2010 00:45:28 Larry Finger wrote:
(2) In drivers/ssb/pci.c, the firmware loading process reads the file, then
modifies it using the bus address.
No. You don't need firmware loading at all.
udev can just set the mac address through the standard ioctl calls.
Just like how
On Tuesday 23 March 2010 09:55:39 Florian Fainelli wrote:
Why not use random_ether_addr and only use the digits that you are interested
in?
Because it's not constant across reboots.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
On Tuesday 23 March 2010 21:58:22 Calvin Walton wrote:
On Tue, 2010-03-23 at 09:25 -0500, Larry Finger wrote:
Will someone please write me udev rule(s) that do the following:
1. Detect a MAC address of FF:FF:FF:FF:FF:FF
2. If this is the first time for this bus address, then generate a
On Monday 22 March 2010 07:28:23 Calvin Walton wrote:
Hi,
On Sat, 2010-03-20 at 19:14 -0500, Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a
On Monday 22 March 2010 22:56:44 Larry Finger wrote:
Does anyone have any suggestions on what characteristic could be used to
generate a unique MAC address for a box in a udev rule?
/dev/urandom
Yeah, there's the chance of clashes. In practice there won't be any clashes,
however. If you think
On Monday 22 March 2010 23:19:54 Larry Finger wrote:
On 03/22/2010 04:55 PM, Michael Buesch wrote:
I don't see a problem for udev to distinguish the cards. It can do it
merely on
the bus-ID. That's unique. Yeah, it might change if you change the hardware.
But do we care? I say
On Sunday 21 March 2010 01:14:51 Larry Finger wrote:
Some recent BCM43XX devices lack an on-board SPROM. The pertinent data
from the SPROM could be included in the kernel; however, this presents
a problem in the generation of a unique, reproducible MAC address. The
solution has been to create
On Thursday 18 March 2010 22:38:17 Larry Finger wrote:
On 03/18/2010 02:31 PM, Michael Buesch wrote:
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
(1) Modify b43-fwcutter to take data from an existing SPROM,
Why not extend the ssb-sprom tool? I don't think this has anything
On Thursday 18 March 2010 18:46:35 Larry Finger wrote:
(1) Modify b43-fwcutter to take data from an existing SPROM,
Why not extend the ssb-sprom tool? I don't think this has anything to do with
firmware, except that we (ab)use the firmware loading mechanism of the kernel
for loading the blob
On Saturday 13 March 2010 19:38:01 Gábor Stefanik wrote:
I know this one it is compatible with aircrack supporting injection
Thank you for your invaluable help ..
thank
As a general rule, do not bug Michael with injection-related
questions; the only one in the team who cares about
On Tuesday 02 March 2010 23:25:48 William Bourque wrote:
So if I get this right, this code is responsible of handling the b43
devices, as well as several other PCI-E devices, correct?
Nah, this is a broadcom specific thing of the on-chip SSB bus.
Because now that you mention this, the wired
On Monday 01 March 2010 01:22:50 Michael Buesch wrote:
Well, you are confusing address spaces here.
On a PCI based SSB device all host-side MMIO transfers go into
the PCI device's address space first. The core-switching moves the window of
the SSB address space that is mapped into 0-0xFFF
On Sunday 28 February 2010 02:37:21 Rafał Miłecki wrote:
W dniu 27 lutego 2010 15:51 użytkownik Michael Buesch m...@bu3sch.de
napisał:
On Saturday 27 February 2010 12:12:23 Rafał Miłecki wrote:
2010/2/10 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki
On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote:
2010/2/28 Rafał Miłecki zaj...@gmail.com:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
I confirm, it still crashes on my notebook as well.
On Sunday 28 February 2010 21:30:38 Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@bu3sch.de wrote:
It says 8k for all of my devices there. So an MMIO write to 0x2000
and above writes to completely random memory.
My BCM4312 device is 16K:
Region 0: Memory
On Monday 01 March 2010 00:38:16 Nathan Schulte wrote:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
The latest patch, which is a partial success according to some
testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon).
Then either I am misinterpreting the logs, or the last
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl sets
0x8000 in register 0x280a - an undocumented register.
Well, it is not only undocumented, it's also far
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB?
If so, you should really make
On Saturday 27 February 2010 12:12:23 Rafał Miłecki wrote:
2010/2/10 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote:
+#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state
machine */
The comment doesn't make a lot of sense
On Saturday 27 February 2010 12:09:30 Rafał Miłecki wrote:
2010/2/9 Michael Buesch m...@bu3sch.de:
On Tuesday 09 February 2010 21:04:40 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_common.c | 11 +++
drivers/net/wireless
On Saturday 27 February 2010 16:55:09 Larry Finger wrote:
On 02/27/2010 09:16 AM, Michael Buesch wrote:
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312
On Saturday 27 February 2010 20:45:50 Gábor Stefanik wrote:
2. Just before the SPROM readout, we are missing a Set 0x8000 in
MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous
Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and
indeed, the value read out from
PS is currently not supported on b43.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Friday 19 February 2010 16:40:40 Larry Finger wrote:
[8018c2d4] skb_put+0x74/0x90
[80c9a8e4] b43_dma_rx+0x338/0x444 [b43]
[80c87420] b43_controller_restart+0x7a0/0x974 [b43]
The traceback indicates a controller restart. Does your log show any reason
for
that event? That may help
On Friday 19 February 2010 21:28:01 Stefan Wahren wrote:
@Michael: Okay, is there any method to get more reliable information
about the kernel panic (strace, ...) or a idea to faster reproduce the
kernel panic than waiting?
I think the backtrace is pretty good as-is, if you ignore the
On Tuesday 09 February 2010 21:04:40 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_common.c | 11 +++
drivers/net/wireless/b43/phy_common.h |2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git
On Tuesday 09 February 2010 21:04:41 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_n.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c
On Tuesday 09 February 2010 21:04:33 Rafał Miłecki wrote:
+#define B43_MMIO_PSM_PHY_HDR 0x492 /* programmable state machine */
The comment doesn't make a lot of sense.
In case you don't know, the PSM is the part of the hardware
that executes the firmware.
--
Greetings, Michael.
On Sunday 07 February 2010 13:48:59 Rafał Miłecki wrote:
2010/2/7 strk s...@keybit.net:
On Sat, Feb 06, 2010 at 06:54:44PM -0600, Larry Finger wrote:
You can get the wireless-compat sources for kernel 2.6.26 and build that.
Othersise, go to kernel.org and get the full sources.
I opted
On Sunday 07 February 2010 14:18:43 Rafał Miłecki wrote:
So pressing something like Fn+FX can eventually be handled by BIOS and
can cause hardware (physical) enabling radio?
Yeah, could be the case. It could also be handled by another kernel driver
(wmi).
In no case will the wireless driver be
On Sunday 07 February 2010 15:09:05 Rafał Miłecki wrote:
W dniu 7 lutego 2010 14:22 użytkownik Michael Buesch m...@bu3sch.de napisał:
On Sunday 07 February 2010 14:18:43 Rafał Miłecki wrote:
So pressing something like Fn+FX can eventually be handled by BIOS and
can cause hardware (physical
On Sunday 07 February 2010 15:30:18 strk wrote:
On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote:
rfkill is a hardware lock in the case of broadcom. Software can only read
the state.
(There may be laptops with broadcom cards where rfkill can be changed by
software
On Sunday 07 February 2010 15:44:01 strk wrote:
On Sun, Feb 07, 2010 at 03:37:36PM +0100, Michael Buesch wrote:
On Sunday 07 February 2010 15:30:18 strk wrote:
On Sun, Feb 07, 2010 at 02:05:09PM +0100, Michael Buesch wrote:
rfkill is a hardware lock in the case of broadcom. Software
On Sunday 07 February 2010 15:59:53 strk wrote:
On Sun, Feb 07, 2010 at 03:48:07PM +0100, Michael Buesch wrote:
On Sunday 07 February 2010 15:44:01 strk wrote:
Ok, so supposedly here the situation can be on of these:
1) b43legacy driver is wrong while reading kill switch state
On Wednesday 03 February 2010 20:33:44 Larry Finger wrote:
If b43 or b43legacy are deauthenticated or disconnected, there is a
possibility that a reconnection is tried with the queues stopped in
mac80211. To prevent this, start the queues before setting
STAT_INITIALIZED.
In b43, a similar
On Monday 25 January 2010 18:59:59 Rafał Miłecki wrote:
+/* Complex number using 2 32-bit signed integers */
+typedef struct { s32 i, q; } b43_c32;
No typedef. ever.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Monday 25 January 2010 19:36:27 Rafał Miłecki wrote:
W dniu 25 stycznia 2010 19:35 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
2010/1/25 Michael Buesch m...@bu3sch.de:
On Monday 25 January 2010 18:59:59 Rafał Miłecki wrote:
+/* Complex number using 2 32-bit signed integers
to sleep, but we are not allowed
to sleep in the callback due to mac80211's RCU locking.
Signed-off-by: Michael Buesch m...@bu3sch.de
Tested-by: Larry Finger larry.fin...@lwfinger.net
Reported-by: ke...@kutfo.hit.bme.hu
Cc: Johannes Berg johan...@sipsolutions.net
Cc: stable sta...@kernel.org
On Saturday 23 January 2010 04:36:50 David Woodhouse wrote:
On Fri, 2010-01-22 at 20:16 -0500, John W. Linville wrote:
On Fri, Jan 22, 2010 at 11:33:40PM +0100, Michael Buesch wrote:
So while we are at it, I'd really like to migrate away from the berlios
list.
It's really just
On Friday 22 January 2010 21:47:03 Rafał Miłecki wrote:
As you can see I've used git send-email for submission this time! I've
no idea what I did wrong that patch 1/5 was sent incorrectly. I just
generated patches with
git format-patch --cover-letter -o b43
, then modified -...patch (ONLY
On Friday 22 January 2010 22:59:26 Michael Buesch wrote:
On Friday 22 January 2010 21:47:03 Rafał Miłecki wrote:
As you can see I've used git send-email for submission this time! I've
no idea what I did wrong that patch 1/5 was sent incorrectly. I just
generated patches with
git format
On Tuesday 19 January 2010 23:59:32 Rafał Miłecki wrote:
Out of curiosity, could someone tell what Opera does incorrectly when
sending patches?
They are base64 encoded.
We use a 7 or 8bit encoding for our mails.
I think that opera automatically switches to base64 encoding due to
the special
On Sunday 17 January 2010 17:37:29 Gábor Stefanik wrote:
While you are at it, why aren't you programming these table writes?
The table handling functions are AFAIK already in place...
Because we like small patches.
Please do _not_ increase the patchsize.
--
Greetings, Michael.
On Sunday 17 January 2010 23:37:50 Rafał Miłecki wrote:
@@ -1895,14 +1880,12 @@ static int b43_nphy_cal_tx_iq_lo(struct b43_wldev
*dev,
b43_phy_write(dev, B43_NPHY_IQLOCAL_CMDNNUM, tmp);
if (type == 1 || type == 3 || type == 4) {
-
On Thursday 14 January 2010 13:21:27 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/net/wireless/b43/phy_common.c | 14 ++
drivers/net/wireless/b43/phy_common.h |1 +
drivers/net/wireless/b43/phy_lp.c | 17 ++---
3
On Tuesday 12 January 2010 20:38:07 Rafał Miłecki wrote:
struct nphy_txgains { u16 txgm[2]; u16 pga[2]; u16 pad[2]; u16 ipa[2]; };
+struct nphy_iq_est { s32 iq0_prod; u32 i0_pwr; u32 q0_pwr; s32 iq1_prod;
+ u32 i1_pwr; u32 q1_pwr; };
So it seems I didn't notice this
On Tuesday 12 January 2010 20:38:56 Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
Uh, bigger one. This patch causes false warning:
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_rev2_cal_rx_iq’:
drivers/net/wireless/b43/phy_n.c:627: warning: large integer
On Monday 11 January 2010 03:38:53 Larry Finger wrote:
Yes, my fault. The specs are now corrected so that these statements are
((s8)((s[1] 8) 0x3F) 2) 2
I think that is right.
No it is not.
You need to do this:
(s8)(((s[1] 8) 0x3F) 2) 2
Alternatively add another pair of
On Monday 11 January 2010 22:13:31 Rafał Miłecki wrote:
2010/1/10 Michael Buesch m...@bu3sch.de:
On Sunday 10 January 2010 23:13:34 Rafał Miłecki wrote:
+ s32 results_min[4];
+ u8 vcm_final[4];
+ s32 results[4][4];
+ s32 miniq[4][2];
+ memset(results_min, 0, sizeof
On Monday 11 January 2010 23:27:18 Rafał Miłecki wrote:
Whoops, I should have explained what I mean. I am not sure what CFLAGS
make picks for compiled but I get:
CC [M] drivers/net/wireless/b43/phy_n.o
drivers/net/wireless/b43/phy_n.c: In function ‘b43_nphy_rev2_rssi_cal’:
On Sunday 10 January 2010 23:13:20 Rafał Miłecki wrote:
+ buf[0] += (s8)(((s[0] 0x3F) 2) 2);
+ buf[1] += (s8)s[0] 8) 0x3F) 2) 2);
+ buf[2] += (s8)(((s[1] 0x3F) 2) 2);
+ buf[3] += (s8)s[1] 8) 0x3F) 2) 2);
I suggest buf[3] +=
On Sunday 10 January 2010 23:13:34 Rafał Miłecki wrote:
+ s32 results_min[4];
+ u8 vcm_final[4];
+ s32 results[4][4];
+ s32 miniq[4][2];
+ memset(results_min, 0, sizeof(s32) * 4);
+ memset(vcm_final, 0, sizeof(u8) * 4);
+ memset(results, 0, sizeof(s32) * 4 * 4);
On Friday 08 January 2010 09:30:27 Rafał Miłecki wrote:
I need to implement
http://bcm-v4.sipsolutions.net/802.11/PHY/ClkFgc
Where I can put my
void b43_phy_clock_fgc(struct b43_wldev *dev, bool clock) { ... }
? Is end of phy_common.c file OK for this?
yes. Note that the 0x2 bit has
On Thursday 07 January 2010 00:22:11 Rafał Miłecki wrote:
W dniu 6 stycznia 2010 22:30 użytkownik Gábor Stefanik
netrolller...@gmail.com napisał:
On Wed, Jan 6, 2010 at 10:09 PM, Rafał Miłecki zaj...@gmail.com wrote:
diff --git a/drivers/net/wireless/b43/phy_lp.c
On Wednesday 06 January 2010 16:40:32 Rafał Miłecki wrote:
b43: N-PHY: implement b43_nphy_stay_carrier_search and it's calls
Hm, The phrase stay carrier earch doesn't make a lot of sense to me.
Is stray carrier search or something like that meant?
Not that I care much, but I'm just wondering if
On Wednesday 06 January 2010 19:18:39 Rafał Miłecki wrote:
Dude what is up with this e-mail data on your patches in the commit log?
That is way of encoding non-ASCII chars in mail header. You can find
info about this in RFC. That is =?UTF-8?B? prefix and base 64
encoded text.
That was
On Monday 04 January 2010 22:51:40 Oncaphillis wrote:
Did any of the patches for a device without a sprom make it
into the 2.6.33-rc2 ?
No we decided that the patches were not acceptable and need a rewrite towards
firmware loading mechanism.
Nobody's currently doing that, though.
--
On Monday 04 January 2010 23:34:19 Rafał Miłecki wrote:
W dniu 4 stycznia 2010 21:36 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
Next there is a lot of code after b43_nphy_workarounds(dev); call
that I can not recognize. Let's just take some lines for example:
On Monday 04 January 2010 01:10:32 Rafał Miłecki wrote:
Please, see table on:
http://bcm-v4.sipsolutions.net/ChipCommon
No I mean where does the specs say to _write_ to that register?
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
On Monday 04 January 2010 11:23:36 Rafał Miłecki wrote:
W dniu 4 stycznia 2010 11:03 użytkownik Michael Buesch m...@bu3sch.de
napisał:
On Monday 04 January 2010 01:10:32 Rafał Miłecki wrote:
Please, see table on:
http://bcm-v4.sipsolutions.net/ChipCommon
No I mean where does the specs
On Sunday 03 January 2010 22:30:27 Rafał Miłecki wrote:
Michael, you gave me some reviews of patches I was very glad to see. I
posted some (hopefully) corrected versions but didn't get your
response.
Can we expect you ACKing patches as well?
I post this question publicly as I may be not
On Sunday 03 January 2010 22:34:38 Rafał Miłecki wrote:
Also I need some help with:
//TODO: Set bit 0x40 in the Chip Control register (0x28)
could someone let me know how can I write to chip control register? Is
following correct?
tmp = b43_read16(dev, 0x28);
b43_write16(dev, 0x28, tmp
On Saturday 02 January 2010 17:33:53 Rafał Miłecki wrote:
--- a/drivers/net/wireless/b43/tables_nphy.h
+++ b/drivers/net/wireless/b43/tables_nphy.h
-extern const u8 b43_ntab_adjustpower0[];
+static const u8 b43_ntab_adjustpower0[];
Are you serious? o.O
Come on... You can do better ;)
--
On Monday 28 December 2009 05:49:14 Larry Finger wrote:
+ tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO_SHIFT);
This does not make any sense.
Did you mean:
+ tmp = ~(SSB_IMCFGLO_SERTO | SSB_IMCFGLO_REQTO);
+ tmp |= 3;
So you set
On Monday 28 December 2009 20:09:05 Larry Finger wrote:
I did get that wrong. The Broadcom code does the equivalent of
tmp = tmp ~0x77 | 3
Ok, so you need my version of the masking.
which is what my code ended up doing by accident, but REQ is set to zero.
Yeah, OK to me. It's a workaround
As I have said several times. I am not interested in fixing this. Just revert
the patch.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
On Wednesday 23 December 2009 11:34:39 Rafał Miłecki wrote:
W dniu 22 grudnia 2009 02:40 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
It's just compilation-tested as I don't own N-PHY device yet (should receive
one for Christmas). Not sure if we even support SSB used for N-PHY cards.
On Wednesday 23 December 2009 19:19:19 Larry Finger wrote:
ACK for the relocation of the tables.
Well, the _tables_ aren't actually relocated with that patch. The tables
are already in the tables_nphy.c file. You just relocate the functions that
upload
the tables.
So if you want to relocate the
On Monday 21 December 2009 22:31:10 Larry Finger wrote:
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3 slots in the
DMA header cache cross a page boundary. Such a situation is allowed on
my system, but it
On Monday 21 December 2009 23:02:39 Larry Finger wrote:
On 12/21/2009 03:47 PM, Michael Buesch wrote:
On Monday 21 December 2009 22:31:10 Larry Finger wrote:
Hi,
I placed a number of test prints in my system trying to find where a
DMA data error might occur. In doing so, I found that 3
On Monday 21 December 2009 23:20:06 Larry Finger wrote:
Here, it was slot 74 that crossed the page boundary. At 110 bytes per
every 2 slots, that works out to 4070 bytes for 0 - 73. From that, I
infer that the cache starts on a page boundary.
Yeah well. For you.
--
Greetings, Michael.
On Saturday 19 December 2009 07:26:10 Larry Finger wrote:
Michael,
As you may recall, I dumped writes to the PCI config space for both
b43 and the wl driver. I found that wl wrote to address 0x40. In
looking around other drivers, I found the following fragment in ipw2100:
/* We
On Saturday 19 December 2009 17:11:30 Larry Finger wrote:
On 12/19/2009 04:11 AM, Michael Buesch wrote:
And if you do a patch, don't put it into ssb. Put it into b43.
One further question about putting the patch into b43. Apparently,
register 0x40 is not preserved across a suspend/resume
On Sunday 13 December 2009 17:45:31 Albert Herranz wrote:
The b43 driver includes a capability mechanism that open source firmwares
(like OpenFWWF) can use to inform the driver about supported
characteristics.
The OpenFWWF firmware doesn't support yet QoS and reflects that via
its
On Thursday 10 December 2009 17:27:57 Larry Finger wrote:
If a user encounters the Fatal DMA Problem with a BCM43XX device, and
still wishes to use b43 as the driver, their only option is to rebuild
the kernel with CONFIG_B43_FORCE_PIO. This patch removes this option and
allows PIO mode to be
On Saturday 28 November 2009 18:12:20 Larry Finger wrote:
Thanks for testing the other patch. To try to test the differences,
I also dumped the PCI configuration writes and found one that wl does.
Please see if this one helps.
Larry
Index:
On Saturday 28 November 2009 19:03:30 Larry Finger wrote:
On my x86_64 system, I get the Fixing latency ... message printed out
just before the code writes 0x40 to PCI-E configuration register 0x0d
(PCI_LATENCY_TIMER). The wl driver does that same write on my machine.
Do you have any
On Sunday 29 November 2009 00:43:29 Larry Finger wrote:
Sorry about the problem with the previous try. This one does write the
PCI configuration the same as wl does.
Please see if this one helps.
Index: wireless-testing/drivers/ssb/pci.c
On Tuesday 24 November 2009 09:51:37 Oncaphillis wrote:
On 11/20/2009 12:12 PM, Michael Buesch wrote:
This patch adds a generic mechanism for overriding the SPROM mechanism
on devices without SPROM hardware.
There currently is a major problem with this:
It tries to deduce a MAC address
On Tuesday 24 November 2009 22:15:52 Chris Vine wrote:
On Tue, 24 Nov 2009 13:06:43 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
This E-mail is to summarize what I have learned to date.
The pm_qos change does nothing useful. It may have helped a little,
but the side effects are
On Monday 23 November 2009 02:34:09 Larry Finger wrote:
On 11/19/2009 03:24 PM, Michael Buesch wrote:
This rewrites the error handling policies in the TX status handler.
It tries to be error-tolerant as in try hard to not crash the machine.
It won't recover from errors (that are bugs
On Monday 23 November 2009 05:45:47 Larry Finger wrote:
On 11/19/2009 03:24 PM, Michael Buesch wrote:
This rewrites the error handling policies in the TX status handler.
It tries to be error-tolerant as in try hard to not crash the machine.
It won't recover from errors (that are bugs
On Monday 23 November 2009 12:00:15 Francesco Gringoli wrote:
Hi Michael,
so you can observe this behavior at your site. Do you mind describing
the exact configuration? Maybe this time I can reproduce this
behavior, as I tried everything to make it happen. I also asked Larry
one of
-by: Michael Buesch m...@bu3sch.de
---
Tested on BCM4306
Index: wireless-testing/drivers/ssb/main.c
===
--- wireless-testing.orig/drivers/ssb/main.c2009-11-06 21:45:29.0
+0100
+++ wireless-testing/drivers/ssb/main.c 2009-11
-by: Michael Buesch m...@bu3sch.de
Cc: sta...@kernel.org
---
Index: wireless-testing/drivers/ssb/sprom.c
===
--- wireless-testing.orig/drivers/ssb/sprom.c 2009-11-23 14:24:57.0
+0100
+++ wireless-testing/drivers/ssb/sprom.c
On Monday 23 November 2009 20:55:06 Larry Finger wrote:
The routine b43_is_hw_radio_enabled() has long been a problem.
For PPC architecture with PHY Revision 3, a read of the register
B43_MMIO_HWENABLED_LO will cause a CPU fault unless b43_status()
returns a value of 2 (B43_STAT_STARTED) (BUG
On Sunday 22 November 2009 19:11:52 Larry Finger wrote:
On 11/22/2009 11:52 AM, Michael Buesch wrote:
On Thursday 19 November 2009 22:24:29 Michael Buesch wrote:
This rewrites the error handling policies in the TX status handler.
It tries to be error-tolerant as in try hard to not crash
On Friday 20 November 2009 02:41:58 Oncaphillis wrote:
On 11/20/2009 12:46 AM, Oncaphillis wrote:
On 11/19/2009 06:44 PM, Michael Buesch wrote:
On Thursday 19 November 2009 16:41:12 Michael Buesch wrote:
Wait, that still can't work. I'll fix it soon...
Ok, here's the updated version
On Friday 20 November 2009 00:55:07 Larry Finger wrote:
On 11/18/2009 11:21 PM, William Bourque wrote:
Also, just saying, but it seems Larry's pm_qos_update_requirement
patch had some good effects; I can hardly get any connectivity without
it. With the patch, the wireless seems to be
On Friday 20 November 2009 11:29:20 Oncaphillis wrote:
Ok -- Some more details about my experience that it appears to be slow.
Note that there are several issues. First one being the sprom calibration
values being _wrong_ for your card. Second one is LP-PHY performance being
crappy in
general
Michael Buesch m...@bu3sch.de
+ * Copyright 2007-2009 Michael Buesch m...@bu3sch.de
*
* Licensed under the GNU/GPL. See COPYING for details.
*/
#include linux/pci.h
#include linux/ssb/ssb.h
+#include linux/etherdevice.h
+#include linux/jhash.h
#include ssb_private.h
@@ -36,6 +38,76
On Friday 20 November 2009 12:38:07 Florian Fainelli wrote:
Why not call once random_ether_addr instead of using some kind of hash? Is it
because you
want the same MAC from a reboot to another?
yes.
Ok, so for BCM63xx I would no longer have to declare my SPROM, fine.
No you still need to
On Thursday 19 November 2009 06:21:45 William Bourque wrote:
Michael Buesch wrote:
Enforce all device constraints on the descriptor memory region.
There are several constraints on the descriptor memory, as documented
in the specification. The current code does not enforce them
On Thursday 19 November 2009 12:07:30 Oncaphillis wrote:
So I'm at a loss here, but if someone comes up with a bright
idea to test or needs more informations I'm willing to test
the resulting code on my machine.
Erm, no. Can you please answer the questions that you didn't answer, yet?
Can you please try the following patch?
http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
On Thursday 19 November 2009 14:26:42 Oncaphillis wrote:
On 11/19/2009 01:49 PM, Michael Buesch wrote:
Can you please try the following patch?
http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch
That seems to freeze my kernel
On Thursday 19 November 2009 16:27:01 Michael Buesch wrote:
On Thursday 19 November 2009 14:26:42 Oncaphillis wrote:
On 11/19/2009 01:49 PM, Michael Buesch wrote:
Can you please try the following patch?
http://bu3sch.de/patches/wireless-testing/20091119-1349/patches/002-ssb-rewrite-sprom
On Thursday 19 November 2009 16:41:12 Michael Buesch wrote:
Wait, that still can't work. I'll fix it soon...
Ok, here's the updated version. Please test this:
http://bu3sch.de/patches/wireless-testing/20091119-1842/patches/002-ssb-rewrite-sprom-fallback-mechanism.patch
--
Greetings, Michael
1 - 100 of 1753 matches
Mail list logo
