On Mon, 2009-09-14 at 22:01 -0500, Larry Finger wrote:
> I tried it on the file above and got the following:
>
> fin...@larrylap:~/WAG54GX2> ~/sprom/b43_fwcutter.py
> src.GPL/driver/2.6.8.1/extra/wl.ko
> Firmware md5sum is 4f1218df93c23b4e27c83cb208031a1d...
> Extracting a0g0bsinitvals2 of length
Daniel Lenski wrote:
> On Thu, Sep 3, 2009 at 5:25 PM, Daniel Lenski wrote:
>> I have not found any other source of these, unfortunately. I am happy
>> to send the extracted firmware to developers off-list if desired.
>> Linksys's less-than-helpful GPL source code page gives no indication of
>> t
On Thu, Sep 3, 2009 at 5:25 PM, Daniel Lenski wrote:
> I have not found any other source of these, unfortunately. I am happy
> to send the extracted firmware to developers off-list if desired.
> Linksys's less-than-helpful GPL source code page gives no indication of
> the age or date of the vario
Michael Buesch wrote:
> Don't abuse wl->current_dev in the LED work for checking whether we're
> going down. Add an explicit variable.
> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> in various other places of the driver.
>
> Signed-off-by: Michael Buesch
This patc
Don't abuse wl->current_dev in the LED work for checking whether we're
going down. Add an explicit variable.
This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
in various other places of the driver.
Signed-off-by: Michael Buesch
---
Note to self: Don't try to safe a byte
On Monday 14 September 2009 23:01:33 Thomas Ilnseher wrote:
> The current verison of b43 uses "b43_phyop_switch_analog_generic" for A,
> G and LP phys.
>
> According to the spec, this is the wrong behaviour for the LP PHY
> (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore )
>
> While no pr
The current verison of b43 uses "b43_phyop_switch_analog_generic" for A,
G and LP phys.
According to the spec, this is the wrong behaviour for the LP PHY
(see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore )
While no problems on the x86 plattform where seen, this leads to a crash
on the BCM53
On Monday 14 September 2009 22:22:57 Thomas Ilnseher wrote:
> I can now confirm that the patch below DOES compile, and even works.
So can you send a version which conforms to our patch submission standards as
larry explained?
--
Greetings, Michael.
__
I can now confirm that the patch below DOES compile, and even works.
Here is the dmesg output on my router:
r...@openwrt:/tmp# dmesg
b43-phy1: Broadcom 5354 WLAN found (core revision 13)
b43-phy1 debug: Found PHY: Analog 6, Type 5, Revision 0
b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2
Thomas Ilnseher wrote:
> On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
>> Always send patches to John Linville, and CC linux-wireless.
> Ok, the last try ...
>
> As I've seen Gàbor's patch, I noticed that my previous patch was
> bullshit. This patch should work:
>
> (see: http://bcm-v4.
On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
> Always send patches to John Linville, and CC linux-wireless.
Ok, the last try ...
As I've seen Gàbor's patch, I noticed that my previous patch was
bullshit. This patch should work:
(see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore)
Always send patches to John Linville, and CC linux-wireless.
On Mon, Sep 14, 2009 at 9:35 PM, Thomas Ilnseher wrote:
> As I've seen Gàbor's patch, I noticed that my previous patch was
> bullshit. This patch should work:
>
> Signed-off-by: Thomas Ilnseher
>
> diff -uNr b/drivers/net/wireless/b43/
On Monday 14 September 2009 21:10:32 Thomas Ilnseher wrote:
> On Mo, 2009-09-14 at 20:51 +0200, Michael Buesch wrote:
> > On Monday 14 September 2009 20:44:54 Thomas Ilnseher wrote:
> > >
> > >
> >
> > *) Please inline the patch
> > *) Why do you rename b43_phyop_switch_analog_generic? It's "gen
On Monday 14 September 2009 21:10:04 Gábor Stefanik wrote:
> The generic analog switch routine is not correct for LP-PHY according
> to the latest specs. Implement the proper analog core switch routine.
>
> Signed-off-by: Gábor Stefanik
> ---
> diff --git a/drivers/net/wireless/b43/phy_lp.c
> b/
As I've seen Gàbor's patch, I noticed that my previous patch was
bullshit. This patch should work:
Signed-off-by: Thomas Ilnseher
diff -uNr b/drivers/net/wireless/b43/phy_lp.c
a/drivers/net/wireless/b43/phy_lp.c
--- b/drivers/net/wireless/b43/phy_lp.c 2009-09-14 06:14:18.0 +0200
+++ a/d
On Mo, 2009-09-14 at 21:10 +0200, Gábor Stefanik wrote:
> The generic analog switch routine is not correct for LP-PHY according
> to the latest specs. Implement the proper analog core switch routine.
>
> Signed-off-by: Gábor Stefanik
> ---
> diff --git a/drivers/net/wireless/b43/phy_lp.c
> b/dri
On Mo, 2009-09-14 at 20:51 +0200, Michael Buesch wrote:
> On Monday 14 September 2009 20:44:54 Thomas Ilnseher wrote:
> >
> >
>
> *) Please inline the patch
> *) Why do you rename b43_phyop_switch_analog_generic? It's "generic", because
>it works on the generic PHY0 MMIO register shadow.
It'
The generic analog switch routine is not correct for LP-PHY according
to the latest specs. Implement the proper analog core switch routine.
Signed-off-by: Gábor Stefanik
---
diff --git a/drivers/net/wireless/b43/phy_lp.c
b/drivers/net/wireless/b43/phy_lp.c
index 80da9c7..b0e127a 100644
--- a/dri
On Monday 14 September 2009 20:44:54 Thomas Ilnseher wrote:
>
>
*) Please inline the patch
*) Why do you rename b43_phyop_switch_analog_generic? It's "generic", because
it works on the generic PHY0 MMIO register shadow.
*) Please use b43_phy_mask and b43_phy_set.
--
Greetings, Michael.
diff -uNr compat-wireless-2009-09-14/drivers/net/wireless/b43/phy_a.c compat-wireless-2009-09-14.mod/drivers/net/wireless/b43/phy_a.c
--- compat-wireless-2009-09-14/drivers/net/wireless/b43/phy_a.c 2009-09-14 06:14:18.0 +0200
+++ compat-wireless-2009-09-14.mod/drivers/net/wireless/b43/phy_
Michael Buesch schrieb:
> On Monday 14 September 2009 20:35:42 Daniel Schmitt wrote:
>> Michael Buesch schrieb:
>>> On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote:
well, same issue:
ssb: Sonics Silicon Backplane found on PCI device :00:02.0
ssb: Core 0 found: ChipCommo
On Monday 14 September 2009 20:35:42 Daniel Schmitt wrote:
> Michael Buesch schrieb:
> > On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote:
> >> well, same issue:
> >> ssb: Sonics Silicon Backplane found on PCI device :00:02.0
> >> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vend
Michael Buesch schrieb:
> On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote:
>> well, same issue:
>> ssb: Sonics Silicon Backplane found on PCI device :00:02.0
>> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
>> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, ven
On Mon, Sep 14, 2009 at 7:42 PM, Michael Buesch wrote:
> On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote:
>> well, same issue:
>> ssb: Sonics Silicon Backplane found on PCI device :00:02.0
>> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
>> ssb: Core 1 found: IEEE
On Monday 14 September 2009 18:56:08 Daniel Schmitt wrote:
> well, same issue:
> ssb: Sonics Silicon Backplane found on PCI device :00:02.0
> ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
> ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)
> ssb: Core 2 foun
well, same issue:
ssb: Sonics Silicon Backplane found on PCI device :00:02.0
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)
ssb: Core 2 found: PCMCIA (cc 0x80D, rev 0x01, vendor 0x4243)
ssb: Core 3 found: V90
Daniel Schmitt wrote:
> Larry, I don't think that sprom_do_read is able to read _ANY_ valid data
> because if I do it today it results it
Is there any reason to suspect a timing issue? I'm not familiar with
your platform. If that is the issue, perhaps might try (my mailer will
mangle this, but you
Gábor Stefanik wrote:
> On Sun, Sep 13, 2009 at 7:05 PM, Daniel Schmitt
> wrote:
>> Hello Group,
>>
>> I posted a few days ago my problems with this WLAN minipci card:
>>
>> Linux OpenWrt 2.6.28.10 #5 Thu Sep 10 20:36:33 CEST 2009 armv5teb unknown
>> 00:02.0 0280: 14e4:4325 (rev 02)
>> Su
Larry, I don't think that sprom_do_read is able to read _ANY_ valid data
because
if I do it today it results it
r...@openwrt:/# insmod ssb
ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x02, vendor 0x4243)
ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x04, vendor 0x4243)
ssb: Core 2 found: PCMCI
29 matches
Mail list logo
